Peter, You raise an interesting question about the “what should we do” thing to do.
In my experience, whether in software or not, the best course of action is always to do the right thing, the “what should we do”. Every single time I take another course of action, it turns out to be a false economy. What seems less expensive at first is, in reality, almost always more expensive in the long run. Tom Harper Phoenix Software International Sent from my iPhone > On Dec 4, 2021, at 10:05 AM, Peter Relson <rel...@us.ibm.com> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -------------------------------------------------------------------------------- This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
