I was thinking along those lines but then had a better idea. See my other post.
-----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Michael Stein Sent: Friday, April 28, 2023 6:31 PM To: [email protected] 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 [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
