Re: Inexplicable 0C4!
@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. I don't recall seeing what the reason code was with the 0C4. That is highly relevant. But assuming it was a program interrupt for which there is a translation exception ID (If this was 0C4-4 there might well not be a TEID) and that that ID contains an address, I don't know why you would expect PSA+90 at the time of a dump to have anything of relevance (especially in z/architecture). And I have no idea what "PDS+A8" is, but perhaps you meant PSA+A8. At the time of the program check PSA+A8 for 8 bytes was set with the translation exception ID. That too has no relevance at the time of the dump. The operating system would then have moved that somewhere else because PSA+A8 would then be set again on the next program interrupt that is defined to provide a TEID. That "somewhere else", for the simple case (not recursive program checks), is LCCXLCCAPVAD which has the comment "Translation exception address (from 168-175)" which isn't architecturally accurate in that the value is not necessarily an "address". 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: Inexplicable 0C4!
I could search for the zero bytes using SRST but presumably that would hit the same problem going off the end of a page Do not presume anything. Read the POp. Carefully. "May or may not" means exactly what it says. It is allowed to do it and it is allowed not to do it, architecturally. In practice, a given machine will choose one way or the other but even that is not guaranteed. It would architecturally be allowed to do it one way on Mondays and the other way on Tuesdays. If you use SRST with a big enough range you will eventually encounter storage to which you are not authorized to read (unless you are key 0), or storage that is not allocated and will blow up. The x'7000' page in the address space is intentionally left as one that will always blow up on reference. 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: Inexplicable 0C4!
On 4/28/2023 10:25 AM, Steve Smith wrote: Frankly, I think it was unwise by z/OS to lump translation exceptions (PICs 10, 11, 39-3B) in with S0C4. There's a fundamental difference between attempting to access storage with the wrong key, and storage that doesn't exist (S0C5 is a variant). S0D0 for the latter would have make sense. Many abend codes have reason codes. Abend0C4 reason codes are simply the PIC codes. That seems canonical to me if you think of an 0C4 as a "storage access problem" whether by protection or translation or whatever. Consult the reason code for the specific failure reason. Makes sense. To my mind, the bigger issue is the inconsistent handling of the NSI address in the PSW. If it's a protection exception, the PSW NSI address has been incremented by the ILC. For a translation exception is has not been incremented (to allow for easy retry by the OS after the page fault is resolved). Subtle complexities of this kind help make z/OS dump reading difficult for those new to the platform... -- 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: Inexplicable 0C4!
I would have said that it was unwise of IBM to overload ABEND S0C4 in OS/VS, but that once they had done so there was no graceful way to change it. From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Friday, April 28, 2023 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! To be clear, the TEA is only relevant for Translation Exceptions, and a PIC 4 is not. Notwithstanding that your trace entry example *is* a PIC 4, and that is great information. Frankly, I think it was unwise by z/OS to lump translation exceptions (PICs 10, 11, 39-3B) in with S0C4. There's a fundamental difference between attempting to access storage with the wrong key, and storage that doesn't exist (S0C5 is a variant). S0D0 for the latter would have make sense. I'm quite clear that changing such things isn't practicable. sas On Fri, Apr 28, 2023 at 12:52 PM Ed Jaffe wrote: > On 4/28/2023 1:32 AM, Robin Atwood wrote: > > @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. > > The TEA is displayed on various IPCS displays. It's captured for the > SDWA at just the right time. I think the PSA fields could be overlaid > before they are dumped, so I would never trust them. > > Personally, my favorite "go to" after inspecting PSW and registers is > the SYSTRACE. (I did a GSE UK pitch on that in November and a reprised > it as a SHARE pitch in Atlanta.) For example, a protection exception: > > 0004 0149 03923F00 PGM004 _1747106C 00060004 > 4714 8000 7F328404 <-- Here! > 0004 0149 03923F00 *RCVY PROG940C4000 0004 > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://secure-web.cisco.com/1LTeO8jjKs-9V68uCa-qszCjWRxkKrKtDIA9Y6siWpcmrg1V4fnTK5QXpBUBNlzSKP41w8ZfHJznskS6KbFFNNCsedRr6pefb7X0jjA9JG4zzYtXncb04UYn7MT0oX2tSSi7e7x8Y62lHhFkm5xm_K6Xi7JDok91XcBwVK-uJ9WcPhRPNwAC2x6My_E1bph2tzBREZiIg63r1Z6pgkB5ZO_nE4QnaoU8KqbG1HlGtfp3IUF2rAiVoM8Lk1_0g6jmZu-UCwV5oeAkQdkUZYvwtpDVotknpH8vUfFI7KZaKFDLtL7s44kWlrLCgvZsE1TCDFuvmiRuaTGjQAfZcIaxmjwZth28cPPvwffz6nQ8XThqaKNkrmd5Bs1Fe3aGtOvsUSJ-21GPz-dDxqo713UaOhOxEO7jrnF_T-DXSX1e8T80/https%3A%2F%2Fwww.phoenixsoftware.com%2F > > -- 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: Inexplicable 0C4!
To be clear, the TEA is only relevant for Translation Exceptions, and a PIC 4 is not. Notwithstanding that your trace entry example *is* a PIC 4, and that is great information. Frankly, I think it was unwise by z/OS to lump translation exceptions (PICs 10, 11, 39-3B) in with S0C4. There's a fundamental difference between attempting to access storage with the wrong key, and storage that doesn't exist (S0C5 is a variant). S0D0 for the latter would have make sense. I'm quite clear that changing such things isn't practicable. sas On Fri, Apr 28, 2023 at 12:52 PM Ed Jaffe wrote: > On 4/28/2023 1:32 AM, Robin Atwood wrote: > > @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. > > The TEA is displayed on various IPCS displays. It's captured for the > SDWA at just the right time. I think the PSA fields could be overlaid > before they are dumped, so I would never trust them. > > Personally, my favorite "go to" after inspecting PSW and registers is > the SYSTRACE. (I did a GSE UK pitch on that in November and a reprised > it as a SHARE pitch in Atlanta.) For example, a protection exception: > > 0004 0149 03923F00 PGM004 _1747106C 00060004 > 4714 8000 7F328404 <-- Here! > 0004 0149 03923F00 *RCVY PROG940C4000 0004 > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
On 4/28/2023 1:32 AM, Robin Atwood wrote: @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. The TEA is displayed on various IPCS displays. It's captured for the SDWA at just the right time. I think the PSA fields could be overlaid before they are dumped, so I would never trust them. Personally, my favorite "go to" after inspecting PSW and registers is the SYSTRACE. (I did a GSE UK pitch on that in November and a reprised it as a SHARE pitch in Atlanta.) For example, a protection exception: 0004 0149 03923F00 PGM 004 _1747106C 00060004 4714 8000 7F328404 <-- Here! 0004 0149 03923F00 *RCVY PROG 940C4000 0004 -- 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: Inexplicable 0C4!
The interruptible instructions (usually) only get interrupted if the string is longer than 256 bytes, which is not usually the case. We just need a simple function for operating on short strings, very often. Some of the suggestions to allocate lots of extra pages were somewhat missing the point! -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Friday, April 28, 2023 7:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! On 28/4/23 19:57, Robin Atwood wrote: > I need to know the length of the string, preferably without needing a > new parameter and altering a lot of code. At which point I remembered > that the XL/C compiler generates inline code for the strlen(s) function. For > those who are interested, this is: Why don't you just use TRT like the C/C++ compiler does for it's inline string handling optimizations? In our experience those interruptible instructions may seem like syntactic sugar but they don't perform better. The only noticeable difference was the introduction of the SIMD instructions. > > LRR4,R2 copy string ptr > XRR0,R0 search for zero byte > SRST R0,R4 search > BO*-4 resume search > SLR R0,R2 get length > > I assume some magic causes the SRST not to "recognize an access > exception" because normally the first register > (R0 here) contains an address limiting the search. Well, that was an > interesting exercise! > > Thanks > > On Fri, Apr 28, 2023 at 6:33 PM Robin Atwood 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 On >> Behalf Of Michael Stein >> Sent: Thursday, April 27, 2023 10:20 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> 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 R3PSW >>> >>> 0009C5EC 1AA748F8 7FFF 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 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: Inexplicable 0C4!
On 28/4/23 19:57, Robin Atwood wrote: I need to know the length of the string, preferably without needing a new parameter and altering a lot of code. At which point I remembered that the XL/C compiler generates inline code for the strlen(s) function. For those who are interested, this is: Why don't you just use TRT like the C/C++ compiler does for it's inline string handling optimizations? In our experience those interruptible instructions may seem like syntactic sugar but they don't perform better. The only noticeable difference was the introduction of the SIMD instructions. LRR4,R2 copy string ptr XRR0,R0 search for zero byte SRST R0,R4 search BO*-4 resume search SLR R0,R2 get length I assume some magic causes the SRST not to "recognize an access exception" because normally the first register (R0 here) contains an address limiting the search. Well, that was an interesting exercise! Thanks On Fri, Apr 28, 2023 at 6:33 PM Robin Atwood 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 On Behalf Of Michael Stein Sent: Thursday, April 27, 2023 10:20 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 R3PSW 0009C5EC 1AA748F8 7FFF 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 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: Inexplicable 0C4!
K3wl. Using R0 as R_1 reminds me of the BXH/BXLE trick for testing successive bits. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Robin Atwood [abend...@gmail.com] Sent: Friday, April 28, 2023 7:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! I need to know the length of the string, preferably without needing a new parameter and altering a lot of code. At which point I remembered that the XL/C compiler generates inline code for the strlen(s) function. For those who are interested, this is: LRR4,R2 copy string ptr XRR0,R0 search for zero byte SRST R0,R4 search BO*-4 resume search SLR R0,R2 get length I assume some magic causes the SRST not to "recognize an access exception" because normally the first register (R0 here) contains an address limiting the search. Well, that was an interesting exercise! Thanks On Fri, Apr 28, 2023 at 6:33 PM Robin Atwood 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 On > Behalf Of Michael Stein > Sent: Thursday, April 27, 2023 10:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 R3PSW > > > > 0009C5EC 1AA748F8 7FFF 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 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: Inexplicable 0C4!
Treat the page size as 4K and drive on. The difference in execution speed probably isn't worth the issues. On Fri, Apr 28, 2023 at 7:15 AM Seymour J Metz wrote: > Set the initial length to the remaining bytes on the "page". After that, > use the "page size". That leaves the question of how an unpriveleged > program determines the "page size". > > Scare quotes because a 1 MiB "page" is actually a segment in the > nomenclature of PoOps. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org] > Sent: Friday, April 28, 2023 7:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Inexplicable 0C4! > > On Fri, 28 Apr 2023, at 12:31, Michael Stein wrote: > > > How about setting the length to include just to the end of the current > > page. Then as the first operand doesn't cross a page boundary ... > > Just imagine if the first operand started on the last byte of the page! > > Wouldn't it be better to getmain a page (or a few more), just for the > first operand to reside in, and then follow your "do it in chunks" > approach? > > -- > Jeremy Nicoll - my opinions are my own. > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
Set the initial length to the remaining bytes on the "page". After that, use the "page size". That leaves the question of how an unpriveleged program determines the "page size". Scare quotes because a 1 MiB "page" is actually a segment in the nomenclature of PoOps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org] Sent: Friday, April 28, 2023 7:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! On Fri, 28 Apr 2023, at 12:31, Michael Stein wrote: > How about setting the length to include just to the end of the current > page. Then as the first operand doesn't cross a page boundary ... Just imagine if the first operand started on the last byte of the page! Wouldn't it be better to getmain a page (or a few more), just for the first operand to reside in, and then follow your "do it in chunks" approach? -- Jeremy Nicoll - my opinions are my own. -- 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: Inexplicable 0C4!
I was thinking along those lines but then had a better idea. See my other post. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Stein Sent: Friday, April 28, 2023 6:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! On Fri, Apr 28, 2023 at 03:32:59PM +0700, Robin Atwood wrote: > Thanks, Michael, that is the problem. The next page is available, but > the one after that isn't. > 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. You could look at the TRE instrucion as an optimization and not expect it to do all the work. How about setting the length to include just to the end of the current page. Then as the first operand doesn't cross a page boundary it should avoid the 0C4 since the original address was to a valid storage location and it won't go outside that 4K page. After the TRE the CC is set: For CC 3 the TRE hasn't found the end and there still are bytes to process in the first operand so you loop back to the TRE. For CC 1 the TRE has found the end character so you are done. For CC 0 the TRE has landed on the start of the next page without finding the end character so you give it 4K more (set the length to 4K) branch back to the TRE. -- 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: Inexplicable 0C4!
I need to know the length of the string, preferably without needing a new parameter and altering a lot of code. At which point I remembered that the XL/C compiler generates inline code for the strlen(s) function. For those who are interested, this is: LRR4,R2 copy string ptr XRR0,R0 search for zero byte SRST R0,R4 search BO*-4 resume search SLR R0,R2 get length I assume some magic causes the SRST not to "recognize an access exception" because normally the first register (R0 here) contains an address limiting the search. Well, that was an interesting exercise! Thanks On Fri, Apr 28, 2023 at 6:33 PM Robin Atwood 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 On > Behalf Of Michael Stein > Sent: Thursday, April 27, 2023 10:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 R3PSW > > > > 0009C5EC 1AA748F8 7FFF 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
On Fri, 28 Apr 2023, at 12:31, Michael Stein wrote: > How about setting the length to include just to the end of the current > page. Then as the first operand doesn't cross a page boundary ... Just imagine if the first operand started on the last byte of the page! Wouldn't it be better to getmain a page (or a few more), just for the first operand to reside in, and then follow your "do it in chunks" approach? -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
On Fri, Apr 28, 2023 at 03:32:59PM +0700, Robin Atwood wrote: > Thanks, Michael, that is the problem. The next page is available, > but the one after that isn't. > 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. You could look at the TRE instrucion as an optimization and not expect it to do all the work. How about setting the length to include just to the end of the current page. Then as the first operand doesn't cross a page boundary it should avoid the 0C4 since the original address was to a valid storage location and it won't go outside that 4K page. After the TRE the CC is set: For CC 3 the TRE hasn't found the end and there still are bytes to process in the first operand so you loop back to the TRE. For CC 1 the TRE has found the end character so you are done. For CC 0 the TRE has landed on the start of the next page without finding the end character so you give it 4K more (set the length to 4K) branch back to the TRE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
"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 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 On Behalf > Of Michael Stein > Sent: Thursday, April 27, 2023 10:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 R3PSW > > > > 0009C5EC 1AA748F8 7FFF 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 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: Inexplicable 0C4!
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 On Behalf Of Michael Stein Sent: Thursday, April 27, 2023 10:20 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 R3PSW > > 0009C5EC 1AA748F8 7FFF 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 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: Inexplicable 0C4!
On Thu, 27 Apr 2023 19:58:23 +0700, Robin Atwood wrote: >Notice R3 hasn't changed, so the abend happened on the very first byte. You don't know that. As I read it, POO says that R2 and R3 are adjusted when the condition code is set. It does not say that they are changed with every byte translated. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
IMO R3 should be set to a length that reflects the end of the storage
containing the string.
Setting the length to 2 GB-1 is sloppy programming.
--
Tom Marchant
On Thu, 27 Apr 2023 14:09:17 -0700, Michael Stein wrote:
>On Thu, Apr 27, 2023 at 07:54:56PM +, Seymour J Metz wrote:
>> R1 is the table address; only 256 bytees need to be addressable. R2
>> is the string address, and you need write access to everything up until
>> the delimiter ('00'x in this case.)
>
>No! You need write access for at least 4K from the start of the string even
>if that's past the x'00'.
>
>From z/Architecture Priciples of Operation for the TRE instruction:
>
> 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.
>
>His operand is 7fff long so it's longer than 4K so the at a minimum
>he needs write access to the 4K where the string starts and the
>next 4K too since the string doesn't start on a 4K boundary.
>
>That's probably why his 0C4 only happens sometimes -- it depends
>on the status/protect key of the next 4K block.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
Yikes!
From: IBM Mainframe Discussion List on behalf of
Michael Stein
Sent: Thursday, April 27, 2023 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inexplicable 0C4!
On Thu, Apr 27, 2023 at 07:54:56PM +, Seymour J Metz wrote:
> R1 is the table address; only 256 bytees need to be addressable. R2
> is the string address, and you need write access to everything up until
> the delimiter ('00'x in this case.)
No! You need write access for at least 4K from the start of the string even
if that's past the x'00'.
>From z/Architecture Priciples of Operation for the TRE instruction:
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.
His operand is 7fff long so it's longer than 4K so the at a minimum
he needs write access to the 4K where the string starts and the
next 4K too since the string doesn't start on a 4K boundary.
That's probably why his 0C4 only happens sometimes -- it depends
on the status/protect key of the next 4K block.
--
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: Inexplicable 0C4!
On Thu, Apr 27, 2023 at 07:54:56PM +, Seymour J Metz wrote:
> R1 is the table address; only 256 bytees need to be addressable. R2
> is the string address, and you need write access to everything up until
> the delimiter ('00'x in this case.)
No! You need write access for at least 4K from the start of the string even
if that's past the x'00'.
>From z/Architecture Priciples of Operation for the TRE instruction:
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.
His operand is 7fff long so it's longer than 4K so the at a minimum
he needs write access to the 4K where the string starts and the
next 4K too since the string doesn't start on a 4K boundary.
That's probably why his 0C4 only happens sometimes -- it depends
on the status/protect key of the next 4K block.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
R1 is the table address; only 256 bytees need to be addressable. R2 is the
string address, and you need write access to everything up until the delimiter
('00'x in this case.)
From: IBM Mainframe Discussion List on behalf of
Michael Stein
Sent: Thursday, April 27, 2023 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inexplicable 0C4!
On Thu, Apr 27, 2023 at 03:28:26PM +, Seymour J Metz wrote:
> Is it possible that the string is in key 0 or read-only storage?
It's a certainty for the whole string, but probably not for the part
ending at the first x'00' byte.
TST TRE R2,R1 fold string
R0 R1 R2 R3PSW
0009C5EC 1AA748F8 7FFF 078D04008009BD14
The string goes from the address in R2 for the length in R3:
So from 1AA748F8 for a length of 7FFF.
Now TRE will stop on the character in the low byte of R0 but can
get address exceptions for up to 4K beyond the matching byte.
So whats the protection status of the 4K block after the one pointed to by
R1, ie: 1AA748F8 -> 1AA75000
This 0C4 probably only happens when that next 4K block isn't storable...
--
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: Inexplicable 0C4!
On Thu, Apr 27, 2023 at 03:28:26PM +, Seymour J Metz wrote: > Is it possible that the string is in key 0 or read-only storage? It's a certainty for the whole string, but probably not for the part ending at the first x'00' byte. TST TRE R2,R1 fold string R0 R1 R2 R3PSW 0009C5EC 1AA748F8 7FFF 078D04008009BD14 The string goes from the address in R2 for the length in R3: So from 1AA748F8 for a length of 7FFF. Now TRE will stop on the character in the low byte of R0 but can get address exceptions for up to 4K beyond the matching byte. So whats the protection status of the 4K block after the one pointed to by R1, ie: 1AA748F8 -> 1AA75000 This 0C4 probably only happens when that next 4K block isn't storable... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
Is it possible that the string is in key 0 or read-only storage? From: IBM Mainframe Discussion List on behalf of Michael Stein Sent: Thursday, April 27, 2023 11:19 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 R3PSW > > 0009C5EC 1AA748F8 7FFF 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 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: 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 R3PSW > > 0009C5EC 1AA748F8 7FFF 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
BC 1 seems to be correct. From: IBM Mainframe Discussion List on behalf of Joe Monk Sent: Thursday, April 27, 2023 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! "If the operation is completed with condition code 0, the contents of general register R1 are incremented by the contents of general register R1 + 1, and then the contents of general register R1 + 1 are set to zero. If the operation is completed with condition code 1, the contents of general register R1 + 1 are decremented by the number of bytes processed before the first-operand byte equal to the test byte was encountered, and the contents of general register R1 are incremented by the same number, so that general register R1 contains the address of the equal byte. If the operation is completed with condition code 3, the contents of general register R1 + 1 are decremented by the number of bytes processed, and the contents of general register R1 are incremented by the same number, so that the instruction, when reexecuted, resumes at the next byte to be processed." I think you may want to re-evaulate your BC processing... Joe On Thu, Apr 27, 2023 at 8:53 AM Binyamin Dissen wrote: > Which flavor of 0C4? > > If PIC-10/11, the address is reported. > > On Thu, 27 Apr 2023 19:58:23 +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: > :> > :> > :> > :> L R3,=X'7FFF'string maximum length > :> > :> XRR0,R0 zero terminator byte > :> > :> LA R1,UPRXtranslate table > :> > :>TST TRE R2,R1 fold string > :> > :> BC 1,TSTresume translation > :> > :> > :> > :> R0 R1 R2 R3 > :>PSW > :> > :> 0009C5EC 1AA748F8 7FFF 078D04008009BD14 > :> > :> > :> > :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so > bog > :>standard. I know R3 > :> > :>looks dodgy, but that is because the string to be upper-cased must be > zero > :>byte terminated. > :> > :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all > :>this, why has the instruction caused an > :> > :>abend? The code lives in a server that is running all day, every day. I > :>wondered if the target data had been > :> > :>released by another task, but VSMDATA showed a DQE for the data's page > and > :>no FQE for the data itself, > :> > :>so the data should still be available (as I understand it). Notice R3 > hasn't > :>changed, so the abend happened > :> > :>on the very first byte. > :> > :> > :> > :>Any suggestions gratefully received! > :> > :>Robin > :> > :> > :> > :> > :> > :> > :> > :> > :>-- > :>For IBM-MAIN subscribe / signoff / archive access instructions, > :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Binyamin Dissen > http://www.dissensoftware.com/ > > Director, Dissen Software, Bar & Grill - Israel > > -- > 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: Inexplicable 0C4!
"If the operation is completed with condition code 0, the contents of general register R1 are incremented by the contents of general register R1 + 1, and then the contents of general register R1 + 1 are set to zero. If the operation is completed with condition code 1, the contents of general register R1 + 1 are decremented by the number of bytes processed before the first-operand byte equal to the test byte was encountered, and the contents of general register R1 are incremented by the same number, so that general register R1 contains the address of the equal byte. If the operation is completed with condition code 3, the contents of general register R1 + 1 are decremented by the number of bytes processed, and the contents of general register R1 are incremented by the same number, so that the instruction, when reexecuted, resumes at the next byte to be processed." I think you may want to re-evaulate your BC processing... Joe On Thu, Apr 27, 2023 at 8:53 AM Binyamin Dissen wrote: > Which flavor of 0C4? > > If PIC-10/11, the address is reported. > > On Thu, 27 Apr 2023 19:58:23 +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: > :> > :> > :> > :> L R3,=X'7FFF'string maximum length > :> > :> XRR0,R0 zero terminator byte > :> > :> LA R1,UPRXtranslate table > :> > :>TST TRE R2,R1 fold string > :> > :> BC 1,TSTresume translation > :> > :> > :> > :> R0 R1 R2 R3 > :>PSW > :> > :> 0009C5EC 1AA748F8 7FFF 078D04008009BD14 > :> > :> > :> > :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so > bog > :>standard. I know R3 > :> > :>looks dodgy, but that is because the string to be upper-cased must be > zero > :>byte terminated. > :> > :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all > :>this, why has the instruction caused an > :> > :>abend? The code lives in a server that is running all day, every day. I > :>wondered if the target data had been > :> > :>released by another task, but VSMDATA showed a DQE for the data's page > and > :>no FQE for the data itself, > :> > :>so the data should still be available (as I understand it). Notice R3 > hasn't > :>changed, so the abend happened > :> > :>on the very first byte. > :> > :> > :> > :>Any suggestions gratefully received! > :> > :>Robin > :> > :> > :> > :> > :> > :> > :> > :> > :>-- > :>For IBM-MAIN subscribe / signoff / archive access instructions, > :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > 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: Inexplicable 0C4!
On 4/27/2023 5:58 AM, Robin Atwood wrote: Any suggestions gratefully received! Look at the TEA value in the dump (ignoring the last three nybbles). That will tell you where in virtual storage the problem was discovered. -- 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: Inexplicable 0C4!
No, but perhaps LGFI, avoiding the literal, would be better. From: IBM Mainframe Discussion List on behalf of Clifford McNeill <04cc09e1fcab-dmarc-requ...@listserv.ua.edu> Sent: Thursday, April 27, 2023 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! should this load L R3,=X'7FFF'string maximum length be a load address? LA R3,=X'7FFF' On 4/27/2023 8:52 AM, Binyamin Dissen wrote: > Which flavor of 0C4? > > If PIC-10/11, the address is reported. > > On Thu, 27 Apr 2023 19:58:23 +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: > :> > :> > :> > :> L R3,=X'7FFF'string maximum length > :> > :> XRR0,R0 zero terminator byte > :> > :> LA R1,UPRXtranslate table > :> > :>TST TRE R2,R1 fold string > :> > :> BC 1,TSTresume translation > :> > :> > :> > :> R0 R1 R2 R3 > :>PSW > :> > :> 0009C5EC 1AA748F8 7FFF 078D04008009BD14 > :> > :> > :> > :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog > :>standard. I know R3 > :> > :>looks dodgy, but that is because the string to be upper-cased must be zero > :>byte terminated. > :> > :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all > :>this, why has the instruction caused an > :> > :>abend? The code lives in a server that is running all day, every day. I > :>wondered if the target data had been > :> > :>released by another task, but VSMDATA showed a DQE for the data's page and > :>no FQE for the data itself, > :> > :>so the data should still be available (as I understand it). Notice R3 hasn't > :>changed, so the abend happened > :> > :>on the very first byte. > :> > :> > :> > :>Any suggestions gratefully received! > :> > :>Robin > :> > :> > :> > :> > :> > :> > :> > :> > :>-- > :>For IBM-MAIN subscribe / signoff / archive access instructions, > :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Binyamin Dissen > http://secure-web.cisco.com/14Z0n8HNM1J6A-lr5C6rpokRsSjYebS7TqRLaP2ymVFrOiaHNSa2hlqBFcvHHl0VbDIeh-aNPygmcDzT42x3jngWi7SaEh8HwDibZMtskCdbeJKXq7zoO4pQRGI88_ak-1oHMtvqgLSsg4gaysP9wCKEDGB2_kMrPMymBvbM3yEJvOzLCTBmyxmvBvseZlvGl20q2lZhFiEjrY_sTHlNANYCSC3O3lVSF3-_mlcXt1AyU8fj8AbTsB5RQTVlBjNdZvgB6UUBtAWXZvxDSvj3oMi695E4Luheoux66PYUau56cB07N96lPg0c42XayBMYyiG8qQedBXxiUpQ3xJvQmswCFcKkrdU7-k8L1eJOFvxf1xw7WEY4dUYszOI2lxFjLJ2EdO_QlyKUlpvBLDNrYAygarAo6Ylx8wYg2OUWmngw/http%3A%2F%2Fwww.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > 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: Inexplicable 0C4!
never mind, more coffee On 4/27/2023 9:12 AM, Clifford McNeill wrote: should this load L R3,=X'7FFF' string maximum length be a load address? LA R3,=X'7FFF' On 4/27/2023 8:52 AM, Binyamin Dissen wrote: Which flavor of 0C4? If PIC-10/11, the address is reported. On Thu, 27 Apr 2023 19:58:23 +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: :> :> :> :> L R3,=X'7FFF' string maximum length :> :> XR R0,R0 zero terminator byte :> :> LA R1,UPRX translate table :> :>TST TRE R2,R1 fold string :> :> BC 1,TST resume translation :> :> :> :> R0 R1 R2 R3 :>PSW :> :> 0009C5EC 1AA748F8 7FFF 078D04008009BD14 :> :> :> :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog :>standard. I know R3 :> :>looks dodgy, but that is because the string to be upper-cased must be zero :>byte terminated. :> :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all :>this, why has the instruction caused an :> :>abend? The code lives in a server that is running all day, every day. I :>wondered if the target data had been :> :>released by another task, but VSMDATA showed a DQE for the data's page and :>no FQE for the data itself, :> :>so the data should still be available (as I understand it). Notice R3 hasn't :>changed, so the abend happened :> :>on the very first byte. :> :> :> :>Any suggestions gratefully received! :> :>Robin :> :> :> :> :> :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- 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: Inexplicable 0C4!
should this load L R3,=X'7FFF'string maximum length be a load address? LA R3,=X'7FFF' On 4/27/2023 8:52 AM, Binyamin Dissen wrote: Which flavor of 0C4? If PIC-10/11, the address is reported. On Thu, 27 Apr 2023 19:58:23 +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: :> :> :> :> L R3,=X'7FFF'string maximum length :> :> XRR0,R0 zero terminator byte :> :> LA R1,UPRXtranslate table :> :>TST TRE R2,R1 fold string :> :> BC 1,TSTresume translation :> :> :> :> R0 R1 R2 R3 :>PSW :> :> 0009C5EC 1AA748F8 7FFF 078D04008009BD14 :> :> :> :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog :>standard. I know R3 :> :>looks dodgy, but that is because the string to be upper-cased must be zero :>byte terminated. :> :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all :>this, why has the instruction caused an :> :>abend? The code lives in a server that is running all day, every day. I :>wondered if the target data had been :> :>released by another task, but VSMDATA showed a DQE for the data's page and :>no FQE for the data itself, :> :>so the data should still be available (as I understand it). Notice R3 hasn't :>changed, so the abend happened :> :>on the very first byte. :> :> :> :>Any suggestions gratefully received! :> :>Robin :> :> :> :> :> :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- 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: Inexplicable 0C4!
Which flavor of 0C4? If PIC-10/11, the address is reported. On Thu, 27 Apr 2023 19:58:23 +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: :> :> :> :> L R3,=X'7FFF'string maximum length :> :> XRR0,R0 zero terminator byte :> :> LA R1,UPRXtranslate table :> :>TST TRE R2,R1 fold string :> :> BC 1,TSTresume translation :> :> :> :> R0 R1 R2 R3 :>PSW :> :> 0009C5EC 1AA748F8 7FFF 078D04008009BD14 :> :> :> :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog :>standard. I know R3 :> :>looks dodgy, but that is because the string to be upper-cased must be zero :>byte terminated. :> :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all :>this, why has the instruction caused an :> :>abend? The code lives in a server that is running all day, every day. I :>wondered if the target data had been :> :>released by another task, but VSMDATA showed a DQE for the data's page and :>no FQE for the data itself, :> :>so the data should still be available (as I understand it). Notice R3 hasn't :>changed, so the abend happened :> :>on the very first byte. :> :> :> :>Any suggestions gratefully received! :> :>Robin :> :> :> :> :> :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
Is UPRX a full 256 bytes? From: IBM Mainframe Discussion List on behalf of Robin Atwood Sent: Thursday, April 27, 2023 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Inexplicable 0C4! 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: L R3,=X'7FFF'string maximum length XRR0,R0 zero terminator byte LA R1,UPRXtranslate table TST TRE R2,R1 fold string BC 1,TSTresume translation R0 R1 R2 R3 PSW 0009C5EC 1AA748F8 7FFF 078D04008009BD14 The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog standard. I know R3 looks dodgy, but that is because the string to be upper-cased must be zero byte terminated. R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all this, why has the instruction caused an abend? The code lives in a server that is running all day, every day. I wondered if the target data had been released by another task, but VSMDATA showed a DQE for the data's page and no FQE for the data itself, so the data should still be available (as I understand it). Notice R3 hasn't changed, so the abend happened on the very first byte. Any suggestions gratefully received! Robin -- 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
Inexplicable 0C4!
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: L R3,=X'7FFF'string maximum length XRR0,R0 zero terminator byte LA R1,UPRXtranslate table TST TRE R2,R1 fold string BC 1,TSTresume translation R0 R1 R2 R3 PSW 0009C5EC 1AA748F8 7FFF 078D04008009BD14 The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog standard. I know R3 looks dodgy, but that is because the string to be upper-cased must be zero byte terminated. R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all this, why has the instruction caused an abend? The code lives in a server that is running all day, every day. I wondered if the target data had been released by another task, but VSMDATA showed a DQE for the data's page and no FQE for the data itself, so the data should still be available (as I understand it). Notice R3 hasn't changed, so the abend happened on the very first byte. Any suggestions gratefully received! Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
