Re: AS/400 upgrade costs

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

[snip]

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

I see. Do you know if this was from the Gartner Group's $1.50 a line of code
thing I saw recently? That would make it $150,000 to fix that 100,000 lines
of code. 
   
> 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,

Okay, and I must confess I was picking on you.

> 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

Sorry, just being cheeky. I forgot to put smileys in. I think $68,000 would
be a bargain to fix 4,000 programs.

> 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)

Okay, I'm sorry that I missed the post, so I didn't catch the drift.
   
> 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.

And of course the efforts you have spent so far are part of your cost
calculations, right?

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

I sure do think the use of century is acceptable. I also think it's handy
that it packs in the same number of bytes as without the century.

So, if you are not changing the screens and reports, you will be moving the
7 digit date from the file to a 6 digit field for display? Is that common in
your programs now? Now, if the display is MM/DD/YY and you have changed the
date in the file from YYMMDD or MMDDYY to CYYMMDD, won't your calculation to
screen (or print) change? Is this the /COPY members discussed? I know that
converting to screen or print is pretty common and using the /COPY member
routines for this might be an easy way of unifying it. I was just curious.
   
> 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.

Well, if the application is date controlled, it sure might. While the need
to redesign is unlikely, it is possible. Coding modifications might also be
necessary. If you had a poorly written area it would be more likely. Let's
suppose that a program processes open invoices for a month's period. Since
invoices are "never" open for more than a year and the date in the file is
in MM/DD/YY format, it was pretty easy to toss a logical on the file and
just SETLL on that date with the month keyed by the operator. That will
change with the CYYMMDD. 

The better the original programmer(s) followed good programming methods, the
less likely you are to have work on your hands now.

> 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?

You are if you used to movel that field into a YY field, then do a move to a
MMDD field, then move them to a MMDDYY field for print. That will piss
someone off if the bank won't take the check now because the date's bad. Or
your payroll batch is rejected by the EDI system because your new date
format wasn't approved. 

And what if the date you are looking at is MMDDYY? Then you aready have code
for converting it, right? If that code is a routine within a /COPY and the
programmer used that instead of MULT 10000.01, you're okay. 

> 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)

Well, let's see where we went on that ride, okay?

You said you have about 100 programs to change, right? I don't know how long
they are, but let's say 1000 lines each, okay? So Gartner says about
$150,000 to fix your problem and this other thing you are quoting says about
$68,000. You haven't given a figure but let's look at what you've said. The
100 programs will be rewritten in 5 weeks, and a quick CPYF *MAP will have
you up and running, right?

I'm gonna estimate what you say at about $10,000. That takes into account
the support costs for the senior programmer, his salary and benefits, etc.
plus a few bucks for the system operator running the file copy. Oh, shoot, I
forgot to toss on any money for the time you spent finding out which
programs needed coding. 

I think your estimate is more like what MIS guys are tossing to their bosses
all over the place than what Gartner is tossing. 

Maybe you are right. Maybe you won't need to worry about any archived data
being restored and you won't discover that there is an undocumented process
or that there are PC clients accessing the data files you are modifying and
your changes have sent ripples (that cost the company money) through your
organization. Maybe your programmers will "test" 4 programs a day and they
will all implement in live completely smooth and nobody will notice. Then
they will be back on to other project right away and there won't be any
additional costs for missed deadlines.

But I don't think so.

I also think that any estimate that has $0 in it for implementation is
suspect.

> 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 :-)

But they might bite my head of for being so short sighted, don't you think?
I mean, since I only took the sticker price into account and not the
implementation. After all, I will now need to retrain all of my employees
who use this package and come up with some way of converting my history data
into the new format. Then the implementation process can start. Obviously, a
new system will mean that a lot of procedures are going to change. Hmm,
better allocate a little time to have a look at this solution and make sure
that this new whiz bang (bargain basement) package has all the features that
we require. I'd hate to get almost done with the implementation process and
find out that this new package won't let those guys in security work under
two different job classifications!

One of those execs might even ask me how we got to have 4000 programs for
this application if none of it is custom. 

In my case, it really doesn't matter. The company I work for sells a
software package for running a wholesale distribution company. Our company
has always used 8 digit dates YYYYMMDD. They are converted for screen and
print via a standard interface used in all of our programs. The application
has over 10,000 objects, but none need to be rewritten for the Y2K thing.
Sure, we'll probably discover something as time goes on.


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