Likely that documentation is not taking in to consideration more recent standards.
My source INCITS/ISO/IEC 1989:2014 [2014], the 2014 COBOL standard. It's only available for purchase, but I'll try to put some of it here. 13.10 Constant entry A constant entry defines a constant. A constant may be used in place of a literal. 13.10.1 General format [1 | 01] constant-name-1 CONSTANT [ IS GLOBAL ] [ as-expression | from-expression ] as-expression: AS [ arithmetic-expression | BYTE-LENGTH OF data-name | literal-1 | LENGTH OF data-name ] from-expression: FROM compilation-variable-name-1 ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Brian Chapman <bchapma...@gmail.com> Sent: Wednesday, March 17, 2021 5:20 PM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use? Frank, Do you have a source? https://www.ibm.com/support/knowledgecenter/SS6SG3_6.1.0/pg/tasks/tpbeg04d.html A constant is a data item that has only one value. COBOL does not define a construct for constants. However, you can define a data item with an initial value by coding a VALUE clause in the data description (instead of coding an INITIALIZE statement). On Wed, Mar 17, 2021, 5:48 PM Frank Swarbrick <frank.swarbr...@outlook.com> wrote: > 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Farley, Peter x23353 <0000031df298a9da-dmarc-requ...@listserv.ua.edu> > Sent: Wednesday, March 17, 2021 2:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> > 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Brian Chapman > Sent: Wednesday, March 17, 2021 3:54 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 <gib...@wsu.edu> 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 <IBM-MAIN@LISTSERV.UA.EDU> On > > > Behalf Of Farley, Peter x23353 > > > Sent: Wednesday, March 17, 2021 11:06 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > 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 <IBM-MAIN@LISTSERV.UA.EDU> On > > > Behalf Of Matt Hogstrom > > > Sent: Wednesday, March 17, 2021 1:29 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > 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 > > > m...@hogstrom.org > > > PGP Key: 0x90ECB270 > > > > > > > On Mar 17, 2021, at 11:50 AM, Farley, Peter x23353 > > > > <0000031df298a9da- > > > dmarc-requ...@listserv.ua.edu> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
