The current COBOL standard supports constants. Not a CONSTANTS-SECTION but something like: 01 my-constant IS CONSTANT VALUE "This is a constant string".
I may have the syntax not quite correct, but don't feel like looking it up. IBM has not yet implemented this support in Enterprise COBOL. ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Farley, Peter x23353 <[email protected]> Sent: Wednesday, March 17, 2021 2:47 PM To: [email protected] <[email protected]> Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use? Yeah, I've seen that one too, but that could also happen to any dynamically called subroutine loaded in non-store-protected memory if the table index overrun is big enough (BTDTGTTS and the scars). I wouldn't contemplate embedding such "clever" code in a "normal" application program for the very reason you state, but instead I would put it in its own separately compiled subroutine intended to be dynamically called. Then if they overrun a table limit by a REALLY big amount they will have overwritten far more than just my "clever" routine. Having a CONSTANTS SECTION in addition to WORKING-STORAGE and LOCAL-STORAGE sections would be very nice indeed, and better still if the CONSANTS section used a store-protected storage pool, but we don’t have that, as you say. Of course, just writing the actual assembler code and making that source program yet another separately compiled subroutine is always an option too. It just feels like overkill for a four-instruction subroutine (not counting CSECT, END, AMODE, and RMODE). Replacing "clever" with a "builtin function" like XLC has would be my preferred solution, but we don’t have that to hand yet either. Peter -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Brian Chapman Sent: Wednesday, March 17, 2021 3:54 PM To: [email protected] Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use? It would be nice if COBOL had constant constructs. Knowing my shop's COBOL developers, I could easily see one of them placing a table above this, programmatically ignoring the COBOL OCCURS statement, and overrunning the table and into your VALUE statements. Thank you, Brian Chapman On Wed, Mar 17, 2021 at 2:12 PM Gibney, Dave <[email protected]> wrote: > 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
