× 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 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 / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.