On 19/03/2009, at 5:11 AM, Mark S. Waterbury wrote:
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.
Ha! I didn't think to look that far back. I note that this section of
the ILE RPG Programmer's Guide was completely re-written in VRM510
(when EXTPROC(*CL) etc. was introduced).
Note point 3:
3. If you want your RPG procecure to be used successfully by every ILE
language, do not specify any special value on the EXTPROC keyword.
Instead,
avoid the following types for parameters that are passed by value or
return
values:
o Character of length 1 (1A or 1N)
o UCS-2 of length 1 (1C)
o Graphic of length 1 (1G)
o 4-byte float (4F)
o 1-byte or 2-byte integer or unsigned (3I, 3U, 5I, or 5U) |
That's such POOR design. If you want INTEGRATED Language Environment
programs to interoperate successfully then avoid using common data
types because ONE language has trouble processing them? I can
understand this for things like var-char where some languages have no
direct support but for basic data types? That's just stupid design.
C lets the programmer control widening (not sure if that affects the
return value).
RPG doesn't widen but provides a kludge
COBOL doesn't widen
CL presumes widening is in effect.
What's wrong here? If you want to write common-code usable by all ILE
languages you can't return boolean data types nor 1-byte character,
nor 1-byte integer, nor 2-byte integer. Thus you can't write
procedures of the form isSomethingSet() because you can't return a
boolean reliably to all languages. You (probably) have to use an
integer.
The default behaviour breaks CL. If you kludge it for CL then you
break it for COBOL.
I guess IBM will consider the section prior to "Interlanguage Calling
Considerations"--namely "Interlanguage Calls"--to be sufficient
documentation to let them weasel out of fixing this.
"When passing or receiving data from a program or procedure written in
another
language, it is important to know whether the other language supports
the same
parameter passing methods and the same data types as ILE RPG."
Although the Memo To Users for VRM510 does mention RPG it does not
mention this particular change. None of the later Memo to Users
documents mention it either.
Seems to me the least intrusive means of fixing this now is to add an
option to the CL DCLPRCOPT command to stop widening of return values.
That could be PTFed into 540 and 610 which would give developers time
to adjust. If you don't have the problem then continue as usual. If
you do use problematic return types in CL then remove any %SST kludge
and specify the new compiler option and recompile. Solved. This
approach also fixes it where it's broken--in CL-- rather than forcing
other languages to work around a short-sighted design decision.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
