-----Ursprungliche Nachricht-----
Von: IBM Mainframe Discussion List Im Auftrag von Shmuel Metz
(Seymour J.)
Gesendet: Mittwoch, 20. September 2006 23:53
An: IBM-MAIN@BAMA.UA.EDU
Betreff: Re: OPC variable resolution in JCL included members
on 09/20/2006 at 07:55 AM, Robert Bardos <[EMAIL PROTECTED]> said:
>As I have never worked with OPC nor setup jobs that were
submitted by
>OPC I simply added variable &OCDATE at the relevant places in the
>INCLUDE member.
It's been a while since I did ^M, but my recollection is that they
do
not use Ampersand for substitution. Try
// SET MYDATE=%OCDATE
Better yet, check the manual for the correct character.
Shmuel (Seymour J.) Metz, SysProg and JOAT
-----------------------------------------------
Had it been Control-M you were certainly right about the %
character, Shmuel, and even with OPC the percent character can be
used. Having skimmed the variable substitution and INCLUDE parts
(though the latter is close to non-existant) of some five out of
maybe eight books in the TWS (formerly OPC) bookshelf, I recall
there are three(?) characters serving slightly different purposes.
The ampersand however having turned out perfectly valid for my
needs I'll focus on giving you all a recap of what had happened,
my misconceptions about OPC, my conclusions and (most certainly)
newer misconceptions. All for the sake of increased value of
IBM-MAINs archive.
So how did it start? With a piece of JCL being submitted by OPC
containing a JCL INCLUDE statement pointing to a member which
itself contained syntactically correct OPC variable references.
(As it turned out, OPC does not "look" into included JCL hence the
initial failure).
Well then, I thought, why not assign the OPC variable's content in
the outer JCL to a JCL variable by means of a JCL SET statement
and have it resolved that way in the included JCL statements.
So the operator followed my instructions, somehow (as I don't know
how this is done in OPC) opened the outer JCL for restart,
inserted // SET MYDATE=&OCDATE and had the job restarted. Only to
see it fail miserably again. &OCDATE remained &OCDATE and had not
been resolved.
Later that day I learned that when OPC opens the JCL for restart,
it opens it with the OPC variables already being resolved and does
not do any scan/replacement any more. So in this special case
&OCDATE was no longer OPC's OCDATE variable but simply the string
&OCDATE. Had the statement been in the JCL from the very beginning
then the operator would have seen something like // SET
MYDATE=2006263 when opening the JCL. And the variable would have
resolved nicely in the included statements.
That's my interpretation of what had happened. And my conclusion:
it is perfectly valid to "transport" the value of OPC variables
into included JCL by means of a JCL SET statement but it can't be
done when being inserted anew as part of an OPC job restart.
(Although I remember a "phase=" keyword somewhere in OPC
documentation, I'll better leave it to the OPC experts to expand
on that).
Long post after the second looong day in a row.
Kind regards
Robert Bardos
Ansys AG, Zurich, Switzerland
----------------------------------------------------------------------
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
