Re: pdm vs year 2000

My friend told me that his boss (director of IT) thought a valid
solution
for the year 2000 problem was going back to paper.  

telsci wrote:
> 
> The thing that's WRONG with this implementation is that we have spent time
> and money working on a 50 year postponement of the problem.  Are we all
> assuming the AS/400 will be obsolete by then?  Why not spend the above time
> and money on a 3 or 4 digit year and postpone the problem for 900 or 8000
> years?  Ditto for the COBOL ACCEPT DATE.
> 
> ----------
> > From: Neil Palmer <neil@systemetrix.ca>
> > To: MIDRANGE-L@midrange.com
> > Subject: Re: pdm vs year 2000
> > Date: Sunday, May 25, 1997 6:47 PM
> >
> > It is so, and I see nothing wrong with this implementation.
> > As I said in my reply to Glenn, THINK what the purpose of the date subset
> in
> > PDM is for in the first place.  The century byte is used to determine
> which
> > of two 100 year date ranges PDM will search for.  Actually they could
> have
> > just always taken 1954 to 2053 anyway, as nobody has source members
> created
> > or modified before 1954 anyway (I would say that no one could have any
> > member dates earlier than around 1978 - if they still have a member
> around
> > from an early release S/38).
> >
> >
> > On Sun, 25 May 1997 ConnectY2K@aol.com wrote:
> >
> > >
> > > Neil  this can't be so.
> > > As your note reads dates from 1928 to 2027are ambigous .  The Century
> byte
> > > does  nothing to help?  One would hope to see PDM consistent with the
> rules
> > > for QCENTURY when this is being used as the determinate!
> > >
> > > The AS/400 ''should'' have a single rule across all the system releases
> and
> > > actions. No dual standards. After all multiple standards is how we got
> into
> > > this mess.
> > >
> > > In a message dated 97-05-25 10:10:27 EDT, you write:
> > >
> > > << Subj:    Re: pdm vs year 200
> > >  Date:      97-05-25 10:10:27 EDT
> > >  From:      neil@systemetrix.ca (Neil Palmer)
> > >
> > >
> > >  Well, before the PTF's the default PDM date range was 01/01/00 to
> 12/31/99
> > >  for V3R2, and 01/01/40 to 12/31/39 for V3R7.
> > >  The PTF cover letters (V3R2 SF40680/SF40685/SF40648, V3R7
> > >  SF38642/SF38508/ SF38513) state that the fix is to base the date range
> on
> > > the
> > >  new QCENTURY system value.  If QCENTURY=0 dates are 1928/01/01 to
> > > 2027/12/31,
> > >  and if QCENTURY=1 the PDM date range is 1954/01/01 to 2053/12/31.
> > >  Obviously the 6 digit date entry in PDM can only span 100 years, so
> between
> > >  the two possible values for QCENTURY they cover the full date range
> that is
> > >  presently supported on AS/400 (1928/01/01 to 2053/12/31).  Until
> further
> > >  changes are made to OS/400 it can't handle dates from 2054 on - but I
> don't
> > >  believe most of us will care too much about that - maybe our kids will
> have
> > >  some concerns !   ;-)
> > >  (Or Grandchildren).
> > >
> > >  On Fri, 23 May 1997, Neil Palmer wrote:
> > >
> > >  > No, but I'll try to find out.  The date range in PDM for V3R2 is now
> 
> > >  > inconsistent with V3R7.
> > > > On 23 May 1997, Kahn, David wrote:
> > >  > > On May 22 1997 Neil Palmer wrote:
> > >  > >
> > >  > > >All 3 PTF's can be applied immediately.
> > >  > > >After these are applied, the date range on PDM subset will be
> 01/01/28
> > >  > > >to 12/31/27.
> > >  > >
> > >  > > Neil,
> > >  > >
> > >  > > This is a fix? An idea why they've broken their convention of
> using 1940
> > > to
> > >  > > 2039?
> > >  > >
> > >  > > Dave Kahn - Tengizchevroil, Kazakstan
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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 MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *