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" <IBM-MAIN@LISTSERV.UA.EDU> wrote on 02/22/2022 10:26:40 AM: > From: "Charles Mills" <charl...@mcn.org> > 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" <IBM-MAIN@LISTSERV.UA.EDU> > > 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'00000000', 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
