Is there a common or recommended way to invoke SAS on z/OS in JCL, when invoking SAS and non-SAS steps within the same job stream?
For a stand-alone business task (a.k.a. job), we bring all steps(independent programs to be executed) with their required file definitions, into one script referred to as a JCL proc. When we invoke SAS only, we use the SAS standard JCL proc.
However, invoking the SAS proc within our own JCL procs is causing a problem because we cannot override any file definitions for the SAS steps.
A long time ago, in a galaxy far, far away (my disclaimer for dredging up dusty stuff)...I remember that something like this worked to override defined DD names:
//STEP1.SYSIN DD DSN=MY.OVERRIDE.DSN,DISP=SHR
//STEP1.SYSOUT DD DSN=MY.SYSOUT.FILE,DISP=OLD
It's the STEP1.SYSIN that I'm remembering.
But then I also remember that in production JCL we made our own JCL streams with our own version of the SAS proc, too. If something about the proc needed to change with a new release of the software, the systems folks had some CLIST or REXX utilities that they could run against the PROCLIBS.
I am in that galaxy and it does feel far, far away ;-)
your syntax (and therefore your memory) are just fine
Incorporating the body of the SAS JCL proc into your own JCL stream allowed you to make the kind of overrides for the SAS step, that direct use/invocation of the SAS proc within your own jcl proc eliminated. It appears to be a limitation of the IBM JCL language. Providing that flexibility comes at a price. For example, when a new version of SAS is stored in a new program library, you need something like that REXX or CLIST utility and need to apply it across untold program/JCL libraries.
That is the price of making "special" production that bit more convenient. When this is the only kind of production, it may be a price worth paying. We're still discussing the best way forward (unfortunately, moving everything off z/OS is not one of the options being considered, enough;-)
It has been a few years since I left that Galaxy, but I seem to remember that we had 2 procs for SAS:
1) base/primary job use. We used PanValet. We could open a program and submit it directly with from ISPF.
2) A proc that copied a member from PanValet before submitting it. This involved a parmlib member as well.
But, when we upgraded SAS and other things, it was only necessary to update the three proc's, not all the code. When an upgrade was done, a new primary proc was created that the SAS community could use to verify with explicit ad hoc processing. When it got everyone's blessing, the old primary was "saved" and the new primary was renamed to the original primary name. After a quarter's worth of no reported problems (no news is good news), then the other proc was "saved" and the updates applied without changing the name of the proc. Of course, then a few jobs would suddenly fail and get fixed.
The #1 proc was actually rather versatile. It headed adhoc code where the last step was //sysin *, followed by the SAS code. Of course, it disallowed starting "/*" comments in the first column. We then moved production scheduled jobs to a standard, non-Valet, .pds to hold the program. If we needed to run a multi-step job stream, then the SAS members could not have the header jcl, but we used the same proc, pointing the sysin to the actual SAS member. So we may have a job rp0100dp (resource planning job #0100 daily production) which uses the JCL source file rp0100dp, and that source file then references SAS programs rp0110dp, rp0120dp, rp0131dp, rp0147dp (130 had one major revision, 140 has had 7 major revisions/versions). The PanValet development/test copy would have the member name rp0110dt, with the appropriate header JCL entact.
Message was edited by: Chuck