I suspect that you did "IPL CMS" and are running in ESA/390 Compatibility Mode.
First and most importantly, a client should not be executing a z/Architecture-only instruction while in ESA/390 compatibility mode. That is unpredictable behavior and is definitely not intended to be used. See POPS SA22-7832-12 p. 5-112, LHC: If the program issues any other instruction that is defined as being unique to the z/Architecture architectural mode, it is unpredictable whether an operation exception is recognized or the instruc- tion executes according to its z/Architecture defi- nition. If you instead do "IPL ZCMS" so that you are running in z/Architecture mode, I would expect your LRL instruction to work. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY Date: Fri, 30 Apr 2021 19:35:40 +0000 From: "Stanislawski, Shawn (National VM Capability)" <shaw...@dxc.com> Subject: Ensuring LRL 2nd operand alignment Trying to use the LRL(32) instruction ('C4D' / 'C4xD' opcode). But running into: DMSABE141T Operation exception -> 00DF5124 LRL C45D00006832 00000000 *** 00DF5124 PROG 0001 -> 0139B660 OPERATION Reading in the "zArchitecture Principles of Operation" (SA22-7832-12) = "For LOAD RELATIVE LONG (LRL, LGFRL), the second operand must be aligned on a word boundary,..." Guessing alignment is the problem. I know I can use a DS 0F to start the LRL instruction itself on a word boundary, but any ideas how to ensure that specifically the second operand of the LRL instruction will always be aligned on a word boundary? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN