On 2017-01-17, at 08:25, Vernooij, Kees (ITOPT1) - KLM wrote:
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Paul Gilmartin
> Sent: 17 January, 2017 16:12
> To: [email protected]
> Subject: Re: System Symbols (SYSSYM)
>
> On Tue, 17 Jan 2017 08:55:34 +0000, Mike Shorkend wrote:
>
>> There is one case in which there might be problems. Looking at:
>>
>> //MYFILE DD DSN=&SYSNAME,DISP=(,PASS),UNIT=SYSDA
>>
>> WIth SYSSYM set to DISALLOW, this will create a valid temporary dataset(JCL
>> reference says that you should use a double ampersand but a singe works
>> fine).
>> WIth SYSSYM set to ALLOW, this will create a dataset that is called
>> whatever your SYSNAME is.
>>
>> Other symbols will produce other strange names
>>
> ... Which is good reason that reference to an undefined symbol should *always*
> (yes, aboriginally) have resulted in a JCL error.
>
Agreed, there would have been a change in behavior. Originally,
the statement:
//MYFILE DD DSN=&SYSNAME,DISP=(,PASS),UNIT=SYSDA
would have resulted in a JCL error. With system symbols allowed
it has a valid semantic. But design changes giving valid semantics
to previously invalid constructs are less disruptive than changes
that change the semantic of a valid construct.
And the hazard persists. Someone who codes today with SYSSYM=ALLOW:
//MYFILE DD DSN=&GUBBINS,DISP=(,PASS),UNIT=SYSDA
to allocate a temporary data set is at risk of a behavior change if
GUBBINS ever becomes a defined system symbol. It would be prudent
always to use (as I was taught) the longer form:
//MYFILE DD DSN=&&GUBBINS,DISP=(,PASS),UNIT=SYSDA
There is some practice of allowing a parameter to a PROC to change
a temporary DSN to permanent with a parameter. This could be
supported with such as:
//FOO PROC GUBBINS=&&GUBBINS,...
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
