Re: WTO
Peter, My issue with the exit was a user error ( mine ) we didnt copy and LLA fresh the right library. Scott On Sun, Dec 1, 2019 at 10:22 AM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > I seem to recall there was another such pointer in the SMF structures and > I thought the Nasty Wet Monster Bank used that. But maybe I am mixing > things up. Could have been some other bank. > > These fields were great for local mods and I made extensive use of the > CVTUSER field in the 1980s to hold flags, settings and values (even whole > tables) used by various exits which were used by multiple MVS installations > I supported. I had code (and a change protocol) that could modify these in > flight, thus altering the flow of control in exits and so on. > > The fields that Peter has described (Thank you Peter) are for vendors. If, > in time passed, any Vendor made use of the CVTUSER field he could be sure > he would upset many customers. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Rupert Reynolds > Sent: 30 November 2019 16:40 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] WTO > > ahem! I meant to say CVTUSER, a very different field from CVTUSR :-) > > On Sat, 30 Nov 2019, 15:17 Rupert Reynolds, wrote: > > > Whatever happened to CVTUSR? Back in the 1990s we used to have (from > > memory) a started task that came up briefly during IPL and it > > allocated storage (I forget what key, but read only in the general > > case) for a vector table, pointed CVTUSR at that, and then it stopped > itself. > > > > So if I was (say) at Nasty Wet Monster Bank, it would point CVTUSR at > > the NMVT, which we could use for anything within reason. > > > > Ruz > > > > On Sat, 30 Nov 2019, 13:56 Peter Relson, wrote: > > > >> Lennie wrote: > >> > >> Is this intended to be undocumented? > >> Is there a published list of the existing assignments of those slots? > >> > >> > >> To the first: it is documented. To the extent appropriate, that being > >> commentary in the data area book and showing the fields as "PI". > >> To the second: no. > >> > >> It is up to each ISV whether they want to make known what slot they > >> are using (and up to them to document whatever they feel appropriate > >> about such use). > >> > >> 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Maximum initiator in JES ?
is the maximum number of JES2 managed initiators, but you can add WLM managed initiators to your batch processing too. The WLM managed initiators don't count against the limit. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Sunday, December 1, 2019 12:48 PM, johnnydeep san wrote: > Hi all, > > What is the max initiator i can assign ? . Google says , in case > is correct , Why cant more than that. in INITDEF . Just a > curiosity question . Please guide me . > > - > > 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
Maximum initiator in JES ?
Hi all, What is the max initiator i can assign ? . Google says , in case is correct , Why cant more than that. in INITDEF . Just a curiosity question . Please guide me . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
I seem to recall there was another such pointer in the SMF structures and I thought the Nasty Wet Monster Bank used that. But maybe I am mixing things up. Could have been some other bank. These fields were great for local mods and I made extensive use of the CVTUSER field in the 1980s to hold flags, settings and values (even whole tables) used by various exits which were used by multiple MVS installations I supported. I had code (and a change protocol) that could modify these in flight, thus altering the flow of control in exits and so on. The fields that Peter has described (Thank you Peter) are for vendors. If, in time passed, any Vendor made use of the CVTUSER field he could be sure he would upset many customers. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rupert Reynolds Sent: 30 November 2019 16:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] WTO ahem! I meant to say CVTUSER, a very different field from CVTUSR :-) On Sat, 30 Nov 2019, 15:17 Rupert Reynolds, wrote: > Whatever happened to CVTUSR? Back in the 1990s we used to have (from > memory) a started task that came up briefly during IPL and it > allocated storage (I forget what key, but read only in the general > case) for a vector table, pointed CVTUSR at that, and then it stopped itself. > > So if I was (say) at Nasty Wet Monster Bank, it would point CVTUSR at > the NMVT, which we could use for anything within reason. > > Ruz > > On Sat, 30 Nov 2019, 13:56 Peter Relson, wrote: > >> Lennie wrote: >> >> Is this intended to be undocumented? >> Is there a published list of the existing assignments of those slots? >> >> >> To the first: it is documented. To the extent appropriate, that being >> commentary in the data area book and showing the fields as "PI". >> To the second: no. >> >> It is up to each ISV whether they want to make known what slot they >> are using (and up to them to document whatever they feel appropriate >> about such use). >> >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
I confess I thought we were talking about a single installation. But as I said, I was asking mainly out if interest, and to see whether IBM have done anything with it, rather than making a recommendation. Ruz On Sun, 1 Dec 2019, 14:28 Peter Relson, wrote: > Regarding CVTUSER, the problem, as Charles Mills alluded to, is that at > this point it is hard to "know" that no one else is using it. > It "should" be used only only with the approval of the customer that > "owns" the system. > > But at this point, if you can't know that, many feel it not worth the > risk. > > The same is true of TCBUSER. And that's why we created STCBUSER which > documents the expected rules for its use. > > At this point, many feel that neither CVTUSER nor TCBUSER is safe to use. > YMMV. > > 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: WTO
Regarding CVTUSER, the problem, as Charles Mills alluded to, is that at this point it is hard to "know" that no one else is using it. It "should" be used only only with the approval of the customer that "owns" the system. But at this point, if you can't know that, many feel it not worth the risk. The same is true of TCBUSER. And that's why we created STCBUSER which documents the expected rules for its use. At this point, many feel that neither CVTUSER nor TCBUSER is safe to use. YMMV. 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: WTO
About impossible for a vendor to deal with hundreds of customers' unique way of sharing a single CVTUSER. @Peter's vendor words work like a champ (voice of experience). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rupert Reynolds Sent: Saturday, November 30, 2019 2:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Yes, using CVTUSER sensibly for a whole organisation requires authorised code to run at IPL time, which must allocate a USERVT in common storage and point CVTUSER at that. There will be other ways, but once that work is done, it is relatively little work to use it for each product that needs an entry. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
