Re: CBU HMC activation - switching back
To answer Jake's original question, CBU can be deactivated at any time by command (either in z/OS, on HMC/SE, or by API, depending on your hardware model). That stops the licensing accrual for CBU (as well as limiting the MSU back to non-CBU value). Several ways to do it, the simplest is to vary offline the CPs that were activated by the CBU (which could be more than general purpose processors). z/OS is smart enough to then stop the CBU record (mark it inactive). Undoing any charges for the accidental CBU period is a manual process to be discussed with your IBM rep, but showing good faith by using the commands to undo the CBU, rather than continuing to run with the increased MSU capacity, is probably a factor in value discussions. Note SCRT reports for that month will also pick up on the extra MSU as they are used, which may affect non-IBM software pricing. On Sat, Dec 4, 2021 at 11:42 PM Jake Anderson wrote: > Hello > > Is it possible to swtich back to temporary CBU activation incase it someone > has activated the CBU permanently by mistake ? > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBU HMC activation - switching back
On Sun, 5 Dec 2021 00:46:34 +, Seymour J Metz wrote: >Isn't a real DR usually temporary? > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > CBU Test last only for 10 days whereas a CBU for an actual DR can last for up to 90 days... Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBU HMC activation - switching back
Isn't a real DR usually temporary? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Stuart Holland [stuartz...@outlook.com] Sent: Saturday, December 4, 2021 5:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CBU HMC activation - switching back That happened to us once (person replied that it was a real DR instead of a test). We contacted IBM right away and they fixed the CBU settings and didn't charge us. On 12/4/2021 6:41 AM, Jake Anderson wrote: > Hello > > Is it possible to swtich back to temporary CBU activation incase it someone > has activated the CBU permanently by mistake ? > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBU HMC activation - switching back
That happened to us once (person replied that it was a real DR instead of a test). We contacted IBM right away and they fixed the CBU settings and didn't charge us. On 12/4/2021 6:41 AM, Jake Anderson wrote: Hello Is it possible to swtich back to temporary CBU activation incase it someone has activated the CBU permanently by mistake ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBU HMC activation - switching back
W dniu 04.12.2021 o 13:41, Jake Anderson pisze: Hello Is it possible to swtich back to temporary CBU activation incase it someone has activated the CBU permanently by mistake ? There are two modes of CBU Test and Real Activation. Test can be switched back at any time you want or it will be back automatically. Real Activation means you are in deep sh*t and you should call IBM rep ASAP. Formal statement is you did Real Activation, it was your choice, end of story. In real world they may accept reasonable explanation. Of course this is business problem, not technical. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Trying to use long parm= in started task
On Sat, 4 Dec 2021 15:22:29 +, Colin Paice wrote: > >I would be happy with some better doc ( I'll raise another RCF), explaining >what happens. > No. >The buglet that needs fixing is > Yes. >// 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 ' > According to the doc: https://www.ibm.com/docs/en/zos/2.5.0?topic=jcl-coding-symbols-in-apostrophes> o Symbols are not substituted on the SET statement, so A is set to "&USER", not substituted. o Symbols are substituted on EXEC PARM, so yes, "Z &USER Y". Is it clear that statements are not rescanned for further substitutions? I know IBM's position is, "We don't document what we do not do." But this is such a prevalent expectation that it might deserve an exception. I believe that ampersands introduced by substitution are not treated as special characters; apostrophes and blanks introduced by substitution are treated as special characters Do *not* document it and call it a "feature". When a customer whines, "It no longer works the way it used to!" IBM's courageous riposte should be, "we fixed a defect: it now works as it has always been documented. You shouldn't have relied on its working contrary to specification." Still, I'd prefer the specification and behavior be simplified. >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 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Trying to use long parm= in started task
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 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
Re: Trying to use long parm= in started task
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 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Trying to use long parm= in started task
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
Re: CBU HMC activation - switching back
Check with IBM in any case. You'll need their involvement. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: Saturday, December 4, 2021 7:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CBU HMC activation - switching back Hello Is it possible to swtich back to temporary CBU activation incase it someone has activated the CBU permanently by mistake ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CBU HMC activation - switching back
Hello Is it possible to swtich back to temporary CBU activation incase it someone has activated the CBU permanently by mistake ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
