An error message for an unused symbolic parameter may be reasonable; throwing away everything to the right of a bad symbol, with no warning, is not.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Thursday, December 2, 2021 1:59 PM 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? Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- 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
