BC 1 seems to be correct. ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Joe Monk <[email protected]> Sent: Thursday, April 27, 2023 10:47 AM To: [email protected] 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 <[email protected]> wrote: > Which flavor of 0C4? > > If PIC-10/11, the address is reported. > > On Thu, 27 Apr 2023 19:58:23 +0700 Robin Atwood <[email protected]> > 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'7FFFFFFF' 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 > :> > :>00000000 0009C5EC 1AA748F8 7FFFFFFF 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 [email protected] with the message: INFO IBM-MAIN > > -- > Binyamin Dissen <[email protected]> > http://www.dissensoftware.com/ > > Director, Dissen Software, Bar & Grill - Israel > > ---------------------------------------------------------------------- > 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
