Registered: 1427341674 Posts: 136
Reply with quote
I came across a scheduling requirement earlier today, that on the surface of it looks like text replacement of parameters in the submitted might be a reasonable response. Other than deciding which variables to use to scan and replace, this is not a major job. It leaves the possibility of creating job blanks and have parts of the JCL and parameter data replaced to create new jobs at submission. Has anyone ever wished they had such a job tailoring function? How useful would that be? Should we do it the same way as all other scan and replace functions, using the declared variables?
Registered: 1428693211 Posts: 48
Reply with quote
it could be a good idea to be able to build jobs out of parts. Jobs are usually managed by someone other than the system programmer who writes GAL scripts, so to avoid confusion and let the job writer have the power to determine how their jobs will be submitted I suggest some sort of separate facility, other than the normal variables lists in scripts. The reason being that the script writer will not need to know about the variables, and have to take steps to be sure they are included inline in the script. Then have a specific function to change the job submission variables when needed. It might be a good idea to insist on a naming standard, say starting the name with a $, which does not appear often in JCL.
//SYSPARMS DD DSN=hlq.AUTOMAN.PARMS
//SYSJOBV DD DSN=hlq.AUTOMAN.PARMS(JOBV)
// EXEC PGM=. . . . . .
then JOBV might contain:
VAR $JANAM LEN 8
VAR $PROC1 LEN 8
and maybe initialization
LET $PROC1 = 'xxxxxx'
Ypu might want to think about a JOBVARS operator to distinguish these slightly different variables to avoid confusion about what you are doing
LET (JOBVAR)$JANAM = 'jobname'
or something like that