Re: How soon is too soon? (was Re: Can iSeries Access to ACS migration be automated?)

If you have a very simple, or maybe even a somewhat complex, vendor
package which still uses RPG/400 or RPG36 only, extremely simple CL, I can
see how you would be confused as to why would they find it so difficult to
keep up with OS upgrades.

The first, most obvious, (at least to those who have upgraded past V5R4)
is that an upgrade past that was much like the CISC-to-RISC upgrade after
V3R2. If you didn't have observability for code compiled prior to V5R1
then the object code wouldn't convert and work on 6.1 or above. Removing
observability was often done to reduce object size but mainly to make it
tougher to reverse engineer code to hack the security mechanism vendors
had to make sure you were authorized to run on that machine. There are
other ways of protecting the vendors property now.

ERP vendors may require you to upgrade their software to get to a version
which is compatible with the new OS. If you have heavily modified their
code this could be a hard row to hoe.

Then there could be any other number of items.

People who did asinine stuff like avoiding API's but coding CPYSPLF of IBM
reports to disk files and then reading that to gather information. EVERY
release of OS has a generic warning in their Memo To Users that this may
bite you in the butt.

People who coded API's improperly and instead of using the offset fields
in the list headers hardcoded offsets.

New commands, like RUNSQL, clobbering home grown versions of the same.

Changing defaults on commands.

Certain system options which are no longer allowed. For example,
QSECURITY:
System security level . . . : 30 10=Physical security only (no
longer
supported)

Increases in system limitations. I remember Al Barsa (God rest his soul)
going into an absolute tizzy over IBM increasing the number of digits in
the number of spool files allowed in a job. That meant changing TAATOOL.

People also mentioned dropping of certain IBM products. One big example
was Office Vision/400. I had commands from that imbedded into code.

One vendor may be hung up on another vendor. And if the first vendor lags
- they lag. For example, vendors who expect Seagull to be working on
their system. Or packages who use another vendor's document imaging
system but that vendor may have a history of lagging way behind on release
upgrades.

Now we starting getting into other dependencies. Which is kind of like
the OV/400 dependency but different. Let's take Java versions for
example. There is only one version of Java which works on V5R4 and on
7.2. And it did not ship with V5R4 media but had to be ordered
separately. Therefore there are probably few to none vendor packages
dependent on Java which work on both V5R4 and 7.2 which do not require
some tweaking. (And this may be obsolete, it have be as early as 7.1 that
had little java compatibility with V5R4). I have had versions of Domino
fail solely due to Java products being dropped. Of course IBM documents
this, and tells you to upgrade Domino first, but some people like to push
the envelope. Other 'middleware' products in this category include:
Websphere.
We have a version of IBM Sametime which will not work on 7.2 because of
Java and Websphere issues. The official solution is upgrade to a newer
version of Sametime first. Which is quite common among vendors (as I
mentioned in the ERP issue). However, since IBM cannot supply one
reference of someone running Sametime on IBM i we are trying to move
Sametime off platform. This is a product it does not pay to be bleeding
edge - PMR's may stay open for months. The migration is going so badly we
are looking at going to a cloud based solution. It's coming up on eight
months. And anything that doesn't allow me to be on the latest version of
the OS really draws my ire.

I have had a vendor package fail simply because their check to see if you
have a compatible version of Java installed was to check for 5761JV1,
option such-and-such. Well, 7.1 may have still called java 5761JV1 but
7.2 started calling it 5770JV1.

Vendors often have issues with the simplest of things. Easily worked
around but a delay nonetheless. Examples include when IBM started
supporting letters in system serial numbers. "Um, the guy who wrote our
key generator is on vacation..."

Vendors often lag behind because they have hardware so old that it won't
support a new release. I leaned on them hard but they kept deferring the
hardware upgrade until the new release was GA.

Simple rule of thumb. Always read the Memo To Users. If you skipping a
release, read that MTU anyway. For example if you upgrade from V5R4 to
7.1 read both the 6.1 and the 7.1 MTU.
Check with your vendor for support.
When evaluating new vendors ask them this: "Are you an active participant
in IBM's Early Ship Program? Will you have a ready to run solution on
announcement date for any new release of IBM i (and it's successors)?"

Rob Berendt