Re: Equivalent REXX ALLOCATE command compared to JCL

Paul Gilmartin

unread,

Apr 16, 2012, 11:48:09 AM4/16/12

to

On Apr 16, 2012, at 09:30, Ward Able, Grant wrote:
>
> I wish to build some TSO ALLOCATE statements for a datasetlist concatenating a number of files. But the twist is, I want to use the UNIT=AFF=SYSUT1 parameter on all except the first DD statement. I wish to dynamically allocate a number of files then call IEBGENER in order to copy several input files into a single output file. I am building the list of datasets, but then the allocation command is:
>
> address tso "ALLOC F(SYSUT1) DA("dslst") SHR"
>
Not straightforward. My approach would be to allocate
the first data set; open it; scrape the unit from the
TIOT (or must one go to the UCB?); allocate the others,
then use the CONCAT option.

But DYNALLOC might fail with UNIT in use. It certainly
won't let me allocate multiple NEW data sets on a sigle
volume.

There's lots of room for Requirements for new DYNALLOC
facilities here.

> The ALLOCATE command does not seem to be able to do what I require, which is to emulate this JCL:
> //SYSUT1 DD DSN=CICST.TMONARCH.G1994V00,DISP=SHR
> // DD DSN=CICST.TMONARCH.G1995V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1996V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1997V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1998V00,DISP=SHR,
> // UNIT=AFF=SYSUT1

My sympathies,
gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

John P Kalinich

unread,

Apr 16, 2012, 11:49:45 AM4/16/12

to

You could execute Rexx in batch (IRXJCL) and allocate via JCL with
UNIT=AFF=.

Regards,
John K

Grant Ward of the TSO REXX Discussion List <TSO-...@vm.marist.edu> wrote
on 04/16/2012 10:30:09 AM:

> I wish to build some TSO ALLOCATE statements for a datasetlist
> concatenating a number of files. But the twist is, I want to use the
> UNIT=AFF=SYSUT1 parameter on all except the first DD statement. I
> wish to dynamically allocate a number of files then call IEBGENER in
> order to copy several input files into a single output file. I am
> building the list of datasets, but then the allocation command is:
>
> address tso "ALLOC F(SYSUT1) DA("dslst") SHR"
>

> The ALLOCATE command does not seem to be able to do what I require,
> which is to emulate this JCL:
> //SYSUT1 DD DSN=CICST.TMONARCH.G1994V00,DISP=SHR
> // DD DSN=CICST.TMONARCH.G1995V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1996V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1997V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1998V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
>

> How do I do this? Any ideas?
>
> --
> Regards - Grant

Mickey

unread,

Apr 16, 2012, 11:56:10 AM4/16/12

to

I would look into using BPXWDYN....when TSO ALLOC doesn't get it done,
BPXWDYN usually does.

--------------------------------------------------
From: "Ward Able, Grant" <GWar...@DTCC.COM>
Sent: Monday, April 16, 2012 11:30 AM
To: <TSO-...@VM.MARIST.EDU>
Subject: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

> Hi REXXers,

>
> I wish to build some TSO ALLOCATE statements for a datasetlist
> concatenating a number of files. But the twist is, I want to use the
> UNIT=AFF=SYSUT1 parameter on all except the first DD statement. I wish to
> dynamically allocate a number of files then call IEBGENER in order to copy
> several input files into a single output file. I am building the list of
> datasets, but then the allocation command is:
>
> address tso "ALLOC F(SYSUT1) DA("dslst") SHR"
>
> The ALLOCATE command does not seem to be able to do what I require, which
> is to emulate this JCL:
> //SYSUT1 DD DSN=CICST.TMONARCH.G1994V00,DISP=SHR
> // DD DSN=CICST.TMONARCH.G1995V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1996V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1997V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
> // DD DSN=CICST.TMONARCH.G1998V00,DISP=SHR,
> // UNIT=AFF=SYSUT1
>
> How do I do this? Any ideas?
>
> --
> Regards - Grant

> =======================================
> The views I have expressed on this website/service are my own personal
> views, and are not endorsed or supported by, and do not necessarily
> express or reflect, the views, positions or strategies of my employer.
> =======================================
>
>
> The Depository Trust and Clearing Corporation
> 1 Appold Street
> Broadgate West
> London EC2A 2DQ
> Phone: (0) 207 650 1496
>
> _____________________________________________________________
> 
> DTCC DISCLAIMER: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or
> entity to whom they are addressed. If you have received this email
> in error, please notify us immediately and delete the email and any
> attachments from your system. The recipient should check this email
> and any attachments for the presence of viruses. The company
> accepts no liability for any damage caused by any virus transmitted
> by this email.

Paul Gilmartin

unread,

Apr 16, 2012, 12:03:27 PM4/16/12

to

On Apr 16, 2012, at 09:49, John P Kalinich wrote:

> You could execute Rexx in batch (IRXJCL) and allocate via JCL with
> UNIT=AFF=.
>

The OP may have good reasons not to do this, but
if we knew those reasons, we might be able to devise
a circumvention.

<RANT>
In the Beginning, all allocations were performed by JCL.

Later, DYNALLOC was invented, but with two design objectives:

1) Dynamic allocation was assumed to be useful
only in an interactive TSO session.

2) Tape drives were considered a scarce resource, not
to be bogarted during the programmer's think time.

The increasing use of Rexx as a programming language has
invalidated assumption (1).

The increasing availability of virtual tape drives has
invalidated assumption (2).

DYNALLOC needs to be fixed!
</RANT>

On Apr 16, 2012, at 09:55, Mickey wrote:

> I would look into using BPXWDYN....when TSO ALLOC doesn't get it done,
> BPXWDYN usually does.
>

Alas, here the deficiencies lie not in ALLOC, but in
the underlying SVC 99 which is also used by BPXWDYN
which would suffer the same problem.

-- gil

Paul Gilmartin

unread,

Apr 16, 2012, 12:14:55 PM4/16/12

to

On Apr 16, 2012, at 10:07, Adrian Stern wrote:

> I'm not sure why you need to AFF at all - since these are input files to the
> program and therefore must already exist do you really need that unit
> parameter - if they were catalogued when created they'll be found.
>
> Are you creating them in the same rexx? Why do they have to be on the same
> volume?
>
I'm assuming these are tape data sets to be processed
consecutively, and that the OP desires not to allocate
5 separate drives for them.

Parameters DYNALLOC lacks:

AFF
REF
RETAIN
DEFER
PASS

And it won't tolerate concurrent allocation of multiple
data sets on the same volume.

... all invaluable for tape processing; all supported by JCL
allocation.

BTDTGTTS; DLI; NGDIA.

-- gil

retired mainframer

unread,

Apr 16, 2012, 3:55:11 PM4/16/12

to

Will adding UCOUNT(1) to the ALLOC command help at all?

:>: -----Original Message-----
:>: From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
:>: Of Ward Able, Grant
:>: Sent: Monday, April 16, 2012 8:30 AM

:>: To: TSO-...@VM.MARIST.EDU
:>: Subject: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL
:>:
:>: Hi REXXers,
:>:
:>: I wish to build some TSO ALLOCATE statements for a datasetlist
:>: concatenating a number of files. But the twist is, I want to use the
:>: UNIT=AFF=SYSUT1 parameter on all except the first DD statement. I wish
:>: to dynamically allocate a number of files then call IEBGENER in order to
:>: copy several input files into a single output file. I am building the
:>: list of datasets, but then the allocation command is:
:>:
:>: address tso "ALLOC F(SYSUT1) DA("dslst") SHR"
:>:
:>: The ALLOCATE command does not seem to be able to do what I require,
:>: which is to emulate this JCL:
:>: //SYSUT1 DD DSN=CICST.TMONARCH.G1994V00,DISP=SHR
:>: // DD DSN=CICST.TMONARCH.G1995V00,DISP=SHR,
:>: // UNIT=AFF=SYSUT1
:>: // DD DSN=CICST.TMONARCH.G1996V00,DISP=SHR,
:>: // UNIT=AFF=SYSUT1
:>: // DD DSN=CICST.TMONARCH.G1997V00,DISP=SHR,
:>: // UNIT=AFF=SYSUT1
:>: // DD DSN=CICST.TMONARCH.G1998V00,DISP=SHR,
:>: // UNIT=AFF=SYSUT1
:>:
:>: How do I do this? Any ideas?

Ward Able, Grant

unread,

Apr 17, 2012, 3:53:34 AM4/17/12

to

Thanks for all the responses. The reason I cannot build JCL and submit it is the DSNs are obtained dynamically (extracting the names from the GDG to give me all files for a date range that may be variable) and also it has to be part of a regular scheduled job, not an ad hoc one, hence the REXX calling IEBGENER. And yes, these datasets reside on tape.

It is beginning to look like I will have to do something like process them one at a time, using DISP=MOD for the //SYSUT2 dataset. Major PITA!

Might raise a request for UNIT=AFF to be made available to the ALLOCATE command. Anyone want to bet on how that will be received by Big Blue?

Regards - Grant.

Telephone Internal: x1496 London

Telephone External: +44 (0)207 650 1496

-----Original Message-----

From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Adrian Stern

Sent: 16 April 2012 17:29

To: TSO-...@VM.MARIST.EDU

Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

OK then, process one at a time?

-----Original Message-----

From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Paul Gilmartin

Sent: den 16 april 2012 18:14

To: TSO-...@VM.MARIST.EDU

Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

_____________________________________________________________

 

DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or

entity to whom they are addressed. If you have received this email

in error, please notify us immediately and delete the email and any

attachments from your system. The recipient should check this email

and any attachments for the presence of viruses. The company

accepts no liability for any damage caused by any virus transmitted

by this email.

Ken MacKenzie

unread,

Apr 17, 2012, 7:07:19 AM4/17/12

to

Hi,

For anyone who was previously interested, there is a new version of RXVARS
as well as a brand new program, RXQSORT. RXQSORT will sort the stack for
you and RXVARS can now call RXQSORT to sort the stack. More information
is in the readme files.

Below is a link to a Rapidshare package. I've never used one before so
let me know if there are problems. And there are links to the individual
files on Dropbox.

https://rapidshare.com/#!rapidsave%7C3230838915-1636931829

http://dl.dropbox.com/u/21030343/RXQSORT.XMI
http://dl.dropbox.com/u/21030343/RXQSORT-read_me.txt
http://dl.dropbox.com/u/21030343/RXVARS.XMI
http://dl.dropbox.com/u/21030343/rxvars_old.xmi
http://dl.dropbox.com/u/21030343/rxvars_older.xmi
http://dl.dropbox.com/u/21030343/RXVARS-read_me.txt

Jeff Byrum

unread,

Apr 17, 2012, 7:20:42 AM4/17/12

to

When I have a situation like this, I just have my REXX code tailor a skeleton as a temporary dataset and then submit that. Here's a short sample (be sure to test return codes after the service calls):

"FTOPEN TEMP"
"FTINCL skelname"
"FTCLOSE"
"VGET (ZTEMPF)"
Address TSO "SUBMIT '"ZTEMPF"'"

Would that work for you?

Mickey

unread,

Apr 17, 2012, 8:31:22 AM4/17/12

to

You can still do this with JCL and Syncsort. You code a Rexx to obtain the
file names, and either build the JCL instream and push it to the internal
reader, or you use file tailoring to build the JCL and submit it.

--------------------------------------------------
From: "Ward Able, Grant" <GWar...@DTCC.COM>

Sent: Tuesday, April 17, 2012 3:52 AM

Ward Able, Grant

unread,

Apr 17, 2012, 9:21:30 AM4/17/12

to

Jeff, I am not sure if it would. Can a skeleton cater for an variable number of concatenated files? Sometimes I could have (e.g.) 5 files and at other times (again, e.g.) 19.

I have decided I need to investigate doing this in a different way as not even SVC 99 allows UNIT=AFF. Back to the drawing board.......

Paul Gilmartin

unread,

Apr 17, 2012, 9:28:03 AM4/17/12

to

On Apr 17, 2012, at 01:52, Ward Able, Grant wrote:
>
> Might raise a request for UNIT=AFF to be made available to the ALLOCATE command. Anyone want to bet on how that will be received by Big Blue?
>

Rhetoric? I might guess. But it should be done; it's
past time for DYNALLOC to get its head out of the 20th
century.

Ulrich Krueger

unread,

Apr 17, 2012, 11:10:56 AM4/17/12

to

Grant,
How about determining the needed dataset names in your current job and then
building and submitting a second job which contains the needed JCL -
concatenation? That should solve your problem, shouldn't it?

Regards,
Ulrich Krueger

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of

Ward Able, Grant
Sent: Tuesday, April 17, 2012 12:53 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

Thanks for all the responses. The reason I cannot build JCL and submit it is
the DSNs are obtained dynamically (extracting the names from the GDG to give
me all files for a date range that may be variable) and also it has to be
part of a regular scheduled job, not an ad hoc one, hence the REXX calling
IEBGENER. And yes, these datasets reside on tape.

It is beginning to look like I will have to do something like process them
one at a time, using DISP=MOD for the //SYSUT2 dataset. Major PITA!

Might raise a request for UNIT=AFF to be made available to the ALLOCATE
command. Anyone want to bet on how that will be received by Big Blue?

Regards - Grant.
Telephone Internal: x1496 London
Telephone External: +44 (0)207 650 1496

Kopischke, David G.

unread,

Apr 17, 2012, 11:32:38 AM4/17/12

to

I have a REXX that builds JCL and submits it. We don't allow JOBs with the same name to run simultaneously, so my EXEC just submits them all with the same name and they run serially.

It's not UNIT=AFF, but allows you to run a bunch of JOBs without allocating every device in your shop.

I think I'd be inclined to try one of the other suggestions and see if you can deallocate and reallocate the same DD with a different name on the same device. I've done this before.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Ward Able, Grant

mailgate3.oppenheimerfunds.com made the following annotations
---------------------------------------------------------------------
This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
---------------------------------------------------------------------

Paul Gilmartin

unread,

Apr 17, 2012, 11:58:59 AM4/17/12

to

On Apr 17, 2012, at 09:31, Kopischke, David G. wrote:

> I have a REXX that builds JCL and submits it. We don't allow JOBs with the same name to run simultaneously, so my EXEC just submits them all with the same name and they run serially.
>

It's difficult to guarantee the order in which they'll run,
especially if your system has multiple internal readers.

> It's not UNIT=AFF, but allows you to run a bunch of JOBs without allocating every device in your shop.
>

There is no difficulty using UNIT=AFF in a batch job
although this appears to be a common misconception in
this thread.

On Apr 17, 2012, at 09:10, Rob Zenuk wrote:

> I was wondering about that... Most shops do not allow TSO to allocate tape
> datasets (even the batch TMP). Lots of valid reasons... However with
> virtual tape the reasons are shrinking. I always wished the TMP understood
> if it was running in batch versus an online TSO session and allowed
> different options... Like tape allocation...
>
The TMP has little to do with it. The rules are enforced
by DYNALLOC regardless of how SVC 99 is issued.

Should an EXEC started from a TSO session be considered
batch or interactive? What about IKJEFT* running under JCL?

Should the rules treat virtual tapes differently from real
tapes? Unfortunately for this purpose, virtual tape systems
masquerade as real tapes too well for allocation to easily
make the distinction.

Ted MacNEIL

unread,

Apr 17, 2012, 1:34:57 PM4/17/12

to

Lots of shops still use tape.
It is not something that has become passe.

------Original Message------
From: Adrian Stern
Sender: TSO REXX Discussion List
To: TSO-...@VM.MARIST.EDU
ReplyTo: TSO REXX Discussion List
Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

Sent: 17 Apr 2012 13:12

Alright I haven't seen a tape drive nor heard of one in use since before
2000 - and I've not heard of anyone writing tape files since I've no idea -
the late 80's maybe?

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Rob Zenuk
Sent: den 17 april 2012 17:18
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

I have no doubt these are cataloged datasets. As I said in my last post,
most shops do not allow tape mounts from the TMP. In 30 years I have never
worked in a shop that allowed it...

His ALLOC command is not continued and there is no VOL or UNIT parm.

Rob

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Adrian Stern
Sent: Tuesday, April 17, 2012 8:13 AM
To: TSO-...@VM.MARIST.EDU

Subject: Re: Equivalent REXX ALLOCATE command compared to JCL

I can only imagine that the dataset is on a tape but not catalogued so the
system doesn't know which tape to mount - otherwise it would request the
mount of the appropriate volume.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: den 17 april 2012 17:08
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

On Apr 17, 2012, at 08:55, Ward Able, Grant wrote:

> I have to allocate the input to SYSUT1, but this is failing as the input
is on tape. The ALLOCATE command gives me an error:
>>>> "ALLOC F(SYSUT1) DA('CICST.TMONARCH.G1994V00') SHR"
> IKJ56221I DATA SET CICST.TMONARCH.G1994V00 NOT ALLOCATED, VOLUME NOT
AVAILABLE+
> IKJ56221I VOLUME NECESSARY TO SATISFY YOUR REQUEST NOT ON SYSTEM, AND
CANNOT BE MOUNTED
> +++ RC(12) +++

>
> Looks like I will have to write my JCL to the internal reader. Then I can
resort to using UNIT=AFF, as I had initially intended.
>
With BPXWDYN you must specify the MOUNT option:

MOUNT Resets the S99NOMNT flag,
allowing volumes to be mounted.

I had thought this was the default with TSO ALLOCATE. Perhaps
there's an installation PARM prohibiting it.

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL

Ted MacNEIL

unread,

Apr 17, 2012, 1:41:08 PM4/17/12

to

>They work just like real tapes but they're disk files that you can't browse. A feature rich approach...

Depending on the implementation.
Some are a disk cache with large tape volumes at the back-end.
Some are strictly disk-based.

-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL

Ted MacNEIL

unread,

Apr 17, 2012, 2:02:36 PM4/17/12

to

>No, not correct, what is required is /**/ on the first LOGICAL line. It can
be an enormous comment block that begins with /* and ends with */

Then things have changed.
Both MVS & VM required at least:

/* REXX

on the first line (when I was taught REXX many years ago) and you could close the comment immediately with */, or go on for miles and miles, as long as you closed it , eventually.

Ted MacNEIL

unread,

Apr 17, 2012, 2:38:34 PM4/17/12

to

I assume you think you're funny.
But, there are many (I'm aware of) in both Canada & the US that still use tape.
It's still the most portable of media, inexpensive (especially with the modernisation (virtual) and still out performs disk for sequential processing.

-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL

-----Original Message-----
From: "Adrian Stern" <adrian...@tele2.se>
Date: Tue, 17 Apr 2012 20:03:55
To: <eama...@yahoo.ca>
Subject: RE: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

Is that outer mongolia? Can't be Europe - I've heard there are still vse
machines in the US but that must be a rumour...

Glenn Knickerbocker

unread,

Apr 17, 2012, 2:55:15 PM4/17/12

to

On 4/17/2012 2:02 PM, Ted MacNEIL wrote:
> Both MVS & VM required at least:
>
> /* REXX
>
> on the first line (when I was taught REXX many years ago)

VM never required any text in the comment, just the opening "/*". There
might have been some alternate EXEC interpreter that required
the word REXX before it got built into the actual product.

TSO still requires "REXX" (in any case, and without regard for word
breaks) to appear on the first line, even if the opening comment is
continued onto more lines.

ŹR

Glenn Knickerbocker

unread,

Apr 17, 2012, 2:56:31 PM4/17/12

to

"Adrian Stern" <adrian...@tele2.se> wrote:
> Is that outer mongolia? Can't be Europe - I've heard there are still vse
> machines in the US but that must be a rumour...

By coincidence, I was just sent copies of the VSE manuals today for use
in running a guest VSE system on VM.

ŹR

Leslie Turriff

unread,

Apr 17, 2012, 3:20:50 PM4/17/12

to

Lots of small shops still find it more economical to run multiple z/VSE images under z/OS than to invest in z/OS.

Leslie

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Glenn Knickerbocker
Sent: Tuesday, April 17, 2012 1:54 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.

retired mainframer

unread,

Apr 17, 2012, 3:22:36 PM4/17/12

to

You still need some way to insure the jobs run in the desired order. Jobs
do not necessarily come out of the C/I in the order they went in.

:>: -----Original Message-----

:>: From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf

:>: Of Kopischke, David G.
:>: Sent: Tuesday, April 17, 2012 8:32 AM

:>: To: TSO-...@VM.MARIST.EDU
:>: Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

:>:
:>: I have a REXX that builds JCL and submits it. We don't allow JOBs with

:>: the same name to run simultaneously, so my EXEC just submits them all
:>: with the same name and they run serially.

Ted MacNEIL

unread,

Apr 17, 2012, 3:25:20 PM4/17/12

to

If you say so.
I was taught that /* REXX
was required, in the 1970's, to distinguish from EXEC & EXEC2, when I first learned it in university.

I didn't use REXX under MVS until 1989.

-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL

-----Original Message-----
From: Glenn Knickerbocker <No...@BESTWEB.NET>
Sender: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Date: Tue, 17 Apr 2012 14:53:39
To: <TSO-...@VM.MARIST.EDU>
Reply-To: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject: Re: [TSO-REXX] Equivalent REXX ALLOCATE command compared to JCL

On 4/17/2012 2:02 PM, Ted MacNEIL wrote:
> Both MVS & VM required at least:
>
> /* REXX
>
> on the first line (when I was taught REXX many years ago)

VM never required any text in the comment, just the opening "/*". There
might have been some alternate EXEC interpreter that required
the word REXX before it got built into the actual product.

TSO still requires "REXX" (in any case, and without regard for word
breaks) to appear on the first line, even if the opening comment is
continued onto more lines.

¬R

Ted MacNEIL

unread,

Apr 17, 2012, 9:31:10 PM4/17/12

to

University of Waterloo 1976-1981.
We had VM on a 370, then a 3033, and we 'played' with REXX, in/around 1979/80.
------Original Message------
From: Glenn Knickerbocker
To: Ted MacNEIL
Subject: Re: Equivalent REXX ALLOCATE command compared to JCL
Sent: 17 Apr 2012 21:25

On 17 Apr 2012 12:25:20 -0700, Ted MacNEIL wrote:
>I was taught that /* REXX
>was required, in the 1970's, to distinguish from EXEC & EXEC2, when I
>first learned it in university.

Yep, that would be before it was introduced in VM/SP3 in 1983. I didn't
realize it had made it outside IBM at all before Mike's SHARE talk in
1981. (I didn't encounter it until after I started at IBM in 1984.)

¬R