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