> 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. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, December 2, 2021 3:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Trying to use long parm= in started task Peter, fools rush in. I will give it a shot. Apologies if I was vitriolic. It's just a language detail! Peace and Joy! I see the situation as exactly analogous to most languages I use. If I declare a variable in C++ and do not ever use it then it is a non-event. If I declare a method (subroutine) with a formal parameter that I do not use in the method (analogous to the PROC situation I would say) then I get a warning IIRC that may be dismissed in any of several ways. If I define a variable in Rexx and never use it then it is a non-event. If I declare a procedure in Rexx that does not use one of its arguments it is a non-event. I have never heard anyone say "I wish Rexx would give me an error if a procedure failed to reference one of its arguments." 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, not the unreferenced &MYPARM. It would seem to me that an error on the latter is superfluous. 2. I am missing the compatibility problem. Every change is theoretically a compatibility problem. Suppose IBM were to define a new JCL statement DOTHIS. Well, we have a compatibility problem, right? Every job that had an erroneous // DOTHIS in it somewhere used to fail and now it might not. QED. But obviously that is a ridiculously irrelevant incompatibility. Isn't this the same? Is there really a PROC somewhere with an unreferenced parameter in it, and whose owner is counting on it failing, and who will be surprised and/or inconvenienced if it stops failing? I suppose there might be a hasty sysprog somewhere who is counting on the system telling him that he has an unreferenced parameter. Would not a warning suffice for him? I would say that if he is trying to debug a PROC he should be and probably is in fact paying attention to the messages. Is this error a real problem? I can tell you that it has been a real life problem for me. Here is the situation. I am developing a PROC. I try this. I try that. At some point I change or comment out or remove a JCL statement, and the PROC fails because one of its parameters is now unreferenced. Grrrrr! Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, December 2, 2021 11:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Trying to use long parm= in started task I am surprised at the vitriole regarding IEFC657I THE SYMBOL xxx WAS NOT USED Every time I have seen that message it was because the proc creator (me) screwed up (sometimes in a subtle way). -- Ignoring that situation does not seem to be in the user's best interest. -- Warning about that situation is not either because no one will notice the warning. -- Treating it as an error seems to me to be the right action. It has helped innumerable people over the years. This is quite different than a compiler, for example, optimizing out something that proves not to be used. This could not unconditionally be changed, for compatibility reasons. That says that an option such as "do not treat as an error" would have to be provided and used. Make the case that this is a good idea. None of the posts I read did so. Sure, one could ask for an option to "ignore" or "treat as warning" but if you knew enough to include that option, wouldn't you just "fix" the proc not to have extraneous unneeded stuff to help everyone not get confused? Asking for improvement in the detection of use of a proc symbol, such as within the ParmDD SYSIN might be reasonable. It was implemented as it was because it was practical to do so. And the limitation that exists can be dealt with. It is not practical to have the system search through the Parm DD if the Parm DD is not inline so could not be done "in general". What would you sacrifice our doing in order to accommodate? It is always fair to ask; but it is also a requirement to understand that there are limited resources to be parceled out among worthy causes. Maybe one could consider an option such as "make a JCL symbol from every proc symbol, with some naming convention" that could make it easier to use the symbols from the proc in a Parm DD without having to do extra stuff, possibly incorporating "EXPORT SYMLIST=*" and the option (if needed) so that JCL symbols are processed within Parm DD (such as the current SYMBOLS=JCLONLY). What am I missing? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN