|
First, the ASC tool is very good so it'll work well for you. Second, there are a number of issues with using the native date fields verses 8-digit numeric fields. If you use RPGIV going to native date fields is a good thing. If you only use RPGIII or mix RPGIV with RPGIII, then going to native date fields is not a good thing. I believe as long as you put your date information into the database fields in YYYYMMDD you can use numeric fields instead of date fields. RPGIII works with these (using your hand-coded routines). And the best thing, RPG IV will read them as well and it is as simple as moving the numeric field to a local RPG IV date variable to do date arithmetic. I believe the ASC tool, as well as IBM's ByPass 2000 tool generate the code that is necessary to handle 8-digit numeric fields as date values. If the files are keyed by this date value, then it is even more important to use the YYYYMMDD format. If the field were a native date field, then the date format would not be important, as OS/400 sorts dates in date sequence regardless of the format. Bob Cozzi -----Original Message----- From: Susan Durrie [SMTP:sed1@earthlink.net] Sent: Thursday, June 05, 1997 10:23 AM To: MIDRANGE-L@midrange.com Subject: Year 2000 We are gearing up to do our Year 2000 conversion. What we have decided so far is that: 1) We will be expanding our files to include the century in all date fields; and 2) On all screens and reports, we will leave the date as a 6 digit representation (unless an exception is absolutely necessary). We are considering purchasing a tool by Advanced Systems Concepts called Century Update, which provides analysis and conversion functionality. Our greatest debate is whether or not to use native dates or to go to an 8 digit numeric YYYYMMDD for our file date fields. Any suggestions, advice, horror stories, etc. would be appreciated. Please email me directly if you do not want to publish a reply to the mailing list. 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 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.