Re: Specifying dates in DDS

John Carr wrote:

>   We took the approach of designing the data base for the future.

>  Programs can be insulated / softcoded / enhanced / evolved.

>  Data Bases will live with you for ever.

John,

You have a very valid point.

Using CCYYMMDD did require some code to remap to the possible display/print
formats.  Even to have displays stateside show MMDDYY required _some_ code to
manipulate the date.  So all we are talking about is some _different_ code, yet
some code non the less.

Until the beginning of 1998 we still supported V2R3 sites so we stored dates
CYYMMDD in packed format.  Gee, only 4 bytes, no overhead, same format returned
by the command processor for a *DATE parameter value.  It worked.

Now we have estimated the remainer of this year to take our applications Y2K
compliant (we started jan 1997) and decided to use true date data types for all
date sensative functions even though they are not ready for prime time by lack 
of
printer and display support.

 A simple EDTCDE(*USA)  or EDTCDE(Y) FORMAT(*JOB or *USRPRF or *JOBD or *ISO,
etc.)  keyword would have handled things nicely.  Don't know how it will
eventually be implemented.  Really don't care at this point in time.

The majority of users are CISC V3R2 and we still will need to have _some_ code 
to
format the dates.  The V4 enhancement pack will overlay the modules to ease
upgrade.

But the point still remains, CCYYMMDD or L date required _some_ code.  Although 
I
must add, the prior data bases (nor the newer ones) live forever. ;-)



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---