The code looks fine, even if invoked in 64 bit mode. I'd worry a bit more about the cache hit, the STCK is likely storing into the same cache line.
> -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Farley, Peter x23353 > Sent: Wednesday, March 17, 2021 11:06 AM > To: [email protected] > Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky > to use? > > Yes, making it a simple callable assembler routine is the safest option, but > introduces yet another assembler routine into the production source pool > when there are fewer and fewer assembler-knowledgeable programmers > left. > > If COBOL supported the "hardware builtin" functions provided with XLC it > would be totally safe. > > As I said in a prior reply, I worry most about the structure of the > PROCEDURE-POINTER possibly changing for 64-bit mode, which an assembler > subroutine certainly avoids. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Matt Hogstrom > Sent: Wednesday, March 17, 2021 1:29 PM > To: [email protected] > Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky > to use? > > I recall doing something like this about 30 years ago which I know would > break one day. I wanted to process VB ISAM but that wasn’t supported so I > figured out a way to search backwards from WS with negative indexes until I > found the DCB for the file and “moved a byte” with the right bit on for V. > > I would expect your hack to work for many years, although, the next guy to > try and maintain the code might not understand it. I’d make it callable > module. I mean, who doesn’t need a good STCK once in a while? > > Nice. > > Matt Hogstrom > [email protected] > PGP Key: 0x90ECB270 > > > On Mar 17, 2021, at 11:50 AM, Farley, Peter x23353 <0000031df298a9da- > [email protected]> wrote: > > > > I discovered that one can code and call extremely simple assembler code > from completely within a COBOL source program, but it is a two-step process > which I will describe below. > > > > My question is whether using a technique like this is "risky" in the sense > that it may someday, under a future incarnation of the compiler, stop > working? > > > > The technique: > > > > Code a simple assembler program like the following and browse the > resulting listing that shows the generated object code: > > > > 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 > > > > Then copy the generated object code into a COBOL source program as > follows: > > > > ID DIVISION. > > PROGRAM-ID. COBSTCKE. > > ENVIRONMENT DIVISION. > > DATA DIVISION. > > WORKING-STORAGE SECTION. > > 01 WS-TOD-VALUE PIC X(16). > > > > 01 WS-GETTOD-PROGRAM. > > * GET ARGUMENT ADDRESS L 15,0(,1) > > 05 FILLER PIC X(04) VALUE X'58F01000'. > > * STCKE INTO ARGUMENT AREA STCKE 0(15) > > 05 FILLER PIC X(04) VALUE X'B278F000'. > > * SET RETURN-CODE = 0 XR 15,15 > > 05 FILLER PIC X(02) VALUE X'17FF'. > > * RETURN TO CALLER BR 14 > > 05 FILLER PIC X(02) VALUE X'07FE'. > > > > 01 WS-GETTOD-PTR. > > 05 GETTOD-ADDR PROCEDURE-POINTER VALUE NULL. > > 05 FILLER REDEFINES GETTOD-ADDR. > > 10 GETTOD-ADDR1 POINTER. > > 10 GETTOD-ADDR2 POINTER. > > > > PROCEDURE DIVISION. > > > > SET GETTOD-ADDR1 TO ADDRESS OF WS-GETTOD-PROGRAM. > > CALL GETTOD-ADDR USING WS-TOD-VALUE. > > DISPLAY FUNCTION HEX-OF (WS-TOD-VALUE). > > GOBACK. > > > > Peter > -- > > 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 [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
