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?
