On Mon, 27 Jan 2014 20:10:04 -0500, Gerhard Postpischil wrote:
>On 1/27/2014 8:03 PM, Paul Gilmartin wrote:
>> A matter of opinion, of course. If I had cautiously coded
>> "PARM='&WOMBAT._1'",
>> I would be protected from the hypothetical change, but get a changed
>> behavior if I left &WOMBAT undefined. I think from the beginning the
>> JCL R/C (whatever) should have made reference to an undefined symbol
>> an error.
>
>That wouldn't have been palatable, as your undefined symbol would have
>been valid as a temporary data set name. As today, a temporary may have
>
I could have defined it.
>one or two ampersands, and it's way too late to change that. It might
>have made more sense to use a different character, e.g., a percent sign,
>to introduce variables (but clashing with the PROC convention).
>
Sure, but couldn't it have been done right five decades ago, if only
the designers hadn't been too stressed by deadlines to think clearly.
By experiment, what you say is true. I'm considerably surprised.
So, then, why do I get:
8 //DDFOUR DD DISP=(,PASS),DSN=&&&&FOUR,UNIT=SYSALLDA,SPACE=(1,0)
STMT NO. MESSAGE
8 IEFC627I INCORRECT USE OF AMPERSAND IN THE DSN FIELD
By JCL rules, two ampersands represent one ampersand, so four ampersands
represent two ampersands, and "&&FOUR" is a valid temp DSN.
ObEmerson?
I hate JCL!
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
