× 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 27/03/2009, at 2:03 PM, David Gibbs wrote:

IMO, the better solution would be to fix the call mechanism so it supports the old technique even if it was a work around.

That would be the most expedient solution for you but perhaps short- sighted in the long run. The real problem is that the call/return mechanism was buggered up way back in VRM230 by some C weenie. It should have been fixed properly when ILE RPG and COBOL came on the scene in VRM310 but given that return values from RPG didn't arrive until about VRM370 it could be argued that they didn't know they'd cocked it up. At that point they should have fixed it properly. The only real pain would have been experienced by vendors who were using both CL and C--count them on the fingers of one hand.

Either that or send an escape message if the technique is used (although I'm not sure how they could detect it).

Don't see how the run-time could know that's what's happening. The compiler would have to catch it in which case a recompile would be necessary. If a recompile is required then they could fix it properly.

As it is now, programs that use the technique do not fail but give the wrong result.


Which is why the response should not be accepted. Existing code will break unless changed even though it uses a documented technique. Documenting such a change in the Memo to Users is a kludge. The proposed change (EXTPROC(*CL)) is itself a kludge and stops RPG from working with COBOL. IBM should take this opportunity to fix it properly and either give the CL programmer control over how CL handles return values or make it transparent by handling the return value in a manner appropriate to the language supplying the return value. For COBOL and RPG handle it as expected, for C widen it. The difficulty here is that, as far as I know, the run-time doesn't know the data type of the return value IN THE RETURNING PROCEDURE.

Adding support via DCLPRCOPT seems the best way to deal with this. The underlying change to pass the return value in a register does not need to change. All that needs to change is:

a) default behaviour is to reinstate the previous widening
and
b) give the CL programmer control over the behaviour

That will solve your immediate problem of existing code continuing to function as expected AND allow a proper fix so RPG programmers don't have to choose between normal return behaviour and C/CL behaviour. The primary benefit of extending DCLPRCOPT is to remove the need for the EXTPROC(*CL) kludge and then generic RPG functions can be written that can be called by all programming languages.


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.