Re: OS/400 Upgrade Problems?

From Al Macintyre

Every IBM box I have worked on has had software written by me on it.
I have NEVER had to tweak it just because we moved to a new OS or box, since 
we left the punched card world.  In the conversion from punched cards, I had 
to tweak some code because the data would be DISK as opposed to punched 
cards, or write some screen interfaces where we never had on-line before, but 
that kind of conversion was exception to rule.  Usually when we switch to a 
new box, part of the planning is upward support for all stuff we had on the 
old box.

I have worked in this industry since the mid 1960's, for various companies 
that were customers of IBM computers up to the AS/400, in which we 
periodically upgraded our Operating System.  Standard Operating Procedure for 
me when we are planning such an upgrade is to re-inventory all purchased 
software packages that run on our OS & contact the suppliers to tell them 
what we plan to do & ask if there will be any problems. Ditto action if we 
are upgrading the AS/400 to a new box.

There might be a problem with license is to CPU, or how # users license 
managed, or since OS/400 changed in some area they use, they need to send us 
media to do an upgrade of their software after OS/400 upgrade but before we 
use their software again, so all will be well.  In the CISC to RISC we had to 
get replacement copies of source that had observables built in ... basically 
the vendor recompiling from their CASE but throwing a flag a different way.  
When our annual maintenance contract is paid up, this service does not cost 
us a dime.  They treat it as part of the normal cost of doing business.

Sometimes we have let our maintenance expire because we not planning to move 
to the latest version of their software, we happy with the old & in those 
cases we have had to re-up the contract to get their support to move it to 
new box or new OS.

There have been cases, particularly in the area of PC emulation, where we are 
using software that was supplied by some vendor that was swallowed up by some 
other vendor & the new vendor's support for the old stuff is lip service only.

The arrangements for this can take a week to 10 days to identify to the 
vendor what our situation is & for them to check the financial details (are 
we paid up on maintenance) & the technical details (what do they need to send 
us).  In a few cases, the last one being SSA (BPCS), their notification 
system was buggy.  They had an invoice to us for some trivial thing AND THEY 
NEGLECTED TO SEND IT TO US, so I call for some upgraded license key & they 
say they will get it to me but it will take a few days ... they check 
finances & see we have some invoice not paid & they stop there AND THEY 
NEGLECT TO TELL US THERE IS A FINANCIAL PROBLEM ... a few days later I check 
back to ask when I will be getting my license key & person on phone not know 
status & will check into it & history repeats ... THEY ARE ASSUMING WE KNOW 
ABOUT THIS INVOICE.

It took dozens of phone calls going up the hierarchy of SSA management until 
they volunteered that license key issuance was on hold waiting on payment of 
this invoice we had never seen, AND THEIR OWN RECORDS CONFIRMED THEY HAD 
NEVER SENT IT TO US, so we got a fax & paid from that, because somehow their 
system was incapable of reprinting invoice & mailing it to us.  From that I 
concluded that SSA was not using BPCS to run their own business.

Sometimes some co-worker has had the assignment of taking care of this stuff 
& does not get it as to why it needs to be done, and why it needs to be 
resolved before the upgrade or box switch.  So we have been in the position 
of the upgrade is this weekend & we do not yet have all the license keys we 
need, or we did the upgrade & we do not have the upgrade stuff for some 
software we are using & users are trying to use it but it is breaking down 
because we have not legalized it on the new box or OS.

The only real cost is the hassle to the MIS staff & any accounting hits.
Sometimes I ask for help from our SE.  Yes we have an SE ... a guy who used 
to work for IBM both as SE & CE so he knows it both, a rare treasure.

You might do your readers a service by inventorying the IBM Partners where 
these kinds of folks have ended up.

Did you see the Midrange_L thread on IBM Billing ... that is a dimension to 
this.

I have had financial persons who did not get it on paying for OS ... we 
cannot trade in OS-old for OS-new ... there is a price tag for OS-each ... I 
had suggested that we put that price tag on the lease for the AS/400 box, and 
they had the $$$ pro-rated on the whole thing over 3 years, then 2 years 
later we did OS-upgrade, so now the IBM Leasing bill contained the 1 year 
payments on the old OS, and the beginnings of payments on the new OS, and 
accounting wanted to stop payment on the OS we not using any more.

There is a mine field of things that can go wrong when this is not done right.

Every OS upgrade adds hundreds of new neat things, and takes away a small 
handful of things that IBM used to support.  If your business is dependent on 
something that is going away, you had better know it in advance, and plan 
some conversion for that application, and that can get expensive & be time 
consuming.

We are on an application that will not run on the next OS/400.
I have told people repeatedly about this in our company & the reaction is one 
of two.
There are people who understand what I am saying.
There are people like with blinders on.

I feel we are headed for a fall.  It will take 6 months perhaps to convert 
the application to a form that is IBM supported in the future.  I need a 
consensus from the users regarding redesign of the application.  We have no 
consensus & we have no discussion.

I know that when BP talks top management into some upgrade it is reality 2 
months later & often BP has ignored our sizing questionairre & upgrades since 
their last sale.  Everyone in last sentence has blinders on regarding 
application that will not work on next OS.

Consider the fact that IBM has many AS/400 models optimized for different 
kinds of processing & the marketing people are pushing the latest & greatest 
models for whatever is the big deal of the times ... client server 
e-business, in which those great models might be totally hopeless for 
whatever core functions a company uses to run its business.

This is why companies need to keep their sizing questionairre current & 
insist that the sales reps include some guarantees associated with upgrades.  
If we go from this OS or box to that ... what impact is it going to have on 
our operations ... will we need to do any conversion because the new OS & the 
greater reliance on SQL does not use as much native AS/400 so that access to 
data bases is not as efficient, so we need more memory or faster CPU to stay 
even, or rewrite some applications.

When an upgrade is not done right, it is seldom immediately obvious to the 
folks in the trenches, or to their bosses, what all who might have done wrong.

Financial costs of this are non-existant to trivial when done right.
Data in the files serviced by software running on box or OS needs no 
conversion.
Upgrades done right are over a weekend with users on old version Friday nite 
& on new version Monday morning & the transition for them is totally 
transparent. 

In the PC world, when we go from Win 3.x to Win 9.x, the concept of upward 
compatibility has not yet achieved market demand, or when we go from Product 
97 to Product 2k in the same series, ditto ... it is a major data conversion 
hassle, akin to switching from ERP/400-this to ERP/400-that & you have to pay 
full price on Product 2k ... Hey we OWN Product 97 ... doesn't that count for 
anything discount wise ... don't you have conversion tools.  No, take what 
works or forget it.

I also have had some co-workers whose conversion experience is limited.
They witness an ERP conversion that took 1 year.
They witness a 400 conversion that appeared to them to take a weekend 
(because of good MIS preparation).
They witness a Y2K in which we sustained no damage.

They think that all conversions are the same way.
They were not directly involved in the planning preparation so they think are 
none.
They do not understand differences between the various kinds of conversions, 
so flatly incredulous when I say ... this conversion will take many months, 
perhaps a year & need a team of 10 people ... this conversion will take a 
weekend & I would like to have a few hours help from our SE.

So, in conclusion, if you have readers encountering what they think are 
excessive fees, they are probably folks inexperienced in the reality of this 
who did not do proper planning for the upgrade.  The problem you describe is 
not a common concern among experienced AS/400 staffers, but it is a common 
problem, because there is a growing disconnect between people who use 
technology & manage technology, and what has to be done to make it work 
effectively, and to do upgrades properly.

You need to be putting this research question to managers of the MIS staff of 
AS/400 ... the people who make the financial & other decisions to go for this 
or that upgrade, the folks who are on NONE of these internet lists, the folks 
who approve our IBM education.

>  From:    abrown@as400network.com (Anna Brown)
>  
>  Hi all, 
>  
>  Let me begin by introducing myself, since I haven't posted to the list
>  before.  My name is Anna Brown, and I am an Editorial Research Assistant
>  with the AS/400 Network.  I'm researching a story for News/400, and I was
>  hoping to get some input from the list on this issue.
>  
>  Some of our readers have encountered what they consider to be excessive 
fees
>  to upgrade their business applications to be compatible with the latest
>  OS/400 releases. Is this a widespread concern among AS/400 users?  Have any
>  of you run into this problem when upgrading to V4R4 or V4R5?  Please email
>  me privately if you have any information that you'd like to share.
>  
>  Thanks for your help! 
>  
>  -Anna 
>  
>  P.S.  For those of you who have already seen this request on the Ignite400
>  list, I apologize for the repetition!
>  
>  Anna Brown
>  Editorial Research Assistant
>  AS/400 Network - NEWS/400
>  Duke Communications
>  221 E. 29th Street
>  Loveland, CO  80538
>  Phone (970)613-4989
>  Fax (970)663-3285
>  abrown@as400network.com

Al Macintyre  ©¿©
MIS Manager Green Screen Programmer & Computer Janitor of BPCS 405 CD Rel-02 
running on AS/400 V4R3 http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies

Y2K is not the end of my universe, but a re-boot of that old Chinese curse.
The road to success is always under construction.
Accept that some days you are the pigeon and some days the statue.
Murphy's Mom brought wrong baby home from hospital so it should be Kelly's 
Law.
When in doubt, read the documentation, assuming you can find it.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---