×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 02-Nov-2015 14:22 -0600, Charles Wilt wrote:
My $.02...
Best practice would be to regression test the app's functionality
<<SNIP>>
Agreed; after any recompile, performed for any reason, given that
recompiled code is going to be moved [up a chain towards or] into
production. But having used a tool to modify the source and then to
compile from that modified source using an entirely different compiler,
just seems to make that choice all the more obvious :-)
That being said, CVTRPGSRC is as bullet proof as you'll ever find.
In 10+ years, I've only had 1 "working" RPG III program that failed
after conversion to RPG IV. I say working because the issue was by a
parameter mismatch. It just happened that the RPG III didn't get the
same crap in memory the the RPG IV version did.
I expect that existing bugs such as those [especially, specifically,
any issue with parameter mismatches] would be what typically is exposed
as a /problem/ if\when the regression testing runs; i.e. exposing
existing bugs that had merely gone unnoticed, effectively by chance,
possibly due only to nuances of the compiler and data alignment choices.
Or similarly by chance, existing bugs may not be manifest with the
newly compiled, or by the worst of all fortunes, manifest seemingly
randomly [despite they were seemingly never exposed having been compiled
with the old compiler]. Much less likely, is that the origin of a
problem would be anything the source /conversion/ would have
introduced\broken, or what the different compiler would have done
_incorrectly_ with that /converted/ code; either are possible origins,
both are unlikely, yet there is an increased chance for the latter if
any HIPer maintenance has not been applied to the newer compiler.
Note: I have converted very few RPG sources using that feature. I do
not recall ever experiencing an issue with SRCTYPE(RPG), although I have
a suspicion that I may have had an issue once with an SQLRPG [yet that
could have been on pre-release OS+compilers]. And I have never used the
Convert RPG Source (CVTRPGSRC) command against a Source Type specified
as any of RPT, RPG38, or RPT38 for the source member to be converted.
midrange.com
