×
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.
Hello, all interested parties:
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 about this in the V*6R1 Memo To Users*
manual, as far as I can tell.
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 "fixing"
this problem "at its source"...
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, we have a problem."
Sincerely,
Mark S. Waterbury
midrange.com
