2.5 Heads Up

[Mark Jacobs]

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://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

--
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

[Michael Brennan]

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%2F&data=04%7C01%7Cmichael.brennan%40HCL.COM%7C7d0dfeb6448d49b980ed08d999611902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637709464598544436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AUWdMIZVSX9o4FtXEGzv%2BSjl3VlV4fEyZNdaMAH2KMw%3D&reserved=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.com&data=04%7C01%7Cmichael.brennan%40HCL.COM%7C7d0dfeb6448d49b980ed08d999611902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637709464598544436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zVDihii1NWTciU37wWb%2B1EzY779W%2FNFYBd2mBCiZqQU%3D&reserved=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

Re: 2.5 Heads Up

[Mark Jacobs]

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&search=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&data=04|01|michael.brennan%40HCL.COM|7d0dfeb6448d49b980ed08d999611902|189de737c93a4f5a8b686f4ca9941912|0|0|637709464598544436|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=zVDihii1NWTciU37wWb%2B1EzY779W%2FNFYBd2mBCiZqQU%3D&reserved=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 authorize

Re: 2.5 Heads Up

[Ed Jaffe]

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

[Mark Jacobs]

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&search=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

[Mark Jacobs]

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&search=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

[Ed Jaffe]

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

[Paul Gilmartin]

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

[Mark Jacobs]

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&search=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

[Lennie Dymoke-Bradshaw]

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

[Paul Gilmartin]

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

[Mark Jacobs]

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&search=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

[Jim Mulder]

  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

AW: 2.5 Heads Up

[Kerstin Schwob]

Keine Ahnung, ob das jemals bei uns passieren könnte...




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&search=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
>
> --

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List  Im Auftrag von 
Mark Jacobs
Gesendet: Montag, 21. Februar 2022 21:00
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: 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&search=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

--
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

[Seymour J Metz]

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

[Charles Mills]

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

[Seymour J Metz]

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

[Charles Mills]

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

[Lennie Dymoke-Bradshaw]

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

[Charles Mills]

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

[Charles Mills]

"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

[Jim Mulder]

  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

[Steve Thompson]

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

[Paul Gilmartin]

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

[Seymour J Metz]

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

[Ed Jaffe]

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

[Charles Mills]

> 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

[Seymour J Metz]

>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

[Ed Jaffe]

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

[Seymour J Metz]

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

[Seymour J Metz]

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

[Ed Jaffe]

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

[Leonard D Woren]

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

[Peter Relson]

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

[Allan Staller]

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

[Ed Jaffe]

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

[Allan Staller]

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-zad&data=04%7C01%7Callan.staller%40HCL.COM%7Cd60027a37a5b4957dd5f08d9fad20ec3%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637816602673605564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GoPgZ8w1Ynntt8rWiiG%2BztOg3rgfM4Xm4PzE4i4Jklo%3D&reserved=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%2F&data=04%7C01%7Callan.staller%40HCL.COM%7Cd60027a37a5b4957dd5f08d9fad20ec3%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637816602673605564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CTOJkEDHyvY52vfujY%2FDa4P4IaohF7Vdarnj8I%2BS3r4%3D&reserved=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

[Tony Harminc]

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

[Peter Relson]

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

[Seymour J Metz]

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

DSENQSHR (was: 2.5 Heads Up)

[Paul Gilmartin]

On Tue, 22 Feb 2022 02:03:21 -0400, Jim Mulder \wrote:

>  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.
>  
Thanks.

I like the suggestion of ignoring the content of location 4 and proceeding
with the constant value x'000130E1'.

Historians tell me that in the earliest days of OS/360 et al. ENQs established
by initiators were simply held until job termination.  Is that correct?

Later, the behavior was changed to DEQ after the last step mentioning
each DSN.  I don't see that this was ever optional; it was unconditional.

Why was the DSENQSHR behavior similarly made unconditional,
avoiding the need for the 3×3 matrix in


Often, the cost of complexity outweighs the value of flexibility.
Particularly, what is the value to customers in providing JES2 JOBCLASS
sensitivity rather than only a simple binary option on the JOB statement?

-- 
Thanks again,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

ZAD and C/C++ (was:: 2.5 Heads Up)

[Paul Gilmartin]

On Tue, 1 Mar 2022 13:28:01 +,  wrote:
>
>ZAD is not supported on z/OS under z/VM. ":-(
>Is there any SOD or RFE or the like for this?
>
>
Many releases ago, I saw a report the C RTL treatment of following a
NULL pointer was changing.  I tested open( NULL, ... ) with releases
before and after the change.  The earlier reported Invalid Pointer; the
later Invalid Filename.  I considered the earlier more precise and
correct.  I conjecture that IBM had fecklessly accommodated
programmers accustomed to misusing NULL instead of e.g. (void I)"".

There are probably still programs that follow null pointers. What will
become of them?

I favor strict error reporting.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Charles Mills]

C is a standardized language. IBM's main target market is programs ported from 
other platforms. I have no idea what the standard is, but IBM *may* simply be 
following it. fopen(NULL, ...) is pretty useless any way you slice it.

I have no idea what (void I)"" would mean and I don't *think* it is valid C. A 
quick test of auto foo = (void I)""; gives me a bunch of errors.

NULL is nothing special in C: it is just an alias for 0 (zero). That lead to a 
somewhat astonishing behavior in a particular situation involving overloaded 
functions, and the new (C++ only? Perhaps C also) language standards include 
nullptr, which is specifically an *address* of zero, and is a better usage than 
NULL if the meaning is "the address of nothing." That is, "you are expecting me 
to pass you an address and I am telling you that I have no address to give you."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, March 1, 2022 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ZAD and C/C++ (was:: 2.5 Heads Up)

On Tue, 1 Mar 2022 13:28:01 +,  wrote:
>
>ZAD is not supported on z/OS under z/VM. ":-(
>Is there any SOD or RFE or the like for this?
>
>
Many releases ago, I saw a report the C RTL treatment of following a
NULL pointer was changing.  I tested open( NULL, ... ) with releases
before and after the change.  The earlier reported Invalid Pointer; the
later Invalid Filename.  I considered the earlier more precise and
correct.  I conjecture that IBM had fecklessly accommodated
programmers accustomed to misusing NULL instead of e.g. (void I)"".

There are probably still programs that follow null pointers. What will
become of them?

I favor strict error reporting.

-- 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: ZAD and C/C++ (was:: 2.5 Heads Up)

[Paul Gilmartin]

On Tue, 1 Mar 2022 08:46:35 -0800, Charles Mills  wrote:

>..., but IBM *may* simply be following it. fopen(NULL, ...) is pretty 
> useless any way you slice it.
>


On Mac OS:
printf ("%d\n",  open( "",   0  ) );
-1
No such file or directory

printf ("%d\n",  open( NULL, 0  ) );
-1
Bad address

I think both are optimal.  OpenGroup doesn't specify the latter/

>I have no idea what (void I)"" would 
>
Typo for (void *).  Short finger?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Seymour J Metz]

Is nullptr an address of 0, or is it an address guarantied to not be valid?

“An integer constant expression with the value 0, or such an expression cast to 
type void *, is called a null pointer constant. If a null pointer constant is 
converted to a pointer type, the resulting pointer, called a null pointer, is 
guaranteed to compare unequal to a pointer to any object or function.”


--
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, March 1, 2022 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

C is a standardized language. IBM's main target market is programs ported from 
other platforms. I have no idea what the standard is, but IBM *may* simply be 
following it. fopen(NULL, ...) is pretty useless any way you slice it.

I have no idea what (void I)"" would mean and I don't *think* it is valid C. A 
quick test of auto foo = (void I)""; gives me a bunch of errors.

NULL is nothing special in C: it is just an alias for 0 (zero). That lead to a 
somewhat astonishing behavior in a particular situation involving overloaded 
functions, and the new (C++ only? Perhaps C also) language standards include 
nullptr, which is specifically an *address* of zero, and is a better usage than 
NULL if the meaning is "the address of nothing." That is, "you are expecting me 
to pass you an address and I am telling you that I have no address to give you."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, March 1, 2022 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ZAD and C/C++ (was:: 2.5 Heads Up)

On Tue, 1 Mar 2022 13:28:01 +,  wrote:
>
>ZAD is not supported on z/OS under z/VM. ":-(
>Is there any SOD or RFE or the like for this?
>
>
Many releases ago, I saw a report the C RTL treatment of following a
NULL pointer was changing.  I tested open( NULL, ... ) with releases
before and after the change.  The earlier reported Invalid Pointer; the
later Invalid Filename.  I considered the earlier more precise and
correct.  I conjecture that IBM had fecklessly accommodated
programmers accustomed to misusing NULL instead of e.g. (void I)"".

There are probably still programs that follow null pointers. What will
become of them?

I favor strict error reporting.

-- 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: ZAD and C/C++ (was:: 2.5 Heads Up)

[Charles Mills]

Ah! (void *). I know what that means, but I am perhaps too dense to see what 
(void *)"" would accomplish. I "get" what it is doing -- casting a char* (or 
maybe a const char*) as a void* -- but other than for some obscure test I don't 
see the purpose.

Certainly open(NULL, ...) is a possible real-life mistake. You write a function 
that expects a passed file name; I call it thinking it is "smart" enough to 
know that a filename of NULL means don't use a file; you try to open what I 
pass.

Too lazy to test and see what happens. I certainly agree that "bad address" is 
a lot more useful than "no such file." "Address is NULL" would be even more 
useful, to distinguish this special case from the case of some random garbage 
pointer. The programmer could look for "how might I be passing NULL?" as 
opposed to looking for "what might have corrupted that address?"

There is so much HORRIBLE error diagnosis out there. I have been wrestling the 
past week with the Google App Store. Would not take an e-mail address on a 
particular page. Error message: "E-mail address is not valid." Huh? I get 
e-mail there. After hours of hacking it turned out to mean "that e-mail address 
is not associated with any gmail address." Another situation where it was 
rejecting an e-mail address, this time with the error "! Try reformatting". 
Well, gee, it was your basic e-mail format, som...@domain.com. No blanks or 
anything like that. Never did figure out what they wanted; got around the 
problem another way. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, March 1, 2022 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

On Tue, 1 Mar 2022 08:46:35 -0800, Charles Mills  wrote:

>..., but IBM *may* simply be following it. fopen(NULL, ...) is pretty 
> useless any way you slice it.
>
<https://en.wikipedia.org/wiki/Fuzzing>

On Mac OS:
printf ("%d\n",  open( "",   0  ) );
-1
No such file or directory

printf ("%d\n",  open( NULL, 0  ) );
-1
Bad address

I think both are optimal.  OpenGroup doesn't specify the latter/

>I have no idea what (void I)"" would 
>
Typo for (void *).  Short finger?

-- 
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: ZAD and C/C++ (was:: 2.5 Heads Up)

[Charles Mills]

Well, I am not the C standard, but you can find it online. 

I believe nullptr is numerically equal to zero, but it is a pointer type. It
is perhaps equivalent to (void *)0

It is specifically not an integer, unlike NULL, which is another name for
the integer zero.



int foo = NULL;  // compiles
int bar = nullptr;  // generates an error 
void *sojack = nullptr;   // compiles

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, March 1, 2022 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

Is nullptr an address of 0, or is it an address guarantied to not be valid?

"An integer constant expression with the value 0, or such an expression cast
to type void *, is called a null pointer constant. If a null pointer
constant is converted to a pointer type, the resulting pointer, called a
null pointer, is guaranteed to compare unequal to a pointer to any object or
function."


--
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, March 1, 2022 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

C is a standardized language. IBM's main target market is programs ported
from other platforms. I have no idea what the standard is, but IBM *may*
simply be following it. fopen(NULL, ...) is pretty useless any way you slice
it.

I have no idea what (void I)"" would mean and I don't *think* it is valid C.
A quick test of auto foo = (void I)""; gives me a bunch of errors.

NULL is nothing special in C: it is just an alias for 0 (zero). That lead to
a somewhat astonishing behavior in a particular situation involving
overloaded functions, and the new (C++ only? Perhaps C also) language
standards include nullptr, which is specifically an *address* of zero, and
is a better usage than NULL if the meaning is "the address of nothing." That
is, "you are expecting me to pass you an address and I am telling you that I
have no address to give you."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Tuesday, March 1, 2022 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ZAD and C/C++ (was:: 2.5 Heads Up)

On Tue, 1 Mar 2022 13:28:01 +,  wrote:
>
>ZAD is not supported on z/OS under z/VM. ":-(
>Is there any SOD or RFE or the like for this?
>
>
Many releases ago, I saw a report the C RTL treatment of following a
NULL pointer was changing.  I tested open( NULL, ... ) with releases
before and after the change.  The earlier reported Invalid Pointer; the
later Invalid Filename.  I considered the earlier more precise and
correct.  I conjecture that IBM had fecklessly accommodated
programmers accustomed to misusing NULL instead of e.g. (void I)"".

There are probably still programs that follow null pointers. What will
become of them?

I favor strict error reporting.

-- 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Paul Gilmartin]

On Tue, 1 Mar 2022 18:09:14 +, Seymour J Metz wrote:

>Is nullptr an address of 0, or is it an address guarantied to not be valid?
>
Ah, pedantry!  It depends on whether "invalid" is equivalent to "unequal
to a pointer to any object ..." (or whether one implies the other.). The
statement below does not constrain the storage representation of NULL
(as in type-punning).  I believe the behavior of "if ( NULL ) ..." (specified
elsewhere) requires that (intt) NULL be zero.

Cases to consider:
o a putative pointer to the interior of a multi-byte object
o an arbitrary int value cast to (void *)
o a pointer to a free()ed object.

>�An integer constant expression with the value 0, or such an expression cast 
>to type void *, is called a null pointer constant. If a null pointer constant 
>is converted to a pointer type, the resulting pointer, called a null pointer, 
>is guaranteed to compare unequal to a pointer to any object or function.�

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Seymour J Metz]

Metz's Law of Anal Retentive Developers: "Never validate an input field unless 
you *KNOW* what the rules are: assumption, belief, habit, urban legends, etc., 
don't count!" The world is full of people that "validate" names without having 
a clue about any ethnicity but their own and e-mail addresses when the can't 
even spell RFC. "An e-mail address is invalid if it uses characters hat I don't 
use in mine." or some such idiocy.

My other pet peeve for web sites is forms with long input fields and no 
explanation of the required syntax. Are blanks allowed, mandatory or 
prohibited? Ditto hyphens and slashes. Is a long ZIP code field 5 or 9? I can't 
think of any others off the top of my head, but I would bet that they exist.

Or take client-side scripts - please!


--
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, March 1, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

Ah! (void *). I know what that means, but I am perhaps too dense to see what 
(void *)"" would accomplish. I "get" what it is doing -- casting a char* (or 
maybe a const char*) as a void* -- but other than for some obscure test I don't 
see the purpose.

Certainly open(NULL, ...) is a possible real-life mistake. You write a function 
that expects a passed file name; I call it thinking it is "smart" enough to 
know that a filename of NULL means don't use a file; you try to open what I 
pass.

Too lazy to test and see what happens. I certainly agree that "bad address" is 
a lot more useful than "no such file." "Address is NULL" would be even more 
useful, to distinguish this special case from the case of some random garbage 
pointer. The programmer could look for "how might I be passing NULL?" as 
opposed to looking for "what might have corrupted that address?"

There is so much HORRIBLE error diagnosis out there. I have been wrestling the 
past week with the Google App Store. Would not take an e-mail address on a 
particular page. Error message: "E-mail address is not valid." Huh? I get 
e-mail there. After hours of hacking it turned out to mean "that e-mail address 
is not associated with any gmail address." Another situation where it was 
rejecting an e-mail address, this time with the error "! Try reformatting". 
Well, gee, it was your basic e-mail format, som...@domain.com. No blanks or 
anything like that. Never did figure out what they wanted; got around the 
problem another way.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, March 1, 2022 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

On Tue, 1 Mar 2022 08:46:35 -0800, Charles Mills  wrote:

>..., but IBM *may* simply be following it. fopen(NULL, ...) is pretty 
> useless any way you slice it.
>
<https://secure-web.cisco.com/1aJzItmS0H9nv-yaXomvv3Q0sTqMdjNY8S9FJLyhlMJPFtj1sFpPM2S6ZEWm26Z_AwjvPZ3CHL6kbMFGytKw_Stj7fgtpgVVt7JIVOlERyCwJi7ZU3esNmAqPwFI-xK3L0A5MlbKD_MRhbnj5ZP5J8atEcaRka8q0poYofY_ZE59fMzkCmsLh4tHCTJYtqFlxiEE_b2rFAi-R5LAYYQB6LwDh6NoMrXHVrJswXDapPSiQnkLgcp7c33apV-NIzOC9KEylwlSjavUoSsqFnsw-V--zKnId43bCM12i6EyJiPcrrdnfK6Bs1v9g-IMjnUGsumhoMPhhA_0spAUhKvmZrLDk_acznz5mL4FVPyodaAaDUiJsnxhDI2lYMDiZg03JKX-XYVz2PjJMchWEu1OYSD3l5KEx3B2TezBwokwe1CcROK9Gx8jEMIH-i7tdbdFj/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFuzzing>

On Mac OS:
printf ("%d\n",  open( "",   0  ) );
-1
No such file or directory

printf ("%d\n",  open( NULL, 0  ) );
-1
Bad address

I think both are optimal.  OpenGroup doesn't specify the latter/

>I have no idea what (void I)"" would
>
Typo for (void *).  Short finger?

--
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: ZAD and C/C++ (was:: 2.5 Heads Up)

[Charles Mills]

I see what you are asking. You are probably quoting the standard correctly.
I am speaking as a practical programmer, not as a standards writer:

- It is guaranteed to be consistent. If you pass me nullptr and I compare
what you pass to nullptr it will always compare equal, even if your code was
compiled differently from mine.
- It is never the address of any actual C "thing." There is no risk that you
pass me the address of some C "thing" and it turns out coincidentally to be
logically equal to nullptr. (Yes, if you pass me the address of the PSA that
logic will fail. I would say the PSA is not a "C thing.")
- It is in fact 0 on the three C's I care about: MS, gcc and xlc (and
probably Clang) -- and I am going to guess most other C's.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, March 1, 2022 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

Is nullptr an address of 0, or is it an address guarantied to not be valid?

"An integer constant expression with the value 0, or such an expression cast
to type void *, is called a null pointer constant. If a null pointer
constant is converted to a pointer type, the resulting pointer, called a
null pointer, is guaranteed to compare unequal to a pointer to any object or
function."


--
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, March 1, 2022 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

C is a standardized language. IBM's main target market is programs ported
from other platforms. I have no idea what the standard is, but IBM *may*
simply be following it. fopen(NULL, ...) is pretty useless any way you slice
it.

I have no idea what (void I)"" would mean and I don't *think* it is valid C.
A quick test of auto foo = (void I)""; gives me a bunch of errors.

NULL is nothing special in C: it is just an alias for 0 (zero). That lead to
a somewhat astonishing behavior in a particular situation involving
overloaded functions, and the new (C++ only? Perhaps C also) language
standards include nullptr, which is specifically an *address* of zero, and
is a better usage than NULL if the meaning is "the address of nothing." That
is, "you are expecting me to pass you an address and I am telling you that I
have no address to give you."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Tuesday, March 1, 2022 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ZAD and C/C++ (was:: 2.5 Heads Up)

On Tue, 1 Mar 2022 13:28:01 +,  wrote:
>
>ZAD is not supported on z/OS under z/VM. ":-(
>Is there any SOD or RFE or the like for this?
>
>
Many releases ago, I saw a report the C RTL treatment of following a
NULL pointer was changing.  I tested open( NULL, ... ) with releases
before and after the change.  The earlier reported Invalid Pointer; the
later Invalid Filename.  I considered the earlier more precise and
correct.  I conjecture that IBM had fecklessly accommodated
programmers accustomed to misusing NULL instead of e.g. (void I)"".

There are probably still programs that follow null pointers. What will
become of them?

I favor strict error reporting.

-- 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Seymour J Metz]

I once had lust in my heart for the PEDANT license plate in the NSF garage. 
And, yes, some of these "minor" pedantic difference do have major practical 
consequences.


--
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, March 1, 2022 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

On Tue, 1 Mar 2022 18:09:14 +, Seymour J Metz wrote:

>Is nullptr an address of 0, or is it an address guarantied to not be valid?
>
Ah, pedantry!  It depends on whether "invalid" is equivalent to "unequal
to a pointer to any object ..." (or whether one implies the other.). The
statement below does not constrain the storage representation of NULL
(as in type-punning).  I believe the behavior of "if ( NULL ) ..." (specified
elsewhere) requires that (intt) NULL be zero.

Cases to consider:
o a putative pointer to the interior of a multi-byte object
o an arbitrary int value cast to (void *)
o a pointer to a free()ed object.

>�An integer constant expression with the value 0, or such an expression cast 
>to type void *, is called a null pointer constant. If a null pointer constant 
>is converted to a pointer type, the resulting pointer, called a null pointer, 
>is guaranteed to compare unequal to a pointer to any object or function.�

--
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: ZAD and C/C++ (was:: 2.5 Heads Up)

[Seymour J Metz]

I believe that in current PL/I compilers, NULL is an address that z/OS 
guaranties to be invalid, i.e., no page frame assigned. Way back when, PL/I 
used zero, which caused the obvious problems.


--
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, March 1, 2022 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

I see what you are asking. You are probably quoting the standard correctly.
I am speaking as a practical programmer, not as a standards writer:

- It is guaranteed to be consistent. If you pass me nullptr and I compare
what you pass to nullptr it will always compare equal, even if your code was
compiled differently from mine.
- It is never the address of any actual C "thing." There is no risk that you
pass me the address of some C "thing" and it turns out coincidentally to be
logically equal to nullptr. (Yes, if you pass me the address of the PSA that
logic will fail. I would say the PSA is not a "C thing.")
- It is in fact 0 on the three C's I care about: MS, gcc and xlc (and
probably Clang) -- and I am going to guess most other C's.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, March 1, 2022 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

Is nullptr an address of 0, or is it an address guarantied to not be valid?

"An integer constant expression with the value 0, or such an expression cast
to type void *, is called a null pointer constant. If a null pointer
constant is converted to a pointer type, the resulting pointer, called a
null pointer, is guaranteed to compare unequal to a pointer to any object or
function."


--
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, March 1, 2022 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

C is a standardized language. IBM's main target market is programs ported
from other platforms. I have no idea what the standard is, but IBM *may*
simply be following it. fopen(NULL, ...) is pretty useless any way you slice
it.

I have no idea what (void I)"" would mean and I don't *think* it is valid C.
A quick test of auto foo = (void I)""; gives me a bunch of errors.

NULL is nothing special in C: it is just an alias for 0 (zero). That lead to
a somewhat astonishing behavior in a particular situation involving
overloaded functions, and the new (C++ only? Perhaps C also) language
standards include nullptr, which is specifically an *address* of zero, and
is a better usage than NULL if the meaning is "the address of nothing." That
is, "you are expecting me to pass you an address and I am telling you that I
have no address to give you."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Tuesday, March 1, 2022 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ZAD and C/C++ (was:: 2.5 Heads Up)

On Tue, 1 Mar 2022 13:28:01 +,  wrote:
>
>ZAD is not supported on z/OS under z/VM. ":-(
>Is there any SOD or RFE or the like for this?
>
>
Many releases ago, I saw a report the C RTL treatment of following a
NULL pointer was changing.  I tested open( NULL, ... ) with releases
before and after the change.  The earlier reported Invalid Pointer; the
later Invalid Filename.  I considered the earlier more precise and
correct.  I conjecture that IBM had fecklessly accommodated
programmers accustomed to misusing NULL instead of e.g. (void I)"".

There are probably still programs that follow null pointers. What will
become of them?

I favor strict error reporting.

-- 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Charles Mills]

> any ethnicity but their own

In my much younger days -- the first significant system I ever worked on --
I wrote a name-indexing scheme that assumed all surnames were at least three
characters long. This was of course back in the day when we worried
obsessively about bytes and CPU cycles.

Turned out that the client -- Blue Cross of Northern California -- had
hundreds of customers surnamed Ng.

Oops.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, March 1, 2022 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

Metz's Law of Anal Retentive Developers: "Never validate an input field
unless you *KNOW* what the rules are: assumption, belief, habit, urban
legends, etc., don't count!" The world is full of people that "validate"
names without having a clue about any ethnicity but their own and e-mail
addresses when the can't even spell RFC. "An e-mail address is invalid if it
uses characters hat I don't use in mine." or some such idiocy.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Seymour J Metz]

There was an IBM employee with that surname who gave excellent diagnostic 
presentations at SHARE.


--
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, March 1, 2022 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

> any ethnicity but their own

In my much younger days -- the first significant system I ever worked on --
I wrote a name-indexing scheme that assumed all surnames were at least three
characters long. This was of course back in the day when we worried
obsessively about bytes and CPU cycles.

Turned out that the client -- Blue Cross of Northern California -- had
hundreds of customers surnamed Ng.

Oops.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, March 1, 2022 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

Metz's Law of Anal Retentive Developers: "Never validate an input field
unless you *KNOW* what the rules are: assumption, belief, habit, urban
legends, etc., don't count!" The world is full of people that "validate"
names without having a clue about any ethnicity but their own and e-mail
addresses when the can't even spell RFC. "An e-mail address is invalid if it
uses characters hat I don't use in mine." or some such idiocy.

--
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: ZAD and C/C++ (was:: 2.5 Heads Up)

[Paul Gilmartin]

On Tue, 1 Mar 2022 10:53:44 -0800, Charles Mills wrote:

>> any ethnicity but their own
>.   ...
>I wrote a name-indexing scheme that assumed all surnames were at least three
>characters long. This was of course back in the day when we worried
>obsessively about bytes and CPU cycles.
> 
I worked at a site that required user names be (truncated) surname,
first initial, middle initial.  I searched CA directories so I could wonder
what they'd do if Cheng K. Fu of San Diego ever was hired.


>-Original Message-
>From: Seymour J Metz
>Sent: Tuesday, March 1, 2022 10:46 AM
>
>Metz's Law of Anal Retentive Developers: "Never validate an input field
>unless you *KNOW* what the rules are: assumption, belief, habit, urban
>legends, etc., don't count!" 
> 
Corollary:  Middleware shouldn't validate inputs beyond what the lowest
level does.  E.g. member names should be passed as-is to BLDL.  If
I can create it with Assembler I should be able to allocate it with JCL.

On Tue, 1 Mar 2022 19:13:21 +, Seymour J Metz wrote:

>When the field is 16 it's clear that they don't want the spaces, ...
>
That is not obvious to the casual eyeball at the first glance.  The
friendliest  systems either tolerate optional spaces or auto tab at
each 4 characters.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Mike Schwab]

https://en.wikipedia.org/wiki/Chin-Lung_Hu play for 2 MLB baseball teams.

On Tue, Mar 1, 2022 at 6:53 PM Charles Mills  wrote:
>
> > any ethnicity but their own
>
> In my much younger days -- the first significant system I ever worked on --
> I wrote a name-indexing scheme that assumed all surnames were at least three
> characters long. This was of course back in the day when we worried
> obsessively about bytes and CPU cycles.
>
> Turned out that the client -- Blue Cross of Northern California -- had
> hundreds of customers surnamed Ng.
>
> Oops.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Tuesday, March 1, 2022 10:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)
>
> Metz's Law of Anal Retentive Developers: "Never validate an input field
> unless you *KNOW* what the rules are: assumption, belief, habit, urban
> legends, etc., don't count!" The world is full of people that "validate"
> names without having a clue about any ethnicity but their own and e-mail
> addresses when the can't even spell RFC. "An e-mail address is invalid if it
> uses characters hat I don't use in mine." or some such idiocy.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[David Crayford]

On Tue, 2022-03-01 at 10:35 -0800, Charles Mills wrote:
> Well, I am not the C standard, but you can find it online. 
> 
> I believe nullptr is numerically equal to zero, but it is a pointer
> type. It
> is perhaps equivalent to (void *)0

nullptr is a pointer literal of type std::nullptr_t, and it's a prvalue
  (you cannot take the address of it using &).

4.10 about pointer conversion says that a prvalue of type
std::nullptr_t is a null pointer constant, and that an integral null
pointer constant can be converted to std::nullptr_t. The opposite
direction is not allowed. This allows overloading a function for both
pointers and integers, and passing nullptr to select the pointer
version. Passing NULL or 0 would confusingly select the int version.

A cast of nullptr_t to an integral type needs a reinterpret_cast, and
has the same semantics as a cast of (void*)0 to an integral type
(mapping implementation defined). A reinterpret_cast cannot convert
nullptr_t to any pointer type. Rely on the implicit conversion if
possible or use static_cast.

The Standard requires that sizeof(nullptr_t) be sizeof(void*).

> 
> It is specifically not an integer, unlike NULL, which is another name
> for
> the integer zero.
> 
> 
> 
> int foo = NULL;  // compiles
> int bar = nullptr;  // generates an error 
> void *sojack = nullptr;   // compiles
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> Behalf Of Seymour J Metz
> Sent: Tuesday, March 1, 2022 10:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)
> 
> Is nullptr an address of 0, or is it an address guarantied to not be
> valid?
> 
> "An integer constant expression with the value 0, or such an
> expression cast
> to type void *, is called a null pointer constant. If a null pointer
> constant is converted to a pointer type, the resulting pointer,
> called a
> null pointer, is guaranteed to compare unequal to a pointer to any
> object or
> function."
> 
> 
> --
> 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, March 1, 2022 11:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)
> 
> C is a standardized language. IBM's main target market is programs
> ported
> from other platforms. I have no idea what the standard is, but IBM
> *may*
> simply be following it. fopen(NULL, ...) is pretty useless any way
> you slice
> it.
> 
> I have no idea what (void I)"" would mean and I don't *think* it is
> valid C.
> A quick test of auto foo = (void I)""; gives me a bunch of errors.
> 
> NULL is nothing special in C: it is just an alias for 0 (zero). That
> lead to
> a somewhat astonishing behavior in a particular situation involving
> overloaded functions, and the new (C++ only? Perhaps C also) language
> standards include nullptr, which is specifically an *address* of
> zero, and
> is a better usage than NULL if the meaning is "the address of
> nothing." That
> is, "you are expecting me to pass you an address and I am telling you
> that I
> have no address to give you."
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, March 1, 2022 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ZAD and C/C++ (was:: 2.5 Heads Up)
> 
> On Tue, 1 Mar 2022 13:28:01 +,  wrote:
> > 
> > ZAD is not supported on z/OS under z/VM. ":-(
> > Is there any SOD or RFE or the like for this?
> > 
> > 
> Many releases ago, I saw a report the C RTL treatment of following a
> NULL pointer was changing.  I tested open( NULL, ... ) with releases
> before and after the change.  The earlier reported Invalid Pointer;
> the
> later Invalid Filename.  I considered the earlier more precise and
> correct.  I conjecture that IBM had fecklessly accommodated
> programmers accustomed to misusing NULL instead of e.g. (void I)"".
> 
> There are probably still programs that follow null pointers. What
> will
> become of them?
> 
> I favor strict error reporting.
> 
> -- gil
> 
> ---
> ---
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN

Re: ZAD and C/C++ (was:: 2.5 Heads Up)

[Seymour J Metz]

IMHO, Chien-Shiung Wu would have gotten the Nobel Prize had she been male.

<https://en.wikipedia.org/wiki/Chien-Shiung_Wu>


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Tuesday, March 1, 2022 10:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

https://secure-web.cisco.com/1PXbV8bBOYAuiVtorpuZs7XE3pKinLwmLYKWPEJUV_PkTrzvWRyNuYDzK47foMg_IwN3TABRuvj8-6d952PU7Pg-fSwtIB4V3NLol2wqOLH_Vh_bIrhLnjTrXt1XW4HVTk9DPjC2uuSEoTeOojHiX-nvU6TI8d5otKWeqR9YnchPqlAF_87McO983XagIQA8zboCCtRKubYkttWZgaBVScNJ1y8ijfkw-96QjeEVIb-tXNTq_SrofW1RJZey9zfWvs4jPYQd59IlyRK6YdTzKvLbBlp0m3xC2UHlW5SDl1WqO-5gs_oQp6vKx5gRBemX90HZeonb5RR1Yvp9oMep7wsNFubNVVj7ErAUUu9IhfukBVrLwevduXMA2F4N1wwH-sZWGfpXU3rqfr-9M3MvnpGM_9fg4GFkuYyb5NRGWqV3O7CI-QrCTqoqu9HKiKviT/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FChin-Lung_Hu
 play for 2 MLB baseball teams.

On Tue, Mar 1, 2022 at 6:53 PM Charles Mills  wrote:
>
> > any ethnicity but their own
>
> In my much younger days -- the first significant system I ever worked on --
> I wrote a name-indexing scheme that assumed all surnames were at least three
> characters long. This was of course back in the day when we worried
> obsessively about bytes and CPU cycles.
>
> Turned out that the client -- Blue Cross of Northern California -- had
> hundreds of customers surnamed Ng.
>
> Oops.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Tuesday, March 1, 2022 10:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)
>
> Metz's Law of Anal Retentive Developers: "Never validate an input field
> unless you *KNOW* what the rules are: assumption, belief, habit, urban
> legends, etc., don't count!" The world is full of people that "validate"
> names without having a clue about any ethnicity but their own and e-mail
> addresses when the can't even spell RFC. "An e-mail address is invalid if it
> uses characters hat I don't use in mine." or some such idiocy.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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