× 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: YEAR 2000
  • From: Susan Durrie <sed1@xxxxxxxxxxxxx>
  • Date: Sun, 22 Jun 1997 10:21:16 -0500

Thanks to all who responded to my first Year 2000 query and sorry to
beat this dead horse again.  But... I still need help.  
  1)  We are commited to Y2K by the end of this year and we haven't
started.
  2)  We have about 900 RPG programs that will need conversion.  Our
file dates are all (or 95-99%) referenced to a date field in a field
reference file.  Most (80%) of our date manipulation is currently
covered by standard copy sources.
  3)  I have calculated a raw estimate of 6-7 people working 40 hour
weeks through the end of the year to cover this project.  Is this
reasonable or outrageous?  This would be without a conversion tool.
And would include testing and documentation.  
  4)  We would like to go to native dates.  I am pushing this heavily,
and in fact, the response from the mailing list leans this way.  Our
code is not RPGIV yet, but will be eventually.  We do know how to deal
with native dates in RPGIII/RPG400 code. Our date routines for calcu-
lating date differences will probably involve a call to an RPGIV
program.  
  5)  Advantages of native dates are storage space, built-in date
manipulation in RPGIV (sans screens and printer files), compatability
with SQL.  What else?  Do PC applications retrieving data from the
AS/400 recognize a native date as a date?  I've had some very confusing
feedback in this area.  
  6)  Disadvantages of native dates are performance issues, and 
problems manipulating native dates with non-RPGIV code (although I
wouldn't consider this a major issue).  The worst issue is that we
would like to use a conversion tool, and I haven't seem to come across
a conversion (not analysis) tool that will handle native dates.  Are
there any out there?  (That work right now, we can't wait for any
next releases.)
  7)  Our representation on screens and reports will continue to be
6 digit.  We will probably be using a user-defined sliding window
for century determination.  Had thought to include century or full
date as hidden screen fields, but not sure if time will allow.
  8)  We do not retain century critical dates, such as birthdates.

I apologize once again for dragging this up again,
but I have a minimal amount of time for research at this stage.

TIA,

Susan Durrie
sed1@earthlink.net
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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 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.