× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: pdm vs year 2000
  • From: "telsci" <telsci@xxxxxxxxxxxx>
  • Date: Mon, 26 May 1997 08:49:21 -0400

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  
*
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
> > umidr
> > 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * 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   *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.