I just looked at the LR for PROCEDURE-POINTER. It says it has to be an entry point. I could see a future version of the compiler disallowing a SET to a working storage data item.
>From the LR: A procedure-pointer can point to a function descriptor for one of the following or can contain NULL: . The primary entry point of a COBOL program as defined by the program-ID paragraph of the outermost program of a compilation unit . An alternate entry point of a COBOL program as defined by a COBOL ENTRY statement . An entry point in a non-COBOL program Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Wednesday, March 17, 2021 10:57 AM To: [email protected] Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use? The actual CALL statement if the structure of the PROCEDURE-POINTER changes (e.g., for 64-bit mode). Peter -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Charles Mills Sent: Wednesday, March 17, 2021 1:07 PM To: [email protected] Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use? That is some impressive hacking! Something about it seems inherently risky as you know, but hard to see how it stops working. Which particular line of code might not be supported in the future? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Wednesday, March 17, 2021 8:50 AM To: [email protected] Subject: This Call-Assembler-inside-COBOL technique works, but is it risky to use? 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
