AL4, Shirley. IBM used a similar trick with pseudo-register references way back when.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [[email protected]] on behalf of Tom Harper [[email protected]] Sent: Tuesday, May 4, 2021 9:48 AM To: [email protected] Subject: Re: Ensuring LRL 2nd operand alignment Here is how I code a similar instruction: CNOP 2,4 LLILF R14,0 ORG *-4 DC A(symbol+X’80000000’) BASSM R14,R15 So that the second operand can be an ADCON or VCON. You could do the same with LRL. Sent from my iPhone > On May 4, 2021, at 9:18 AM, Peter Relson <[email protected]> wrote: > > Tony H asked about a use case for LRL: > one obvious one is a non-reentrant module. > Or, as Shmuel mentioned, it might have been needed for cases where there > is no binder support for fullword immediate relocatable expressions. > > As to the OP's actual question, there are limited choices that come to > mind > -- the code was not actually running on a z10 or later machine; the OP > says "not the case". > -- If this is VM perhaps they have done something to ask that VM treat the > execution environment as an older machine. There is the concept of the > "virtual architecture level". > -- the data shown does not represent what happened -- either it was not a > PIC 1 or it was not a PIC 1 at that address. If this is repeatable then it > could have been helpful to show some preceding data and have the trace > that was shown cover the instruction before as well. > > Regardless, alignment of the operand is not relevant to the discussion. As > pointed out, a misaligned operand would have resulted in a specification > exception. > > Peter Relson > z/OS Core Technology Design -------------------------------------------------------------------------------- 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.
