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

I used to work for a vendor, and we did support customers who had not come up to the current level or even current - 2.

We also made sure to be able to run on the most current OS level, and when 6.1 came out, we were on an early-ship so that we could be sure it'd all work.

We clearly stated the latter on our site, and these were part of a standard statement of support.

Now we didn't have the scope that, say, certain ERP vendors have as to number of programs and all.Still, with early-ship and ANZOBJCVN and other tools IBM provided, there is little excuse (other than time and money and personnel) for lagging behind. IBM was not happy with such laggards, for sure, as it kept customers from upgrading.

If any vendor had misplaced code that had been compiled at v4 or lower, they were in trouble - and should be, I guess!! A recompile at v5+ basically took care of observability needed for object conversion.

Changes in hardware support can be more problematic, as well as the OOPS you cite, where people hard-code positions from APIs - a poor practice that was discouraged from the very start when IBM opened up APIs.

In sum, I guess I'd say, check out your vendors - we're all somewhere on the spectrum as to OS levels and need to be sure we get products that let us move forward when we can and choose to do so.

Vern

On 8/8/2015 5:51 AM, Wilson, Jonathan wrote:

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