×
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 15/01/2010, at 12:24 AM, rob@xxxxxxxxx wrote:
Wouldn't this always be passed back and forth? Passed from the
calling
program to the subprocedure and then passed back? So therefore, how
could
you promote from integer to decimal and not get promoted back?
Didn't mean the return on the same call but rather: 5i can be passed
in to a 7,2p but a 7,2p cannot be passed in to a 5i.
Although thinking about that a bit more indicates a potential problem:
Caller passes a 5i containing 32766 into a procedure expecting a 7,2p.
The value is received correctly. The procedure performs a calculation
and returns 65535.99. This fits within the 7,2 but will not fit within
the receiving 5i thus a problem. I would expect a run-time error in
this case: Receiver too small for result.
I think this means that the compiler wouldn't need to check compatible
sizes at compile-time (although it could and issue a warning message
about potential problems) but rather is more concerned with whether
the actual values will fit at run-time.
This is really no different from current behaviour where I can eval a
15,5 into a 5i as long as the actual value will fit.
Interesting discussion but somewhat moot.
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
