Joe Pluta wrote:
How many programs are
non-compliant once you recompile them?
Well, none.
And I'm purely picking at a nit here, but a lot of programs nowadays
aren't compiled, as such, but are re-bound instead if they're ILE.
I.e., the modules are recompiled.
Now, after that, if everything has been done correctly for many
years in a row, even recompiling both all modules and all programs
and rebinding ILE, then things usually will be okay.
But irregularities _do_ creep in over the years.
New developers come, old developers go, techniques and technologies
change. Information gets lost or communicated not quite correctly.
The actual recompiles generally aren't that big of a deal. However,
**IMO**, a vendor _cannot_ let it go at that. Extensive regression
testing _must_ be done as well. If enough code is involved and it's
been around long enough, there's a risk that some little API change
has happened or that a module that once was single-use has been
picked up for a different purpose by a long-gone developer.
When that testing is done for a pre-GA VRM, there can be unexpected
delays. When vendor code is touching obscure elements of pre-GA
VRMs, when pre-GA PTFs aren't _quite_ perfect, the delays can be
irritating and extensive.
And the testing must include effective upgrades of all products on
V5R3 and V5R4 at least, and then upgrading those systems to V6R1, as
well as simply installing fresh on all of those. Making ready for
V6R1 means giving customers something that works on prior releases
and that still works after they do their i5/OS upgrades.
The simple creation of test plans can take significant time. The
acquisition of hardware resources and allocation of those can take time.
And no need to go deeply into providing support for customers in
many different countries (CCSIDs) or for those with unusual hardware
configurations or for strange DB2 or Java or TCP/IP group PTFs or...
Again IMO, vendors really should do a lot more than just recompile.
Not that I'm getting a little burned out by testing or anything. :-)
Tom Liotta
midrange.com
