I believe that statement in the JCL Reference is in error and needs to be deleted or at the very least completely rewritten. My quite substantial experience using this technique over the last 10-15 years is that using JCL symbols as part of the definition of other JCL symbols works flawlessly every time. There is no unpredictability. If the symbol used to define one symbol isn’t already defined, you get the literal “&SYMB” value that you coded as part of the definition. This works for both SET and PROC and EXEC statements, without any failures or unpredictability that I have ever seen. The resulting VALUE of that symbol may cause errors, but there is no unpredictability to the symbol definition process.
I cannot imagine any circumstance in which the result of defining one JCL symbol using another JCL symbol would ever be unpredictable. If there is any possible case where the result is unpredictable, IBM should be required to specify the circumstances and explain why. Peter P.S. – I will add that all of my experience using symbols to define other symbols also uses EXPORT SYMLIST=* as a standard part of JCL and SYMLIST=JCLONLY for in-stream DD’s with symbols to be substituted. From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin Sent: Wednesday, September 20, 2023 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is SMP/E needed for installs? On Wed, 20 Sep 2023 04:12:20 +0000, Peter Hannigan wrote: > ... >// SET A&RPREFIX=' ' > <https://www.ibm.com/docs/en/zos/2.5.0?topic=symbols-defining-nullifying-jcl> - Do not specify JCL symbols within other JCL symbols. The results can be unpredictable, especially if the imbedded JCL symbol is not previously defined. Damn feckless IBM! Don't call a construct "unpredictable". Either report it as a JCL error or specify the effect in the Ref. But ISVs should avoid "unpredictable" constructs in customer-facing code. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
