Re: What is IEANTRTR in Authorized Assembler Services Reference?

[Jon Perryman]

On Sun, 14 Apr 2024 00:11:28 +0300, Binyamin Dissen 
 wrote:

>I was looking to see if this was supported in 2.4, but didn't find it

IBM guarantees upward compatibility but not backward. You must always assemble 
your product with your lowest supported libraries (e.g. 2.4 AMACLIB, AMODGEN, 
MACLIB, MODGEN) otherwise the generated code may not be compatible with lower 
releases.

I believe I used name tokens in z/OS 1.8 but your minimum release libraries are 
you guide to which macro's are supported..

>This macro does not need any authorization.

Some macros in the authorized assembler macro book don't require running 
authorized but are affected if you are running authorized. Name tokens is one 
of those. Name tokens are useful in all environments (including unauthorized) 
but when used in an authorized environment, you will want them secured 
otherwise you may have a security exposure.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Wayne Bickerdike]

VSE JCL. First time I had to use it...Well all the DLBLS before the EXEC.
Actually more logical.

The O/S? We could run a production CICS region on a 1 MIP machine. That's
tight. (and a Meg of main).

On Mon, Apr 15, 2024 at 11:29 AM Wayne Bickerdike  wrote:

> If there are embedded ./ IEBUPDTE in the JCL, I write a .# ADD card as
> the header and then use my PUTPDS REXX code.
>
> The odds of a .# ADD appearing I guesstimate as nil.
>
> Yes, it's annoying but really, who cares?
>
> On Mon, Apr 15, 2024 at 10:37 AM Paul Gilmartin <
> 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Sun, 14 Apr 2024 19:47:38 -0400, Steve Thompson wrote:
>>
>> >JES3 is not retarded.
>> >
>> I may have judged hastily from such as that the OUTPUT JCL statement
>> came to JES2 before JES3.  You could pay extra to not get the feature.
>>
>> >JES3 has this:
>> >//*DATASET parameters.
>> >
>> >//*ENDDATASET
>> >
>> Those look like comments.  I guess it provides a sort of compatibility
>> in that JES2 will ignore them.  At the cost of making it harder to
>> detect and report typos.
>>
>> Can the delimiter be changed to allow such lines within instream data?
>>
>>
>> >This is what the z/OS MVS JCL REF has for the parameters:
>> >   ...
>> >//*DATASET DDNAME=ddname[,parameter]...
>>
>> >This allows one to put that data in-stream, define what DD will
>> >be using it. And then the JOB Step that gets it, the data is
>> >encapsulated better than JES2 does it.
>> >
>> I see little use in the feature.  But if I don't like it, or dln't
>> understand it, I don't have to use it.
>>
>> >So I think this can handle the problem of "IEBUPDTE".
>> >
>> No.  The problem is not in JES[23], but in IEBUPDTE, which
>> has nothing like a DLM= parm which would allow data lines
>> resembling IEBU{DtE commands to appear instream.
>>
>> --
>> Thanks,
>> gil
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> Wayne V. Bickerdike
>
>

-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Wayne Bickerdike]

If there are embedded ./ IEBUPDTE in the JCL, I write a .# ADD card as
the header and then use my PUTPDS REXX code.

The odds of a .# ADD appearing I guesstimate as nil.

Yes, it's annoying but really, who cares?

On Mon, Apr 15, 2024 at 10:37 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 14 Apr 2024 19:47:38 -0400, Steve Thompson wrote:
>
> >JES3 is not retarded.
> >
> I may have judged hastily from such as that the OUTPUT JCL statement
> came to JES2 before JES3.  You could pay extra to not get the feature.
>
> >JES3 has this:
> >//*DATASET parameters.
> >
> >//*ENDDATASET
> >
> Those look like comments.  I guess it provides a sort of compatibility
> in that JES2 will ignore them.  At the cost of making it harder to
> detect and report typos.
>
> Can the delimiter be changed to allow such lines within instream data?
>
>
> >This is what the z/OS MVS JCL REF has for the parameters:
> >   ...
> >//*DATASET DDNAME=ddname[,parameter]...
>
> >This allows one to put that data in-stream, define what DD will
> >be using it. And then the JOB Step that gets it, the data is
> >encapsulated better than JES2 does it.
> >
> I see little use in the feature.  But if I don't like it, or dln't
> understand it, I don't have to use it.
>
> >So I think this can handle the problem of "IEBUPDTE".
> >
> No.  The problem is not in JES[23], but in IEBUPDTE, which
> has nothing like a DLM= parm which would allow data lines
> resembling IEBU{DtE commands to appear instream.
>
> --
> Thanks,
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Steve Thompson]

JES2 also has /* commands, such as:

/*JOBPARM
/*MESSAGE
/*NETACCT
/*NOTIFY
/*OUTPUT
/*PRIORITY
/*ROUTE
etc.


So I would imagine those look like comments to you.

MVS has JCL so does VSE. Each of them has a "spooler" system 
(JES2|JES3 for MVS and POWER for DOS type systems last I did a 
DOS/VSE-ESA migration to z/OS such as

* $$ SLI xxx   ).


But depending on whether or not you have JES3 installed and/or 
JES2 installed (JES3 had to be the PRIMARY subsystem, JES2 can be 
secondary) would determine if //*MAIN (and such) was just a 
comment or directed the JES3 system to do something.


JES3 also has a command to cause a JOB to run on a specific 
"LPAR" (Back in the day, CEC).


//*MAIN says which MVS system(s) to select from to schedule this 
JOB to run/execute.


You should really look at a JCL REF manual. All of this is 
documented there. But the JES3 DOC may be gone. I don't know when 
IBM will (or already has) pulled the JES3 JCL doc (z/OS 2.4 has 
it). I haven't needed (yet) to get a full copy of the 3.1 manuals 
to look at new stuff.


Steve Thompson


On 4/14/2024 8:36 PM, Paul Gilmartin wrote:

On Sun, 14 Apr 2024 19:47:38 -0400, Steve Thompson wrote:


JES3 is not retarded.


I may have judged hastily from such as that the OUTPUT JCL statement
came to JES2 before JES3.  You could pay extra to not get the feature.


JES3 has this:
//*DATASET parameters.

//*ENDDATASET


Those look like comments.  I guess it provides a sort of compatibility
in that JES2 will ignore them.  At the cost of making it harder to
detect and report typos.

Can the delimiter be changed to allow such lines within instream data?



This is what the z/OS MVS JCL REF has for the parameters:
   ...
//*DATASET DDNAME=ddname[,parameter]...
This allows one to put that data in-stream, define what DD will
be using it. And then the JOB Step that gets it, the data is
encapsulated better than JES2 does it.


I see little use in the feature.  But if I don't like it, or dln't
understand it, I don't have to use it.


So I think this can handle the problem of "IEBUPDTE".


No.  The problem is not in JES[23], but in IEBUPDTE, which
has nothing like a DLM= parm which would allow data lines
resembling IEBU{DtE commands to appear instream.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Paul Gilmartin]

On Sun, 14 Apr 2024 19:47:38 -0400, Steve Thompson wrote:

>JES3 is not retarded.
>
I may have judged hastily from such as that the OUTPUT JCL statement
came to JES2 before JES3.  You could pay extra to not get the feature.

>JES3 has this:
>//*DATASET parameters.
>
>//*ENDDATASET
> 
Those look like comments.  I guess it provides a sort of compatibility
in that JES2 will ignore them.  At the cost of making it harder to
detect and report typos.

Can the delimiter be changed to allow such lines within instream data?


>This is what the z/OS MVS JCL REF has for the parameters:
>   ...
>//*DATASET DDNAME=ddname[,parameter]...

>This allows one to put that data in-stream, define what DD will
>be using it. And then the JOB Step that gets it, the data is
>encapsulated better than JES2 does it.
>
I see little use in the feature.  But if I don't like it, or dln't
understand it, I don't have to use it.

>So I think this can handle the problem of "IEBUPDTE".
>
No.  The problem is not in JES[23], but in IEBUPDTE, which
has nothing like a DLM= parm which would allow data lines
resembling IEBU{DtE commands to appear instream.

-- 
Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Steve Thompson]

JES3 is not retarded.

JES3 has this:

//*DATASET parameters.

//*ENDDATASET

This is what the z/OS MVS JCL REF has for the parameters:

//*DATASET DDNAME=ddname[,parameter]...
The parameters are:
    MODE= {E}
          {C}
    J= {YES}
   {NO }
    CLASS= {NO }
   {MSGCLASS}
   {class }



This allows one to put that data in-stream, define what DD will 
be using it. And then the JOB Step that gets it, the data is 
encapsulated better than JES2 does it.


So I think this can handle the problem of "IEBUPDTE".

JES3 had lots of interesting features. I noticed MVS getting 
those features as we were moving towards SYSPLEX.


Steve Thompson

On 4/14/2024 12:30 PM, Paul Gilmartin wrote:

On Sun, 14 Apr 2024 11:48:02 -0400, Steve Thompson wrote:


In a JES2 environment, DLM= can be up to and including 8
characters (JES3 is limited to 2, not sure of JES3+).


Why is JES3 so retarded?  Useful features tend to be added to
JES2 earlier than JES3.


In that case, what odds are there of coming up with a safe string?


Almost certainty for any reasonable file size.  The interesting
question then is, "What's the most efficient way to discovedr
a safe string?"

However, IEBUPDTE has no sort of DLM option, so there's
no way to protect data lies beginning with with "./"  It's
puzzling that the IEBUPDTE designers never foresaw that
problem.  Consider, letting the Devil provide the test case:

/*Rexx
./ADD perverse comment  */
say 'Hello, World!'



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Paul Gilmartin]

On Sun, 14 Apr 2024 18:06:01 +, Lennie Bradshaw wrote:

>Paul Gilmartin said,
>>> And no DLM is safe to use with instream XMIT output. <<
>
>True. However, for any given stream there is ahigh likelihood of finding a 2 
>char symbols that would work for that stream. I wrote a program to scan files 
>to find a suitable delimiter string to use some years back. I've lost it now 
>of course!
> 
Which doesn't address the problem of IEBUPDTE when a data record
begins with "./"/

Does anyone claim it's possible?

As for finding a delimiter for JCL, I'd SORT UNIQUE on columns 1-2;
inspect the median value.  If it's high, iterate using the top half;
if low, iterate using the bottom half.


>-Original Message-
>From:  Paul Gilmartin
>Sent: 14 April 2024 14:04
>
>On Sat, 13 Apr 2024 20:01:50 -0500, Mike Schwab wrote:
>
>>You nan set it up for a //SYSIN DD DATA,DLM='??' and add the
>>'??'
>>Card at the end.
>> 
>That's not enough.  If the input PDS contains a member with a line beginning 
>with "./", which is likely in JCL with instream data, IEBUPDTE will improperly 
>treat it as a command, not data.
>
>A similar problem arises if a data line begins with "??".
>
>And no DLM is safe to use with instream XMIT output.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Tony Harminc]

On Sun, 14 Apr 2024 at 14:06, Lennie Bradshaw 
wrote:

> Paul Gilmartin said,
> >> And no DLM is safe to use with instream XMIT output. <<
>
> True. However, for any given stream there is ahigh likelihood of finding a
> 2 char symbols that would work for that stream. I wrote a program to scan
> files to find a suitable delimiter string to use some years back. I've lost
> it now of course!
>

But of course that means you have to pre-scan the data. Yet another
processing stage.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Lennie Bradshaw]

Paul Gilmartin said,
>> And no DLM is safe to use with instream XMIT output. <<

True. However, for any given stream there is ahigh likelihood of finding a 2 
char symbols that would work for that stream. I wrote a program to scan files 
to find a suitable delimiter string to use some years back. I've lost it now of 
course!

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 14 April 2024 14:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ./ ADD - which utility?

On Sat, 13 Apr 2024 20:01:50 -0500, Mike Schwab wrote:

>You can set it up for a //SYSIN DD DATA,DLM='??' and add the
>'??'
>Card at the end.
> 
That's not enough.  If the input PDS contains a member with a line beginning 
with "./", which is likely in JCL with instream data, IEBUPDTE will improperly 
treat it as a command, not data.

A similar problem arises if a data line begins with "??".

And no DLM is safe to use with instream XMIT output.



>On Sat, Apr 13, 2024 at 6:52 PM Paul Gilmartin wrote:
>>
>> On Sun, 14 Apr 2024 08:34:30 +1000, Wayne Bickerdike wrote:
>>
>> >I have some REXX code that extracts all members of a PDS and writes 
>> >it to a sequential file. Each member extracted is prefixed with the 
>> >./ADD card with the original member name. Handy for moving a PDS to another 
>> >system.
>> >IEBUPDTE was the utility of choice when all we had was a card punch 
>> >and card reader. (1975).
>> >
>> Have you just rediscovered IEBPTPCH?
>>
>> How does this work if your input PDS is a JCL library containing some 
>> jobs with IEBUPDTE steps with instream commands?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Paul Gilmartin]

On Sun, 14 Apr 2024 11:48:02 -0400, Steve Thompson wrote:

>In a JES2 environment, DLM= can be up to and including 8
>characters (JES3 is limited to 2, not sure of JES3+).
>
Why is JES3 so retarded?  Useful features tend to be added to
JES2 earlier than JES3.

>In that case, what odds are there of coming up with a safe string?
> 
Almost certainty for any reasonable file size.  The interesting
question then is, "What's the most efficient way to discovedr
a safe string?"

However, IEBUPDTE has no sort of DLM option, so there's
no way to protect data lies beginning with with "./"  It's
puzzling that the IEBUPDTE designers never foresaw that
problem.  Consider, letting the Devil provide the test case:

/*Rexx
./ADD perverse comment  */
say 'Hello, World!'

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM key management products

[Phil Smith III]

Charles wrote:
>When I was doing security presentations as part of my job one of the
>"controversies" I ran into was that the supposed percentage of insider
>attacks is all over the place. I used to see 85% in one set of
>statistics and nearly zero in others. I have no independent knowledge.

My point is that most insider attacks are not going to also exploit some 
cross-LPAR weakness: they're going to exploit some access. And if you have 
access, then data set encryption doesn't add any security.

Again, Swiss cheese--it's not zero added value, just IMHO relatively minor. The 
insider attack is both better and worse than the external attack: better 
because they're presumably more quick and opportunistic--insiders would be less 
likely to hammer away at something for months trying to find a way in, I 
expect; worse because they're likely more targeted--the insider has a higher 
probability of knowing where the crown jewels are.

Data set encryption has its place and adds some value. What I resist is the 
all-too-common "We encrypted some data sets, so now we're safe". No, what 
you've done is added a SMALL amount of additional protection. All that data is 
in the clear whenever it's used, and that represents significant risk. If you 
can work with it in its protected state, that risk is dramatically reduced.

>I see it as a real possibility:
>"It's only a sandbox system, so we pretty much give developers
>whatever access they say they need."

Ibid.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Steve Thompson]

In a JES2 environment, DLM= can be up to and including 8 
characters (JES3 is limited to 2, not sure of JES3+).


In that case, what odds are there of coming up with a safe string?

Just asking.

Steve Thompson

On 4/14/2024 9:04 AM, Paul Gilmartin wrote:

On Sat, 13 Apr 2024 20:01:50 -0500, Mike Schwab wrote:


You can set it up for a //SYSIN DD DATA,DLM='??' and add the
'??'
Card at the end.


That's not enough.  If the input PDS contains a member with a line
beginning with "./", which is likely in JCL with instream data,
IEBUPDTE will improperly treat it as a command, not data.

A similar problem arises if a data line begins with "??".

And no DLM is safe to use with instream XMIT output.




On Sat, Apr 13, 2024 at 6:52 PM Paul Gilmartin wrote:

On Sun, 14 Apr 2024 08:34:30 +1000, Wayne Bickerdike wrote:


I have some REXX code that extracts all members of a PDS and writes it to a
sequential file. Each member extracted is prefixed with the ./ADD card with
the original member name. Handy for moving a PDS to another system.
IEBUPDTE was the utility of choice when all we had was a card punch and
card reader. (1975).


Have you just rediscovered IEBPTPCH?

How does this work if your input PDS is a JCL library containing some
jobs with IEBUPDTE steps with instream commands?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Paul Gilmartin]

On Sun, 14 Apr 2024 09:35:00 -0400, David Spiegel  wrote:

>Hi Gil,
>Please see PDSLOAD (CBT File 093).
> 
This appears to be a companion to  OFFLOAD:


which says:
...  If the program detects IEBUPDTE control cards in the member of the 
PDS, the './' identifiers of the member records are altered to '><'.  

That relocates the problem without solving it for the case in which
a member contains both lines beginning with './' and both lines beginning
with ''><'. 

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[David Spiegel]

Hi Gil,
Please see PDSLOAD (CBT File 093).

Regards,
David

On 2024-04-14 09:04, Paul Gilmartin wrote:

On Sat, 13 Apr 2024 20:01:50 -0500, Mike Schwab wrote:


You can set it up for a //SYSIN DD DATA,DLM='??' and add the
'??'
Card at the end.


That's not enough.  If the input PDS contains a member with a line
beginning with "./", which is likely in JCL with instream data,
IEBUPDTE will improperly treat it as a command, not data.

A similar problem arises if a data line begins with "??".

And no DLM is safe to use with instream XMIT output.




On Sat, Apr 13, 2024 at 6:52 PM Paul Gilmartin wrote:

On Sun, 14 Apr 2024 08:34:30 +1000, Wayne Bickerdike wrote:


I have some REXX code that extracts all members of a PDS and writes it to a
sequential file. Each member extracted is prefixed with the ./ADD card with
the original member name. Handy for moving a PDS to another system.
IEBUPDTE was the utility of choice when all we had was a card punch and
card reader. (1975).


Have you just rediscovered IEBPTPCH?

How does this work if your input PDS is a JCL library containing some
jobs with IEBUPDTE steps with instream commands?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ./ ADD - which utility?

[Paul Gilmartin]

On Sat, 13 Apr 2024 20:01:50 -0500, Mike Schwab wrote:

>You can set it up for a //SYSIN DD DATA,DLM='??' and add the
>'??'
>Card at the end.
> 
That's not enough.  If the input PDS contains a member with a line
beginning with "./", which is likely in JCL with instream data,
IEBUPDTE will improperly treat it as a command, not data.

A similar problem arises if a data line begins with "??".

And no DLM is safe to use with instream XMIT output.



>On Sat, Apr 13, 2024 at 6:52 PM Paul Gilmartin wrote:
>>
>> On Sun, 14 Apr 2024 08:34:30 +1000, Wayne Bickerdike wrote:
>>
>> >I have some REXX code that extracts all members of a PDS and writes it to a
>> >sequential file. Each member extracted is prefixed with the ./ADD card with
>> >the original member name. Handy for moving a PDS to another system.
>> >IEBUPDTE was the utility of choice when all we had was a card punch and
>> >card reader. (1975).
>> >
>> Have you just rediscovered IEBPTPCH?
>>
>> How does this work if your input PDS is a JCL library containing some
>> jobs with IEBUPDTE steps with instream commands?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM key management products

[Radoslaw Skorupka]

W dniu 12.04.2024 o 22:57, Tony Harminc pisze:

On Fri, 12 Apr 2024 at 12:22, Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:


[...]
I personally am still having a hard time wrapping my head around the “real
benefit” of dataset encryption.   Everyone who has READ or more access to
the dataset, must also be permitted to the Key.   Those same people are
still able to copy/print/steal that data.So who does that leave?
  Those that are not permitted to the dataset, and those who administer the
storage.Those that don’t have access to the dataset aren’t going to get
the data, encrypted or not.   Those who administer the storage usually have
access to move/manage the installations data.These are the people who
dataset encryption is protecting against.   That is a very small population
to go to this effort on.


I think this is analogous to "Why do airline pilots have to go through
security at the airport? After all, we trust them with our lives when
they're flying the plane."  And of course the answer is that the security
check is applied to everyone because it catches people who *look* like
airline pilots and are carrying a bomb. Or are real pilots under duress
because someone's got their child, etc. etc. etc.

Yes, storage administrators are a small population, but their credentials
can be compromised as much as anyone else's, and then you're not dealing
with rogue storage admins but with criminal (or goverment or whatever)
actors. And storage admins (or their credentials) may well make a better
target than those of application users because the admins have much broader
access to data.


To complement, storage admins are NOT the only group affected.
RACF is not working outside of z/OS system image, which could mean the 
following:

- volumes are accessible from other LPAR/system/RACF realm.
- DASD array was connected to another CPC. What CPC? In my server room? 
The CPC connected via DWDM, etc.


IMHO the worst assumption is "we have rules which are strictly 
followed". Starting from "RACF db cannot be read by anyone".


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sv: ./ ADD - which utility?

Thanks, I found the JCL and run the jobs successfully. 

(I had several large files with ./ ADD and the data stacked after, it was one 
file per PDS. Had I thought I really would need them I had made smaller files 
and the JCL separate.)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN