Two digit date window

>                        ... until one day IBM decides to change the date
>window.  Instead of 1940 - 2039 the window is moved ahead 20 years ...
>

But the solution in that case is to not change the system value from
1940.  The users, in 2040, would need to start using 4-digit years for
functions like CHGJOB DATE(), but the *MDY views would still work for
the historical data (of course trying to enter new data using a 2-digit
year will be a bit more interesting...).

For compatibility reasons IBM could, I theorize, default the system
value to 1940 at least initially.  In say 10 years or so (maybe when
30 year mortgages start to approach 2040?) IBM may change that default
to 1970 (or whatever) for new/scratch installs; but upgrades (as is
done today for many system values) would just stay at the previous
value (1940) until such time as the system administrator set a new
value (and presumeably verified that they no longer needed a window
over the 2-digit year values less than say 1970).  At this point planning
would certainly come into play.

Bruce

> >> 1939 or 1927  or 28 and below go Boom too under  the 1940- 2039 theory
>
> >> All windows are only as stable  as  their internal pivot year relates
>to the dates received for processing. YES/NO?
>
>Yes - but ..........  Maybe I'm not saying things very clearly.  Let me try
>it this way and then I'll get on with real work <g>
>
>"Real" dates on the database don't really have a pivot year - they are
>stored as a day count - not as year digits subject to pivot interpretation.
>The value stored on DASD will be the same for Jan 1st 1940 regardless of
>whether DATFMT is *MDY or *ISO.
>
>Let's say I have designed a database.  It includes a "real" type L date
>field, because I was told it would guarantee that only valid dates would
>ever be stored.  I chose DATFMT(*MDY) as the format for that date because
>that is what my users like and because the dates will _never_ go outside
>the range 1950 - 2020.
>
>This works well for a while until one day IBM decides to change the date
>window.  Instead of 1940 - 2039 the window is moved ahead 20 years to (say)
>1960 - 2059.   The first time that my application reads a record with a
>date in the 1940 - 1959 range it will blow up.  Not on every record - just
>anywhere the stored binary day count equates to a date outside the new
>range.  Not only that it will do so in a way that gives me no way of
>effectively handling the error, since it will occur while the buffer is
>being unpacked.
>
>In order to resolve this I would have to do a CHGPF with new DDS that
>changes the *MDY format to (say) *USA (I am assuming that this works -
>can't think why it shouldn't - otherwise I have to copy the file).  But
>then I have to modify all my programs to handle the 4 digit year.  That is
>not acceptable to me.  I used "real" dates for reasons of integrity - a
>change in the window broke that rule.  I now have dates stored that are
>outside the window, and I have no choice but to change my programs to
>accept 4 digit years.
>


+---
| 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
+---