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