I think LISTSERV screwed over your ampersands as it did mine. I'll
try to reply by email and repair them.
On 2014-09-10, at 09:28, Tom Wasik wrote:
>
> As for the ['&&'] being converted to '&' that was a long internal debate.
> The concern was that the instream data is being fed to a service that may
> also be doing substitution. We were thinking of things like the high level
> assembler. The intent may be that the double [&&] was intended for that
> service. The instream process removing that could cause problems later down
> the line. So it was decided that the instream substitution service would NOT
> un-double the &.
>
I think I side with the losers here, even though long ago I wished
I could subsitute symbols in assembler instream SYSIN. There's
significant value in using consistent conventions.
Is all this documented? Is an RCF required?
I'd be mollified by an example in the JCL Reference of how one could
achieve in PARMDD with substitution enabled the equivalent of:
//X EXEC PGM=WHATEVER,PARM='The value of &&SYSUID is &SYSUID..'
(You concoct the example; I'll supply the RCF.) I'm thinking of
such as:
// EXPORT ...
//SET A=&& (Is that right?)
...
//PARMDD DD *,SYMBOLS=JCLSYM
The value of &A.SYSUID is &SYSUID..
(But that might let unwanted spaces sneak into my text.)
> Also note that there is another oversight that was pointed out. The &SYSUID
> symbol is not being substituted in the instream data. That should have been
> done. OA45995 was
>
I stumbled into that; I thought it was a feature. I know &SYSUID is
somehow sui generis -- it seems to be neither a static system symbol,
nor a dynamic system symbol, nor a JCL symbol, nor ... What is it,
anyway?
> created to correct that oversight. I mention this because you happened to
> use &USER in your JCL. Until the APAR is available, you could set
> USER=&SYSUID or even SYSUID=&SYSUID
>
I discovered the first of those. In the end, I used WOMBAT in
order not to broadcast my userID on the Web (though I have slipped
on occasion).
But are your circumventions in violation of a statement in the JCL
Reference that symbols should not be defined in terms of other
symbols? An RCF for examples of what's allowed or discouraged
might be proper. And, dammit, the Converter should issue warnings
on any use of deprecated constructs.
Thanks,
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
