On Thu, 2 Dec 2021 14:59:30 -0400, Peter Relson <rel...@us.ibm.com> wrote:
>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 To me. the biggest problem with not having a way to ignore a unused PROC parameter is what do you do when you have a PROC parameter that is obsolete? If you remove it from the PROC, then Jobs that specify that parameter will get the IEFC657I error message. Changing JCL to remove the PROC parameter is often difficult in a real Production environment. Depending on the parameter you might be able to add a dummy statement to the PROC like: //DUMMYDD DD DUMMY,DSN=SYS1.PROCLIB(&OBPARM.),DISP=SHR The parameter is now referenced in the PROC and hopefully the values specified in JCL will equate to a valid member name, (the member does not have to exist, it just needs to be valid). Obviously this option will not work for all parameters. -- Dale R. Smith ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
