Rob Schramm wrote:
>I am personnally waiting for the UserID "passphrase" something in the
>64-128 character range..
You get 108 characters to play with in "classic" RACF: up to 8 for the user
ID and up to 100 for the (mixed case) passphrase. Passphrases are available
with the z/OS Security
Hi Tony,
If RPG has specific BLKSIZE maximums, then SMS autochanging BLKSIZE could cause
this behaviour.
Validate dataset attributes.
On Mon, 23 Jul 2018 12:12:52 -0400, Tony Thigpen wrote:
>IEC020I 001-4,HSR003B,STEP0017,STYWRK,1818,HKYP05,
>IEC020I PROD.HKY.WORK.HSR003B.WK1.S050
>IEC020I
EXACTLY
CharlesSent from a mobile; please excuse the brevity.
Here, I'll trust IBM's Statement of Integrity. Nanograms, not tons,
and those known are quietly and rapidly being repaired.
Social engineering, "magic" SVCs, update access to authorized libraries, ...
do not contradict tne
On Mon, 23 Jul 2018 21:52:53 -0400, Rob Schramm wrote:
>TSO is NOT a good example. The flipping in and out of authorization has
>been discussed ad infinitum. Pick something else for discussion points
>
I consider TSO a good example in that it illustrates a principle that untrusted
users should
TSO is NOT a good example. The flipping in and out of authorization has
been discussed ad infinitum. Pick something else for discussion points
unless we are diverging into what's possible, and there are tons of
inadvisable ways to break mvs integrity.
Rob Schramm
On Mon, Jul 23, 2018, 9:47 PM
On Mon, 23 Jul 2018 22:53:59 +, Seymour J Metz wrote:
>I hope not, and IBM will take an APAR if it's possible. The one exception is
>that an unauthorized TSO command can ask the TMP to run an authorized command
>(or service), but the TMP will set the unauthorized command non-dispatchable
Yeah, I hate it when they steal my eyeballs and my fingertips and flat get
away with it.
sas
On Mon, Jul 23, 2018 at 2:12 PM, Rob Schramm wrote:
> I am personnally waiting for the UserID "passphrase" something in the
> 64-128 character range..
>
> with an optional cursory DNA scanner with
Yes, and any code that runs in supervisor state (certain exits, for example)
could (using an unapproved and undocumented but easy-to-deduce technique)
presumably change an address space from not-authorized to authorized -- but
the exit code would have to be installation-permitted.
There should be
On Mon, 23 Jul 2018 22:46:52 GMT "esst...@juno.com" wrote:
:>Im sure there is an Integrity exposure with these scenarios.
:>1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
No.
.
:>2)Can a Problem Program attach a subtask (with the DCB parameter) that is
authorized ? The
Actually, you can, but the unauthorized code can't run while the authorized
code is running and the unauthorized code can only invoke the authorized code
that IBM or the installation allows. Think TSO,
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
Jobsteps are authorized, not subtasks. The jobstep is either authorized or
it is not (in the scenarios you describe below).
There is no (supported, official, "z/OS") way to transition from
non-authorized to authorized. You cannot "become authorized" except at
jobstep initiation time.
Charles
I hope not, and IBM will take an APAR if it's possible. The one exception is
that an unauthorized TSO command can ask the TMP to run an authorized command
(or service), but the TMP will set the unauthorized command non-dispatchable
for the duration.
--
Shmuel (Seymour J.) Metz
Don't be so sure of the integrity exposure.
In cases 1 and 2 I know the called program does not run authorized.
Case 3 I would have to investigate, but I bet it is not possible.
Chris Blaicher
Technical Architect
Syncsort, Inc.
-Original Message-
From: IBM Mainframe Discussion List
Hi,
.
Im sure there is an Integrity exposure with these scenarios.
1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
.
2)Can a Problem Program attach a subtask (with the DCB parameter) that is
authorized ? The dcb is not in the steplib concatenation.
.
3)Can a Problem
Nothing breaks with JOBLIB, it just causes confusion. This thread exhibit A.
I think someone changed a LRECL/BLKSIZE..
On Tue, Jul 24, 2018 at 7:29 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Tue, 24 Jul 2018 06:40:30 +1000, Wayne Bickerdike wrote:
>
> >So
On Mon, 23 Jul 2018 16:29:37 -0500, Paul Gilmartin wrote:
>On Tue, 24 Jul 2018 06:40:30 +1000, Wayne Bickerdike wrote:
>
>>Going back at least 40 years, one golden rule. Don't use JOBLIB..
>>
>Hadn't heard. What breaks?
Nothing, AFAIK.
--
Tom Marchant
On Tue, 24 Jul 2018 06:40:30 +1000, Wayne Bickerdike wrote:
>So it's a PDSE.
>
What breaks with PDSE?
o Well, EXCP, I suppose.
o Stashing a TTR to use in a later job (STEP.
But why do such things?
>Going back at least 40 years, one golden rule. Don't use JOBLIB..
>
Hadn't heard. What
On Mon, 23 Jul 2018 16:32:29 -0400, Tony Thigpen wrote:
>Data Set Name . . . : TST.COMPILE.LIBRARY
>
>General Data Current Allocation
> Management class . . : **None** Allocated cylinders : 434
> Storage class . . . : **None** Allocated extents . : 1
>
I wouldn't go so far as to say don't use JOBLIB :)
But, I'll bet that whatever level of RPG this is, doesn't fully understand
PSE/E
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Wayne Bickerdike
> Sent: Monday, July 23,
So it's a PDSE.
Going back at least 40 years, one golden rule. Don't use JOBLIB..
On Tue, Jul 24, 2018 at 6:32 AM, Tony Thigpen wrote:
> Data Set Name . . . : TST.COMPILE.LIBRARY
>
> General Data Current Allocation
> Management class . . : **None**
Data Set Name . . . : TST.COMPILE.LIBRARY
General Data Current Allocation
Management class . . : **None** Allocated cylinders : 434
Storage class . . . : **None** Allocated extents . : 1
Volume serial . . . : HKYSY0 Maximum dir. blocks : NOLIMIT
Type 80 records do not exactly have subtypes. They have events and qualifiers,
which are similar in concept to a certain extent, but at a different offset in
the record.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of
Taking wagers that it's a PDS/E?
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tony Thigpen
> Sent: Monday, July 23, 2018 11:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC020I 001-4 question
>
> Found something. Doing
Found something. Doing more research, but thought I would provide the
info in case it rings anyone's bell.
The only jobs that have this problem, also have a test library in the
JOBLIB. If the test library is removed, then the RPG works fine.
Fails:
//JOBLIB DD
The file out on his webpage shows that DAF hasn't been updated since 2010. I
know that recently, I was seeing invalid smf 80 records, but it turns out they
are newer subtypes (x'1BB'). I just repeated a couple lines of code, that
basically says it's ok, but doesn't process the data.
I see in
I am personnally waiting for the UserID "passphrase" something in the
64-128 character range..
with an optional cursory DNA scanner with life sign detection.
Rob Schramm
On Mon, Jul 23, 2018 at 6:17 AM John Eells wrote:
> As the owner of the TSO/E plan at the time, I was stunned when SHARE
On 7/23/2018 12:27 AM, Lizette Koehler wrote:
I was reading through the code for DAF (File 94) on CBTTAPE.ORG.
I was wondering if there are new fields, who might be updating this utility?
In Type 42 - I see a new subtype 26 for NFS.
See below
Tony Thigpen
Lizette Koehler wrote on 07/23/2018 01:43 PM:
Could they try another utility like SORT on the file to see if the same error
occurs?
Will try this
When the error occurs, do they rerun the job and still get the same error?
If fails during the rerun. The only way they
Could they try another utility like SORT on the file to see if the same error
occurs?
When the error occurs, do they rerun the job and still get the same error?
Is it always shop written programs that get the IEC020I error?
Do these programs have a common subroutine reading files?
Does the
If you have StarTool (or CBT version of PDS command) you can to a 'verify'
against the load library. Verify reads (and loads) all members of a PDS and
reports stats like largest block encountered. It also reports on any I/O or
fetch errors.
.
.
J.O.Skip Robinson
Southern California Edison
> they can not get the program to ever run correctly again, even after
re-compiling
If the problem is the dataset or a dataset/program mismatch then recompiling
the program will not help, of course.
Charles
-Original Message-
From: IBM Mainframe Discussion List
Wild guess:
I found this explanation for S001-4 on some web sites:
S001-4 AbendInput file record length is not equal to the length stated
in the DD or the FD. Wrong length record. IO error, damaged tape, device
malfunction. With disk, reading a dataset that was allocated but never
written
I have a site with a bunch of old RPG programs. Lately, it seems that
sometimes the get the following. Once it happens, they can not get the
program to ever run correctly again, even after re-compiling.
IEC020I 001-4,HSR003B,STEP0017,STYWRK,1818,HKYP05,
IEC020I PROD.HKY.WORK.HSR003B.WK1.S050
Barbara Nitz wrote:
On Mon, 23 Jul 2018 06:05:43 -0400, John Eells wrote:
Over the past few years, COBOL and PL/I have added support for Product
Registration Services, and can be disabled using IFAPRFxx entries. XL
C/C++ is a feature of z/OS and can similarly be enabled or disabled with
As the owner of the TSO/E plan at the time, I was stunned when SHARE
told us this was the top priority for TSO/E. We pushed back. We said
"what about longer IDs that map into the 7-character namespace instead"?
"What about these other TSO/E requirements"? But those who maintained
this was
On Mon, 23 Jul 2018 06:05:43 -0400, John Eells wrote:
>Over the past few years, COBOL and PL/I have added support for Product
>Registration Services, and can be disabled using IFAPRFxx entries. XL
>C/C++ is a feature of z/OS and can similarly be enabled or disabled with
>IFAPRDxx.
>
>This does
Over the past few years, COBOL and PL/I have added support for Product
Registration Services, and can be disabled using IFAPRFxx entries. XL
C/C++ is a feature of z/OS and can similarly be enabled or disabled with
IFAPRDxx.
This does not cover everything, of course, but it's a start.
That's right. By add new data to I meant adding new datasets. I wanted to use
RACF for the access part (which would have covered the changing and extending
data).
Apparently that can only be performed with the RACF exit, but that's not very
elegant.
Brian
38 matches
Mail list logo
