You may wish to consider:
https://www.ibm.com/support/pages/how-generate-and-read-zos-slip-zero-address-detection-zad-report
Tom Harper
Phoenix Software International
On 7/3/2024 2:57 AM, David Cole wrote:
There is a program in SYS1.LINKLIB named IGVDGNPP. It is a diagnostic
tool provided by IBM. You would start it at IPL time and let it run
for the life of the IPL.
Its job is to change the contents of unassigned low storage
periodically to values other than zero. You give it a time interval
and a list of fullword values to rotate through.
It's purpose is to uncover programs (such as the OP's example) that
(a) accidently use values from low storage and (b) happen to work
because such values are always zero.
The hope is, when the values are non-zero, such previously "working"
programs will likely program check and thereby uncover their bugs.
Colesoft is a development shop, so we run whatever tools IBM (and
others) provide that help with uncovering bugs. IGVDGNPP is one such
tool, so we've been running it here for around a decade and a half.
Using XDC commands and the OP's bug as guidance, I set up a command
string to display 7 bytes at each of the 2 low-storage locations
referenced by:
- "CLC 0(R7),ECOMMA"
- [aka "CLC 0(7,0),107(0)"].
The XDC command string is "FORMAT 0 BYTES=7 DATA;;FORMAT 107N BYTES=7
DATA".
Since we run IGVDGNPP, I would expect the displays to change over
time. Sure enuf...
1st time result:
XDC ===> f 0 b=7 data;;f 6b b=7 data
_ 00000000_00000000 0s (A.S.DBCOLE7) --- @PSA+0, @LEPILOG+0,
@TEA+0, LOWCORE+0
_ +0 @TEA LOWCORE
_ +0 @PSA 50404143 504041 *& .& *
_ 00000000_0000006B 0s (A.S.DBCOLE7) --- @PSA+6B, @LEPILOG+6B,
@TEA+6B, LOWCORE+6B
_ +6B 43504041 435040 *.& .& *
In this case, the CLC would find a mismatch.
A later result:
XDC ===> f 0 b=7 data;;f 6b b=7 data
_ 00000000_00000000 0s (A.S.DBCOLE7) --- @PSA+0, @LEPILOG+0,
@TEA+0, LOWCORE+0
_ +0 @TEA LOWCORE
_ +0 @PSA AAAAAAAA AAAAAA *.......*
_ 00000000_0000006B 0s (A.S.DBCOLE7) --- @PSA+6B, @LEPILOG+6B,
@TEA+6B, LOWCORE+6B
_ +6B AAAAAAAA AAAAAA *.......*
In this case, the CLC would find a match.
The PROC we run is this:
//* *//
//* *//
//* THIS PROCEDURE WILL PRIME THE RESTART OLD PSW, THE *//
//* MACHINE CHECK OLD PSW, AND THE MACHINE CHECK LOGOUT *//
//* AREA AND SAVE AREAS WITH THE VALUE SPECIFIED BY THE *//
//* V= PARAMETER, AT THE INTERVAL SPECIFIED BY THE T= *//
//* PARAMETER (T IS IN UNITS OF HUNDREDTHS OF SECONDS, *//
//* IN HEX). THE PURPOSE IS TO MAKE THESE AREAS NON-ZERO *//
//* TO CATCH PROGRAMS WHICH ACCIDENTALLY REFERENCE THEM, *//
//* AND GET LUCKY AND DO NOT ABEND BECAUSE THEY ARE *//
//* USUALLY ZERO. *//
//* *//
//* IF IGVDGNPP IS TERMINATED VIA AN MVS STOP (P) *//
//* COMMAND, IT SETS ALL MODIFIED AREAS TO ZERO BEFORE *//
//* TERMINATING. *//
//*
//IGVDGNPP PROC T=0000EA60,V='50404143,AAAAAAAA,55555555,FFFFFFFF'
//IGVDGNPP EXEC PGM=IGVDGNPP,REGION=2M,TIME=1440,
// PARM='&T,&V'
- It changes the contents of unused low storage every 10 minutes:
(EA60hex = 60000dec = 10 minutes).
- It rotates through a list of 4 fword values.
Information about IGVDGNPP was published here around sixteen years
ago:
https://bit.listserv.ibm-main.narkive.com/agsiSOGc/if-someone-remember-low-core-refrence.
Dave Cole, Developer
[email protected] (business)
At 7/3/2024 12:17 AM, Binyamin Dissen wrote:
In zOS2.4 is was 000A0000 000130E1, a bad restart new PSW.
In zOS2.5, zeroes.
This has caused issues with code that fetched from zero (where a
previous
instruction did not verify that a non-null address being loaded) .
On Tue, 2 Jul 2024 21:54:24 +0000 "Schmitt, Michael"
<[email protected]>
wrote:
:>The REXX code displays:
:>
:>0000000000000000
:>0000000000000000
:>
:>Which would explain why it isn't branching.
:>
:>We were on z/OS 2.4 before.
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List <[email protected]> On
Behalf Of Phil Smith III
:>Sent: Tuesday, July 2, 2024 4:46 PM
:>To: [email protected]
:>Subject: Re: What's at a comma?
:>
:>I don't think "breaks this code" is fair. More like "This code is
now equally broken but no longer randomly 'works' quite as often".
:>
:>In any case, x'6B' is in the middle of:
:>FLCER018 DS CL104 FLCE 18x: reserved
:>...which starts at location x'18'.
:>
:>On my 2.4 system, that's all zeroes. Location 0 sure isn't all
zeroes; it is, of course, the IPL PSW.
:>
:>/* REXX */say c2x(storage(x2d(00), 8)); say c2x(storage(x2d(6b), 8))
:>displays both. I'd be astonished if those were ever the same.
Unless there's some prefixing majick getting in here. What do you
see when you run that Rexx snippet?
:>
:>And what z/OS version did you come from?
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List <[email protected]>
On Behalf Of Schmitt, Michael
:>Sent: Tuesday, July 2, 2024 5:10 PM
:>To: [email protected]
:>Subject: What's at a comma?
:>
:>Today I learned that z/OS 2.5 upgrade breaks this code:
:>
:> CLC 0(R7),ECOMMA IS THIS A COMMA
:> BNE PD07240 IF NOT, BRANCH
:> :
:>ECOMMA EQU X'6B' COMMA (,)
:>
:>Which has worked since 1985.
:>
:>Yes, I know that this is incorrect code. It worked because the
input never has a comma there. The "correct" result is to branch.
Now it doesn't.
:>
:>
:>(spoilers ahead if you want to figure out what's wrong for
yourself...)
:>
:>
:>So what's wrong is they meant to code CLI. But they didn't, so
this assembles as if it were:
:>
:> CLC 0(7,0),107(0)
:>
:>But 0 isn't a base register, so it is comparing the 7 bytes at
address x'0' to what's at address x'6B'. Right?
:>
:>My question is: what is at those two addresses? Whatever it is,
it must have never been the same before, but now it is always the
same.
:>
:>(Unless there's some z/OS 2.5 thing where storage reads at low
core behave differently)
:>
:>
:>
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO
IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
--------------------------------------------------------------------------------
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 [email protected] with the message: INFO IBM-MAIN
