Peter, I would be happy with some better doc ( I'll raise another RCF), explaining what happens.
The buglet that needs fixing is // set A='&USER' // EXEC PGM,PARM='Z &A Y' the parameter passed to the program is 'Z' I would expect either 'Z Y' or 'Z &USER Y ' real example //IHS EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD //PARMDD DD *,SYMBOLS=EXECSYS SH /u/mqweb3/conf/ccc.sh aa &A2 x &AV &T1. y &AV. z /* //STDOUT DD SYSOUT=H //STDERR DD SYSOUT=H prints out the parameters aa Colin On Sat, 4 Dec 2021 at 15:05, Peter Relson <[email protected]> wrote: > I agree that it is counter-intuitive (and unfriendly) that, for proc > symbol yyy, you can do > SET xxx=&yyy > but that > SET xxx='&yyy' or even SET xxx='&yyy.' (if a trailing period were > necessary to clearly identify a symbol's usage) do not do what you'd > expect. > > Specifically, it appears that the substitution does not happen within the > quotes (so when you use &xxx, you get, literally, &yyy). > So it's more than just that IEFC657I gets issued if &yyy is not used > anywhere else, it's that the SET symbol substitution value is not what is > desired. > > Maybe this can be improved compatibly (it's important that it be felt that > it can be done compatibly -- while individuals hate the inconsistency of > the function, customers hate it even more when things that worked last > release don't work this release). Obviously one could consider a > parmlib-specifiable option to identify a changed set of rules if such a > change were provided by option and a customer was willing to take the risk > of activating it for all their users, so that each individual would not > have to ask to use a new set of rules. > > As to justification, it's surely the obvious one: $$$. > Why should that be a surprise? These are business decisions and tradeoffs. > > Presumably, the case that needed to be handled involved special > characters. And presumably that case was handled. > Would it have been nicer to have a more general solution? Sure. > Would it have been worth the resource investment? I don't know the answer. > > > And, by the way, the future outlook (to me) is getting dimmer. I long for > the days when "MVP" stood for Most Valuable Player. The new MVP (which > includes the word "Minimum") can lead towards "what's the least that we > can get away with doing" thinking. I far prefer "what should we do" > balanced with "what can we afford to do" (because maybe that leads towards > a staged delivery plan that might start with "not as much" but could end > up at "what should we do" -- if the plan gets carried to fruition, > although I've seen too many cases of not being good at carrying a plan to > fruition). > > 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
