------------------------------------<snip>--------------------------------
I've just ran into a situation where I could really use some new
"systemsymbols" in JCL. In a batch job, we can basically only use
&SYSUID in the JCL. I could use two more, and I don't think that they
would introduce any problems. They would be &SYSJOBNA which would be the
job name, and &SYSJOBNU which would be the "job number" (like
JOB12345). My basic use for these would be an attempt to have an "almost
unique" dataset name or UNIX PATH name generated with these values. I do
some really weird stuff (as is likely already known). My application in
this one case was for something like:
-------------------------<example snipped>----------------------------
In any case, does this sound reasonable? Am I overlooking a case where
either of these system symbols could be "indeterminate"? The only one
that I can think of is a case where a job is NJE transmitted to another
site and receives a different job number. In that case, I think the job
number should be the job number at the execution site.
-----------------------------<unsnip>----------------------------
John, geting the JOBNAME shouldn't be too much of a problem; the value
could be set at conversion time. Getting the job number might be more of
a problem, since JES would have to get involved here.
You might wanty to consider an Assember routine that will query JES2 for
job number and your ASCB for the job name. Then do a dynamic allocation
of the HFS/ZFS file and create the appropriate JCL, then pump it through
the internal reader for your PERL step. Consider using the DYNAM routine
from the CBTTAPE to do the allocation.
--
Rick
--
Remember that if you’re not the lead dog, the view never changes.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
