Rob,
All good points. That's almost a tutorial on what to look out for while
getting ready for and upgrade.
I'll suggest that there is an even simpler root cause why many OEM software
vendors are not ready when IBM is. They don't have an administrator like
yourself on staff that is sophisticated enough to help them with these types
of issues. Several of my customers are software vendors. They hire me to
do the system administration on a retainer so they can do what they do best,
develop software. I worry about the system for them. When it comes time to
perform the upgrade I assist in getting them onto the new version and with
remediation as needed. (all part of the service)
I do have OEM Vendor customers that simply refuse to put up V7R2 because the
customer base is not pushing them for it and they prefer to continue to
invest in the software directly rather than pulling back and doing all the
regression testing etc. needed to put up a new release. One recently
upgraded without knowing it. They requested a new partition for development
and I put it up for them, at V7R2. When I pointed out to them that
everything was fine, they let me upgrade the other partitions as well.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, August 10, 2015 7:31 AM
To: Midrange Systems Technical Discussion
Subject: 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
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Wilson, Jonathan" <piercing_male@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 08/08/2015 06:51 AM
Subject: Re: How soon is too soon? (was Re: Can iSeries Access to
ACS migration be automated?)
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
On Thu, 2015-08-06 at 13:56 -0400, rob@xxxxxxxxx wrote:
I too have seen vendors waiting too long to support the current level of
IBM i. One, I have replaced vendors who have done this and won't
hesitate
to do so in the future. Two, I tend to shy away from any vendor who
brags
they still support numerous old versions of the OS. These people often
have old machines that cannot upgrade to the new levels of the OS.
I'm curious, what wonderful and hidden design trait, language, or trick
prevents the vendor and/or user from upgrading the OS?
Would I be correct in thinking that the vendor supplied programs have
had all the "stuff" removed that allows the OS version changes to go
unnoticed (observability?) with basically in-place
re-compilation/translation?
Is there some other "thing" that means that if the OS is upgraded the
programs will stop working, such as license keys or version checks
embedded in the code?
I can understand that if an IBM product is dropped, which tends to be at
the same time as an OS version upgrade, then it becomes a real problem
for the vendor and user if the product is based on that IBM
application... but in other cases what causes the delay.
I always believed that one of the greatest selling points of the "400"
was is ability to run very old code with no changes and, specifically,
no manual re-compilation.
That said, I can see some potential "opps" areas where, for example, a
program hard codes positional fields instead of using offsets and makes
the assumption that just because X was at position 724 it will always be
there, when it should have extracted X at position 7 at the offset Y.
(Had that bite me once, never again!)
Jon
midrange.com
