"may or may not" simply signifies that the behaviour can change in different hardware implementations, typically by machine model but even by engineering change level. I've run into this often, but IBM is rigorous in only doing this for instruction behaviour that is incidental to the correct operation of the instruction. Valid programs will never run into the "may or may not" condition; invalid programs can have unpredictable and inconsistent results. Seems fair to me, as this tradeoff is essential for instruction speed and performance.
On Fri, Apr 28, 2023 at 6:33 PM Robin Atwood <[email protected]> wrote: > Thanks, Michael, that is the problem. The next page is available, but the > one after that isn't. Obviously, I had read the entry for TRE in the PoOps > but didn't take in the significance of the Access Exceptions clause. (In > fact, I still don't understand it: > "may or may not"!) > > The problem is I maintain legacy C code originally developed with SAS/C, > which had a strupr(s) function. There is no length > parameter, so I was at a loss what to set R1+1 to for the TRE instruction. > I could search for the zero bytes using SRST but > presumably that would hit the same problem going off the end of a page. > Although, the SRST will wrap at top of storage - what does that imply? I > could invent the strnupr(s,n) function but that will involve many code > changes. ☹ > > @Ed Jaffe: thanks for the tip about the TEA, but where do you find it? > IPCS STATUS FAILDATA displays it but, in my dumps, PSA+90 and PDS+A8 both > have zero in the address part. > > Thanks to all who replied. > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Michael Stein > Sent: Thursday, April 27, 2023 10:20 PM > To: [email protected] > Subject: Re: Inexplicable 0C4! > > On Thu, Apr 27, 2023 at 07:58:23PM +0700, Robin Atwood wrote: > > I have had two of these during the course of two months, so it's > > getting serious! > > > > The abend happens in my implementation of a C strupr() function when > > the TRE instruction is executed: > > > > TST TRE R2,R1 fold string > > > > R0 R1 R2 R3 PSW > > > > 00000000 0009C5EC 1AA748F8 7FFFFFFF 078D04008009BD14 > > from principles of operation TRE: > > Access exceptions for the portion of the first operand to the right of > the last byte processed may or may not be recognized. For an operand > longer than 4K bytes, access exceptions are not recognized for locations > more than 4K bytes beyond the last byte processed. > > Access exceptions for all 256 bytes of the second operand may be > recognized, even if not all bytes are used. > > The first operand is > 4K bytes, R2 is 1AA748F8, what's the status of the > next page? > > R1 looks ok as the 2nd operand only needs to clear 256 bytes. > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
