Ignoring the wrong and/or irrelevant comments, anyone who is having trouble
running REXX, TSO, or ISPF in batch, please write to me directly. Chances
are, I've been there and done that. (See below.)
To get you started
1. Create a JCL PROC to start TSO in batch: You can do one of these.
- If you can execute your logon proc in batch, this step is mostly
done.
- or, under SDSF look at your TSO session or a timed out one. Do an
SE on the JCL; ((10, c all xx '//', etc. and you have JCL that
mimics your
logon proc.
-
- or, start with // EXEC PGM=IJKEFT01. Include DDs for SYSTSPRT and
SYSTSIN,
- use DDLIST with what you want in your batch environment, and
type SAVE. That will generate a CLIST with all your allocations.
- Execute the generated CLIST with PARM= or from SYSTSIN.
2. Allocate or DD ISPPROF to a UNIT VIO, CYL SPACE 1,1,1. Model the
DCB after your own profile dataset.
3. Use ISPLOG DD SYSOUT=* or ALLOCATE DD(ISPLOG) DATA(*). IIRC, the DCB
is RECFm=VA, LRECEL=137. Check youR ISPLOGn.LIST dataset.
4. Create a REXX exec to start ISPF in batch. I always do this so I
don't have to worry about what needs ISPF or not. See my previous work on
the very rare ISPSPROF ENQ and the very common getting the return code to
the JCL level with ZISPFRC.
5. Write a REXX EXEC to wrap any TSO command in JCL to invoke the above
(1 and 4), adding a JOB card and anything else you need. Since the early
1990s, I've used the name SPAWN, as it does what SPAWN on other platforms
does.
6. Arrange for your "spawn" to take an argument which it adds to the job
and for that argument to be passed to the EXEC from #5 above.
7. (Optional) To make your "spawn" really robust, have it add any stack
contents to the end of the job. This will let you add any DDs for datasets
that need deadlock ENQing protection, or anything else.
This should get you started.
Now, anytime you want to execute a TSO command, including REXX EXECs, in
batch use:
- [TSO] %Spawn %myrexxex myarg..."
- or from REXX: "%Spawn %myrexex myargs..." or call Spawn "%myrexex
myargs..."
It's not exactly trivial to do it right. It is worth doing.
If you want to have some real fun, try emulating JCL in the foreground.
*-D I've done it.
OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.
On Tue, Dec 22, 2020 at 3:33 PM Paul Gilmartin <
[email protected]> wrote:
> On Tue, 22 Dec 2020 15:05:47 -0600, Hobart Spitz wrote:
> >
> >Still not enough? Write (or get your favorite assembler programmer to
> >write) a CMS SLEEP like program. There might be one on a CBT tape or on
> >the web.
> >
> Assembler!? CBT tape!? What rock have you been under for the few
> decades that bog standard OS/390 Rexx has had:
> address SYSCALL 'sleep' <seconds>
>
> >99% of what JCL does for you can be done in REXX. 99% of what you can do
> >with REXX *cannot* be done in JCL. Anyone who thinks otherwise is just
> >wrong or is too lazy to do a little extra work that saves a lot of work
> >later. Work smart, not hard.
> >
> I settled on a synthesis: code allocations, the JCL 1% as JCL DD statements
> and the 99% heavy lifting in IRXJCL Rexx or IKJEFT01 Rexx. I wash my hands
> after writing the JCL.
>
> Mr. Natural sez, Use the right tool for the job.
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
