Re: 2.5 Heads Up
I assume that PR/SM still uses SIE, so the fundamental question is whether SIE supports second level ZAD.But, yes, regardless an RFE for z/VM should be the first step. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Tuesday, March 1, 2022 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up ZAD is not supported on z/OS under z/VM. ":-( Is there any SOD or RFE or the like for this? That would have to be an RFE for z/VM (and conceivably also for the machine itself). At least at the time this was introduced and z/OS exploited it, z/VM did not surface the ZAD capability to a guest. I do not know if that is still the case. If it is surfaced, SLIP will allow it. So you could try and see if you get an acceptance vs rejection message. And if you get the former, please submit a pub update request. 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: 2.5 Heads Up
ZAD is not supported on z/OS under z/VM. ":-( Is there any SOD or RFE or the like for this? That would have to be an RFE for z/VM (and conceivably also for the machine itself). At least at the time this was introduced and z/OS exploited it, z/VM did not surface the ZAD capability to a guest. I do not know if that is still the case. If it is surfaced, SLIP will allow it. So you could try and see if you get an acceptance vs rejection message. And if you get the former, please submit a pub update request. 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: 2.5 Heads Up
On Mon, 28 Feb 2022 at 10:50, Ed Jaffe wrote: > On 2/28/2022 5:21 AM, Allan Staller wrote: > > > Peter, > > Can you post the trap? > > > https://www.ibm.com/docs/en/zos/2.5.0?topic=traps-slip-zero-address-detection-zad > "ZAD is not supported on z/OS under z/VM. ":-( Is there any SOD or RFE or the like for this? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
Classification: Confidential Thanks Ed -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Jaffe Sent: Monday, February 28, 2022 9:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don't click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] On 2/28/2022 5:21 AM, Allan Staller wrote: > Classification: Confidential > > Peter, > Can you post the trap? https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dtraps-slip-zero-address-detection-zaddata=04%7C01%7Callan.staller%40HCL.COM%7Cd60027a37a5b4957dd5f08d9fad20ec3%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637816602673605564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GoPgZ8w1Ynntt8rWiiG%2BztOg3rgfM4Xm4PzE4i4Jklo%3Dreserved=0 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.phoenixsoftware.com%2Fdata=04%7C01%7Callan.staller%40HCL.COM%7Cd60027a37a5b4957dd5f08d9fad20ec3%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637816602673605564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=CTOJkEDHyvY52vfujY%2FDa4P4IaohF7Vdarnj8I%2BS3r4%3Dreserved=0 This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
On 2/28/2022 5:21 AM, Allan Staller wrote: Classification: Confidential Peter, Can you post the trap? https://www.ibm.com/docs/en/zos/2.5.0?topic=traps-slip-zero-address-detection-zad -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
Classification: Confidential Peter, Can you post the trap? Thanks in advance, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Saturday, February 26, 2022 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] You apparently also do not run with Zero Address Detection activated (a SLIP ZAD trap). You should strongly consider doing so. As to "the cat's out of the bag": a bag of IBM+ISV's is a pretty big bag. You use undocumented things at your own risk. 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 ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
You apparently also do not run with Zero Address Detection activated (a SLIP ZAD trap). You should strongly consider doing so. As to "the cat's out of the bag": a bag of IBM+ISV's is a pretty big bag. You use undocumented things at your own risk. 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: 2.5 Heads Up
Yep. We ran into a 14-year old bug when trying to run one of our products on a system it normally isn't run on. Eventually tracked it down to an incorrect (CLC which should have been CLI) reference to a PSA field which had always been zero. But on that one system, someone had fired up IGVDGNPP and that field wasn't zero. Tilt. Luckily we hit it before a customer (or IBM) did. Good test tool. Why isn't it documented? The cat's out of the bag now. Check with Google. /Leonard Jim Mulder wrote on 2/22/2022 11:37 AM: Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will modify all of the reserved fields in every CPU's PSA in order to expose latent defects in code that happens to seem to work when reserved fields contain zeroes. But since that may expose latent defects in other code (IBM, ISV, or customer), it's not the kind of thing you would want to use on a production system. We of course use that tool on our test systems, so that we tend to not have zeros at PSA+4 on our z/OS 2.5 test systems, which may have contributed to the bug escaping our notice until it got into the field. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 02/22/2022 10:26:40 AM: From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Date: 02/22/2022 02:28 PM Subject: Re: 2.5 Heads Up Sent by: "IBM Mainframe Discussion List" Would using some "debug" type utility to store a non-zero value at address 4 be a partial circumvention? The pre-Z restart PSW is never used for anything now -- is that correct? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, February 21, 2022 10:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Location 4 means address 4 (i.e. offset 4 in the PSA). There was a latent bug from a prior release in the loop control code so that it was erroneously fetching from address 4, and behaving especially badly when the data at that location is x'', which it is as of z/OS 2.5. In prior releases, it was x'000130E1' when in zArchitecture mode. -- 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: 2.5 Heads Up
On 2/22/2022 3:33 PM, Seymour J Metz wrote: Are you sure that it doesn't change the timing? We have seen no observable difference in execution timing. We run it constantly... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
For ESA it's real (not absolute) addresses 0-511; for Z architecture the firs 512 bytes of the second page fram are also protected. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Tuesday, February 22, 2022 1:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Right ... Is there a control register bit or something like that for authority to store in the PSA (+ Key 0 of course). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, February 22, 2022 9:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up There will be multiple versions of that address for PSA for each active processor in the LPAR. I don't think that KEY 0 is adequate authority to store there either. Could be done from a hardware console though. -- 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: 2.5 Heads Up
Are you sure that it doesn't change the timing? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Ed Jaffe [edja...@phoenixsoftware.com] Sent: Tuesday, February 22, 2022 4:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up On 2/22/2022 1:22 PM, Seymour J Metz wrote: >> ZAD SLIP tracing can catch these issues without changing the outcomes. > ? https://www.ibm.com/docs/en/zos/2.5.0?topic=traps-slip-zero-address-detection-zad -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1d309o_nymYI4NN81SNQkROySA789myax_FNmDF4wdekHkf5qOcDYvHGuOQ7rhaurezAWcbUIXhzufzfx4Ik4pzYwwmZoerhyOzoei6FF1aXvaBtPUdtuaj1V-0X5Yuaj0WwAW64h_V5x2fYyLqeeCgwz3ltssPfeOc4aqG9y_3iR0ynUt-IpA3FzP_DHoQZoun6N-o7NYfWR0p5KciVNgvrXmwmJ7JPoo4bOnt9QSsMFKd-yqQLwF_awcR3MLqiKorP-wvicETOyvBn4pG5UThfApMD3SAaQpSLhaljsr0hgKxFFlrfpWk-tjYyLYeYjHI81jUnnZDcwP1NRa-Eh0RuP6BL_nTZp64mE64R42R9Td_uLJSTTaT2Xw_RkL4gnSip2HK5Z2LXD6McT84Cq8htuAMRIzPLoRUUlfcz7c7eCVHg6lIixALmuOYZvuIof/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
On 2/22/2022 1:22 PM, Seymour J Metz wrote: ZAD SLIP tracing can catch these issues without changing the outcomes. ? https://www.ibm.com/docs/en/zos/2.5.0?topic=traps-slip-zero-address-detection-zad -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
>ZAD SLIP tracing can catch these issues without changing the outcomes. ? From: IBM Mainframe Discussion List on behalf of Ed Jaffe Sent: Tuesday, February 22, 2022 3:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up On 2/22/2022 12:28 PM, Seymour J Metz wrote: > I also hate problems that disappear when I turn tracing or other diagnostics > on. ZAD SLIP tracing can catch these issues without changing the outcomes. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1zz7JwFcR3Dnf7eDnDTj6-08C9oMw4zDXReedtZjlpNl583efQ7OBHthtoa5VC1fZhrL-rdSjU6ALJaRzDWN2swwzRleBh3TnIfKifyHSBKi2qi1bZ479PTpkk1Q0dVCcLmDWluhoTWFUgVf57-j4NpgNGlas5KwZIe5y5gNljIU5D8tgyK8TToRe2P7SdxT8VO-LPwFt6zZ2372L6YGmLslfbl3vOisDqcEDuDIlsPkv0_Mn8UKJ73KiHY4yi_vjUiufxtZw4MLyD_eHqGhxVWWFav90zDsT7fDFq8X-xZPFtUny-JhL1d-O71xAGgy4k9E4kn8YEK7pLx7Ms5XvIMKF69WPEftfvUZu6tBODdlz8FRp3Jzxqx8EGuG8DY1wAAbb4A-n6mOxmKW6_Znjb6xhnwf6L7uEET_UBV0LQTE72ErB-aRmLeHtBIcRxFTE/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
> expose latent defects in code that happens to seem to work when reserved fields contain zeroes Need to test the other side of that coin: code that only works when a reserved field contains non-zeroes. Obviously there is no limit to the possible conditions. What about code that erroneously tests one bit of some reserved field, or does an erroneous TM/BM on some reserved field? Software testing, as all of us know too well, is a fraught exercise. Finding bugs is not too bad; it's the finding of the *absence* of bugs that is tough. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Tuesday, February 22, 2022 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will modify all of the reserved fields in every CPU's PSA in order to expose latent defects in code that happens to seem to work when reserved fields contain zeroes. But since that may expose latent defects in other code (IBM, ISV, or customer), it's not the kind of thing you would want to use on a production system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
On 2/22/2022 12:28 PM, Seymour J Metz wrote: I also hate problems that disappear when I turn tracing or other diagnostics on. ZAD SLIP tracing can catch these issues without changing the outcomes. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
I also hate problems that disappear when I turn tracing or other diagnostics on. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Tuesday, February 22, 2022 3:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up On Tue, 22 Feb 2022 15:37:51 -0400, Jim Mulder wrote: >.. > We of course use that tool on our test systems, so that we tend to >not have zeros at PSA+4 on our z/OS 2.5 test systems, which may >have contributed to the bug escaping our notice >until it got into the field. > Tsk. Tsk. At times I have requested various tools on our systems, declined because their presence might invalidate our tests. And I recall a piece of vendor software that abended in production mode but gave the result I intended in test mode. SR. "User error: RTFM. You're using something documented as 'unpredictable'." Correct, but too unpredictable for my taste. -- gi -- 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: 2.5 Heads Up
On Tue, 22 Feb 2022 15:37:51 -0400, Jim Mulder wrote: >.. > We of course use that tool on our test systems, so that we tend to >not have zeros at PSA+4 on our z/OS 2.5 test systems, which may >have contributed to the bug escaping our notice >until it got into the field. > Tsk. Tsk. At times I have requested various tools on our systems, declined because their presence might invalidate our tests. And I recall a piece of vendor software that abended in production mode but gave the result I intended in test mode. SR. "User error: RTFM. You're using something documented as 'unpredictable'." Correct, but too unpredictable for my taste. -- gi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
Be nice to have a tool like that to run on our Sand Box systems Might catch some old ALC code doing something not too bright in the z/OS world that was OK at MVS 3.8 Yes, some of us do have code that old. Just say'n' Steve Thompson On 2/22/22 14:37, Jim Mulder wrote: Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will modify all of the reserved fields in every CPU's PSA in order to expose latent defects in code that happens to seem to work when reserved fields contain zeroes. But since that may expose latent defects in other code (IBM, ISV, or customer), it's not the kind of thing you would want to use on a production system. We of course use that tool on our test systems, so that we tend to not have zeros at PSA+4 on our z/OS 2.5 test systems, which may have contributed to the bug escaping our notice until it got into the field. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 02/22/2022 10:26:40 AM: From: "Charles Mills" To:IBM-MAIN@LISTSERV.UA.EDU Date: 02/22/2022 02:28 PM Subject: Re: 2.5 Heads Up Sent by: "IBM Mainframe Discussion List" Would using some "debug" type utility to store a non-zero value at address 4 be a partial circumvention? The pre-Z restart PSW is never used for anything now -- is that correct? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, February 21, 2022 10:03 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Location 4 means address 4 (i.e. offset 4 in the PSA). There was a latent bug from a prior release in the loop control code so that it was erroneously fetching from address 4, and behaving especially badly when the data at that location is x'', which it is as of z/OS 2.5. In prior releases, it was x'000130E1' when in zArchitecture mode. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@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: 2.5 Heads Up
Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will modify all of the reserved fields in every CPU's PSA in order to expose latent defects in code that happens to seem to work when reserved fields contain zeroes. But since that may expose latent defects in other code (IBM, ISV, or customer), it's not the kind of thing you would want to use on a production system. We of course use that tool on our test systems, so that we tend to not have zeros at PSA+4 on our z/OS 2.5 test systems, which may have contributed to the bug escaping our notice until it got into the field. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 02/22/2022 10:26:40 AM: > From: "Charles Mills" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/22/2022 02:28 PM > Subject: Re: 2.5 Heads Up > Sent by: "IBM Mainframe Discussion List" > > Would using some "debug" type utility to store a non-zero value at address 4 > be a partial circumvention? > > The pre-Z restart PSW is never used for anything now -- is that correct? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jim Mulder > Sent: Monday, February 21, 2022 10:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 2.5 Heads Up > > Location 4 means address 4 (i.e. offset 4 in the PSA). > > There was a latent bug from a prior release in the loop control > code so that it was erroneously fetching from address 4, and > behaving especially badly when the data at that location > is x'', which it is as of z/OS 2.5. In prior releases, > it was x'000130E1' when in zArchitecture mode. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
"Low-address protection is under control of bit 35 of control register 0, the low-address-protection-control bit. When the bit is zero, low-address protection is off; when the bit is one, low-address protection is on." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, February 22, 2022 10:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Right ... Is there a control register bit or something like that for authority to store in the PSA (+ Key 0 of course). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, February 22, 2022 9:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up There will be multiple versions of that address for PSA for each active processor in the LPAR. I don't think that KEY 0 is adequate authority to store there either. Could be done from a hardware console though. -- 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: 2.5 Heads Up
Right ... Is there a control register bit or something like that for authority to store in the PSA (+ Key 0 of course). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, February 22, 2022 9:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up There will be multiple versions of that address for PSA for each active processor in the LPAR. I don't think that KEY 0 is adequate authority to store there either. Could be done from a hardware console though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
There will be multiple versions of that address for PSA for each active processor in the LPAR. I don't think that KEY 0 is adequate authority to store there either. Could be done from a hardware console though. Lennie Dymoke-Bradshaw https://rsclweb.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 22 February 2022 15:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Would using some "debug" type utility to store a non-zero value at address 4 be a partial circumvention? The pre-Z restart PSW is never used for anything now -- is that correct? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, February 21, 2022 10:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Location 4 means address 4 (i.e. offset 4 in the PSA). There was a latent bug from a prior release in the loop control code so that it was erroneously fetching from address 4, and behaving especially badly when the data at that location is x'', which it is as of z/OS 2.5. In prior releases, it was x'000130E1' when in zArchitecture mode. -- 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: 2.5 Heads Up
Interesting question, but the problem at hand is pure z/OS. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, February 22, 2022 7:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Do any of z/TPF, z/VM or z/VSE ever run in ESA mode? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Tuesday, February 22, 2022 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Would using some "debug" type utility to store a non-zero value at address 4 be a partial circumvention? The pre-Z restart PSW is never used for anything now -- is that correct? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, February 21, 2022 10:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Location 4 means address 4 (i.e. offset 4 in the PSA). There was a latent bug from a prior release in the loop control code so that it was erroneously fetching from address 4, and behaving especially badly when the data at that location is x'', which it is as of z/OS 2.5. In prior releases, it was x'000130E1' when in zArchitecture mode. -- 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: 2.5 Heads Up
Do any of z/TPF, z/VM or z/VSE ever run in ESA mode? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Tuesday, February 22, 2022 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Would using some "debug" type utility to store a non-zero value at address 4 be a partial circumvention? The pre-Z restart PSW is never used for anything now -- is that correct? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, February 21, 2022 10:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Location 4 means address 4 (i.e. offset 4 in the PSA). There was a latent bug from a prior release in the loop control code so that it was erroneously fetching from address 4, and behaving especially badly when the data at that location is x'', which it is as of z/OS 2.5. In prior releases, it was x'000130E1' when in zArchitecture mode. -- 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: 2.5 Heads Up
Would using some "debug" type utility to store a non-zero value at address 4 be a partial circumvention? The pre-Z restart PSW is never used for anything now -- is that correct? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, February 21, 2022 10:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Location 4 means address 4 (i.e. offset 4 in the PSA). There was a latent bug from a prior release in the loop control code so that it was erroneously fetching from address 4, and behaving especially badly when the data at that location is x'', which it is as of z/OS 2.5. In prior releases, it was x'000130E1' when in zArchitecture mode. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
Yes. From PoOps: In the z/Architecture architectural mode, a restart interruption causes the old PSW to be stored at real locations 288-303 and a new PSW, designating the start of the program to be executed, to be fetched from real locations 416-431. In the ESA/390-compat- ibility mode, a restart interruption causes the short- format old PSW to be stored at real locations 8-15 and a short-format new PSW to be fetched from real locations 0-7. The instruction-length code and inter- ruption code are not stored. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Lennie Dymoke-Bradshaw [032fff1be9b4-dmarc-requ...@listserv.ua.edu] Sent: Monday, February 21, 2022 6:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up Maybe they were using the contents of location 4 instead of a 4? e.g. LA R5,4 vs LA R5,4(,R5) I think location 4 used to be part of the Restart new PSW under old-style 31-bit operation. Maybe it is no longer used. Lennie Dymoke-Bradshaw https://secure-web.cisco.com/1yM40BYyhO9Myr1uDKTVftC_rDZJWU453aYsRt9-vIEFTQYNIqirIxHqlI61L2K7SdEN0zik2mOy1aqNvlhQcoOkidpY1wkqosg98Pmz5RabR9xPu_PXCJjeBvz-clWpmlz8RNW7gJOF6oQTvgR1EVcCemVzoOeYnVvryaKMnaayMjfciNOpGVwbG993h01ccRjrmWmFmdkraas9yWAR_kvJBqL2jqfhy3nNk5FWGmMMeYmuE1nfi_8n8ZWk9MU0_-_XVc205oR5H4lrZ6kBEjpXIKrCOrkKEve-L8PlsRhVDeFE-rLIvfT6uIfrjP0rAwaUHoXqGcxxJC-4U_n1KXliXCiWMK71XinXhzVn6bdGFanQynXe7uSYxhK332leWBVhxXMw5RwS0-FLQLm274Ee4st6Nj1Cuj2HYDNs57Y6aknPmBjpJM4FmjlAW53iD/https%3A%2F%2Frsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 21 February 2022 22:03 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up On Mon, 21 Feb 2022 12:54:14 -0800, Ed Jaffe wrote: >On 2/21/2022 12:00 PM, Mark Jacobs wrote: >> Found APAR OA62381 for this problem. PTFs are not yet available. > Yet: APAR status Closed as program error. >Hugely helpful! THANKS! > >https://www.ibm.com/support/pages/apar/OA62381 > Local fix BYPASS/CIRCUMVENTION: Set DSENQSHR to DISALLOW in the relevant JOBCLASSes Doesn't that just say, "Don't do that!"? Hardly a circumvention. if the storage at location x'0004' is zeroed out. What's llocation 4 supposed to mean? -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
Location 4 means address 4 (i.e. offset 4 in the PSA). There was a latent bug from a prior release in the loop control code so that it was erroneously fetching from address 4, and behaving especially badly when the data at that location is x'', which it is as of z/OS 2.5. In prior releases, it was x'000130E1' when in zArchitecture mode. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 02/21/2022 05:02:54 PM: > From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/22/2022 12:49 AM > Subject: Re: 2.5 Heads Up > Sent by: "IBM Mainframe Discussion List" > > On Mon, 21 Feb 2022 12:54:14 -0800, Ed Jaffe wrote: > > >On 2/21/2022 12:00 PM, Mark Jacobs wrote: > >> Found APAR OA62381 for this problem. PTFs are not yet available. > > > Yet: APAR status > Closed as program error. > > >Hugely helpful! THANKS! > > > >https://www.ibm.com/support/pages/apar/OA62381 > > > Local fix > BYPASS/CIRCUMVENTION: > Set DSENQSHR to DISALLOW in the relevant JOBCLASSes > > Doesn't that just say, "Don't do that!"? Hardly a circumvention. > > if the storage at location x'0004' is zeroed out. > > What's llocation 4 supposed to mean? > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
True, but the hard loop was impacting our users more than the loss of functionally that DSENQSHR provided. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Monday, February 21st, 2022 at 7:30 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 21 Feb 2022 23:51:34 +, Mark Jacobs wrote: > > > I needed to use the circumvention so as to bypass the hard loop in our 2.5 > > system. > > That treats only the symptom. It provides no substitute for the needed > function. > > > Storage location x'0004' is in the PSA. It maps to this; "V(IEAVRSTR)" > > - SECOND HALF OF RESTART NEW PSW MDC128 > > > --- Original Message --- > > > > On Monday, February 21st, 2022 at 5:02 PM, Paul Gilmartin wrote: > > > > > > https://www.ibm.com/support/pages/apar/OA62381 > > > > > > Local fix > > > > > > BYPASS/CIRCUMVENTION: > > > > > > Set DSENQSHR to DISALLOW in the relevant JOBCLASSes > > > > > > Doesn't that just say, "Don't do that!"? Hardly a circumvention. > > -- > > 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: 2.5 Heads Up
On Mon, 21 Feb 2022 23:51:34 +, Mark Jacobs wrote: >I needed to use the circumvention so as to bypass the hard loop in our 2.5 >system. > That treats only the symptom. It provides no substitute for the needed function. >Storage location x'0004' is in the PSA. It maps to this; "V(IEAVRSTR)" - >SECOND HALF OF RESTART NEW PSW MDC128 > >--- Original Message --- >On Monday, February 21st, 2022 at 5:02 PM, Paul Gilmartin wrote: >> > https://www.ibm.com/support/pages/apar/OA62381 >> >> Local fix >> BYPASS/CIRCUMVENTION: >> Set DSENQSHR to DISALLOW in the relevant JOBCLASSes >> >> Doesn't that just say, "Don't do that!"? Hardly a circumvention. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
Maybe they were using the contents of location 4 instead of a 4? e.g. LA R5,4 vs LA R5,4(,R5) I think location 4 used to be part of the Restart new PSW under old-style 31-bit operation. Maybe it is no longer used. Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 21 February 2022 22:03 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2.5 Heads Up On Mon, 21 Feb 2022 12:54:14 -0800, Ed Jaffe wrote: >On 2/21/2022 12:00 PM, Mark Jacobs wrote: >> Found APAR OA62381 for this problem. PTFs are not yet available. > Yet: APAR status Closed as program error. >Hugely helpful! THANKS! > >https://www.ibm.com/support/pages/apar/OA62381 > Local fix BYPASS/CIRCUMVENTION: Set DSENQSHR to DISALLOW in the relevant JOBCLASSes Doesn't that just say, "Don't do that!"? Hardly a circumvention. if the storage at location x'0004' is zeroed out. What's llocation 4 supposed to mean? -- 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: 2.5 Heads Up
I needed to use the circumvention so as to bypass the hard loop in our 2.5 system. Storage location x'0004' is in the PSA. It maps to this; "V(IEAVRSTR)" - SECOND HALF OF RESTART NEW PSW MDC128 Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Monday, February 21st, 2022 at 5:02 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 21 Feb 2022 12:54:14 -0800, Ed Jaffe wrote: > > > On 2/21/2022 12:00 PM, Mark Jacobs wrote: > > > > > Found APAR OA62381 for this problem. PTFs are not yet available. > > Yet: APAR status > > Closed as program error. > > > Hugely helpful! THANKS! > > > > https://www.ibm.com/support/pages/apar/OA62381 > > Local fix > > BYPASS/CIRCUMVENTION: > > Set DSENQSHR to DISALLOW in the relevant JOBCLASSes > > Doesn't that just say, "Don't do that!"? Hardly a circumvention. > > if the storage at location x'0004' is zeroed out. > > What's llocation 4 supposed to mean? > > -- 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: 2.5 Heads Up
On Mon, 21 Feb 2022 12:54:14 -0800, Ed Jaffe wrote: >On 2/21/2022 12:00 PM, Mark Jacobs wrote: >> Found APAR OA62381 for this problem. PTFs are not yet available. > Yet: APAR status Closed as program error. >Hugely helpful! THANKS! > >https://www.ibm.com/support/pages/apar/OA62381 > Local fix BYPASS/CIRCUMVENTION: Set DSENQSHR to DISALLOW in the relevant JOBCLASSes Doesn't that just say, "Don't do that!"? Hardly a circumvention. if the storage at location x'0004' is zeroed out. What's llocation 4 supposed to mean? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
On 2/21/2022 12:00 PM, Mark Jacobs wrote: Found APAR OA62381 for this problem. PTFs are not yet available. Hugely helpful! THANKS! https://www.ibm.com/support/pages/apar/OA62381 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
Found APAR OA62381 for this problem. PTFs are not yet available. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Monday, February 21st, 2022 at 1:22 PM, Ed Jaffe wrote: > On 10/27/2021 8:47 AM, Mark Jacobs wrote: > > > We migrated one of our systems to z/OS 2.5 last weekend and immediately > > started getting a hard loop during job conversion/interpretation either in > > the JES2CIxx or INIT address space depending on your JOBDEF INTERPRET= > > setting. > > > > The loop could occur with any batch job,but not every batch job. IBM has > > found the loop in module IEFNB903 and are looking at it. The looping > > condition only occurs if DSENQSHR is enabled for the job. In our case the > > JOBCLASS definitions had DSENQSHR=AUTO. Once we changed it to > > DSENQSHR=DISALLOW the problem no longer occurred. > > We are now seeing this in our z/OS 2.5 JES2 environments. The loop is in > > IEFNB903. > > Your IBM-MAIN posting was from way back in October. I assumed this would > > have been fixed by now. > > Did IBM take an APAR? > > -- > > Phoenix Software International > > Edward E. Jaffe > > 831 Parkview Drive North > > El Segundo, CA 90245 > > https://www.phoenixsoftware.com/ > > > > This e-mail message, including any attachments, appended messages and the > > information contained therein, is for the sole use of the intended > > recipient(s). If you are not an intended recipient or have otherwise > > received this email message in error, any use, dissemination, distribution, > > review, storage or copying of this e-mail message and the information > > contained therein is strictly prohibited. If you are not an intended > > recipient, please contact the sender by reply e-mail and destroy all copies > > of this email message and do not otherwise utilize or retain this email > > message or any or all of the information contained therein. Although this > > email message and any attachments or appended messages are believed to be > > free of any virus or other defect that might affect any computer system into > > which it is received and opened, it is the responsibility of the recipient > > to ensure that it is virus free and no responsibility is accepted by the > > sender for any loss or damage arising in any way from its opening or use. > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
I don't remember. I'm no longer working at $previousjob so I don't have access to the case I opened at the time. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Monday, February 21st, 2022 at 1:22 PM, Ed Jaffe wrote: > On 10/27/2021 8:47 AM, Mark Jacobs wrote: > > > We migrated one of our systems to z/OS 2.5 last weekend and immediately > > started getting a hard loop during job conversion/interpretation either in > > the JES2CIxx or INIT address space depending on your JOBDEF INTERPRET= > > setting. > > > > The loop could occur with any batch job,but not every batch job. IBM has > > found the loop in module IEFNB903 and are looking at it. The looping > > condition only occurs if DSENQSHR is enabled for the job. In our case the > > JOBCLASS definitions had DSENQSHR=AUTO. Once we changed it to > > DSENQSHR=DISALLOW the problem no longer occurred. > > We are now seeing this in our z/OS 2.5 JES2 environments. The loop is in > > IEFNB903. > > Your IBM-MAIN posting was from way back in October. I assumed this would > > have been fixed by now. > > Did IBM take an APAR? > > -- > > Phoenix Software International > > Edward E. Jaffe > > 831 Parkview Drive North > > El Segundo, CA 90245 > > https://www.phoenixsoftware.com/ > > > > This e-mail message, including any attachments, appended messages and the > > information contained therein, is for the sole use of the intended > > recipient(s). If you are not an intended recipient or have otherwise > > received this email message in error, any use, dissemination, distribution, > > review, storage or copying of this e-mail message and the information > > contained therein is strictly prohibited. If you are not an intended > > recipient, please contact the sender by reply e-mail and destroy all copies > > of this email message and do not otherwise utilize or retain this email > > message or any or all of the information contained therein. Although this > > email message and any attachments or appended messages are believed to be > > free of any virus or other defect that might affect any computer system into > > which it is received and opened, it is the responsibility of the recipient > > to ensure that it is virus free and no responsibility is accepted by the > > sender for any loss or damage arising in any way from its opening or use. > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
On 10/27/2021 8:47 AM, Mark Jacobs wrote: We migrated one of our systems to z/OS 2.5 last weekend and immediately started getting a hard loop during job conversion/interpretation either in the JES2CIxx or INIT address space depending on your JOBDEF INTERPRET= setting. The loop could occur with any batch job,but not every batch job. IBM has found the loop in module IEFNB903 and are looking at it. The looping condition only occurs if DSENQSHR is enabled for the job. In our case the JOBCLASS definitions had DSENQSHR=AUTO. Once we changed it to DSENQSHR=DISALLOW the problem no longer occurred. We are now seeing this in our z/OS 2.5 JES2 environments. The loop is in IEFNB903. Your IBM-MAIN posting was from way back in October. I assumed this would have been fixed by now. Did IBM take an APAR? -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
If JOBDEF INTERPET=JES the loop occurs in the JES2CI0x address space. If JOBDEF INTERPRET=INIT, the initiator address space that selects the job loops. With DSENQSHR=ALLOW on the JOBCLASS, the loop will/can happen only if the job card has DSENQSHR=ALLOW. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, October 27th, 2021 at 4:30 PM, Michael Brennan <034cc18fb308-dmarc-requ...@listserv.ua.edu> wrote: > You indicated that it depended on the setting for JOBDEF INTERPRET=. What is > your JOBDEF INTERPRET= setting that the problem occurs under? Also does the > loop occur if one defaults to DSENQSHR=ALLOW on the JOBCLASS setting? Just > curious. > > Michael > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > Sent: Wednesday, October 27, 2021 10:47 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: 2.5 Heads Up > > [CAUTION: This Email is from outside the Organization. Unless you trust the > sender, Don’t click links or open attachments as it may be a Phishing email, > which can steal your Information and compromise your Computer.] > > We migrated one of our systems to z/OS 2.5 last weekend and immediately > started getting a hard loop during job conversion/interpretation either in > the JES2CIxx or INIT address space depending on your JOBDEF INTERPRET= > setting. > > The loop could occur with any batch job,but not every batch job. IBM has > found the loop in module IEFNB903 and are looking at it. The looping > condition only occurs if DSENQSHR is enabled for the job. In our case the > JOBCLASS definitions had DSENQSHR=AUTO. Once we changed it to > DSENQSHR=DISALLOW the problem no longer occurred. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com=04|01|michael.brennan%40HCL.COM|7d0dfeb6448d49b980ed08d999611902|189de737c93a4f5a8b686f4ca9941912|0|0|637709464598544436|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000=zVDihii1NWTciU37wWb%2B1EzY779W%2FNFYBd2mBCiZqQU%3D=0 > > - > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, copying, > disclosure, modification, distribution and / or publication of this message > without the prior written consent of authorized representative of HCL is > strictly prohibited. If you have received this email in error please delete > it and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses
Re: 2.5 Heads Up
You indicated that it depended on the setting for JOBDEF INTERPRET=. What is your JOBDEF INTERPRET= setting that the problem occurs under? Also does the loop occur if one defaults to DSENQSHR=ALLOW on the JOBCLASS setting? Just curious. Michael From: IBM Mainframe Discussion List on behalf of Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, October 27, 2021 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 2.5 Heads Up [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] We migrated one of our systems to z/OS 2.5 last weekend and immediately started getting a hard loop during job conversion/interpretation either in the JES2CIxx or INIT address space depending on your JOBDEF INTERPRET= setting. The loop could occur with any batch job,but not every batch job. IBM has found the loop in module IEFNB903 and are looking at it. The looping condition only occurs if DSENQSHR is enabled for the job. In our case the JOBCLASS definitions had DSENQSHR=AUTO. Once we changed it to DSENQSHR=DISALLOW the problem no longer occurred. Mark Jacobs Sent from [ProtonMail](https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com%2Fdata=04%7C01%7Cmichael.brennan%40HCL.COM%7C7d0dfeb6448d49b980ed08d999611902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637709464598544436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AUWdMIZVSX9o4FtXEGzv%2BSjl3VlV4fEyZNdaMAH2KMw%3Dreserved=0), Swiss-based encrypted email. GPG Public Key - https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.comdata=04%7C01%7Cmichael.brennan%40HCL.COM%7C7d0dfeb6448d49b980ed08d999611902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637709464598544436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=zVDihii1NWTciU37wWb%2B1EzY779W%2FNFYBd2mBCiZqQU%3Dreserved=0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
