Re: AS/400 upgrade costs

** Reply to note from "James W. Kilgore" <qappdsn@ibm.net> Fri, 28 Nov 1997 
14:41:43 +0000

[snip]

> > I think your estimate is more like what MIS guys are tossing to their bosses
> > all over the place than what Gartner is tossing.
>   
> I think so too. That's why I felt that $68k was a bit overstated to
> address the real problem. Now if the code is REALLY bad with MMDDYY stored
> dates and such, it's not going to be quite a slam dunk. But then again,
> the original poster stated that no logic changes were required, simple
> translate RPG to VB so that Payroll MUST be pretty sound to begin with
> (yea, I'm being cheeky now)

;-)

I don't think that $68,000 is necessarily an overstatement for fixing 200
programs. If you take your case, then even if everything goes as you have
planned you are STILL fixing the problem. In honesty, you need to start
counting the expense to fix your code from back when you started putting in
the /COPY member and recoding to use them instead of having date routines
and handling written into each program. Of course, also the original field
changes to include century, etc.
   
> In the instance of Payroll, because of the potential of audit, we keep
> data for 7 years on-line and print out expired data. For other apps,
> archival restore is an issue. As far as the PC apps go I'll get a little
> cheeky again for a moment and recall a thread where I stated that it was
> IS responsabilty to manage what data the users are allowed to get at and
> there was a whole bunch of screeming about it being THEIR data. Never
> disagreed with that concept, just a database open door policy. Now here
> comes the cheeky part...since it's THEIR data and THEIR little queries and
> THEIR little downloads and THEIR little imports it's THEIR problem! Not
> really but I just loved saying it. ;-)
>   
> We pretty much take a stewardship role with their data and would prep the
> downloads. We've got a pretty good head start on that one. For those
> department managers who do have access to raw data, I can't speak for
> their estimated costs. But you are right, it does have to be taken into
> account. (It wasn't in the original posters cost estimates) Since it would
> be required in any of the three scenerios, fix, rewrite, replace. That
> cost would roughly impact all three choices about equally. Training may
> have a similarly equal impact, as could any conversion programs. Just a
> hip shot on that one.<snip>

Well, I think that costs would be much lower for handling a conversion to
seven digit dates than for replace, as the end users who download that data
have only to learn to deal with the different format, not learn new files,
records, etc. 

> All valid points. Come to think of it, the original post hadn't mentioned
> any of these issues in the $68k vs $24k choice. Just application cost so
> I'll have to suppose that those costs are in addition to. Therefore
> savings stays the same. But now we're looking at going all the way to $21k
> plus that $3k hardware upgrade to break about even on a make vs buy
> decision. Darn, if our Payroll wasn't the product we sell I'ld go get me a
> new one! ;-)

:-)

I think I didn't understand about the $68k estimate. I thought it was an
estimate based on the $ per line of code in the press. If it was, then I
think it does have in it costs for implementation and customization. The
$24k cost sounds like a "sticker price" cost.

My point was (is) that really $1.50 a line of code might not be out of line.
When I first read it, I thought it was crazy. But when I look at the
realities of fixing code and implementing soltutions, it doesn't seem so far
off. 

If you take into account the costs you have already incurred to make your
code Y2K compliant, then you might feel the same. Basically, what you should
look at is that your company falls into the "95% complete" category for
doing the Y2K conversion. 

I think the guys who have the most expense coming up, are those who cut the
most corners in the past. I know of a shop where a lot of code was written
using six digit dates and a lot of 10000.01 conversion going on (it was 36
code). But the shop never paid a good salary to programmers so they had
terrible turn over and always had a majority of trainee/junior programmers
in shop. 

In fact I did a project for them a year or two back where I had to fix a
whole bunch of reports that were written without even taking into account
the year! Reports were blowing up because they had upgraded their disk space
and could finally keep more detail online than 6 months worth. As they got
into the new year they doubled up data on reports. 

I don't know what their Y2K effort looks like right now, but I would be very
concerned if I were them. 

The sticker price is the starting point. After that, there are a lot of
other costs to be considered. 

Our customers paid a lot of money for our software. It included a big
investment in Y2K compliance, because there is some overhead in keeping 8
digit dates but displaying only the 6 digit ones. Your customers have the
same advantage (but I don't know what your software costs). As a result they
can concentrate on running their companies and not sweat the problems that
their competitors must. 

So what the original poster might take into account is that the reason they
are stuck comparing $68k vs. a VB rewrite is because they were short sighted
in the first place and if they don't want to be caught by the same errors in
the future they should look at ALL the costs. There is probably a lot of
customization built into the code that now needs to be Y2k compliant. If
they buy the Y2K compliant code, how much will it cost to add the
customization? Of course, we have already discussed the implementation and
retraining costs. 

One place that you and I seem to agree is that a lot of work is probably
already done. Many major companies have already spent time over the last
decades on Y2K compliance. 

Many short sighted companies are in deep water.

> Anyway, I think I hear a turkey sandwich calling me..gotta run.

Mmmm. My favorite part of turkey is the sandwiches. I always make a turkey
way too big and have my favorite sandwiches for days. I hope you had a very
happy Thanksgiving!

 

Chris Rehm
Mr.AS400@ibm.net

How often can you afford to be unexpectedly out of business?
Get an AS/400.
+---
| 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
+---