Hello, all interested parties:
(cross-posted from RPG400-L list)
One problem with this, and with the proposed "solution" (to add
"EXTPROC(*CL:name)" to all the RPG procedure prototypes and recompile
ALL callers), is that the previous behavior that David is talking about
was _not_ just some /word-of-mouth/ "_work around_" but it was
*documented* in the _IBM manuals_, as recently as 1999, vis:
http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/qb3agy03/2.6.4?SHELF=&DT=19990317104340
So, now, we seem to have a clear case where IBM has somehow apparently
"broken" the backwards compatibility of compiled program objects, which
is and has always been one of the _hallmarks_ of OS/400 and i5/OS.
:-o There was no warning in the *V6R1 Memo To Users* manual about
this issue, as far as I can tell.
I compiled a small test CLLE module and RPGLE module that purposely does
not use EXTPROC(*CL:name), to demonstrate this problem,; I compiled them
with DBGVIEW(*ALL), bound them together with CRTPGM, and ran the program
under debug, and it worked "as expected" under V5R2 through V5R4. Next,
I saved the *PGM in a save file, and restored it on a V6R1 machine, and
ran it under "debug" and, sure enough, there was the problem, just as
David originally described it. So, the same program, with exactly the
same sequence of NMI instructions, now produces different results. :-o
I don't care whose fault it is, or was. I believe it was a mistake when
"*EXTPROC(*CL:name)*" was added to the RPG IV compiler. It would have
been far better, in my opinion, to add /procedure prototyping /for
external procedures to the ILE CL language. That would allow customers
to "fix" this issue "at its source"... after all, it is the ILE CL
compiler that needs to know how values will be returned, no?
Still, what to do about all those already-existing pre-compiled programs
out there with this situation? They are already compiled, and they were
"working", right up through V5R4. Now, all of a sudden, at V6R1, they no
longer "work" as they once did, apparently due to the mandatory
re-encapsulation of the program creation template (aka. New MI) using
the new improved SLIC Optimizing Translator (OX) at V6R1, which
apparently generates some different instruction sequences, especially to
do with parameter passing.
"Rochester, I think we have a problem."
Sincerely,
Mark S. Waterbury
midrange.com
