Re: Job dates

[D.BALE@xxxxxxxxxxxxx]

IMO...

All the windowing technique does is give you another 40 years to fix the
2-digit year problem or otherwise make it go away.  You're now down to 38.
When Y2.04K rolls around, they'll be cursing at us retired old fogeys for
*STILL* not fixing it right!  So you throw another window at it?  What a PITA!
 Will the "window" survive the compliance process when you're getting letters
from all your customers in 2038?

If you really want to fix it, go to a four-digit year.  One of the nice things
about this company (Handleman) is that they did the Y2K thing in the early
'90s and converted every single date in the system to an 8-digit yyyymmdd
format.

End of story.

- Dan
Dan Bale says "BAN DALE!"
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------
>
> >> Note that the system does provide support for various windowing
>techniques of 2-digit years --  they just don't apply to how the system
>treats job dates.
>
>Thanks for the clarification Bruce.  It is also worth pointing out that
>this fixed window is the one used by RPG, COBOL, etc. when handling two
>digit dates.  I assume SQL is the same as the underlying support is the
>same.  For this reason I can't see that the window could be changed other
>than by introducing new date formats.  It would be a disaster waiting to
>happen.
>

While the current window is indeed fixed from the point of view of
RPG, SQL, Query, etc. I'm not sure that introducing a new system value
such as (to make one up) QBASEYEAR where a default value of 1940 would
indicate that the system should interpret 2-digit years within the range
of 1940 to 1940+99 would necessarily create a disaster.  The introduction
of such a system value would imply that the various languages, utilities,
and such would need to start making a run-time (as opposed to compile
hard code) check for year range, and most likely necessitate the
recompilation of applications that would utilize the new window
definition, but with sufficient planning one could then change the
theoretical QBASEYEAR to say 1970 without having to introduce new date
formats (and subsequent updates to all the code written to only
recognize the old date formats).  Obviously such a change would have
to be planned also to take into consideration that the dates of 1940 to
1969 (in my example) just disappeared from a 2-digit year point of view
(they became 2040 to 2069...don't you just love windows?)

With such a change, CHGJOB DATE(061550) could now be June 15 2050 (where
today you would have to specify CHGJOB DATE(06152050) which I personally
consider to be a much clearer way to specify it -- using the 4-digit
year -- anyway).

Could a disaster happen?  Absolutely if proper planning is not done.  The
same is also true of changing quite a few other system values.

Bruce
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---