× 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: IBM Y2K Readiness
  • From: Bob Crothers <bob@xxxxxxxxxxxxxx>
  • Date: Thu, 30 Jul 1998 10:48:14 -0000
  • Organization: Cornerstone Communications, LLC

Just FYI, Fax Server/401 uses an 8 digit date in our Y2K version 
(v5.0).  The only place we do any windowing is on some of the screens 
where we left the date with a 2 digit year.  But the files themselves 
all have a 4 digit year.

Regards,
Bob Crothers
Cornerstone Communications, LLC
www.faxserver401.com

PS: I am one of the developers of Fax Server/401.

-----Original Message-----
From:   Leland, David [SMTP:dleland@Harter.com]
Sent:   Thursday, July 30, 1998 9:23 AM
To:     'MIDRANGE-L@midrange.com'
Subject:        IBM Y2K Readiness

Just received an interesting response from IBM regarding their Year 
2000
readiness.  We are using their Fax/400 product and they claim it to be
Y2K ready.  I questioned this in an e-mail to them since I had noticed 
a
log file (QAFFTLOG, which is an important file to us) had a 6 digit 
date
in it (in the format YYMMDD) and did not have a century code to go 
along
with it.  Following is the response I received from IBM:

> Answer 2) The OS/400 and IBM Licensed Programs will, in most cases
> continue to
> use a 6 digit date field for "release to release" compatibility. The
> system has
> delivered additional function for those cases where customers need 
to
> see dates
> in a different format. Some of those functions are *DATE for RPG
> returns 8
> digit dates, CVTDAT supports 8 digit dates, ILE COBOL can extract 8
> digit dates
> along with a variety of other "tools". You can find out about these
> functions
> in a document titled "AS/400 Roadmap to the Year 2000" we have on 
our
> web page
> at:
>
>      http://www.softmall.ibm.com/as400/year2000/rldss/
>
> The system previously had used a 6 digit date field with a 2 digit
> year. In
> that case, the year field represented 00 to 99. With the Year 2000
> ready
> versions of AS/400 products, the year field has been shifted through
> the use of
> a "window" so that the years 40 to 99 are associated with a "19" and
> 00 to 39
> are associated with a "20". In this manner, the system continues to
> use a 2
> digit year but can determine through the use of that window, the
> non-ambiguous
> year... You can find out more about the "window" in the AS/400 
Roadmap
> document.
>
It sounds like they're telling me that they don't intend to change the
date from a 6 digit date and it's up to me to use the date "window"
technique to determine the correct year.  Does anyone else besides me
feel that that's not right?  They could essentially tell me that any 
IBM
system database file is Y2K ready as long as it has a 2 digit year.

What do you think?
Dave
+---
| 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
+---

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.