Okay, I get it, but this ship is not very ship-shape. Seeing as DSN=&MYPRM means what it means, then when IBM introduced variable symbols they should have used && or % or something, not a single ampersand. Yeah, yeah, that boat has departed the dock.
The IEFC657I does not really do the job though, does it? If I have PROC MYPARM='SYS1.FOO' and mistakenly code DSN=&MYPRM then I will not get an error on it assuming I have also coded something=&MYPARM elsewhere in the PROC. Right? I think I still say that two wrongs don't make a right. Flagging what (I say) should be a non-error is not the answer to some other coding mistake. If someone codes DSN=&MYPRM the error will show up somewhere, either as a DSN not found or as a "can't catalog a temp DSN" or something. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Seymour J Metz Sent: Thursday, December 2, 2021 12:27 PM To: [email protected] Subject: Re: Trying to use long parm= in started task > 1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and then > mistakenly code &MYPRM instead of &MYPARM in the body of the PROC, then the > error is the undefined &MYPRM, //SYSBAR DD DSN=&MYPRM,DISP=(MOD,PASS) Is valid. At the time IBM defined the syntax, there were no symbolic parameters. Changing that to invalid would break every job that used a single ampersand for a temporary dataset name. Do I like it? No, but that ship has sailed. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
