ACCEPT x FROM DATE issue 
Author Message
 ACCEPT x FROM DATE issue

Anyone have a good workaround for the fact that the ACCEPT identifier FROM
DATE command gives only two digits for the year? I'm coding some routines to
timestamp output files and would feel sort of stupid if they "expire" in three
years.

What are Y2K programmers doing to get around this?

 - Paul



Sun, 04 Jul 1999 03:00:00 GMT  
 ACCEPT x FROM DATE issue

Quote:

>Anyone have a good workaround for the fact that the ACCEPT identifier FROM
>DATE command gives only two digits for the year? I'm coding some routines to
>timestamp output files and would feel sort of stupid if they "expire" in three
>years.

Check to see if your COBOL utilizes the intrinsic function CURRENT-DATE.

VAX COBOL has since version 5.0.  It's format is MOVE FUNCTION CURRENT-DATE
TO <variable>.  It returns a 21 byte alphanumeric field with the first 4
bytes being the four numeric digits of the year, then 2 for month, then 2
for day then the time in the form hh:mm:ss.nn in the next 8.  The last five
digits are returned as 00000 and are reserved for future use.

If not see what type of system library calls you could make to retrieve the
century digits.

Quote:
>What are Y2K programmers doing to get around this?

I'm using the intrinsic function.

Good luck as I get back to the Y2K business at hand.....

Sallie

================================================================================
  Think of me what you will          | Sallie Kudra, Applications Analyst II
  I've got a little space to fill... | ISD, Clemson University, Clemson, SC

================================================================================



Sun, 04 Jul 1999 03:00:00 GMT  
 ACCEPT x FROM DATE issue

Quote:

> Anyone have a good workaround for the fact that the ACCEPT identifier FROM
> DATE command gives only two digits for the year? I'm coding some routines to
> timestamp output files and would feel sort of stupid if they "expire" in three
> years.

> What are Y2K programmers doing to get around this?

>  - Paul

There are several ways around this:

1. As Sallie Kudra mentioned, if your compiler supports intrinsic functions
   then use the appropriate one.  You might want to investigate upgrading
   your COBOL compiler if necessary.  If you can't do that in a reasonable
   time frame, see below.  Also, if you are using the IBM COBOL II compiler
   there is an APAR to give you an assembler subprogram which returns the
   full date.

2. If #1 above is not possible, you could write a C or assembler subprogram
   to obtain the date with 4-digit year from the operating system.  Does
   your operating system support 4-digit years?  Some don't.

3. Ignore the whole thing, store the date with 2-digit year, and let the
   somebody else figure it out.  This could be a cost-effective solution if  
   the date is only printed and never compared to another date, used to    
   compute day-of-week, et cetera.  

4. Add a little "date-windowing" logic to your program to build the date
   with the century.  If you're always writing current-date, just
   add something like this to the program:
   IF CURRENT-YY > 95
       MOVE '19' TO CURRENT-CENTURY
   ELSE
       MOVE '20' TO CURRENT-CENTURY
   END-IF
   This buys you a lot of time, and it's easy to do.  It will probably more
   than cover the useful life of your program.  Of course, it's no
   fun to replicate it in 1000 programs, and could lead to a maintenance
   nightmare when you get your #1 solution.

5. If your systems will be doing a lot of date windowing, like #4 above,
   you might consider writing a standard subprogram to convert YY to CCYY
   using a standard cutoff year.  It could also be helpful interpreting
   dates in existing files.  Of course you have to know how wide your date  
   horizon is.

Good Luck!

Arnold Trembley
Software Engineer I (and working on a Year 2000 project)
MasterCard International
St. Louis, Missouri



Sun, 04 Jul 1999 03:00:00 GMT  
 ACCEPT x FROM DATE issue


Quote:
>Anyone have a good workaround for the fact that the ACCEPT identifier FROM
>DATE command gives only two digits for the year? I'm coding some routines to
>timestamp output files and would feel sort of stupid if they "expire" in three
>years.

>What are Y2K programmers doing to get around this?

It really depends on how long you plan to use the file.  Probably the
easiest way is to pick a number (say 80) and compare the returned 2
digit year against it, assuming that anything over 80 is in the 1900's
and place the '19' in front of it  while anything under 80 is in the
2000's, placing the '20' in front of it.

Dave

The opinions expressed in this post are purely my own.



Tue, 06 Jul 1999 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. ACCEPT x FROM DATE issue

2. ACCEPT x FROM DATE issue

3. Problem "Accept from date"

4. ACCEPT FROM DATE & COBOL II

5. Y2K Bug found in ACCEPT FROM DATE

6. ACCEPT FROM DATE

7. VS COBOL II - Accepting 9(08) date from system

8. accept from date

9. accept from date

10. need help with date issue

11. Date/Time issues

12. Date/Time issues

 

 
Powered by phpBB® Forum Software