× 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: AS/400 upgrade costs
  • From: "James W. Kilgore" <qappdsn@xxxxxxx>
  • Date: Wed, 26 Nov 1997 08:49:17 +0000
  • Organization: Progressive Data Systems, Inc.

My last post was meant to be a little cheeky, but I would like to take your
numbers to task.

I'm not picking on you, but I think that your estimate is indicitive of how the
media has hyped up the cost of Y2K complience.

Sure it's going to take time and cost some money.  I'm not disputing that.  It's
when it's stated that 4,000 programs and 500 files have to be brought to
complience that the authors credibility goes right down the toilet in my eyes.

Let me explain...there are two types of date fields in our data base.  There are
informational dates and there are dates that trigger an action or control a
sequencing of data.  Informational dates do not HAVE to be altered to meet Y2K
complience.

So let's say I have a file which adds text to a transaction code on
reports/displays, it contains a date last changed.  Guess what....I'm not going
to mess with the file nor any programs which maintain it. Don't have to.  No
programs act upon that information, no file change required, no conversion
program either.

Hire date for an employee? Yep, to do a seniority report.  Birth date? Nope...We
won't be hiring anyone born 2000+ until 2016.  But then again, we don't perform
any action on birth year, we do for month and day (Happy Birthday note on pay
stub) so I'm not sure we'll ever have to deal with it.  And if our insurance
company wanted the age of our employees, a window technique will work just fine.

Invoice due date? You bettcha.  Invoice date? Don't think so.  We age by due
date.  Things stay current until due.  Besides to do a cronological transaction
list, sort would include accounting year.  Sure Jan 2000 report would look a
little scewed, but as long as no action is triggered, who cares.  Changing it
isn't WORTH the cost.

So you can see that the $68,000 you mentioned is not realistic.  Therefore I 
have
to doubt your estimating technique and the third domino to fall would be your
credibilitly of the estimate to develop a new application from scratch.

JM2CW

P.S.  I know you mentioned that you inherited this installation, but
zowie..hadn't anyone every heard of library lists?  Even the S/36 let you throw
your standard apps into #LIBRARY with a user library which only needed to 
contain
customized programs. And if their approach is any indication of the quality of
the application, I think I would give serious consideration to tossing it also.
BTW, I think you can buy a canned Payroll for the AS/400 for less than 24K.

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

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.