Re: AS/400 upgrade costs -- MIDRANGE-L



Chris Rehm wrote:

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

Don't recall, read it on this list recently.


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

Thanks OK...no offense taken.

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

To fix 4,000 programs you're right.  I just find it hard to swallow that EVERY 
program must be
modified manually.

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

Yep, by a good deal of effort I'm talking about consumming a Sr Pgmrs life for 
about two
weeks. (Well....it seemed like a lot in dog years...)  But that wasn't just for 
Payroll, it
was for all of the applications.  I'll get to the ripple effects later in this 
post.

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

When we first started to design this version of our applications we packed the 
dates just to
save disk space and stored them in CYYMMDD format.  Made it easy to date 
sequence files, range
select on query, etc. and gave us a little peace of mind knowing that we had a 
provision for
Y2K and back burnered any thought of actually dealing with it.  And you are 
right in that all
programs that print or display a date already do the format change via /COPY 
members. We use
them extensively.  Right down to /COPY for doing a CHAIN, CHAIN w/ no lock, 
SETLL, READ,
initialize a record, etc in the event we wanted to switch to SQL or whatever. 
Change the /COPY
and do a wholesale recompile - done.  The original plan was SAA complience and 
code
portability but we dropped that idea.  But we kept the replaceable /COPY 
concept to make a
platform change easier. And we could make client specific modifications to a 
member without
necessarily touching the main program itself.

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

Gottcha....personally I feel sorry for anyone who has stored dates in MMDDYY 
format, in the
above case year will have to be asked for, screens changed, etc.

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

Right on.  I think I've seen figures around the 70% of efforts are in 
maintenance.  We wanted
to keep it to a minimum

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

Oh didn't I tell you that the reformat /COPY takes CYYMMDD as input and can 
output YYYYMMDD?
We had to write these because of the lack of a CVTDAT at the time.  It used to 
just do MMDDYY
or DDMMYY until the demand to download files to PC apps which use 8 digit dates 
came around.

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

Good God! A chill ran down my spine when I read that =:-o  I have to admit, we 
used to do that
on the S/36.  Being cute and all that.

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

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

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>

> But I don't think so.
>
> I also think that any estimate that has $0 in it for implementation is
> suspect.

I would suspect it also, it's built into the 2Hrs per program estimate.

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

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


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

With the exception of 7 digit vs 8 digit dates, we're pretty much in the same 
boat except for
some really old custom stuff at the client sites. I feel that we're in pretty 
good shape also,
probably not true for everyone though.

I'm sure too that some user will come ascreeming when something croaks, but as 
long as pay
checks get out on time and the taxes are deposited we've covered the primary 
objective and can
deal with the unexpected.

It's the media sensationalizing that gets me grumpy I guess.  30 year bank 
loans had to solve
the problem in 1970, my drivers license has an expiration date of 082802..guess 
they solved
the issue last year.

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

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