×
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 / \
--------------------------------------------------------------------
midrange.com
