× 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: Year 2000
  • From: "James W. Kilgore" <qappdsn@xxxxxxx>
  • Date: Fri, 06 Jun 1997 23:29:55 -0700
  • Organization: Progressive Data Systems, Inc.

DAsmussen@aol.com wrote:
> 
> Doing a Y2K conversion AND converting to ILE is a bit ambitious, don't you
> think?  It was my understanding that there were some performance problems
> with the date data types at one point, is this still the case?

I agree.  One major overhaul at a time. please.......

The performance problems may be addressed in the next version, who
knows.
Think about it though, to support date date types, IBM was faced with
either handling the conversion within each program product or at the
data base level.  (the products always gets the result)

The only way we can think of to get around it is to create new logicals
which do not include the date fields if they are not being used in a
particular program.  Sort of like pulling the input specs for unused
fields on a S/3 when you were stuck with a machine which only had 16k to
work with and the program went into overlays.

Because of backlog and time contraints, we bit the bullet and stuck with
7,0 packed dates for everthing except birthdates.  We are at 3.1 and the
*date command processor variable returns a 7,0 cyymmdd variable so we
decided to stick with that.  This got us y2k "compliant".  We're not
real happy with the decision. Technically speaking, date data types are
not that hard to work around in RPG/400, but all the files were already
7,0 packed date formated.

We have reworked our date routines so that when a 7,0 cyymmd date comes
in it is Z-ADDed to a 8,0 field then we add/subtract 1900 from the year
giving us yyyymmdd.  Since we use standard /COPY routines for all date
manipulation, we used the QUSRTOOL SCNALLSRC (Scan all source) to get a
hit list of the programs using the routines.

For those shops not getting the benefits of ILE reusable code, /COPY is
the next best thing going.
If you are a RPG/400 shop and not using /COPY, you might want to give it
some thought.  These routines could make the starting point for service
programs in the future.

Just my .02
-- 
===================================================
James W. Kilgore   | Progressive Data Systems, Inc.
President          | 311 31st Ave SE
(206) 848-2567     | Puyallup, Washington 98374 USA
qappdsn@ibm.net    | http://www.ultimate.org/PDS
===================================================
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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:
Replies:

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.