The COBOL CURRENT-DATE value is only accurate to hundredth of a second, far too coarse for generating unique values in multi-LPAR systems where many, many millions of records are processed all day long, each possibly needing a unique value (or sometimes multiple unique values) for various application purposes.
Only STCKE supplies values with enough precision in high-volume multi-LPAR environments. The COBOL V6.x intrinsic function FORMATTED-CURRENT-DATE hints at possibly higher-precision values below hundredths of seconds, and on pages 468-470 of the V6.3 Language Reference there are descriptions of possible formats that include up to 9 fractional digits for the seconds value, though how many of those are guaranteed unique from one function call to the next isn’t mentioned. As it is currently documented I would need to do some extensive empirical testing to see just how unique these values would be, and time costs money. In the end, using the STCKE value is just easier, since converting a suitably-precise binary value from the value of a call to FORMATTED-CURRENT-DATE would be a bit messy. Certainly possible, but messy. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Joe Monk Sent: Wednesday, March 17, 2021 6:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use? Why would you do this instead of using the intrinsic function CURRENT-DATE from COBOL? https://urldefense.com/v3/__https://www.ibm.com/support/knowledgecenter/en/SS6SG3_6.3.0/lr/ref/rlinfcur.html__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!ePM1Q5_p1SrkmS1tiXcXeScShKryCt48WpfRoCb02Wxu36lcmBtdE8ChCoqKDePwvfTvvA$ Joe On Wed, Mar 17, 2021 at 10: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
