× 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: Fri, 28 Nov 1997 03:46:33 +0000
  • Organization: Progressive Data Systems, Inc.



Chris Rehm wrote:

> ** Reply to note from "James W. Kilgore" <qappdsn@ibm.net> Wed, 26 Nov 1997 
>08:49:17 +0000
>
> Hi James. Saw your reply and regretted that I hadn't seen the rest of the
> thread.
>
> My God! $68,000 for fixing 4000 programs? What was he thinking! After all,
> let's suppose there are actually 4000 programs there. Okay, let's say that 5%
> of them actually require recoding (now, I am being a little conservative on
> this as I would suspect that it would probably be higher). Okay, so now
> we have a much easier 200 programs.
>
> So, if a programmer just re-wrote 4 a week, then he would be done in a year.
> Now, I think we probably better use a senior programmer for this, because a
> new guy might require us to hire a tester to make sure these fixes actually
> work.
>
> Hmm, a year's worth of a senior programmer's time counting support and
> benefits makes $68,000 seem a little weak.
>
> But I wonder if our programmer can keep up this pace of 4 rewrites a week for
> the whole year?
>
> Do you suppose the media would blow this same conversion out of proportion by
> thinking that it might take more than an average of 1.25 days per program to
> review, redesign, rewrite, test/debug, implement, and do operational testing?
> Or do you suppose they are blowing it out of proportion by assuming that way
> too many programs will need to be modified?
>
> Maybe they think it will take time to figure out how many programs will need
> to be modified?
>

Chris,

My little ditty was response to two different posts actually.

The first was about a media report of 100,000 lines of code needing change at x 
$/line, yadda,
yadda, yadda which I commented that I don't believe an application contains 
100,000 lines of
DATE related code, therefore the extrapolated cost is false.

The second had to do with a statement of estimated cost to upgrade a Payroll 
application
($68K-4000 pgms-500 files) to Y2K vs rewrite in VB for $24K where the comments 
you saw came
from.

IMHO I concluded that a payroll application which is already Y2K compliant (and 
worth it's
salt) can be purchased for less than $24K.  I believe the original post quoted 
a 3K upgrade to
their AS/400 as a part of the deal, so I guess the real question was could you 
upgrade your
Payroll for under $21K or do a VB rewrite for less.

jets(*fired)  afterburners (*on)

As I said, I'm not picking on the poster of the fix vs replace position, but I 
do question the
validity of the reported effort of Y2K compliance and the stated cost of 
scratch development.
Even within your own posting, without any smileys, I'm having a hard time of 
telling whether
you are between a rock and hard place and venting, or just being cheeky, but in 
either case
the point is, at times a fix or scratch rewrite is out of line when a replace 
is the least
expensive, most timely effort.  (I personally feel that the original poster had 
an agenda that
did not include Y2K Payroll at lowest cost, but that would be a different 
thread)

We've spent a good deal of effort in determining the efforts required to meet 
Y2K within our
own applications and don't see it as such a big deal. Within 800,000+/- lines 
of code, we have
determined that about 6 /COPY members (we're RPG III/400) and 100 programs NEED 
modification.
We are using a window technique, already have 7 digit dates in 80% of the files 
(digit 7 is
century because *DATE PARM type in the command processor did it that way, for 
how many years?)
and will NOT be changing any screen displays or reports (they already show 
MM/DD/YY or
DD/MM/YY).  In the older files where there are 6 digit dates, a CPYF *MAP and 
recompile gets
us half way home.

Maybe it's just a matter of expectations, but we expect 4 programs per day, per 
programmer,
since they just have to test compatibility of standardized modules, not 
redesign nor rewrite
as you state.  Again, we are testing dates, just dates.  I don't see where that 
requires
redesign/rewrite of ANY application.

Example:  A Payroll program (the original case at point) has deductions with an 
effective date
in YYMMDD format being changed to CYYMMDD format. Redesign? Rewrite? I think 
SETLL/READP will
still get the most recent rate without redesigning or rewriting hours * rate, 
minimum
qualification, maximum limits, etc..  Am I missing something here?

BTW, we kinda see senior programers as problem solvers, the remaining minions 
spend the time
to twiddle thumbs waiting for test results.  (If you could only see how far the 
tongue was in
the cheek on that one! Sort of.) Basically, in just about any profession there 
are those that
solve problems and those that implement solutions. The latter are less 
expensive.

afterburners (*off)  jets(*cooled)

If you are between a rock and hard space, there's still a New Year's around the 
corner which
contains the hope of resolution.  If a fix to what you already have is $68K and 
a rewrite can
be done for $24K yet a  replacement can be had for $<10K, well what can I 
say...kick that old
code to the curb....don't waste the time....take your family on vacation 
instead.  BTW a $58K
saving is easy to sell upstairs. They may even give you a bonus for it :-)



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