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