× 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 14/03/2009, at 2:23 AM, Barbara Morris wrote:

This is at least partly my fault, more likely all my fault.

Unless you are the person who, way back in VRM230, decided to make ILE CL handle return values in the same way as ILE C then I doubt it's your fault. I think you did explain how to use a CHAR(2) and %SUBST to work around the problem but the real problem is the dumb design decision made early on.

Even though ILE RPG was introduced at VRM310 this problem was not apparent until VRM320 due to the 310 implementation not handling return values--this was because 310 only handled a single "procedure" per module and ILE RPG did not support proper procedures until 320.

COBOL also supported returning values from procedures via the GIVING/ RETURNING keyword(s). Both ILE RPG and ILE COBOL support the same parameter and return value semantics and any OS/400 programmer moving to ILE from OPM COBOL or RPG would expect CL to behave in the same manner. Two CUSTOMER programming languages outweigh one VENDOR programming language.

It is at this point that the design error in ILE CL should have been corrected. Yes, it would have been painful for anyone who had embarked on ILE development at that time but consider who that would have been. Given that ILE was only useful for C and CL almost no customers would have been using it. Only vendors would have been affected and they have both the skill and money to deal with such an incompatible change.

However, it seems to me that CL could handle this transparently. It can determine what type of language is being called and behave accordingly. If calling C then expect widened return values otherwise behave as normal.

I realise IBM has a strong history of backwards compatibility and tries not to break existing behaviour but there is enough evidence to show IBM will do it when it needs to and this is a clear case of where a previous bad decision should have been corrected. As it stands this had been broken for 10 releases and a kludge provided for 4 releases. Given that VRM610 has changed so much related to the program model used by the OS this would have been an opportunity to correct the defect while customers and vendors are already expecting migration issues.

From VRM230 to VRM450 only C and CL worked properly in an ILE environment. From VRM510 RPG joins that club but ONLY if the developer specifically allows for it using the EXTPROC(*CL) kludge. As far as I know COBOL still has this problem.

The I in ILE is for Integrated ... hmm ... don't think so!

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.