Agreed about whether the that data area lands in storage that is
"executable=yes" being a real potential problem.
Agreed about the STCKE code being possibly incorrect for the AMODE 64 case.
I have decided not to use this clever but risky approach and have fallen back
to a simple assembler routine, though the COBOL 6.3 UUID4 intrinsic function is
a compelling alternative to STCKE, and is supported to boot.
I may not yet have that COBOL function installed on my employer's systems (we
are at COBOL V6.2 and that function was added via PTF according to the V6.3
documentation), so I may be stuck with STCKE in assembler for the moment
anyway. I will test and see.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Peter Relson
Sent: Thursday, March 18, 2021 7:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky
to use?
EXTERNAL EMAIL
Make sure that the storage for this lands in code that is "executable=yes"
(I have no idea if the compiler would put this into storage obtained for the
module as opposed to something more dynamic). Imagine if, some day, the default
for STORAGE OBTAIN changes from executable=no to executable=yes.
As to being able to work in AMODE 64, the code shown is possibly incorrect for
AMODE 64.
COBSTCKE CSECT ,
L 15,0(,1) GET ARGUMENT ADDRESS
STCKE 0(15) STCKE INTO ARGUMENT AREA
XR 15,15 SET RETURN CODE = 0
BR 14 RETURN TO CALLER
The L might have to be LLGT in order to work predictably in AMODE 64 unless it
is known that the linkage to get here always results in the high half of reg 15
being 0 when AMODE 64 (which it might, as long as this is not RMODE 64)..
Peter Relson
z/OS Core Technology Design
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
