> In COBOL compilers starting with COBOL for OS/390 & VM V2R2, the > ACCEPT DATE uses STCK. In previous compilers, it used SVC 11. >This has caused strange results for some users of system SET DATE.
Oh, that's interesting, Tom. I did some more searching and found an IBM Technote (No. 1170967) that explains the who, what and where: http://www-1.ibm.com/support/docview.wss?uid=swg21170967 (Before anyone continues reading, please read this document first) So, based on the explanations in this Technote, any call to obtain the date that uses the COBOL "ACCEPT id FROM DATE YYYYMMDD" new-style syntax and was compiled under an older COBOL compiler - or - COBOL "ACCEPT id FROM DATE" old-style syntax and was recently recompiled using a current COBOL compiler - or - Other functions that use STCK to return the hardware clock's date have the potential to return a "bad date" if the system's hardware clock is out of sync with the software clock (because the software clock was changed with the operator command "SET DATE=..."). That then could explain Brian P.'s problem. If his user's COBOL program, when run within a one-hour window around midnight returns a date that's "a day off", then it must be retrieving the hardware clock's date and the hardware clock is out of sync with the software clock by an hour or more. That also explains, why I've never come across this situation in the shops I've worked in. In spring and fall, the time was always set/changed in the hardware clock, a POR was performed and all LPARs were re-IPLed. That means, that the system's hardware clock and any LPARs' software clocks were always in sync. No matter which clock your program looked at, you'd always get a correct local date and time. (OK, call me old-fashioned. That's the way it worked for the shop and it prevented timestamp problems with some finicky database applications' transaction logfiles. It if works, don't break it. Yes, I know, there's probably other ways to do this without a POR, but that's something to discuss in another thread.) To wrap this up ... what can we recommend that Brian P. and his user do? (1) Change the hardware clock to keep it in sync with the software clock and use PARMLIB TIMEZONE offsets? (2) Change any affected COBOL programs to use a FUNCTION or CALL to COBOL- or LE-date/time routines that retrieve their data from the software clock, local time, instead of the hardware clock? (3) ??? Any other suggestions? Regards, Ulrich Krueger -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Ross Sent: Friday, August 24, 2007 9:29 PM To: [email protected] Subject: Source of COBOL ACCEPT DATE >Can someone tell me, where exactly the DATE is taken from when a >COBOL program executes ACCEPT DATE? >Is it >(a) the running system clock, local time, as of the moment ACCEPT >DATE is executed? >- or - >(b) the date in effect at the moment the program (or step) started? It is (A) for all COBOL compilers. As for the source... In COBOL compilers starting with COBOL for OS/390 & VM V2R2, the ACCEPT DATE uses STCK. In previous compilers, it used SVC 11. This has caused strange results for some users of system SET DATE. Cheers, TomR >> COBOL is the Language of the Future! << ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
