Submitting jobs through REXX and reading the spool through REXX gives us immense potential to automate many manual activities in mainframes.
In this post, we will see how to submit a job from REXX using the Skeleton concept.
Using Skeleton, we are able to pass values to the JCL during REXX execution. Skeleton is like a JCL template, whichever value you wish to pass during the runtime, you can setup a variable name for it and prefix it with &.
For example:
//&JOBID JOB ('Skeleton'),'&USRID',MSGCLASS=R,
// MSGLEVEL=(1,1),CLASS=T,NOTIFY=&USRID,
// TIME=5
In this skeleton, &USRID and &JOBID are the dynamic parameters. Hence, it is mandatory that in your REXX script, you have these variable names populated.
Lets have a look at the REXX.
/*REXX*
USRID=SYSVAR(SYSUID) /*Populates the User ID from System variable SYSUID*/
JOBID=USRID"R" /* Concatenates User ID with a R */
How to submit a skeleton:
TEMP_FILE="'"Your PS File--A Dummy file"'"
"ALLOC FI(ISPFILE) DA("TEMP_FILE") SHR"
"ISPEXEC LIBDEF ISPSLIB DATASET ID('Your PDS where your skeleton is residing')"
"ISPEXEC FTOPEN "
"ISPEXEC FTINCL "Your Skeleton Member Name" "
"ISPEXEC FTCLOSE "
"ISPEXEC VGET (ISPFILE)"
X=OUTTRAP("SUB.")
ADDRESS TSO "SUBMIT "TEMP_FILE" "
X=OUTTRAP("OFF")
"FREE FI(ISPFILE)"
Upon execution of this REXX, your jcl would get submitted. In case of queries, please write in comments.
In REXX, we have control of the address space to which a command will be passed. By default, everything happens in 'address TSO'. When you
ReplyDeleteaddress TSO "ISPEXEC ..."
(what you're doing here), you're saying "Hey, TSO, send this to ISPEXEC for me, please" and TSO dispatches a fresh ISPEXEC task to handle the chore. It dispatches a fresh ISPEXEC task for --EACH-- such command.
If, instead, you
address ISPEXEC
"FTOPEN .."
"FTINCL .."
"FTCLOSE .."
you use the already-existing ISPEXEC environment and save the overhead of dispatching all those new tasks.
I agree to your feedback... Thank you :)
DeleteP.s.: EVERY REXX routine should start with "address (something)". Relying on defaults is foolish and dangerous.
ReplyDeleteYou should also "SIGNAL ON NOVALUE" to guarantee that you never accidentally use a variable with an unknown value.
Well, trusting defaults isn't foolish or dangerous. If it doesn't work as it should be, then mainframes is longtime gone already.
Delete