Re: Generating WTO Messages to do message suppression
One of the ways we test our Syzygy automation products is to simply type the
message on the console as if it was a regular command or the entire message we
want to test (we also have a process to do this internally from our product,
but I'm assuming that the OP isn't a customer so doesn't have it) . Anyway,
this does generate a IEE305I message saying that the command ("whatever you
typed") is invalid, but our automation products pick it up and acts on it
anyway. Of course, there is a parm to turn this feature off, but as of yet, no
one has asked us what that parm is. :)
Brian
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Generating WTO Messages to do message suppression
I like using a system rexx exec for this, it can easily produce MLWTOs for
testing automation:
/* REXX TEST - Rexx for issuing test messages for testing */
ConnectId = 'firstline';
Rc=AXRMLWTO(strip('CSQX548E !Q4 CSQXRESP Messages sent to local dead-letter
queue, 467'), 'Connectid','d');
Rc=AXRMLWTO(strip('channel QQM_ACCESS.TO.CSQ4'), 'Connectid','d');
Rc=AXRMLWTO(strip('reason=2053 (MQRC_Q_FULL)'), 'Connectid','de');
Return
On Mon, 21 Aug 2023 12:40:41 -0400, Mark Regan wrote:
>Is there a way to generate WTO messages via a batch job to check message
>suppression? At my last site, where we had NetView, we used a CLIST (or was
>it REXX), to do this.
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Generating WTO Messages to do message suppression
Hi Mark, Another possibility ... Run DFSMSdss (ADRDSSU)and use the WTO/WTOR Command. Regards,. David On 2023-08-21 12:40, Mark Regan wrote: Is there a way to generate WTO messages via a batch job to check message suppression? At my last site, where we had NetView, we used a CLIST (or was it REXX), to do this. Regards, Mark Regan, K8MTR General, EN80tg CTO1 USNR-Retired (1969-1991) Nationwide Insurance, Retired, 1986-2017 z/OS Network Systems Programmer (z NetView, z/OS Communications Server) Email: marktre...@gmail.com LinkedIn: https://www.linkedin.com/in/mark-t-regan -- 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: Generating WTO Messages to do message suppression
Tony, I are right about the extra plus sign... I used this trick in the past to attack the z. If you want to remove the plus sign, you can write a system rexx exec to use axrwto. ITschak בתאריך יום ב׳, 21 באוג׳ 2023 ב-21:30 מאת Tony Harminc : > On Mon, 21 Aug 2023 at 12:44, ITschak Mugzach wrote: > > > user TSO SEND command '+IKJX0001I BLA BLA',cn(00) (or the actual name of > > the console at your shop. It is also a tricky way to fool automation > > products... > > Those automation products should be set up to check for the leading + > sign. (In your example you've added a second + which will come out as > ++.) > > That + is there precisely so that unuthorized programs can't fool > operators (in the old days) or auto-ops these days into acting on a > bogus message. But of course some auto-ops actions can be legitimately > triggered by messages from an unauthorized program. > > Tony H. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Generating WTO Messages to do message suppression
On Mon, 21 Aug 2023 at 12:44, ITschak Mugzach wrote: > user TSO SEND command '+IKJX0001I BLA BLA',cn(00) (or the actual name of > the console at your shop. It is also a tricky way to fool automation > products... Those automation products should be set up to check for the leading + sign. (In your example you've added a second + which will come out as ++.) That + is there precisely so that unuthorized programs can't fool operators (in the old days) or auto-ops these days into acting on a bogus message. But of course some auto-ops actions can be legitimately triggered by messages from an unauthorized program. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Generating WTO Messages to do message suppression
Mark, user TSO SEND command '+IKJX0001I BLA BLA',cn(00) (or the actual name of the console at your shop. It is also a tricky way to fool automation products... ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Mon, Aug 21, 2023 at 7:41 PM Mark Regan wrote: > Is there a way to generate WTO messages via a batch job to check message > suppression? At my last site, where we had NetView, we used a CLIST (or was > it REXX), to do this. > > Regards, > > Mark Regan, K8MTR General, EN80tg > CTO1 USNR-Retired (1969-1991) > Nationwide Insurance, Retired, 1986-2017 > z/OS Network Systems Programmer (z NetView, z/OS Communications Server) > > Email: marktre...@gmail.com > LinkedIn: https://www.linkedin.com/in/mark-t-regan > > -- > 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
Generating WTO Messages to do message suppression
Is there a way to generate WTO messages via a batch job to check message suppression? At my last site, where we had NetView, we used a CLIST (or was it REXX), to do this. Regards, Mark Regan, K8MTR General, EN80tg CTO1 USNR-Retired (1969-1991) Nationwide Insurance, Retired, 1986-2017 z/OS Network Systems Programmer (z NetView, z/OS Communications Server) Email: marktre...@gmail.com LinkedIn: https://www.linkedin.com/in/mark-t-regan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO and IEF170I message
Scott Ballentine corrected my "expectation". The default default, in the absence of any routcode, desccode, mcsflag and CONSOLxx definition is routcodes 1-16. Many exits do not run in environments where WTP (routcode 11) would work. Some SMF exits, I believe, describe how to issue messages from "within". It is, simply put, important that you identify where you want your messages to go. 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 and IEF170I message
The code runs in an exit In case it matters (unlikely as that is), what kind of "exit"? At least "is it some sort of WTO-related exit"? --> No, it is not a WTO-related exit. Is there something in the WTO parameters that causes the IEF170 message to disappear ? Maybe a combination of MCSFLAG, DESC and ROUTCDE ? The first question for any WTO is where do you want it to go? You then set MCSFLAG, DESC, and/or ROUTCDE to meet that desire. IEF170I comes from Write To Programmer processing (either by the WTP macro or by WTO(r) with routing code 11). --> MCSFLAG=HRDCPY did it. I did not set ROUTCDE or DESC. I no longer get the IEF170I message. I would not have expected routing code 11 to be included by default. Perhaps you have some WTO-related exit that changes the routing codes. And perhaps the environment of your exit is not appropriate for WTP. Thanks to all, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO and IEF170I message
The code runs in an exit In case it matters (unlikely as that is), what kind of "exit"? At least "is it some sort of WTO-related exit"? Is there something in the WTO parameters that causes the IEF170 message to disappear ? Maybe a combination of MCSFLAG, DESC and ROUTCDE ? The first question for any WTO is where do you want it to go? You then set MCSFLAG, DESC, and/or ROUTCDE to meet that desire. IEF170I comes from Write To Programmer processing (either by the WTP macro or by WTO(r) with routing code 11). I would not have expected routing code 11 to be included by default. Perhaps you have some WTO-related exit that changes the routing codes. And perhaps the environment of your exit is not appropriate for WTP. 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 and IEF170I message
Pierre, I have used MCSFLAG=HRDCPY with success Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em terça-feira, 18 de outubro de 2022 22:17:34 GMT+2, Charles Mills escreveu: Yikes indeed! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Abell Sent: Tuesday, October 18, 2022 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO and IEF170I message And she was deemed to possibly your next President. YIKES John T. Abell Tel: 800-295-7608 Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax: 800-295-7609 International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pierre Fichaud Sent: Tuesday, October 18, 2022 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: WTO and IEF170I message I issue a plain WTO : wto 'This is a message' I also issue a WTO : wto text=dsa_wtotext,mf=(e,dsa_wtoarea) In both cases the WTO appears in the SDSF LOG. But I also get an IEF170I message for each WTO no matter the flavor. IEF170I 3 This is a message A WTO or WTOR macro requested a write-to-programmer (WTP) operation. The system was unable to complete WTP processing due to an error 3 means "The system issued the PUT macro to a system message data set, but failed." The code runs in an exit but since SVCs are allowed in the exit, the code must execute in TCB mode. Is there something in the WTO parameters that causes the IEF170 message to disappear ? Maybe a combination of MCSFLAG, DESC and ROUTCDE ? Thanks in advance, Pierre. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO and IEF170I message
Yikes indeed! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Abell Sent: Tuesday, October 18, 2022 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO and IEF170I message And she was deemed to possibly your next President. YIKES John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609 International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pierre Fichaud Sent: Tuesday, October 18, 2022 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: WTO and IEF170I message I issue a plain WTO :wto 'This is a message' I also issue a WTO :wto text=dsa_wtotext,mf=(e,dsa_wtoarea) In both cases the WTO appears in the SDSF LOG. But I also get an IEF170I message for each WTO no matter the flavor. IEF170I 3 This is a message A WTO or WTOR macro requested a write-to-programmer (WTP) operation. The system was unable to complete WTP processing due to an error 3 means "The system issued the PUT macro to a system message data set, but failed." The code runs in an exit but since SVCs are allowed in the exit, the code must execute in TCB mode. Is there something in the WTO parameters that causes the IEF170 message to disappear ? Maybe a combination of MCSFLAG, DESC and ROUTCDE ? Thanks in advance, Pierre. -- 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 and IEF170I message
As you have not specified ROUTCDE, CONSOL** takes over. Probably includes 11. On Tue, 18 Oct 2022 13:37:35 -0500 Pierre Fichaud wrote: :>I issue a plain WTO : wto 'This is a message' :>I also issue a WTO : wto text=dsa_wtotext,mf=(e,dsa_wtoarea) :>In both cases the WTO appears in the SDSF LOG. :>But I also get an IEF170I message for each WTO no matter the flavor. :>IEF170I 3 This is a message :>A WTO or WTOR macro requested a write-to-programmer (WTP) operation. The system was unable to complete :>WTP processing due to an error :>3 means "The system issued the PUT macro to a system message data set, but failed." :>The code runs in an exit but since SVCs are allowed in the exit, the code must execute in TCB mode. :>Is there something in the WTO parameters that causes the IEF170 message to disappear ? :>Maybe a combination of MCSFLAG, DESC and ROUTCDE ? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO and IEF170I message
And she was deemed to possibly your next President. YIKES John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609 International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pierre Fichaud Sent: Tuesday, October 18, 2022 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: WTO and IEF170I message I issue a plain WTO :wto 'This is a message' I also issue a WTO :wto text=dsa_wtotext,mf=(e,dsa_wtoarea) In both cases the WTO appears in the SDSF LOG. But I also get an IEF170I message for each WTO no matter the flavor. IEF170I 3 This is a message A WTO or WTOR macro requested a write-to-programmer (WTP) operation. The system was unable to complete WTP processing due to an error 3 means "The system issued the PUT macro to a system message data set, but failed." The code runs in an exit but since SVCs are allowed in the exit, the code must execute in TCB mode. Is there something in the WTO parameters that causes the IEF170 message to disappear ? Maybe a combination of MCSFLAG, DESC and ROUTCDE ? Thanks in advance, Pierre. -- 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
WTO and IEF170I message
I issue a plain WTO :wto 'This is a message' I also issue a WTO :wto text=dsa_wtotext,mf=(e,dsa_wtoarea) In both cases the WTO appears in the SDSF LOG. But I also get an IEF170I message for each WTO no matter the flavor. IEF170I 3 This is a message A WTO or WTOR macro requested a write-to-programmer (WTP) operation. The system was unable to complete WTP processing due to an error 3 means "The system issued the PUT macro to a system message data set, but failed." The code runs in an exit but since SVCs are allowed in the exit, the code must execute in TCB mode. Is there something in the WTO parameters that causes the IEF170 message to disappear ? Maybe a combination of MCSFLAG, DESC and ROUTCDE ? Thanks in advance, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Tony, I was one of those 37x5 people for a lot of years working VTAM/NCP/NPSI ... Scott On Wed, Dec 4, 2019 at 4:21 PM Tony Harminc wrote: > On Tue, 3 Dec 2019 at 08:36, Peter Relson wrote: > > > > > Regarding both of the anchor tables: slots 1009-1024 are reserved for > > customer usage (i.e., the owner of the system), in whatever way they > > choose. Those slots will never be "given out". I do agree that it's > > unfortunate that 30+ years ago I named the fields with "customer" in both > > the description and in the "C" of "CTBL". Perhaps I was thinking that > > ISV's are customers too. > > > > It all depends on your point of view. Anyone who worked with IBM 37x5 comms > controllers and modems from the local telco will remember that both pieces > of equipment had a connector labelled something like "to customer's > equipment". The actual customer often owned neither. > > Tony H. > > -- > 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: WTO
On Tue, 3 Dec 2019 at 08:36, Peter Relson wrote: > > Regarding both of the anchor tables: slots 1009-1024 are reserved for > customer usage (i.e., the owner of the system), in whatever way they > choose. Those slots will never be "given out". I do agree that it's > unfortunate that 30+ years ago I named the fields with "customer" in both > the description and in the "C" of "CTBL". Perhaps I was thinking that > ISV's are customers too. > It all depends on your point of view. Anyone who worked with IBM 37x5 comms controllers and modems from the local telco will remember that both pieces of equipment had a connector labelled something like "to customer's equipment". The actual customer often owned neither. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Customer Anchor Table (was: WTO)
Peter, Thank you for the explanation. I understand the Customer anchor table you mentioned above. Scott On Wed, Dec 4, 2019 at 8:18 AM Peter Relson wrote: > I think that ECVTCTB2 was mentioned at a technical disclosure meeting in > Pok with the ISVs several years ago. > > Regardless, this is the wording that I now provide upon "assignment" of a > slot (with nnn, xxx, yyy, zzz filled in) describing what that assignment > "gets you", and it applies to existing assignments as well: > > I have assigned slot nnn to yyy. > These are the 4 bytes at offset zzz in the area pointed to > by ECVTCTBL. > > You also "automatically" get entry nnn in the CICS Vendor Anchor > Table. For that, you use invocations such as > DFHKEVAT SETSLOT|GETSLOT,INDEX=nnn > If this is of interest to your company, > to get the macros, send a note to cics...@uk.ibm.com and request > to be a participant of the Early Test Program (ETP). > > If not IBM, > As of z/OS 2.3 (not earlier releases) you also get slot > nnn (field FXEFRAT_SLOT_nnn) in the z/OS Function Registry > mapped by macro FXEFR in the area pointed to by XCVT_FRAT. > > As of z/OS 2.3 (not earlier releases) you also get 8-byte slot > nnn in the area pointed to by ECVTCTB2 (the 8 bytes at offset > x'yyy') > > > 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 > -- *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
Customer Anchor Table (was: WTO)
I think that ECVTCTB2 was mentioned at a technical disclosure meeting in Pok with the ISVs several years ago. Regardless, this is the wording that I now provide upon "assignment" of a slot (with nnn, xxx, yyy, zzz filled in) describing what that assignment "gets you", and it applies to existing assignments as well: I have assigned slot nnn to yyy. These are the 4 bytes at offset zzz in the area pointed to by ECVTCTBL. You also "automatically" get entry nnn in the CICS Vendor Anchor Table. For that, you use invocations such as DFHKEVAT SETSLOT|GETSLOT,INDEX=nnn If this is of interest to your company, to get the macros, send a note to cics...@uk.ibm.com and request to be a participant of the Early Test Program (ETP). If not IBM, As of z/OS 2.3 (not earlier releases) you also get slot nnn (field FXEFRAT_SLOT_nnn) in the z/OS Function Registry mapped by macro FXEFR in the area pointed to by XCVT_FRAT. As of z/OS 2.3 (not earlier releases) you also get 8-byte slot nnn in the area pointed to by ECVTCTB2 (the 8 bytes at offset x'yyy') 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
Perhaps, but it certainly wasn't in the message chain I was responding to. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Wayne Driscoll Sent: Tuesday, December 3, 2019 10:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO And he later sent out a mea culpa e-mail correcting himself. Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, December 2, 2019 5:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO EXTERNAL EMAIL Whatever Peter did or did not point out in some other message, he wrote Peter wrote "Upon request (to me), IBM assigns to an ISV a slot in the anchor tables pointed to by CVTCTBL". -- Shmuel (Seymour J.) Metz https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Cb6af737e2dde4ad6332208dd66bb%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637109252788910948sdata=IYExCrDyqwR75AHhQBoCYUU6C%2BPKQAS1rpVJFNbs%2FOo%3Dreserved=0 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Monday, December 2, 2019 5:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Sigh. No such thing as CVTCTBL, which Peter Relson pointed out several days ago. Both fields are in the ECVT: ECVTCTBL DCV(CSRCTABL) Customer anchor table. * Slots assigned by IBM. ... ECVTCTB2 DCV(CSRCTAB2) Customer anchor table 2 * (8-byte slots) I wish the commentary said "vendor" (or something like that), not "customer". sas On Mon, Dec 2, 2019 at 4:38 PM Seymour J Metz wrote: > I couldn't find CVTCTBL in the V2R4 Data Areas either. -- 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://secure-web.cisco.com/1JGOQbBVx6zxeU0v06NQTeSwGRsJHiU8gCCLZStZQAHpCyCsApJpQYyOTGxR2-nrdxxYs4BSkAWOpC8sHO1nDSMWAUUj3bLkNvYiVLpUzQFKQbZxHah0k_1KtvjiBKC6_GJ6dgBNPoUV6MxGlJxnJ-6zxp915nC1YouhBMuULyQRU6-pJaE3n-zZ6eEFuu0rMNXVax4HlLmHi6nTKRwl-WaLQ0OaeK8XJ40XB27hSO6ThxiDH1hm6ROOaIyhFJI5SkCJ8JTVwk54OWXBYeFY1kpzLWVGcahQA3AUMHEv_hpzkEDBfu_cCN7CO8lC0tq5I40GGYFlUD3HSyAz_0iqmwnYzGiBgpQUAINOVo3xpR-Q6ZMh9gMqEjTboSyl5GqQl/https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://secure-web.cisco.com/1L04GoYlyHrbANVxuNje4LRqEIMvkiJr9bx9ZfoVJRTsZU6mT35PQhrzFmEGuzL7ken7oVSjDfXr0EpkHVBSLc5zuh4WeGziLuCzg2RipZrVfvFmjB0pFD60qP2wUAjoHzVJH-armgmWksOsnxtQplgUXgLC94ki7trei0IHdtTl8h15yw7-52dH-v5jHWeEK1UudGvL7ihZfLbgv3qSwkr7Tk_LCb8Wx6VCyzbKgelmuG14OAD_NtGNcIZBYwv_JEinUYMfR1rcGWgIskoj2dB6S3CaCx3eoHN69tZMeS6qpGQCMLfcYXnSKWqIs5d_c3FPLiv0fqlUQ2uD6TsFFgBDgozwFl5CGQaPDN2E82nOvVw6PBUy49AuWRNKMeqJmbB6IgWgHBRFQDxN3W3ZcPg/http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences Privacy Policy - http://secure-web.cisco.com/12uR1WKk8vmDJoZp8AeOts5RI92Ws6kwRNrRL-ly5SwlKiXvEBRiUUidjJ0IdAzFLbHcPGwc9DiYti6F6ffEuWZEW1mzUbu-AgKSvK4tFqSI7dQP-1ygZ0pQM1utlzEfjyplSHTrZkjgdtqV-wafHgNWquV6hwn7Hq2lVlpwujaiZuzFGduLI7C258ti5GuXol_lAgIm3Hef7v-beiVW4zjdyOuJQt0UefTwObXfON0itY4DFkmBW0hH-8m4xKEHbz1vR_Jr0LKpwYLEaOPkLbBUKKYlgGZP2fOWoRrn02ZB4YUpFHv1-bC4o5g5fFjLvdDchtARVcKjIeoXCezyxaZzUc8-7cEW7JrOh6w4GmmfOgYrwQ1pogUPXEsY8e4e1F6VA7dI9VP2gU9LIYmp4WA/http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- 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
Yes sir ..he sure did On Tue, Dec 3, 2019 at 10:53 AM Wayne Driscoll wrote: > > And he later sent out a mea culpa e-mail correcting himself. > > Wayne Driscoll > Rocket Software > Note - All opinions are strictly my own. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Seymour J Metz > Sent: Monday, December 2, 2019 5:14 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > EXTERNAL EMAIL > > > > > > Whatever Peter did or did not point out in some other message, he wrote > Peter wrote "Upon request (to me), IBM assigns to an ISV a slot in the > anchor tables pointed to by CVTCTBL". > > -- > Shmuel (Seymour J.) Metz > > https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Cb6af737e2dde4ad6332208dd66bb%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637109252788910948sdata=IYExCrDyqwR75AHhQBoCYUU6C%2BPKQAS1rpVJFNbs%2FOo%3Dreserved=0 > > > > From: IBM Mainframe Discussion List on behalf > of Steve Smith > Sent: Monday, December 2, 2019 5:21 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > Sigh. No such thing as CVTCTBL, which Peter Relson pointed out several > days ago. Both fields are in the ECVT: > > ECVTCTBL DCV(CSRCTABL) Customer anchor table. > * Slots assigned by IBM. > ... > ECVTCTB2 DCV(CSRCTAB2) Customer anchor table 2 > * (8-byte slots) > > I wish the commentary said "vendor" (or something like that), not > "customer". > > sas > > > On Mon, Dec 2, 2019 at 4:38 PM Seymour J Metz wrote: > > > I couldn't find CVTCTBL in the V2R4 Data Areas either. > > -- > 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 > > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA > 02451 ■ Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > http://www.rocketsoftware.com/manage-your-email-preferences > Privacy Policy - > http://www.rocketsoftware.com/company/legal/privacy-policy > > > This communication and any attachments may contain confidential > information of Rocket Software, Inc. All unauthorized use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > notify Rocket Software immediately and destroy all copies of this > communication. Thank you. > > -- > 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: WTO
And he later sent out a mea culpa e-mail correcting himself. Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, December 2, 2019 5:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO EXTERNAL EMAIL Whatever Peter did or did not point out in some other message, he wrote Peter wrote "Upon request (to me), IBM assigns to an ISV a slot in the anchor tables pointed to by CVTCTBL". -- Shmuel (Seymour J.) Metz https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Cb6af737e2dde4ad6332208dd66bb%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637109252788910948sdata=IYExCrDyqwR75AHhQBoCYUU6C%2BPKQAS1rpVJFNbs%2FOo%3Dreserved=0 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Monday, December 2, 2019 5:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Sigh. No such thing as CVTCTBL, which Peter Relson pointed out several days ago. Both fields are in the ECVT: ECVTCTBL DCV(CSRCTABL) Customer anchor table. * Slots assigned by IBM. ... ECVTCTB2 DCV(CSRCTAB2) Customer anchor table 2 * (8-byte slots) I wish the commentary said "vendor" (or something like that), not "customer". sas On Mon, Dec 2, 2019 at 4:38 PM Seymour J Metz wrote: > I couldn't find CVTCTBL in the V2R4 Data Areas either. -- 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Peter, To err is human, forgive divine, couldn’t resist it. I remember requesting ours. Scott On Tue, Dec 3, 2019 at 9:32 AM Gord Tomlin wrote: > On 2019-11-28 21:28, Peter Relson wrote: > > I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and > > ECVTCTB2 as the pointer to the 8-byte slots (not ECVTCTBL). > We arranged a slot in ECVTCTBL with you many years ago, but we never > heard about ECVTCTB2. Do we automatically have the same numbered slot in > ECVTCTB2 (obviously double the offset), or do we need to separately > arrange a slot in that table? > > Thanks! > > -- > > Regards, Gord Tomlin > Action Software International > (a division of Mazda Computer Corporation) > Tel: (905) 470-7113, Fax: (905) 470-6507 > Support: https://actionsoftware.com/support/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On 2019-11-28 21:28, Peter Relson wrote: I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and ECVTCTB2 as the pointer to the 8-byte slots (not ECVTCTBL). We arranged a slot in ECVTCTBL with you many years ago, but we never heard about ECVTCTB2. Do we automatically have the same numbered slot in ECVTCTB2 (obviously double the offset), or do we need to separately arrange a slot in that table? Thanks! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Regarding CVTCTBL: I already confessed my error and corrected it in a post subsequent to when I posted that error. The laws of physics make it kind of unlikely that one would be able to post a fix to an append before the post of the append with the error. Sometimes it is just necessary to hope that folks see the correction. Regarding both of the anchor tables: slots 1009-1024 are reserved for customer usage (i.e., the owner of the system), in whatever way they choose. Those slots will never be "given out". I do agree that it's unfortunate that 30+ years ago I named the fields with "customer" in both the description and in the "C" of "CTBL". Perhaps I was thinking that ISV's are customers too. 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
I can’t speak for Peter..this was my notes when received our slot. Scott On Mon, Dec 2, 2019 at 6:14 PM Seymour J Metz wrote: > Whatever Peter did or did not point out in some other message, he wrote > Peter wrote "Upon request (to me), IBM assigns to an ISV a slot in the > anchor tables pointed to by CVTCTBL". > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Steve Smith > Sent: Monday, December 2, 2019 5:21 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > Sigh. No such thing as CVTCTBL, which Peter Relson pointed out several > days ago. Both fields are in the ECVT: > > ECVTCTBL DCV(CSRCTABL) Customer anchor table. > * Slots assigned by IBM. > ... > ECVTCTB2 DCV(CSRCTAB2) Customer anchor table 2 > * (8-byte slots) > > I wish the commentary said "vendor" (or something like that), not > "customer". > > sas > > > On Mon, Dec 2, 2019 at 4:38 PM Seymour J Metz wrote: > > > I couldn't find CVTCTBL in the V2R4 Data Areas either. > > -- > 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 > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Whatever Peter did or did not point out in some other message, he wrote Peter wrote "Upon request (to me), IBM assigns to an ISV a slot in the anchor tables pointed to by CVTCTBL". -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Monday, December 2, 2019 5:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Sigh. No such thing as CVTCTBL, which Peter Relson pointed out several days ago. Both fields are in the ECVT: ECVTCTBL DCV(CSRCTABL) Customer anchor table. * Slots assigned by IBM. ... ECVTCTB2 DCV(CSRCTAB2) Customer anchor table 2 * (8-byte slots) I wish the commentary said "vendor" (or something like that), not "customer". sas On Mon, Dec 2, 2019 at 4:38 PM Seymour J Metz wrote: > I couldn't find CVTCTBL in the V2R4 Data Areas either. -- 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
Peter wrote "Upon request (to me), IBM assigns to an ISV a slot in the anchor tables pointed to by CVTCTBL"; it's CVTCTBL that we couldn't find. ECVTCTBL is there. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of scott Ford Sent: Monday, December 2, 2019 5:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Lennie, My understanding based on my notes from Peter is it’s the ECVTCTBL which is + x’CC’ into the ECVT. The customer anchor varies on it’s offset into the ECVTCTBL Peter the IBM authority we are just a customer. Scott On Mon, Dec 2, 2019 at 4:38 PM Seymour J Metz wrote: > I couldn't find CVTCTBL in the V2R4 Data Areas either. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Lennie Dymoke-Bradshaw > Sent: Thursday, November 28, 2019 10:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > Peter, > > On my z/OS 2.3 system I can find the field ECVTCTBL documented on the Data > Areas manuals in the ECVT and I can find the field in the IHAECVT macro on > the system. > > I can find no reference to the CVTCTBL in the Data Areas or in the CVT > macro. > > Is this intended to be undocumented? > Is there a published list of the existing assignments of those slots? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: > http://secure-web.cisco.com/1kUJcdPnbR8n1h72gwNgrp2UVzTvI7sR7wcn6DqNUoOUS10VXNDEJfC1izjmsvYPkR2uxZig54Q4jvjQpRQBzelu7NZZAfNiybX2ljlDr74BobWJum80VZzomPW5PMR4jqG-uLC6oxGJi6vvGBI8lo_a5WoQU5Udw1F2eoFs4CvstMa9FxxNhL5rt-rpnZSnHwlb-Mm3jUytL_madd825ufpln_jbiXDyo-VEtkBohm8IQ7I4s1KnzOyxYvvu7-qbD3QtZELEsd3ttfGt2OkwEKwjU3nauDgj3GYI9Hs-SjdOQsrShzKJ0ZKxDLXs4VbUsaPLcVcFXPpqT7j_LApKcXsh-sfPEWJKiarrHqTiWFGL49ajyXfsmcZO2JRsWXRzXUwH0wDOEaTQGdAThpm7yCEL5DF8kCEyKYg3zrWEcqdhIJ8TuvzUsGvuqsRT8FYY/http%3A%2F%2Fwww.rsmpartners.com > 'Dance like no one is watching. Encrypt like everyone is.' > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Peter Relson > Sent: 28 November 2019 14:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] WTO > > > If you really need speed, check if IBM has any user vector table entries > specifically assigned for customer use. 4 load instructions instead of > searching thru a chain. IBM assigns each entry (e.g. product vendor > request). I vaguely recall it being called CSRCTABL but I could be wrong. > > > Upon request (to me), IBM assigns to an ISV a slot in the anchor tables > pointed to by CVTCTBL and, starting in z/OS 2.3, ECVTCTBL. > Slots 1009 - 1024 are reserved for customer usage (i.e., the owner of the > system) for whatever they see fit. Slots 1009 - 1024 should be used only > for uses of which the customer approves. > > The slots are 1-origin, so slot 1 is at offset 0. Each slot is 4 bytes > wide via CVTCTBL, 8 bytes wide via ECVTCTBL. The slots are in key 0 > page-fixed common storage. > > 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 > -- Scott Ford IDMWORKS z/OS Development -- 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
Lennie, My understanding based on my notes from Peter is it’s the ECVTCTBL which is + x’CC’ into the ECVT. The customer anchor varies on it’s offset into the ECVTCTBL Peter the IBM authority we are just a customer. Scott On Mon, Dec 2, 2019 at 4:38 PM Seymour J Metz wrote: > I couldn't find CVTCTBL in the V2R4 Data Areas either. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Lennie Dymoke-Bradshaw > Sent: Thursday, November 28, 2019 10:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > Peter, > > On my z/OS 2.3 system I can find the field ECVTCTBL documented on the Data > Areas manuals in the ECVT and I can find the field in the IHAECVT macro on > the system. > > I can find no reference to the CVTCTBL in the Data Areas or in the CVT > macro. > > Is this intended to be undocumented? > Is there a published list of the existing assignments of those slots? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: > http://secure-web.cisco.com/1kUJcdPnbR8n1h72gwNgrp2UVzTvI7sR7wcn6DqNUoOUS10VXNDEJfC1izjmsvYPkR2uxZig54Q4jvjQpRQBzelu7NZZAfNiybX2ljlDr74BobWJum80VZzomPW5PMR4jqG-uLC6oxGJi6vvGBI8lo_a5WoQU5Udw1F2eoFs4CvstMa9FxxNhL5rt-rpnZSnHwlb-Mm3jUytL_madd825ufpln_jbiXDyo-VEtkBohm8IQ7I4s1KnzOyxYvvu7-qbD3QtZELEsd3ttfGt2OkwEKwjU3nauDgj3GYI9Hs-SjdOQsrShzKJ0ZKxDLXs4VbUsaPLcVcFXPpqT7j_LApKcXsh-sfPEWJKiarrHqTiWFGL49ajyXfsmcZO2JRsWXRzXUwH0wDOEaTQGdAThpm7yCEL5DF8kCEyKYg3zrWEcqdhIJ8TuvzUsGvuqsRT8FYY/http%3A%2F%2Fwww.rsmpartners.com > 'Dance like no one is watching. Encrypt like everyone is.' > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Peter Relson > Sent: 28 November 2019 14:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] WTO > > > If you really need speed, check if IBM has any user vector table entries > specifically assigned for customer use. 4 load instructions instead of > searching thru a chain. IBM assigns each entry (e.g. product vendor > request). I vaguely recall it being called CSRCTABL but I could be wrong. > > > Upon request (to me), IBM assigns to an ISV a slot in the anchor tables > pointed to by CVTCTBL and, starting in z/OS 2.3, ECVTCTBL. > Slots 1009 - 1024 are reserved for customer usage (i.e., the owner of the > system) for whatever they see fit. Slots 1009 - 1024 should be used only > for uses of which the customer approves. > > The slots are 1-origin, so slot 1 is at offset 0. Each slot is 4 bytes > wide via CVTCTBL, 8 bytes wide via ECVTCTBL. The slots are in key 0 > page-fixed common storage. > > 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 > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Sigh. No such thing as CVTCTBL, which Peter Relson pointed out several days ago. Both fields are in the ECVT: ECVTCTBL DCV(CSRCTABL) Customer anchor table. * Slots assigned by IBM. ... ECVTCTB2 DCV(CSRCTAB2) Customer anchor table 2 * (8-byte slots) I wish the commentary said "vendor" (or something like that), not "customer". sas On Mon, Dec 2, 2019 at 4:38 PM Seymour J Metz wrote: > I couldn't find CVTCTBL in the V2R4 Data Areas either. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
I couldn't find CVTCTBL in the V2R4 Data Areas either. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw Sent: Thursday, November 28, 2019 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Peter, On my z/OS 2.3 system I can find the field ECVTCTBL documented on the Data Areas manuals in the ECVT and I can find the field in the IHAECVT macro on the system. I can find no reference to the CVTCTBL in the Data Areas or in the CVT macro. Is this intended to be undocumented? Is there a published list of the existing assignments of those slots? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: http://secure-web.cisco.com/1kUJcdPnbR8n1h72gwNgrp2UVzTvI7sR7wcn6DqNUoOUS10VXNDEJfC1izjmsvYPkR2uxZig54Q4jvjQpRQBzelu7NZZAfNiybX2ljlDr74BobWJum80VZzomPW5PMR4jqG-uLC6oxGJi6vvGBI8lo_a5WoQU5Udw1F2eoFs4CvstMa9FxxNhL5rt-rpnZSnHwlb-Mm3jUytL_madd825ufpln_jbiXDyo-VEtkBohm8IQ7I4s1KnzOyxYvvu7-qbD3QtZELEsd3ttfGt2OkwEKwjU3nauDgj3GYI9Hs-SjdOQsrShzKJ0ZKxDLXs4VbUsaPLcVcFXPpqT7j_LApKcXsh-sfPEWJKiarrHqTiWFGL49ajyXfsmcZO2JRsWXRzXUwH0wDOEaTQGdAThpm7yCEL5DF8kCEyKYg3zrWEcqdhIJ8TuvzUsGvuqsRT8FYY/http%3A%2F%2Fwww.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: 28 November 2019 14:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] WTO If you really need speed, check if IBM has any user vector table entries specifically assigned for customer use. 4 load instructions instead of searching thru a chain. IBM assigns each entry (e.g. product vendor request). I vaguely recall it being called CSRCTABL but I could be wrong. Upon request (to me), IBM assigns to an ISV a slot in the anchor tables pointed to by CVTCTBL and, starting in z/OS 2.3, ECVTCTBL. Slots 1009 - 1024 are reserved for customer usage (i.e., the owner of the system) for whatever they see fit. Slots 1009 - 1024 should be used only for uses of which the customer approves. The slots are 1-origin, so slot 1 is at offset 0. Each slot is 4 bytes wide via CVTCTBL, 8 bytes wide via ECVTCTBL. The slots are in key 0 page-fixed common storage. 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
What happened to CVTUSER and TCBUSER is that IBM provider safer mechanisms. CVTUSER is still there, if you're feeling brave. It's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Rupert Reynolds Sent: Saturday, November 30, 2019 10:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO 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
More precisely, its that there is no practical way to get the other users to adopt a common protocol for using it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Saturday, November 30, 2019 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO I think the problem with CVTUSER is that there is only one field but lots of "users" (customer, vendor, other customer department, other vendor, ...). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rupert Reynolds Sent: Saturday, November 30, 2019 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
1. No; it's a relic of having shared storage. Going to MVS doesn't change that. 2. N/T services is certainly a better way to handle it; there are other ways. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Saturday, November 30, 2019 3:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote: >I think the problem with CVTUSER is that there is only one field but lots of >"users" (customer, vendor, other customer department, other vendor, ...). > Is this a relic of single address space design? Is this something better addressed by name/token services? -- gil -- 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
When I've use CVTUSER I had a mod to the macro the assemble the correct contents. However, once you bring in software not under the control of IBM or your installation, all bets are off. BTDT,GTS. Getting an external vendor to change its code to fit installation conventions is a lot more than very little work. IBM has provided better tools. Why not use them? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Rupert Reynolds Sent: Saturday, November 30, 2019 5:34 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. I was just wondering whether people still use it. Ruz On Sat, 30 Nov 2019, 20:31 Charles Mills, wrote: > 1. I have no idea. It is certainly a relic of olden times. > > 2. Yes, or the vector that @Peter has described that led to this thread > offshoot. You can get to the vector with four (?) Loads, and then > presumably one or two more to get to the actual specific "user" data you > need. I suspect the overhead for N/T services -- while pretty efficient -- > is greater. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Saturday, November 30, 2019 12:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote: > > >I think the problem with CVTUSER is that there is only one field but lots > of "users" (customer, vendor, other customer department, other vendor, ...). > > > Is this a relic of single address space design? > > Is this something better addressed by name/token services? > > -- > 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
He did, and he did. In this day and age, there is no excuse for using, e.g., CVTUSER, TCBUSER. IBM has provided safer alternatives. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw Sent: Sunday, December 1, 2019 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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: http://secure-web.cisco.com/1PcvL1Uj14WnRMSgaWaskipon2USjMMQaROSkbJeDAeO2qNbi4zhtM2ymJWBsyvaIasWFfR6O4p-SkTmsAnOJxUo7IUtYUxDBMqGIj7gFvRs8CboiihekRVUrixUFCIOqbsVjT8OUning-EXL9L7SLXybRn9EFK9WoDdafDndUUCw6mQbplBu87g6dLaGlVRRHdhOF4385YLtkmTYTL5WQPGANeNLGsTMYGByORGnSp66rwQziiEkuLgDm1Z2XW7Y6jV3Vm2K9kQCfPxjXPhV0kK8rOAOLnDuGk6HUvQyHV2il8gr9ne4rkdrQoebjIFkqJeeeWJ2KWzWjUZJe0iqaqmb41Ur55Qn9PmUqa970A28T8VQyVbdHYd9RcahZ-y2X5OKu2cB6nQQiW_beoPszln1UpNmGDsCUql0cuWdHBUcxKN9TP7j9WFMO-aEpmsz/http%3A%2F%2Fwww.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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: 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
Re: WTO
It was decided a WTO would be used at the multiple entry points. The exit itself is a skeleton passing parameter list and at the point of exit the parameter list in reg1 was passed in a standard way to the user exit with a .. L R15,=V(name of exit ) BALR R14,R15 Scott On Sat, Nov 30, 2019 at 6:20 PM scott Ford wrote: > Peter, > > Mgmt decided we would’ve use a WTO ...standard > > Scott > > On Sat, Nov 30, 2019 at 5:35 PM Rupert Reynolds > wrote: > >> 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. >> >> I was just wondering whether people still use it. >> >> Ruz >> >> On Sat, 30 Nov 2019, 20:31 Charles Mills, wrote: >> >> > 1. I have no idea. It is certainly a relic of olden times. >> > >> > 2. Yes, or the vector that @Peter has described that led to this thread >> > offshoot. You can get to the vector with four (?) Loads, and then >> > presumably one or two more to get to the actual specific "user" data you >> > need. I suspect the overhead for N/T services -- while pretty efficient >> -- >> > is greater. >> > >> > Charles >> > >> > >> > -----Original Message- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On >> > Behalf Of Paul Gilmartin >> > Sent: Saturday, November 30, 2019 12:20 PM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: WTO >> > >> > On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote: >> > >> > >I think the problem with CVTUSER is that there is only one field but >> lots >> > of "users" (customer, vendor, other customer department, other vendor, >> ...). >> > > >> > Is this a relic of single address space design? >> > >> > Is this something better addressed by name/token services? >> > >> > -- >> > 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 >> > -- > Scott Ford > IDMWORKS > z/OS Development > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Peter, Mgmt decided we would’ve use a WTO ...standard Scott On Sat, Nov 30, 2019 at 5:35 PM Rupert Reynolds wrote: > 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. > > I was just wondering whether people still use it. > > Ruz > > On Sat, 30 Nov 2019, 20:31 Charles Mills, wrote: > > > 1. I have no idea. It is certainly a relic of olden times. > > > > 2. Yes, or the vector that @Peter has described that led to this thread > > offshoot. You can get to the vector with four (?) Loads, and then > > presumably one or two more to get to the actual specific "user" data you > > need. I suspect the overhead for N/T services -- while pretty efficient > -- > > is greater. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Paul Gilmartin > > Sent: Saturday, November 30, 2019 12:20 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: WTO > > > > On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote: > > > > >I think the problem with CVTUSER is that there is only one field but > lots > > of "users" (customer, vendor, other customer department, other vendor, > ...). > > > > > Is this a relic of single address space design? > > > > Is this something better addressed by name/token services? > > > > -- > > 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 > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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. I was just wondering whether people still use it. Ruz On Sat, 30 Nov 2019, 20:31 Charles Mills, wrote: > 1. I have no idea. It is certainly a relic of olden times. > > 2. Yes, or the vector that @Peter has described that led to this thread > offshoot. You can get to the vector with four (?) Loads, and then > presumably one or two more to get to the actual specific "user" data you > need. I suspect the overhead for N/T services -- while pretty efficient -- > is greater. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Saturday, November 30, 2019 12:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote: > > >I think the problem with CVTUSER is that there is only one field but lots > of "users" (customer, vendor, other customer department, other vendor, ...). > > > Is this a relic of single address space design? > > Is this something better addressed by name/token services? > > -- > 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
1. I have no idea. It is certainly a relic of olden times. 2. Yes, or the vector that @Peter has described that led to this thread offshoot. You can get to the vector with four (?) Loads, and then presumably one or two more to get to the actual specific "user" data you need. I suspect the overhead for N/T services -- while pretty efficient -- is greater. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, November 30, 2019 12:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote: >I think the problem with CVTUSER is that there is only one field but lots of >"users" (customer, vendor, other customer department, other vendor, ...). > Is this a relic of single address space design? Is this something better addressed by name/token services? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Sat, 30 Nov 2019 11:31:51 -0800, Charles Mills wrote: >I think the problem with CVTUSER is that there is only one field but lots of >"users" (customer, vendor, other customer department, other vendor, ...). > Is this a relic of single address space design? Is this something better addressed by name/token services? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
I think the problem with CVTUSER is that there is only one field but lots of "users" (customer, vendor, other customer department, other vendor, ...). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rupert Reynolds Sent: Saturday, November 30, 2019 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 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
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
Re: WTO
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
Re: WTO
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
Re: WTO
Thanks Peter. That makes sense. Given that you have not replied regarding the existing slot assignments, I will assume they are not published until I find differently. 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 Peter Relson Sent: 29 November 2019 02:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] WTO Sigh. Sorry. I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and ECVTCTB2 as the pointer to the 8-byte slots (not ECVTCTBL). <> 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
Sigh. Sorry. I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and ECVTCTB2 as the pointer to the 8-byte slots (not ECVTCTBL). <> 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
Peter, On my z/OS 2.3 system I can find the field ECVTCTBL documented on the Data Areas manuals in the ECVT and I can find the field in the IHAECVT macro on the system. I can find no reference to the CVTCTBL in the Data Areas or in the CVT macro. Is this intended to be undocumented? Is there a published list of the existing assignments of those slots? 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 Peter Relson Sent: 28 November 2019 14:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] WTO If you really need speed, check if IBM has any user vector table entries specifically assigned for customer use. 4 load instructions instead of searching thru a chain. IBM assigns each entry (e.g. product vendor request). I vaguely recall it being called CSRCTABL but I could be wrong. Upon request (to me), IBM assigns to an ISV a slot in the anchor tables pointed to by CVTCTBL and, starting in z/OS 2.3, ECVTCTBL. Slots 1009 - 1024 are reserved for customer usage (i.e., the owner of the system) for whatever they see fit. Slots 1009 - 1024 should be used only for uses of which the customer approves. The slots are 1-origin, so slot 1 is at offset 0. Each slot is 4 bytes wide via CVTCTBL, 8 bytes wide via ECVTCTBL. The slots are in key 0 page-fixed common storage. 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
Peter, Exactly, btw sometimes we ask questions but the decisions are not ours for example. Scott On Thu, Nov 28, 2019 at 10:30 AM scott Ford wrote: > Jon, > I agree but this is part of our bread and butter, makes us our money. > > Scott > > On Thu, Nov 28, 2019 at 9:29 AM Peter Relson wrote: > >> >> If you really need speed, check if IBM has any user vector table entries >> specifically assigned for customer use. 4 load instructions instead of >> searching thru a chain. IBM assigns each entry (e.g. product vendor >> request). I vaguely recall it being called CSRCTABL but I could be wrong. >> >> >> Upon request (to me), IBM assigns to an ISV a slot in the anchor tables >> pointed to by CVTCTBL and, starting in z/OS 2.3, ECVTCTBL. >> Slots 1009 - 1024 are reserved for customer usage (i.e., the owner of the >> system) for whatever they see fit. Slots 1009 - 1024 should be used only >> for uses of which the customer approves. >> >> The slots are 1-origin, so slot 1 is at offset 0. Each slot is 4 bytes >> wide via CVTCTBL, 8 bytes wide via ECVTCTBL. The slots are in key 0 >> page-fixed common storage. >> >> 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 >> > -- > Scott Ford > IDMWORKS > z/OS Development > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Jon, I agree but this is part of our bread and butter, makes us our money. Scott On Thu, Nov 28, 2019 at 9:29 AM Peter Relson wrote: > > If you really need speed, check if IBM has any user vector table entries > specifically assigned for customer use. 4 load instructions instead of > searching thru a chain. IBM assigns each entry (e.g. product vendor > request). I vaguely recall it being called CSRCTABL but I could be wrong. > > > Upon request (to me), IBM assigns to an ISV a slot in the anchor tables > pointed to by CVTCTBL and, starting in z/OS 2.3, ECVTCTBL. > Slots 1009 - 1024 are reserved for customer usage (i.e., the owner of the > system) for whatever they see fit. Slots 1009 - 1024 should be used only > for uses of which the customer approves. > > The slots are 1-origin, so slot 1 is at offset 0. Each slot is 4 bytes > wide via CVTCTBL, 8 bytes wide via ECVTCTBL. The slots are in key 0 > page-fixed common storage. > > 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 > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
If you really need speed, check if IBM has any user vector table entries specifically assigned for customer use. 4 load instructions instead of searching thru a chain. IBM assigns each entry (e.g. product vendor request). I vaguely recall it being called CSRCTABL but I could be wrong. Upon request (to me), IBM assigns to an ISV a slot in the anchor tables pointed to by CVTCTBL and, starting in z/OS 2.3, ECVTCTBL. Slots 1009 - 1024 are reserved for customer usage (i.e., the owner of the system) for whatever they see fit. Slots 1009 - 1024 should be used only for uses of which the customer approves. The slots are 1-origin, so slot 1 is at offset 0. Each slot is 4 bytes wide via CVTCTBL, 8 bytes wide via ECVTCTBL. The slots are in key 0 page-fixed common storage. 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
> You can cripple your system if you use a macro that is not valid for every > environment. Good point. Is WTO always an SVC? If so, and you can be called running on an SRB, or certain other situations, then WTO is no good. (If there is a branch option then you must use it in those situations.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon Perryman Sent: Thursday, November 28, 2019 1:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO On Wednesday, November 27, 2019, 08:20:47 AM PST, scott Ford wrote: > My big issue I was at the mercy of CA code. Not blaming them, > but it’s a CA product and I wished their doc was better. If you are talking about the security exit samples, then they accomplished the desired results by discouraging it's use. This is not an exit to learn about coding exits. For high risk exits, never expect anything more than the basics (control blocks, return codes and something trivial that does nothing). They gave you the gun but don't expect them to load it for you. Creating a sample that covers everything you need to know is impossible. SAF calls can occur in almost any type of environment. You can cripple your system if you don't have recovery correct. You can cripple your system if you use a macro that is not valid for every environment. Have you implemented diagnostic tools that don't make the problem worse. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Wednesday, November 27, 2019, 08:20:47 AM PST, scott Ford wrote: > My big issue I was at the mercy of CA code. Not blaming them, > but it’s a CA product and I wished their doc was better. If you are talking about the security exit samples, then they accomplished the desired results by discouraging it's use. This is not an exit to learn about coding exits. For high risk exits, never expect anything more than the basics (control blocks, return codes and something trivial that does nothing). They gave you the gun but don't expect them to load it for you. Creating a sample that covers everything you need to know is impossible. SAF calls can occur in almost any type of environment. You can cripple your system if you don't have recovery correct. You can cripple your system if you use a macro that is not valid for every environment. Have you implemented diagnostic tools that don't make the problem worse. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Wednesday, November 27, 2019, 04:39:07 AM PST, John McKown wrote: > Total agreement that it is bad form in today's world. For subsystems, there > is the SSCT to anchor things. And, as I do for my re-entrant code: a > Name/Token pair (primary address space level) to hold a 64-bit pointer > (even in 24 or 31 bit mode, I make sure the pointer is 64-bit clean).. If you really need speed, check if IBM has any user vector table entries specifically assigned for customer use. 4 load instructions instead of searching thru a chain. IBM assigns each entry (e.g. product vendor request). I vaguely recall it being called CSRCTABL but I could be wrong. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
John, Absolutely, my big issue I was at the mercy of CA code. Not blaming them, but it’s a CA product and I wished their doc was better. Scott On Wed, Nov 27, 2019 at 7:39 AM John McKown wrote: > On Tue, Nov 26, 2019 at 2:40 PM Seymour J Metz wrote: > > > Of course it was reentrant, but was it good form? I prefer to protect > code > > against wild stores by marking it as r/o. > > > > Total agreement that it is bad form in today's world. For subsystems, there > is the SSCT to anchor things. And, as I do for my re-entrant code: a > Name/Token pair (primary address space level) to hold a 64-bit pointer > (even in 24 or 31 bit mode, I make sure the pointer is 64-bit clean).. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > People in sleeping bags are the soft tacos of the bear world. > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Tue, Nov 26, 2019 at 2:40 PM Seymour J Metz wrote: > Of course it was reentrant, but was it good form? I prefer to protect code > against wild stores by marking it as r/o. > Total agreement that it is bad form in today's world. For subsystems, there is the SSCT to anchor things. And, as I do for my re-entrant code: a Name/Token pair (primary address space level) to hold a 64-bit pointer (even in 24 or 31 bit mode, I make sure the pointer is 64-bit clean).. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Of course it was reentrant, but was it good form? I prefer to protect code
against wild stores by marking it as r/o.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
John McKown
Sent: Tuesday, November 26, 2019 3:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO
On Tue, Nov 26, 2019 at 1:21 PM Seymour J Metz wrote:
> What makes your program non-reentrant is failing to serialize shared data.
> Long ago in a galaxy far away IBM actually shipped reentrant code that
> modified itself; AFAIK they have cleaned up that abomination.
>
I agree that it's an abomination. But I have done it for a shared
subroutine in a multitasking system. It was reentrant. What was modified
was a 4 byte address. The code looked to see if the area was zero. If it
was, I would do a GETMAIN. I would then update the address area using a CS
to serialize the update. If the CS "succeeded", I would build a R/O table
in that area. If the CS "failed", I would do a FREEMAIN of the storage.
After this, I picked up the address and used it. This is reentrant
according to the defination in Wikipedia:
https://secure-web.cisco.com/1jsyGkFIj1WTeQ3KJFFZTdshHzHkTsH523_JLLN5q0_8zRvH5fDyxv6HpWDuG1ujz5M7NbyZLHHNNeBOxGyv06V0sdWDShL1sPaXH1ydr99wn9PTrvn8mQ371WstVbYW9PCG2qbfELdMura-qgBInB-IB-0MFntpaaeNNl-bzxuM984GbqsE_ddL1YhbrCgWQubkAMTjEccRf7KB7Q2KwjegMWw1XXJHCrcm4TL_cAMn8vn05YH1ziUeI57MUUZdjlabjreLj_0JG6nWfx-ye-qofzxhB_F3FgEQ-XjO56fQK_SzyF2LiKwEX4wsyo5ysZCu_vh7YWV2-N1K5ebEWMB0I9HfucI47A7MuIAZ005t8G7XOzjLBJl-nGalQLYL-Wc-_7_HKVqSJmz9v6fmKpmTWX7RL5TQyHeMbKnZe5NoKnIcLsmyhUUHUeWo7pX9B/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FReentrancy_%28computing%29
In computing
<https://secure-web.cisco.com/1ZjmEMfGLtGLhHBYNlo3NQbuC9Kx08pOL_xYHK6N6lJTlNhiV7lQeJR9QeHa0xGdpxHX6Ex0Ag42sOV5Bk3UTsfslTCOZTASuDy-2thiEdgjD2MkmVQfUni6DRMRPp1ajS_3i-yhiqpGuizH5X_DLH853XbTQb6CTdSHxKCtRqUkE9Zbswu6ckP6-Px78S05zPg10CJxWwbx35r44jLaAcjkKOJhzCbsWBB4V836cvHp4EOtCJ3cJYWmxwo0rXpkkYBfZdRd-wqFW-X1jaRc-Rc7h3hweFnBhNLPc-8pfHGONgT8ZhUDgyk2Tc_vJ3hkywO6shGbHHuBDV1Bqhv-GPH_yNe8nJgjkWNz94iSmDKi2mw7cOX7zfEL8KbTI-6nWowDe9m3skZtsBw2jdErhzd-jaC4hxTzzVydZmr3dimNQ8Fa_ez3WUPuY7Rz25ged/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FComputing>,
a computer program
<https://secure-web.cisco.com/1lGKb3w6sSwErv4GxKTE3yNh7nP14WN6hR6o-nyDb5ptekbmJbTTDM_lc4VWcup07fzCP-TO8C8OaV-5LRcoCkSyp9qq2SHXP14n35RnxMnVl_6YJWHCUhEnKMl_sCts3arkV7nMwQAundtdNMh1zFJ_sXoi7X6lAevvz1FOLILU-IJs4tXfIGHnxxVl5_wq4N0t6AeDiNwLcO8-1jSzHF_sROWG9Pw6caEuInKeyCOVfZ1bfCbWSfabH_RO6aIoaFSOMqSPRXuXMDxNfpzSUYe9K65PakzlmZfUM4XxoNIr5AUX4BYuS3jYi3MBD2H4ASLprEafCH_YZ31B3YUp2uMOIPyGaTXoKByMDtC17bGlmhcP8QJTW0da25CykpLgrlRm_yQgIV51HS7ObGs57qiRHhki3d7v1-waON8TYwfcU8nt8R0I39rrYj2EYtVzp/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FComputer_program>
or subroutine
<https://secure-web.cisco.com/1LvShaQGJ5Haugx-x0ddU99Ov41vSARE-vQjGXNeQdokAnTPEJkafz5GdzC8YuSs1rIrvhNAAZN9iYRo3WZJimf9UpPju3fxLV5pcbWgHFj_YLSP26nDMlOcht_WXxyRrA1yBnUjefDkSm04JcoNGtkYuv44ce2b7YDAOSYCRSToxAR2boXUFns-cGsY_EDlhkv0nnbDT3BJG6qLpO_efdudqjSAyGX47WCDl8u7sdFfp6iZWA709x-05hYAaNiJ6wPKa20tgFKSLod7PWSxoZCukCAaW2iWDm9U-AQY9fdOob-tybILD-FlqDmJunYWU8mzxSaXyl2oybsTLEs-RvtTcg1_eRIvT9vZp-Ryfnh6X601VNm518qYfchbPk7-vL3jNp1ffp89tzh906FnFCLgDwWaLvGC5triIFwAyVtooKrJKQ8H13oj5ZRBNECjB/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSubroutine>
is called *reentrant* if
multiple invocations can safely run concurrently. The concept applies even
on a single processor system, where a reentrant procedure can be
interrupted in the middle of its execution and then safely be called again
("re-entered") before its previous invocations complete execution. The
interruption could be caused by an internal action such as a jump or call,
or by an external action such as an interrupt
<https://secure-web.cisco.com/1MpbMjgU5e_i-f3Hi_xFBU9ZNtHvnfaeiUOezyUKDEeLcA3ADsEx_zvEQkY5vIDYkQpZfq2sdiBrndsJyZEsyWWHb77RC2rUZ_PIMUbYBeNJ4P1H_Pi7oY5WelOVITBvve7ga-D-cLP3QG8Ux_jemww42LHrzZGaaEiqGylQme0oH11IhkELn57-wDDTvIdYfHj8-D8SPZtotz4sf0lfp59BZyKX-tzI55fC3iK0Yo9m9On5k62AZJVyH12Z453nnht8QBWUOpyYeSN1sdReLk8R1UX_evlWpY8Zx9obM1jegQcqG3vpoScmCetOIvkJv6EO3ftIOHnBglgVhz88u6u4NUg1N2gJZZzlp6IlO53Y0VfFw9KstB6w3N0mVn3RIkspRFQ9Hq_TDIXujwdg6Jp6wAWAb5wlhVVIJTy_v5MaZw-0zP3jjPA7BgOXxFjM7/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInterrupt>
or signal
<https://secure-web.cisco.com/1riRl2wbuaXCOxFX40HwfmYL_ad8twHwqnhuvbmK8v_Uv3h8Xe2Y3TZ7vyA8lyD0e0dpFWGfY3yEAOCGHzyrFd3lzlMeUzVKUA49JBg84UJGNokenz3M7oyjwuKu37PHaHzIzf51VrCnJdP1lzM4qxds2Lf0eW0WBhFKppuMRxCUogkZbtHJRTsJNZPmXuOg7QIBAKdjH-sWDE7VGG09lGfUHR0YvPz7Wl7hnRbAX1YIaeCSEvEQwhf5cx_Xe0gA15ilrCAM_tzh5AtadlscOijNEzjgVDyjOfJ-2KHuiqK19I-K8Bexkq6FE2qY-FqcEP0zcI2XwOFqwzxrJaKGti3sxcTI5WOPnzOMMlIza9PvfqVreQE6c4OGsSfFhlpnaP8UJyOGXsY96Oq8wHsFptm0MsslV5KN_vb_e_k2esAHH01wza0-DYOfI-ce3nkb6/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSignal_%28computing%29>.
The previous
Re: WTO
On Tue, Nov 26, 2019 at 1:21 PM Seymour J Metz wrote:
> What makes your program non-reentrant is failing to serialize shared data.
> Long ago in a galaxy far away IBM actually shipped reentrant code that
> modified itself; AFAIK they have cleaned up that abomination.
>
I agree that it's an abomination. But I have done it for a shared
subroutine in a multitasking system. It was reentrant. What was modified
was a 4 byte address. The code looked to see if the area was zero. If it
was, I would do a GETMAIN. I would then update the address area using a CS
to serialize the update. If the CS "succeeded", I would build a R/O table
in that area. If the CS "failed", I would do a FREEMAIN of the storage.
After this, I picked up the address and used it. This is reentrant
according to the defination in Wikipedia:
https://en.wikipedia.org/wiki/Reentrancy_(computing)
In computing <https://en.wikipedia.org/wiki/Computing>, a computer program
<https://en.wikipedia.org/wiki/Computer_program> or subroutine
<https://en.wikipedia.org/wiki/Subroutine> is called *reentrant* if
multiple invocations can safely run concurrently. The concept applies even
on a single processor system, where a reentrant procedure can be
interrupted in the middle of its execution and then safely be called again
("re-entered") before its previous invocations complete execution. The
interruption could be caused by an internal action such as a jump or call,
or by an external action such as an interrupt
<https://en.wikipedia.org/wiki/Interrupt> or signal
<https://en.wikipedia.org/wiki/Signal_(computing)>. The previous
invocations may resume correct execution before the reentered invocation
completes, unlike recursion
<https://en.wikipedia.org/wiki/Recursion_(computer_science)>, where the
previous invocations may only resume correct execution once the reentered
invocation completes.
Of course, in the latest z/OS code marked RENT (or is it REFR?) I think is
loaded into key 0 storage and my code will fail, just like it does if it's
loaded into LPA. I know of vendors in the past who demanded that their code
be loaded into MLPA to avoid the "no store here". I have seen other code
actually go key 0, change the protection on an LPA page to R/W, updated it,
then change the protection back to R/O.
All of the above is poor coding in today's environment. Today, I would use
some some of Name/Token to "anchor" a data area.
>
> In the case of WTO, use of MF=L in the CSECT does not keep the code from
> being reentrant if, as you describe later, the only use made of it is to
> initialize dynamic storage. Used that way there are no shared data, hence
> no need serialize.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
What makes your program non-reentrant is failing to serialize shared data. Long ago in a galaxy far away IBM actually shipped reentrant code that modified itself; AFAIK they have cleaned up that abomination. In the case of WTO, use of MF=L in the CSECT does not keep the code from being reentrant if, as you describe later, the only use made of it is to initialize dynamic storage. Used that way there are no shared data, hence no need serialize. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Monday, November 25, 2019 5:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO On Monday, November 18, 2019, 05:56:09 AM PST, scott Ford wrote: > My chief complaint is samples. > I spend a lot of time digging for examples. > Working examples which I can refer to and understand > (prototype) before I start writing code. CBTTAPE.ORG has tons of real world code. There is probably a variation on your request there but you will need to think creatively to find it. Since you wanted an exit that issues a WTO then look at IEFACTRT. This implementation will not work in every exit. Samples need to be generic with very little risk. A sample WTO in an exit could easily be misconstrued or unfit for your intended use. > When to use the execute form of the macro vs list, MF= is common and rarely deviates from the accepted standard. MF=(E,label) creates the executable code and belongs in your code where you want to execute the functionality. Think of it as the instruction. MF=L is the problem. Think of this as a DC instruction to reserve storage. Using MF=L in your CSECT makes your program non-reentrant. Using MF=L in your workarea DSECT makes your program reentrant but loses the constant initializer (initializes with X'00'). To be reentrant, it must occur in your CSECT and workarea DSECT. You must copy from the CSECT to the workarea DSECT and make sure the alignment is correct. You must also ensure the pointers are correct. Some programs skip the copy from CSECT to DSECT but they are at risk. Jon. -- 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
Great I will look On Mon, Nov 25, 2019 at 5:38 PM Jon Perryman wrote: > > > On Monday, November 18, 2019, 05:56:09 AM PST, scott Ford < > idfli...@gmail.com> wrote: > > > My chief complaint is samples. > > I spend a lot of time digging for examples. > > > Working examples which I can refer to and understand > > > (prototype) before I start writing code. > > CBTTAPE.ORG has tons of real world code. There is probably a variation on > your request there but you will need to think creatively to find it. Since > you wanted an exit that issues a WTO then look at IEFACTRT. This > implementation will not work in every exit. > > Samples need to be generic with very little risk. A sample WTO in an exit > could easily be misconstrued or unfit for your intended use. > > > When to use the execute form of the macro vs list, > > MF= is common and rarely deviates from the accepted standard. MF=(E,label) > creates the executable code and belongs in your code where you want to > execute the functionality. Think of it as the instruction. > > MF=L is the problem. Think of this as a DC instruction to reserve storage. > Using MF=L in your CSECT makes your program non-reentrant. Using MF=L in > your workarea DSECT makes your program reentrant but loses the constant > initializer (initializes with X'00'). To be reentrant, it must occur in > your CSECT and workarea DSECT. You must copy from the CSECT to the workarea > DSECT and make sure the alignment is correct. You must also ensure the > pointers are correct. Some programs skip the copy from CSECT to DSECT but > they are at risk. > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Monday, November 18, 2019, 05:56:09 AM PST, scott Ford wrote: > My chief complaint is samples. > I spend a lot of time digging for examples. > Working examples which I can refer to and understand > (prototype) before I start writing code. CBTTAPE.ORG has tons of real world code. There is probably a variation on your request there but you will need to think creatively to find it. Since you wanted an exit that issues a WTO then look at IEFACTRT. This implementation will not work in every exit. Samples need to be generic with very little risk. A sample WTO in an exit could easily be misconstrued or unfit for your intended use. > When to use the execute form of the macro vs list, MF= is common and rarely deviates from the accepted standard. MF=(E,label) creates the executable code and belongs in your code where you want to execute the functionality. Think of it as the instruction. MF=L is the problem. Think of this as a DC instruction to reserve storage. Using MF=L in your CSECT makes your program non-reentrant. Using MF=L in your workarea DSECT makes your program reentrant but loses the constant initializer (initializes with X'00'). To be reentrant, it must occur in your CSECT and workarea DSECT. You must copy from the CSECT to the workarea DSECT and make sure the alignment is correct. You must also ensure the pointers are correct. Some programs skip the copy from CSECT to DSECT but they are at risk. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Charles, Yes we do, IBM , provided us an entry in the ECVT ... Scott On Mon, Nov 25, 2019 at 4:33 PM Charles Mills wrote: > Do you have an anchor, a place you could store one 32-bit word? If so, a > lower overhead than GETMAIN is a cell pool. It takes a little work to set > it up initially, but after that you can get 'n' bytes of reentrant storage > very quickly. > > Write me off-line (if you wish) Scott if you want more details. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of scott Ford > Sent: Monday, November 25, 2019 7:46 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > David, > > It’s the way CA calls the exit. There is a workarea dsect and notes from > CA peppered through the exit and doc saying there is a 100 byte limitation. > > Scott > > On Mon, Nov 25, 2019 at 4:20 AM David Crayford > wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > of the storage. Why do you have a constraint of 100 bytes? > > > > On 2019-11-25 1:11 AM, scott Ford wrote: > > > David, > > > > > > True, sorry misread his reply. David my issue is I have limited storage > > for > > > variables, 100 bytes , like being back writing BAL on a 360/20. I > haven’t > > > had this experience on a piece of re-entrant code with this limitation. > > > This was one of the main reasons I asked the question of my colleagues > > here > > > on the Listserv. > > > > > > The exit is Top-secrets exit. > > > > > > Scott > > > > > > On Sun, Nov 24, 2019 at 7:07 AM David Crayford > > wrote: > > > > > >> On 2019-11-23 7:07 AM, scott Ford wrote: > > >>> Henri, > > >>> > > >>> That’s what ended up doing , thank you, I appreciate any help. > > >> Maybe a bit of a misunderstanding here. I think what Henri was > > >> suggesting was using a UNIX shell that pipes messages to /dev/console > > >> which writes WTOs using the syslogd daemon. > > >> > > >> echo "hello" > /dev/console > > >> > > >> I think your problem was related to writing assembler code with WTO > > macros? > > >> > > >> > > >>> Scott > > >>> > > >>> On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper < > henrikui...@zdevops.com> > > >>> wrote: > > >>> > > >>>> Maybe a bit late. But a plain WTO via an echo to /dev/console not an > > >>>> option? > > >>>> > > >>>> Sent from my wireless iPhone > > >>>> > > >>>>> On 19 Nov 2019, at 18:52, scott Ford wrote: > > >>>>> > > >>>>> Bruce, Peter, all: > > >>>>> > > >>>>> A big thanks . its much appreciated by this older t-rex. > > >>>>> > > >>>>> Scott > > >>>>> > > >>>>>> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < > > >> bruce_hew...@hotmail.com> > > >>>>>> wrote: > > >>>>>> > > >>>>>> Hello Scott, > > >>>>>> > > >>>>>> How I do it. > > >>>>>> > > >>>>>> in CSECT copy list form from CONSTANTs section to DSECT working > > >> section > > >>>>>> Update message text > > >>>>>> run WTO execute form > > >>>>>> > > >>>>>> in DSECT > > >>>>>> WTO list form map > > >>>>>> > > >>>>>> in Constants > > >>>>>> WTO_text WTO list form with text > > >>>>>> WTO_length = * - WTO_text > > >>>>>> > > >>>>>> DESCT maps onto your own STORAGE area, thus copying the constant > > LIST > > >>>> form > > >>>>>> over the DSECT map makes the code reentrant. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford < > idfli...@gmail.com > > &
Re: WTO
Do you have an anchor, a place you could store one 32-bit word? If so, a lower overhead than GETMAIN is a cell pool. It takes a little work to set it up initially, but after that you can get 'n' bytes of reentrant storage very quickly. Write me off-line (if you wish) Scott if you want more details. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of scott Ford Sent: Monday, November 25, 2019 7:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO David, It’s the way CA calls the exit. There is a workarea dsect and notes from CA peppered through the exit and doc saying there is a 100 byte limitation. Scott On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote: > That's interesting! You said the exit was re-entrant so how is it > obtaining the working storage. If it's doing a GETMAIN why don't you > just increase the size > of the storage. Why do you have a constraint of 100 bytes? > > On 2019-11-25 1:11 AM, scott Ford wrote: > > David, > > > > True, sorry misread his reply. David my issue is I have limited storage > for > > variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t > > had this experience on a piece of re-entrant code with this limitation. > > This was one of the main reasons I asked the question of my colleagues > here > > on the Listserv. > > > > The exit is Top-secrets exit. > > > > Scott > > > > On Sun, Nov 24, 2019 at 7:07 AM David Crayford > wrote: > > > >> On 2019-11-23 7:07 AM, scott Ford wrote: > >>> Henri, > >>> > >>> That’s what ended up doing , thank you, I appreciate any help. > >> Maybe a bit of a misunderstanding here. I think what Henri was > >> suggesting was using a UNIX shell that pipes messages to /dev/console > >> which writes WTOs using the syslogd daemon. > >> > >> echo "hello" > /dev/console > >> > >> I think your problem was related to writing assembler code with WTO > macros? > >> > >> > >>> Scott > >>> > >>> On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper > >>> wrote: > >>> > >>>> Maybe a bit late. But a plain WTO via an echo to /dev/console not an > >>>> option? > >>>> > >>>> Sent from my wireless iPhone > >>>> > >>>>> On 19 Nov 2019, at 18:52, scott Ford wrote: > >>>>> > >>>>> Bruce, Peter, all: > >>>>> > >>>>> A big thanks . its much appreciated by this older t-rex. > >>>>> > >>>>> Scott > >>>>> > >>>>>> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < > >> bruce_hew...@hotmail.com> > >>>>>> wrote: > >>>>>> > >>>>>> Hello Scott, > >>>>>> > >>>>>> How I do it. > >>>>>> > >>>>>> in CSECT copy list form from CONSTANTs section to DSECT working > >> section > >>>>>> Update message text > >>>>>> run WTO execute form > >>>>>> > >>>>>> in DSECT > >>>>>> WTO list form map > >>>>>> > >>>>>> in Constants > >>>>>> WTO_text WTO list form with text > >>>>>> WTO_length = * - WTO_text > >>>>>> > >>>>>> DESCT maps onto your own STORAGE area, thus copying the constant > LIST > >>>> form > >>>>>> over the DSECT map makes the code reentrant. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford > > >>>> wrote: > >>>>>>> Peter, > >>>>>>> > >>>>>> > >>>>>>> I have to add displays ( WTOs ). I dont have complaints again IBM, > >>>> rarely, > >>>>>>> best people I ever worked with, my issue is howtos. Working > examples > >>>> which > >>>>>>> I can refer to and understand > >>>>>>> (prototype) before I start writing code. When to use the execute > form > >>>> of > >>>>>>> the macro vs list, also let me add I was never an applications > >>>> p
Re: WTO
The OP wants to issue a WTO for diagnostic purposes. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Monday, November 25, 2019 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO I suspect it is the TSS Installation exit. It gets called a lot, has a 100 byte work area, and I suspect you probably don’t want to be doing getmains, etc or anything else that will cause performance issues. It does execute in KEY 0, supervisor state. Although, I don’t know what WTO's have to do with this exit. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Monday, November 25, 2019 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Jon, Absolutely agree, this is the first time I have seen this but not surprising. Scott On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote: > > >> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford < > dcrayf...@gmail.com> wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > > of the storage. Why do you have a constraint of 100 bytes? > > > Some high volume exits are provided with a pre-allocated work area to > avoid a storage obtain in the exit when possible. This does not > prevent you from allocating more storage if needed. If you allocate > more storage, be sure to consider the impact (e.g. cpu or linkage=), > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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
WTO has a lot more overhead than one GETMAIN; if it's legitimate to issue the WTO in the exit, then it's legitimate to issue the GETMAIN or STORAGE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> Sent: Monday, November 25, 2019 1:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO I suspect it is the TSS Installation exit. It gets called a lot, has a 100 byte work area, and I suspect you probably don’t want to be doing getmains, etc or anything else that will cause performance issues. It does execute in KEY 0, supervisor state. Although, I don’t know what WTO's have to do with this exit. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Monday, November 25, 2019 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Jon, Absolutely agree, this is the first time I have seen this but not surprising. Scott On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote: > > >> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford < > dcrayf...@gmail.com> wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > > of the storage. Why do you have a constraint of 100 bytes? > > > Some high volume exits are provided with a pre-allocated work area to > avoid a storage obtain in the exit when possible. This does not > prevent you from allocating more storage if needed. If you allocate > more storage, be sure to consider the impact (e.g. cpu or linkage=), > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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 suspect it is the TSS Installation exit. It gets called a lot, has a 100 byte work area, and I suspect you probably don’t want to be doing getmains, etc or anything else that will cause performance issues. It does execute in KEY 0, supervisor state. Although, I don’t know what WTO's have to do with this exit. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Monday, November 25, 2019 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Jon, Absolutely agree, this is the first time I have seen this but not surprising. Scott On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote: > > >> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford < > dcrayf...@gmail.com> wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > > of the storage. Why do you have a constraint of 100 bytes? > > > Some high volume exits are provided with a pre-allocated work area to > avoid a storage obtain in the exit when possible. This does not > prevent you from allocating more storage if needed. If you allocate > more storage, be sure to consider the impact (e.g. cpu or linkage=), > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Jon, Absolutely agree, this is the first time I have seen this but not surprising. Scott On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote: > > >> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford < > dcrayf...@gmail.com> wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > > of the storage. Why do you have a constraint of 100 bytes? > > > Some high volume exits are provided with a pre-allocated work area to > avoid a storage obtain in the exit when possible. This does not prevent you > from allocating more storage if needed. If you allocate more storage, be > sure to consider the impact (e.g. cpu or linkage=), > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford wrote: > That's interesting! You said the exit was re-entrant so how is it > obtaining the working storage. If it's doing a GETMAIN why don't you > just increase the size > of the storage. Why do you have a constraint of 100 bytes? Some high volume exits are provided with a pre-allocated work area to avoid a storage obtain in the exit when possible. This does not prevent you from allocating more storage if needed. If you allocate more storage, be sure to consider the impact (e.g. cpu or linkage=), Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
I would like to see the exit doco! On 2019-11-25 8:46 PM, scott Ford wrote: David, It’s the way CA calls the exit. There is a workarea dsect and notes from CA peppered through the exit and doc saying there is a 100 byte limitation. Scott On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote: That's interesting! You said the exit was re-entrant so how is it obtaining the working storage. If it's doing a GETMAIN why don't you just increase the size of the storage. Why do you have a constraint of 100 bytes? On 2019-11-25 1:11 AM, scott Ford wrote: David, True, sorry misread his reply. David my issue is I have limited storage for variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t had this experience on a piece of re-entrant code with this limitation. This was one of the main reasons I asked the question of my colleagues here on the Listserv. The exit is Top-secrets exit. Scott On Sun, Nov 24, 2019 at 7:07 AM David Crayford wrote: On 2019-11-23 7:07 AM, scott Ford wrote: Henri, That’s what ended up doing , thank you, I appreciate any help. Maybe a bit of a misunderstanding here. I think what Henri was suggesting was using a UNIX shell that pipes messages to /dev/console which writes WTOs using the syslogd daemon. echo "hello" > /dev/console I think your problem was related to writing assembler code with WTO macros? Scott On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper wrote: Maybe a bit late. But a plain WTO via an echo to /dev/console not an option? Sent from my wireless iPhone On 19 Nov 2019, at 18:52, scott Ford wrote: Bruce, Peter, all: A big thanks . its much appreciated by this older t-rex. Scott On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < bruce_hew...@hotmail.com> wrote: Hello Scott, How I do it. in CSECT copy list form from CONSTANTs section to DSECT working section Update message text run WTO execute form in DSECT WTO list form map in Constants WTO_text WTO list form with text WTO_length = * - WTO_text DESCT maps onto your own STORAGE area, thus copying the constant LIST form over the DSECT map makes the code reentrant. On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: Peter, I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i Regards Bruce -- 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Got any doc for that exit? On 2019-11-25 8:46 PM, scott Ford wrote: David, It’s the way CA calls the exit. There is a workarea dsect and notes from CA peppered through the exit and doc saying there is a 100 byte limitation. Scott On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote: That's interesting! You said the exit was re-entrant so how is it obtaining the working storage. If it's doing a GETMAIN why don't you just increase the size of the storage. Why do you have a constraint of 100 bytes? On 2019-11-25 1:11 AM, scott Ford wrote: David, True, sorry misread his reply. David my issue is I have limited storage for variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t had this experience on a piece of re-entrant code with this limitation. This was one of the main reasons I asked the question of my colleagues here on the Listserv. The exit is Top-secrets exit. Scott On Sun, Nov 24, 2019 at 7:07 AM David Crayford wrote: On 2019-11-23 7:07 AM, scott Ford wrote: Henri, That’s what ended up doing , thank you, I appreciate any help. Maybe a bit of a misunderstanding here. I think what Henri was suggesting was using a UNIX shell that pipes messages to /dev/console which writes WTOs using the syslogd daemon. echo "hello" > /dev/console I think your problem was related to writing assembler code with WTO macros? Scott On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper wrote: Maybe a bit late. But a plain WTO via an echo to /dev/console not an option? Sent from my wireless iPhone On 19 Nov 2019, at 18:52, scott Ford wrote: Bruce, Peter, all: A big thanks . its much appreciated by this older t-rex. Scott On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < bruce_hew...@hotmail.com> wrote: Hello Scott, How I do it. in CSECT copy list form from CONSTANTs section to DSECT working section Update message text run WTO execute form in DSECT WTO list form map in Constants WTO_text WTO list form with text WTO_length = * - WTO_text DESCT maps onto your own STORAGE area, thus copying the constant LIST form over the DSECT map makes the code reentrant. On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: Peter, I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i Regards Bruce -- 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
David, It’s the way CA calls the exit. There is a workarea dsect and notes from CA peppered through the exit and doc saying there is a 100 byte limitation. Scott On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote: > That's interesting! You said the exit was re-entrant so how is it > obtaining the working storage. If it's doing a GETMAIN why don't you > just increase the size > of the storage. Why do you have a constraint of 100 bytes? > > On 2019-11-25 1:11 AM, scott Ford wrote: > > David, > > > > True, sorry misread his reply. David my issue is I have limited storage > for > > variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t > > had this experience on a piece of re-entrant code with this limitation. > > This was one of the main reasons I asked the question of my colleagues > here > > on the Listserv. > > > > The exit is Top-secrets exit. > > > > Scott > > > > On Sun, Nov 24, 2019 at 7:07 AM David Crayford > wrote: > > > >> On 2019-11-23 7:07 AM, scott Ford wrote: > >>> Henri, > >>> > >>> That’s what ended up doing , thank you, I appreciate any help. > >> Maybe a bit of a misunderstanding here. I think what Henri was > >> suggesting was using a UNIX shell that pipes messages to /dev/console > >> which writes WTOs using the syslogd daemon. > >> > >> echo "hello" > /dev/console > >> > >> I think your problem was related to writing assembler code with WTO > macros? > >> > >> > >>> Scott > >>> > >>> On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper > >>> wrote: > >>> > >>>> Maybe a bit late. But a plain WTO via an echo to /dev/console not an > >>>> option? > >>>> > >>>> Sent from my wireless iPhone > >>>> > >>>>> On 19 Nov 2019, at 18:52, scott Ford wrote: > >>>>> > >>>>> Bruce, Peter, all: > >>>>> > >>>>> A big thanks . its much appreciated by this older t-rex. > >>>>> > >>>>> Scott > >>>>> > >>>>>> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < > >> bruce_hew...@hotmail.com> > >>>>>> wrote: > >>>>>> > >>>>>> Hello Scott, > >>>>>> > >>>>>> How I do it. > >>>>>> > >>>>>> in CSECT copy list form from CONSTANTs section to DSECT working > >> section > >>>>>> Update message text > >>>>>> run WTO execute form > >>>>>> > >>>>>> in DSECT > >>>>>> WTO list form map > >>>>>> > >>>>>> in Constants > >>>>>> WTO_text WTO list form with text > >>>>>> WTO_length = * - WTO_text > >>>>>> > >>>>>> DESCT maps onto your own STORAGE area, thus copying the constant > LIST > >>>> form > >>>>>> over the DSECT map makes the code reentrant. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford > > >>>> wrote: > >>>>>>> Peter, > >>>>>>> > >>>>>> > >>>>>>> I have to add displays ( WTOs ). I dont have complaints again IBM, > >>>> rarely, > >>>>>>> best people I ever worked with, my issue is howtos. Working > examples > >>>> which > >>>>>>> I can refer to and understand > >>>>>>> (prototype) before I start writing code. When to use the execute > form > >>>> of > >>>>>>> the macro vs list, also let me add I was never an applications > >>>> program, i > >>>>>> > >>>>>> > >>>>>> > >>>>>> Regards > >>>>>> Bruce > >>>>>> > >>>>>> > -- > >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>>>> send email to lists...@listserv.ua.edu
Re: WTO
That's interesting! You said the exit was re-entrant so how is it obtaining the working storage. If it's doing a GETMAIN why don't you just increase the size of the storage. Why do you have a constraint of 100 bytes? On 2019-11-25 1:11 AM, scott Ford wrote: David, True, sorry misread his reply. David my issue is I have limited storage for variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t had this experience on a piece of re-entrant code with this limitation. This was one of the main reasons I asked the question of my colleagues here on the Listserv. The exit is Top-secrets exit. Scott On Sun, Nov 24, 2019 at 7:07 AM David Crayford wrote: On 2019-11-23 7:07 AM, scott Ford wrote: Henri, That’s what ended up doing , thank you, I appreciate any help. Maybe a bit of a misunderstanding here. I think what Henri was suggesting was using a UNIX shell that pipes messages to /dev/console which writes WTOs using the syslogd daemon. echo "hello" > /dev/console I think your problem was related to writing assembler code with WTO macros? Scott On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper wrote: Maybe a bit late. But a plain WTO via an echo to /dev/console not an option? Sent from my wireless iPhone On 19 Nov 2019, at 18:52, scott Ford wrote: Bruce, Peter, all: A big thanks . its much appreciated by this older t-rex. Scott On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < bruce_hew...@hotmail.com> wrote: Hello Scott, How I do it. in CSECT copy list form from CONSTANTs section to DSECT working section Update message text run WTO execute form in DSECT WTO list form map in Constants WTO_text WTO list form with text WTO_length = * - WTO_text DESCT maps onto your own STORAGE area, thus copying the constant LIST form over the DSECT map makes the code reentrant. On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: Peter, I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i Regards Bruce -- 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 -- 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
David, True, sorry misread his reply. David my issue is I have limited storage for variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t had this experience on a piece of re-entrant code with this limitation. This was one of the main reasons I asked the question of my colleagues here on the Listserv. The exit is Top-secrets exit. Scott On Sun, Nov 24, 2019 at 7:07 AM David Crayford wrote: > On 2019-11-23 7:07 AM, scott Ford wrote: > > Henri, > > > > That’s what ended up doing , thank you, I appreciate any help. > > Maybe a bit of a misunderstanding here. I think what Henri was > suggesting was using a UNIX shell that pipes messages to /dev/console > which writes WTOs using the syslogd daemon. > > echo "hello" > /dev/console > > I think your problem was related to writing assembler code with WTO macros? > > > > > > Scott > > > > On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper > > wrote: > > > >> Maybe a bit late. But a plain WTO via an echo to /dev/console not an > >> option? > >> > >> Sent from my wireless iPhone > >> > >>> On 19 Nov 2019, at 18:52, scott Ford wrote: > >>> > >>> Bruce, Peter, all: > >>> > >>> A big thanks . its much appreciated by this older t-rex. > >>> > >>> Scott > >>> > >>>> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < > bruce_hew...@hotmail.com> > >>>> wrote: > >>>> > >>>> Hello Scott, > >>>> > >>>> How I do it. > >>>> > >>>> in CSECT copy list form from CONSTANTs section to DSECT working > section > >>>> Update message text > >>>> run WTO execute form > >>>> > >>>> in DSECT > >>>> WTO list form map > >>>> > >>>> in Constants > >>>> WTO_text WTO list form with text > >>>> WTO_length = * - WTO_text > >>>> > >>>> DESCT maps onto your own STORAGE area, thus copying the constant LIST > >> form > >>>> over the DSECT map makes the code reentrant. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford > >> wrote: > >>>>> Peter, > >>>>> > >>>> > >>>>> I have to add displays ( WTOs ). I dont have complaints again IBM, > >> rarely, > >>>>> best people I ever worked with, my issue is howtos. Working examples > >> which > >>>>> I can refer to and understand > >>>>> (prototype) before I start writing code. When to use the execute form > >> of > >>>>> the macro vs list, also let me add I was never an applications > >> program, i > >>>> > >>>> > >>>> > >>>> Regards > >>>> Bruce > >>>> > >>>> -- > >>>> 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 > >> -- > >> 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 > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On 2019-11-23 7:07 AM, scott Ford wrote: Henri, That’s what ended up doing , thank you, I appreciate any help. Maybe a bit of a misunderstanding here. I think what Henri was suggesting was using a UNIX shell that pipes messages to /dev/console which writes WTOs using the syslogd daemon. echo "hello" > /dev/console I think your problem was related to writing assembler code with WTO macros? Scott On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper wrote: Maybe a bit late. But a plain WTO via an echo to /dev/console not an option? Sent from my wireless iPhone On 19 Nov 2019, at 18:52, scott Ford wrote: Bruce, Peter, all: A big thanks . its much appreciated by this older t-rex. Scott On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson wrote: Hello Scott, How I do it. in CSECT copy list form from CONSTANTs section to DSECT working section Update message text run WTO execute form in DSECT WTO list form map in Constants WTO_text WTO list form with text WTO_length = * - WTO_text DESCT maps onto your own STORAGE area, thus copying the constant LIST form over the DSECT map makes the code reentrant. On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: Peter, I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i Regards Bruce -- 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 -- 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
Henri, That’s what ended up doing , thank you, I appreciate any help. Scott On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper wrote: > Maybe a bit late. But a plain WTO via an echo to /dev/console not an > option? > > Sent from my wireless iPhone > > > On 19 Nov 2019, at 18:52, scott Ford wrote: > > > > Bruce, Peter, all: > > > > A big thanks . its much appreciated by this older t-rex. > > > > Scott > > > >> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson > >> wrote: > >> > >> Hello Scott, > >> > >> How I do it. > >> > >> in CSECT copy list form from CONSTANTs section to DSECT working section > >> Update message text > >> run WTO execute form > >> > >> in DSECT > >> WTO list form map > >> > >> in Constants > >> WTO_text WTO list form with text > >> WTO_length = * - WTO_text > >> > >> DESCT maps onto your own STORAGE area, thus copying the constant LIST > form > >> over the DSECT map makes the code reentrant. > >> > >> > >> > >> > >> > >>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford > wrote: > >>> > >>> Peter, > >>> > >> > >>> I have to add displays ( WTOs ). I dont have complaints again IBM, > rarely, > >>> best people I ever worked with, my issue is howtos. Working examples > which > >>> I can refer to and understand > >>> (prototype) before I start writing code. When to use the execute form > of > >>> the macro vs list, also let me add I was never an applications > program, i > >> > >> > >> > >> Regards > >> Bruce > >> > >> -- > >> 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Maybe a bit late. But a plain WTO via an echo to /dev/console not an option? Sent from my wireless iPhone > On 19 Nov 2019, at 18:52, scott Ford wrote: > > Bruce, Peter, all: > > A big thanks . its much appreciated by this older t-rex. > > Scott > >> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson >> wrote: >> >> Hello Scott, >> >> How I do it. >> >> in CSECT copy list form from CONSTANTs section to DSECT working section >> Update message text >> run WTO execute form >> >> in DSECT >> WTO list form map >> >> in Constants >> WTO_text WTO list form with text >> WTO_length = * - WTO_text >> >> DESCT maps onto your own STORAGE area, thus copying the constant LIST form >> over the DSECT map makes the code reentrant. >> >> >> >> >> >>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: >>> >>> Peter, >>> >> >>> I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, >>> best people I ever worked with, my issue is howtos. Working examples which >>> I can refer to and understand >>> (prototype) before I start writing code. When to use the execute form of >>> the macro vs list, also let me add I was never an applications program, i >> >> >> >> Regards >> Bruce >> >> -- >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Bruce, Peter, all: A big thanks . its much appreciated by this older t-rex. Scott On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson wrote: > Hello Scott, > > How I do it. > > in CSECT copy list form from CONSTANTs section to DSECT working section > Update message text > run WTO execute form > > in DSECT > WTO list form map > > in Constants > WTO_text WTO list form with text > WTO_length = * - WTO_text > > DESCT maps onto your own STORAGE area, thus copying the constant LIST form > over the DSECT map makes the code reentrant. > > > > > > On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: > > >Peter, > > > > >I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, > >best people I ever worked with, my issue is howtos. Working examples which > >I can refer to and understand > >(prototype) before I start writing code. When to use the execute form of > >the macro vs list, also let me add I was never an applications program, i > > > > Regards > Bruce > > -- > 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: WTO
Hello Scott, How I do it. in CSECT copy list form from CONSTANTs section to DSECT working section Update message text run WTO execute form in DSECT WTO list form map in Constants WTO_text WTO list form with text WTO_length = * - WTO_text DESCT maps onto your own STORAGE area, thus copying the constant LIST form over the DSECT map makes the code reentrant. On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: >Peter, > >I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, >best people I ever worked with, my issue is howtos. Working examples which >I can refer to and understand >(prototype) before I start writing code. When to use the execute form of >the macro vs list, also let me add I was never an applications program, i Regards Bruce -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
IMHO the more technical individuals stands a chance of already knowing some of the missing information, but the less technical individuals are SOL if needed information is missing. Historically, some groups have done better than others at writing manuals, e.g., the people documenting PL/I were much better than the people documenting utilities. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of scott Ford Sent: Sunday, November 17, 2019 2:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Seymour, The way information in various manuals , including IBM and CA has changed. I see it as being structured for the less technical individuals. But thats my opinion .. Scott On Tue, Nov 12, 2019 at 1:57 PM Seymour J Metz wrote: > It's an obvious place, but it doesn't contain the information. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Steve Smith > Sent: Tuesday, November 12, 2019 9:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > If you need this in black & white, see chapter 1 of the MVS Assembler > Services Reference. > > btw, it seems like an "obvious" place to me. > > sas > > On Tue, Nov 12, 2019 at 8:00 AM Peter Relson wrote: > > > > > FSVO is; that is where the information on the responsibilities of > > user-written subroutines is. Perhaps it was supposed to say that system > > services are written to do the same thing, but it doesn't. > > > > > > It should not need to "say" that. Linkage conventions do not apply only > > to interfaces between what you consider a "user" and another user or the > > system. > > > > 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 > > > > > -- > sas > > -- > 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” http://secure-web.cisco.com/1dGD3bKJkN7MAnWuI03_olppJnj2FRlRXQRXwKmaAmjyXTWoWc40LptE8G0vdI1FIeJdXO0rNmx23sX8y1U4u7fzjiRUxTOcGwKpxdwJxN548u2sfeuFTo29uKBv4Vy8I3wvnpbo0Yxdu8hSmG8w-byQNfwemJtfK_oxkQm5AEPY8w0Dzfc_tq7iNmyHRN8llyNM6X_S5H3TcT8FSFDg4ux3VEnDo5fPot675V_yRzyKjQjIsAkQaMi4o4PXWnAoodzrteJGHhMiFH5IRXJl-8KBZE_wNOuX7Wae-MDTNZOak0sKpdTAqpZ8BAz18-1ltP4kG_t_jhNTH8bbzFL64eyM0bZKK_NN9rj3brfQO1WF4L5BqDxvMewct4xuUipFbeYyWLgVP50gbO86AHa6jtYl4CXR9geLt1JjlbPGtk0OJrEAPYqkZ73clzUf--3pS/http%3A%2F%2Fwww.idmworks.com scott.f...@idmworks.com Blog: http://secure-web.cisco.com/1U0ABXBh6DTEmjXcYJeCnr7E_Req9mXTFW1X3RAz7b46i_q7FzwuSko1rrtrcytoK1GyCrSK-hAExG_OlcQ_1s9nbCbDW3FhZaK7wC9oisH1Brhj2Wa9fnpAK0C8X87g14ZsxjtKJNpCiXEOxZCtVAKKgc4wwkKrCb0I0ne4ordmKO4AiOALvfIUjqQgO_6aRaNaNXBPPlQlKVvS0vDFFuNMT1zV3yY7kHyKSkAPzzXuvod8IbOsKB8THPcK_Qb_5PxDMjUzMJ7HEeOJE6Q-_XBP5uq6qDbDcg-L9BXimK9A2R8rdGiilgWe2JG9GUvouMEDwABotnsYJRMi4t9NzHU5NBVLuQtIP0fs760uxhYZmajlseNuD5jHc4Ywzw1X1rcwFJUX61g-hFRS4llyvOVVwX3gKi3WEiCXu2QCi11IvAWm5m69M1Aam9zWTMku6/http%3A%2F%2Fwww.idmworks.com%2Fblog *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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
IMHO, as long as IBM takes the position that supplied samples are not guarantied to be correct, the SRL should explain everything in enough detail that you don't need to rely on the sample. In the specific case of WTO, I suggest that you look at the generated code for various forms. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of scott Ford Sent: Monday, November 18, 2019 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Peter, I agree, since I have been around IBM hardware/software 40+ yrs. My chief complaint is samples. I came up through the ranks the hardway, OJT (on the Job Training ), night school while i was in Operations. So I spend a lot of time digging for examples. Recently, a good example , I am working with another Vendor's exit which i am very familiar with and it is re-entrant. I understand the re-entrant part but I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i was an am a Systems Programmer, so that slants things a tad. Can you offer or anyone offer a place to start looking for examples when one gets into a situation like exits and wtos ..?? Respectfully, Scott On Mon, Nov 18, 2019 at 8:07 AM Peter Relson wrote: > > The way information in various manuals , including IBM and CA has changed. > I see it as being structured for the less technical individuals. > > > Care to provide some examples within the IBM manuals? The presentation of > information in z/OS technical publications is largely unchanged for a very > long time (aside from the recent change from the SMIC to the RURS for > those who are aware of those acronyms). > > 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 > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” http://secure-web.cisco.com/1EtGFPpJlIN8q2GT0iipTz7CIF2QT00EiBMoWKkes4sam-s1NoyqVCGr2LKTFBCJ1rhKmt4touX-wb1Qeg5lkczfZqj_sDFq30Q0oJdAb-rMgdW4w1-L1j7YiEbWU5EEOab7A31A1NMu4PwTvMflb7y20ZyY4cM-h3nIaZrPjcNtIjRqbIJlp2OqCYuGxExvJ8NFXPE8wsLfOEsXtOVFWApi5__flbDSHAOR7s1RYwTqR__uJbWsg0dX8WHkZxZ0UmTW3zklq-7bhKC9qKJ1v6gm2xKarcV5vznp5eZ_qftbTv_sGvSczzCimzW3rY4X-kHjWoHEfrXsUMAPWV0IIAzsAQ1YAxWGBrHPBRNdtch35hSFCAyvIiugjF4CfHZUVMptEfbN6D6BP3geJwelr8J_WNK2sn2RrzunCTRS6zJJ63tfWeliv7bds9EESA657/http%3A%2F%2Fwww.idmworks.com scott.f...@idmworks.com Blog: http://secure-web.cisco.com/1vTzbiRp7QCh3UU4m1iRAa80nUFtpRlwGeuCvE0sSiWNoD46pGVMi6iv0N6YmOnwpiQWiUrEueX9Y1qULf1ri7sar_Yfa-3AZsOCZCRoN2_HRB1iaY1smzoHkifTwbT6dKqrCWVr-EcfOMZ-YwP0jOBxiDqwFFLoUSi1NgHUvvZTojNsCmEdZCyJHv73KSf92ZQDrPeWz6SG7gbcXTRWKNRFDGjTetw_wtVQM0B_ZnJH2nnHWa8WRAHbk_aSdK5AJTTNiMaieQg6Xo_yPHDu4mD5DlGOdJKun5PDwwHjq_S-vamh3cEnf37yFtvefIVSX2K02dx5XC-a0V1KU0C5IKUN7V-3unZ8onDl0QRoS7LoMRhBNkqag7uYdtTHzDRwH0kQadeJeXhwhnsBTA-BDsGqzwYDiiQcQq3cWPtbS3R7ldPorrbiiiP3WgeiEvFfj/http%3A%2F%2Fwww.idmworks.com%2Fblog *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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Peter, I agree, since I have been around IBM hardware/software 40+ yrs. My chief complaint is samples. I came up through the ranks the hardway, OJT (on the Job Training ), night school while i was in Operations. So I spend a lot of time digging for examples. Recently, a good example , I am working with another Vendor's exit which i am very familiar with and it is re-entrant. I understand the re-entrant part but I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i was an am a Systems Programmer, so that slants things a tad. Can you offer or anyone offer a place to start looking for examples when one gets into a situation like exits and wtos ..?? Respectfully, Scott On Mon, Nov 18, 2019 at 8:07 AM Peter Relson wrote: > > The way information in various manuals , including IBM and CA has changed. > I see it as being structured for the less technical individuals. > > > Care to provide some examples within the IBM manuals? The presentation of > information in z/OS technical publications is largely unchanged for a very > long time (aside from the recent change from the SMIC to the RURS for > those who are aware of those acronyms). > > 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 > -- *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: WTO
The way information in various manuals , including IBM and CA has changed. I see it as being structured for the less technical individuals. Care to provide some examples within the IBM manuals? The presentation of information in z/OS technical publications is largely unchanged for a very long time (aside from the recent change from the SMIC to the RURS for those who are aware of those acronyms). 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
Seymour, The way information in various manuals , including IBM and CA has changed. I see it as being structured for the less technical individuals. But thats my opinion .. Scott On Tue, Nov 12, 2019 at 1:57 PM Seymour J Metz wrote: > It's an obvious place, but it doesn't contain the information. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Steve Smith > Sent: Tuesday, November 12, 2019 9:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > If you need this in black & white, see chapter 1 of the MVS Assembler > Services Reference. > > btw, it seems like an "obvious" place to me. > > sas > > On Tue, Nov 12, 2019 at 8:00 AM Peter Relson wrote: > > > > > FSVO is; that is where the information on the responsibilities of > > user-written subroutines is. Perhaps it was supposed to say that system > > services are written to do the same thing, but it doesn't. > > > > > > It should not need to "say" that. Linkage conventions do not apply only > > to interfaces between what you consider a "user" and another user or the > > system. > > > > 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 > > > > > -- > sas > > -- > 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: WTO
It's an obvious place, but it doesn't contain the information. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Tuesday, November 12, 2019 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO If you need this in black & white, see chapter 1 of the MVS Assembler Services Reference. btw, it seems like an "obvious" place to me. sas On Tue, Nov 12, 2019 at 8:00 AM Peter Relson wrote: > > FSVO is; that is where the information on the responsibilities of > user-written subroutines is. Perhaps it was supposed to say that system > services are written to do the same thing, but it doesn't. > > > It should not need to "say" that. Linkage conventions do not apply only > to interfaces between what you consider a "user" and another user or the > system. > > 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 > -- sas -- 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
If you need this in black & white, see chapter 1 of the MVS Assembler Services Reference. btw, it seems like an "obvious" place to me. sas On Tue, Nov 12, 2019 at 8:00 AM Peter Relson wrote: > > FSVO is; that is where the information on the responsibilities of > user-written subroutines is. Perhaps it was supposed to say that system > services are written to do the same thing, but it doesn't. > > > It should not need to "say" that. Linkage conventions do not apply only > to interfaces between what you consider a "user" and another user or the > system. > > 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 > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: High halves, ARs and old vs. new expectations (Was "WTO")
The C or COBOL expects high halves and ARs to be preserved. The assembler routine is ignorant of them. It calls a z/OS function which alters some high halves. Is there a problem? I am tending to think not. The z/OS function (hopefully!) does not alter anything that the modern C or COBOL expects to be preserved. Am I right? Let's be precise. Neither C nor COBOL expects exactly what you wrote. They expect what the linkage conventions say they can expect. So, for example, they expect that high halves 2-14 and ARs 2-14 to be preserved (and they expect that low halves 2-13 are preserved). The z/OS function, whatever it is, will conform to its documentation which in turn relies on the base being what the linkage conventions say. I think that by "alter" you mean both that it alters and also that it does not restore. No function would change to do so. That would be incompatible. New functionality could choose to do so (and document so). Then it would be up to the exploiter of that new function to accommodate that. Here too no harm is done to code that is ignorant of high halves (in this case, code using the new function cannot be considered to be ignorant). 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
FSVO is; that is where the information on the responsibilities of user-written subroutines is. Perhaps it was supposed to say that system services are written to do the same thing, but it doesn't. It should not need to "say" that. Linkage conventions do not apply only to interfaces between what you consider a "user" and another user or the system. 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
>I suppose that that depends what you think is the "obvious location". >I think that the obvious location is in the linkage conventions >documentation (which is within the assembler services guide). Indeed. >That is where the information is. FSVO is; that is where the information on the responsibilities of user-written subroutines is. Perhaps it was supposed to say that system services are written to do the same thing, but it doesn't. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Sunday, November 10, 2019 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Yes it's documented and legit, but it's a change in behaviour over the last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15, and STORAGE OBTAIN did not change the high half of R1. You have no way of knowing if that is true or not. All that you could possibly say is that you did not encounter such a case. The environment that could cause such a case might even not have been under your control and might be uncommon. Anyone relying on the system to preserve regs 0,1,15 (high half or low half, AR or not) in the absence of explicit documentation otherwise is doing so at their customers' peril. This is not new news. The statement is not correct about STORAGE OBTAIN. The high half of R1 has been changed on STORAGE OBTAIN ever since high halves existed. I think that there was a situation, due to user code relying incorrectly on the high half of reg 15 being unchanged across the invocation, where STORAGE OBTAIN acceptably changed the high half of GR15 and the incorrect user code stopped working. Worse, I can't find the general description that existed way back when about R15-R1 being transient. If it's still there, it's not in the obvious location. I suppose that that depends what you think is the "obvious location". I think that the obvious location is in the linkage conventions documentation (which is within the assembler services guide). That is where the information is. Copied from the assembler services guide: Unless otherwise defined by the individual interface, the calling program expects upon return: The low halves (Bits 32-63) of GPRs 2 - 13 are unchanged The high halves (Bits 0-31) of GPRs 2 - 14 are unchanged ARs 2 - 13 are unchanged FPRs 8 - 15 are unchanged; The Floating Point Control (FPC) Register is unchanged except for two fields: the IEEE exception flags and the data exception code (DXC). Vector registers (VRs) 8 - 15, bytes 0 - 7, and the entirety of VRs 16 - 23 are unchanged. When return information is provided in GPR 0, 1, or 15 (for example return and reason codes), only bits 32-63 of the register contain the returned value. Individual interfaces can define that extra registers are unchanged, or that extra registers are not unchanged, or that returned information in registers uses more than bits 32-63. 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
That depends. The short answer is that if the parameter list is in dynamic storage then it is reentrant. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of scott Ford Sent: Sunday, November 10, 2019 5:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Guys, Yeah I found it it happens to be another Well known ISV’s exit. But I have a question in regard to when this exit is called it’s like IRREVX01 , so I assume (I know ) that the WTO should be re-entrant. We are basically using it for diagnostics if needed. Is my assumption correct on the WTO ? Scott On Sun, Nov 10, 2019 at 3:59 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Sun, 10 Nov 2019 09:30:30 -0500, Peter Relson wrote: > > > > >Yes it's documented and legit, but it's a change in behaviour over the > >last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15, > >and STORAGE OBTAIN did not change the high half of R1. > > > > > >You have no way of knowing if that is true or not. All that you could > >possibly say is that you did not encounter such a case. The environment > >that could cause such a case might even not have been under your control > >and might be uncommon. ... > > > I.e. the user, or even an ISV, was depending on undocumented behavior's > remaining unchanged. > > >The statement is not correct about STORAGE OBTAIN. The high half of R1 > has > >been changed on STORAGE OBTAIN ever since high halves existed. ... > > > Does code written at a time before "high halves existed", or perhaps even > before ARs existed, and depending only on OS behavior documented at > such a time, continue to operate correctly? If so, a user has no ground > for a complaint. If it fails now, IBM should graciously apologize and move > on. The pertinent aphorism is, "You can't make an omelet without breaking > eggs." > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- 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: High halves, ARs and old vs. new expectations (Was "WTO")
On Mon, Nov 11, 2019 at 8:45 AM Charles Mills wrote: > Sure, there are lots of solutions (assuming the shop is not mortally > afraid of touching 1993 assembler code, has a budget and staff to do so, > and can find the source). > > My thought is why would the shop expect a problem? Why would a routine > that has been working since 1993 be a suspect in an obscure > high-halves-in-compiled-code problem? > I guess we'll just have to say "times change". Or, if we want to be "nasty", we could say "What isn't specifically saved is subject to being changed." Of course, this means a code review when something significant changes, such as from 32 bit registers to 64 bit registers. Your code might not have changed, but IBM's might have. Ergo, all use of an API used in code _should_ be reviewed. Of course, who has time for that? Curiously, at least around her, that would be another bullet in the "z/OS is junk" argument, despite the fact that Windows has historically had even worse problems. > > Charles > > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: High halves, ARs and old vs. new expectations (Was "WTO")
Sure, there are lots of solutions (assuming the shop is not mortally afraid of touching 1993 assembler code, has a budget and staff to do so, and can find the source). My thought is why would the shop expect a problem? Why would a routine that has been working since 1993 be a suspect in an obscure high-halves-in-compiled-code problem? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 11, 2019 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: High halves, ARs and old vs. new expectations (Was "WTO") On Mon, Nov 11, 2019 at 7:52 AM Charles Mills wrote: > > The interesting scenario is the case of the "know something" caller > > calling a "know nothing" target which in turn calls a "know something" > > target. > > I've been thinking about that one for a couple of days. My scenario is > this: > a recently-compiled C or COBOL program calling a homegrown assembler > function untouched since 1993 calling an MVS service, which now of course > is > a z/OS V2R4 service. > > The C or COBOL expects high halves and ARs to be preserved. The assembler > routine is ignorant of them. It calls a z/OS function which alters some > high > halves. Is there a problem? > > I am tending to think not. The z/OS function (hopefully!) does not alter > anything that the modern C or COBOL expects to be preserved. Am I right? > > Charles > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > IMO, don't do a static "call" to the assembler. I don't know off hand if it is possible, but I'd try to make the HLASM's calling code use the equivalent of a z/OS LINK macro. If that's not possible, then I'd make a slight change to the z/OS HLASM to save the 64 bit GRs and the ARs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: High halves, ARs and old vs. new expectations (Was "WTO")
On Mon, Nov 11, 2019 at 7:52 AM Charles Mills wrote: > > The interesting scenario is the case of the "know something" caller > > calling a "know nothing" target which in turn calls a "know something" > > target. > > I've been thinking about that one for a couple of days. My scenario is > this: > a recently-compiled C or COBOL program calling a homegrown assembler > function untouched since 1993 calling an MVS service, which now of course > is > a z/OS V2R4 service. > > The C or COBOL expects high halves and ARs to be preserved. The assembler > routine is ignorant of them. It calls a z/OS function which alters some > high > halves. Is there a problem? > > I am tending to think not. The z/OS function (hopefully!) does not alter > anything that the modern C or COBOL expects to be preserved. Am I right? > > Charles > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > IMO, don't do a static "call" to the assembler. I don't know off hand if it is possible, but I'd try to make the HLASM's calling code use the equivalent of a z/OS LINK macro. If that's not possible, then I'd make a slight change to the z/OS HLASM to save the 64 bit GRs and the ARs. -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Fri, Nov 8, 2019 at 2:30 PM scott Ford wrote: > All: > > I have a bit of an issue I am trying to resolve in Assembler. We use a > skeleton exit from another vendor and it has been working fine. > It is re-entrant and keep seeing normal WTO's , i.e. ; WTO > 'X',ROUTCDE=11 , are not appearing on SYSLOG. We are using the > WTOS to track through the flow of the exit. Could what i am seeing the exit > being re-entrant and since WTO's use R1 that R1 is being destroyed by > some task ?? > > Scott > > -- > Not every WTO goes to SYSLOG. A message can be suppressed my an MPF exit, or an "automated operations" package. Even without those, a message must pass some criteria to be included. Those are listed here : https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag300/iea3g371.htm (there is "Have the “hardcopy only” message delivery attribute" which migt be OK). To me the simplest way to ensure it is written to the SYSLOG is to use a DESC of either 1, 2, 3, 11, or 12. 1 is "Systen Failure" (nope, wouldn't use that). 2 is "Immediate Action Required" (nope). 3 is "Eventual Action Require" (perhaps). 11 is "Critical Eventual Action Required" (nope). 12 is "Important Information" (sound good to me). Of course, check that R1 is correct and then check R15 upon return to see if something "bad" happened. Also, as an alternative to WTO is the WTL macro. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa900/iea3a9_Description23.htm But IBM says "IBM® recommends you use the WTO macro with the MCSFLAG=HRDCPY parameter instead of WTL, because WTO supplies more data than WTL." -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
High halves, ARs and old vs. new expectations (Was "WTO")
> The interesting scenario is the case of the "know something" caller > calling a "know nothing" target which in turn calls a "know something" > target. I've been thinking about that one for a couple of days. My scenario is this: a recently-compiled C or COBOL program calling a homegrown assembler function untouched since 1993 calling an MVS service, which now of course is a z/OS V2R4 service. The C or COBOL expects high halves and ARs to be preserved. The assembler routine is ignorant of them. It calls a z/OS function which alters some high halves. Is there a problem? I am tending to think not. The z/OS function (hopefully!) does not alter anything that the modern C or COBOL expects to be preserved. Am I right? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, November 11, 2019 5:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Does code written at a time before "high halves existed", or perhaps even before ARs existed, and depending only on OS behavior documented at such a time, continue to operate correctly? I can't think of a case where it wouldn't. Because such code would not have known anything about AMODE 64 or high halves. It would not have had any instructions or behavior that could have been affected by data in any high half (or any AR). That is why (at least "old") services (even with newer support that deals with 64-bit regs) are not supposed to look at data in high halves if the caller is not AMODE 64. That is why old services are not supposed to look at ARs if the caller is not AMODE 31. Going back to MVS/XA, that is why old services are not supposed to look at the high byte of an address if the caller is not AMODE 31 (and, now, is not AMODE 64). Services created after the advent of a new function (be that 64-bit GRs, ARs, or whatever) might always require the user to be cognizant of those new functions. The interesting scenario is the case of the "know something" caller calling a "know nothing" target which in turn calls a "know something" target. The "know nothing" target would not have any code to preserve high halves (or ARs if it went that far back). This is behind the asymmetry in the linkage convention for GRs (high half of GR14 is preserved, low half of GR14 is not for the AMODE 31 case). I'll leave it as an exercise to the reader of how this could be important. For AMODE 64 cases, that asymmetry does not exist. I'd bet that there are (likely many) branch-entry services that do not follow this convention; almost all get away with it just fine (if you're PC-entered or even if you use BAKR to save regs, you're pretty much safe because the PR restores the saved reg 14). Using the high half of GR14, when not AMODE 64, for saving "something" and expecting that to be preserved across a branch-entry interface is counter-intuitive (even if the linkage convention says you can do so). I'd guess that almost no one codes to such an expectation. But then I'd have guessed the same would be true for the high halves of GR0 and GR1 and GR15 (and AR1 and AR15) where they should have known better. 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
Does code written at a time before "high halves existed", or perhaps even before ARs existed, and depending only on OS behavior documented at such a time, continue to operate correctly? I can't think of a case where it wouldn't. Because such code would not have known anything about AMODE 64 or high halves. It would not have had any instructions or behavior that could have been affected by data in any high half (or any AR). That is why (at least "old") services (even with newer support that deals with 64-bit regs) are not supposed to look at data in high halves if the caller is not AMODE 64. That is why old services are not supposed to look at ARs if the caller is not AMODE 31. Going back to MVS/XA, that is why old services are not supposed to look at the high byte of an address if the caller is not AMODE 31 (and, now, is not AMODE 64). Services created after the advent of a new function (be that 64-bit GRs, ARs, or whatever) might always require the user to be cognizant of those new functions. The interesting scenario is the case of the "know something" caller calling a "know nothing" target which in turn calls a "know something" target. The "know nothing" target would not have any code to preserve high halves (or ARs if it went that far back). This is behind the asymmetry in the linkage convention for GRs (high half of GR14 is preserved, low half of GR14 is not for the AMODE 31 case). I'll leave it as an exercise to the reader of how this could be important. For AMODE 64 cases, that asymmetry does not exist. I'd bet that there are (likely many) branch-entry services that do not follow this convention; almost all get away with it just fine (if you're PC-entered or even if you use BAKR to save regs, you're pretty much safe because the PR restores the saved reg 14). Using the high half of GR14, when not AMODE 64, for saving "something" and expecting that to be preserved across a branch-entry interface is counter-intuitive (even if the linkage convention says you can do so). I'd guess that almost no one codes to such an expectation. But then I'd have guessed the same would be true for the high halves of GR0 and GR1 and GR15 (and AR1 and AR15) where they should have known better. 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
