[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | VAX/DEC COBOL |
Notice: | Kit,doc,performance talk info-->DIR/KEY=KIT or DOC or PERF_TALK |
Moderator: | PACKED::BRAFFITT |
|
Created: | Mon Feb 03 1986 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 3250 |
Total number of notes: | 13077 |
3240.0. "Cobol ACCEPT DATE FROM SYSTEM statement" by SIOG::HANLEY () Fri May 09 1997 10:51
Hi,
I have a customer query who would like to know if Digital have
any plans for the ACCEPT DATE FROM SYSTEM statement. We need to
know WHETHER it will be changed in a future release of Cobol to
return a 9(8) date. If it is to change, we need to know WHEN.
I include the customer mail below...
Thanks,
Patrick Hanley
---------------------------------------------------------------
Subject: Cobol ACCEPT DATE FROM SYSTEM statement
We have started our Overpayments Y2K project, and have
already amended some programs. We need to know what is likely
to happen regarding the ACCEPT DATE FROM SYSTEM statement in
Cobol. This statement returns a 6-digit system date, which is not
Y2K compliant.
We have for the time-being adopted the standing instruction
to programmers telling them that where they come across the above
statement, they should replace it with a call to the system
service Sys$GetTim, which I am told, is Y2K compliant. We feel
this is safer than leaving ACCEPT statements in programs, even
though it will take a little more time.
Notwithstanding this, we would like to know if Digital have
any plans for the ACCEPT DATE FROM SYSTEM statement. We need to
know WHETHER it will be changed in a future release of Cobol to
return a 9(8) date. If it is to change, we need to know WHEN. I
would appreciate if you could get an answer on this from Digital
as soon as possible. I'm at (704)3687, if you need me,
Thanks,
T.R | Title | User | Personal Name | Date | Lines |
---|
3240.1 | | WIBBIN::NOYCE | Pulling weeds, pickin' stones | Fri May 09 1997 11:44 | 1 |
| See note 3219.1 -- use FUNCTION CURRENT-DATE.
|