Peter, As I initiated this thread, I'd like to give my perspective.
You are right in that the IEFC657I THE SYMBOL xxx WAS NOT USED message indicates a problem, and it should be looked into. I think other people's comments are shooting the messenger. The real problem for me was // SET AV=&ACTION - works // SET AV='&ACTION' with quotes does not work, and causes the IEFC571 message. In all my years at writing JCL, I had learned to quote strings to avoid errors. Now I have to stop quoting the symbols around these parameters. However I still need quotes around // SET T2='T2T2 BCD' Now I know, I find I can do // SET B=COLIN // SET AV=Z&ACTION.&B. These works. What also complicated the picture was // SET AV=Z&ACTION.&B.&T2 // SET A2='&AV ' //I2 EXEC PGM=BPXBATCH,REGION=0M, // PARM='SH /u/mqweb3/conf/ccc.sh aa &A2 REST' and 'REST' is not passed through, so it looks like 'SET A2='&AV' breaks the parsing at &A2 I would have expected the passed parameter string to be 'aa &AV REST' I'm happy as I can now pass long strings through to my programs. Colin On Thu, 2 Dec 2021 at 19:03, Peter Relson <[email protected]> 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 > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
