|
midrange.com
Bruce,
Thanks for the explanation. Even after talking with support people several
times we did not receive a very clear answer or a reason for the restriction.
Based on what you have just said we know that our programs that did not
get a machine check were just accidents waiting to happen. Maybe the
prototype in RPG should allow VALUE to be specified. Then those of us in
the know could create programs that always work... well most of the time. I
guess we lived without being able to pass a LGL to RPG for 15 years.
This is not that much different. It seems that the parameter passing for ILE
RPG is implemented differently than in ILE C or ILE CL. The CEEDOD
procedure cannot return complete information about RPG parameters.
Someone needs to work on this. I would really benefit from a *VARTYPE
option when specifying prototyped parameters. I think what ILE has done
for RPG is great.
I mentioned that I was disappointed in the ILE CL enhancements because
the only new language construct that I am aware of is CALLPRC. I would
like to see prototype support, subprocedures, more data types, case
statements and more built ins. I would like to see better integration with
the other ILE languages. The "I" in ILE stands for integrated, just try
and call a CEE procedure from ILE CL. The most important thing to get
right in an integrated environment are the interfaces.
It really helps us to understand what is happening, even if it isn't
what we want to happen. I still don't understand the re-compile bit. I
was under the impression that observable AS/400 programs had the
unique ability to be regenerated to support system enhancements.
Thanks for your help,
David Morris
>>> <bvining@VNET.IBM.COM> 01/21 12:39 PM >>>
David and Mark,
...
Now ILE RPG and ILE COBOL implement function return values, but when
returning a character (1 byte) value these languages elect to not place
the value on the stack (like C and CL expect) but rather place a pointer
to the value on the stack. CL calls RPG expecting a one byte character
return value on the stack; actually receives a pointer on the stack,
attempts to work with pointer as if it were character data -- and things
go down hill rather rapidly. So what is the "fix"? Well one would be
to "correct" RPG and COBOL to treat 1 byte character function return
values in the same manner as C and CL; but that would mean making every
user of ILE RPG and ILE COBOL recompile all their programs (or at least
those using/giving function return values). This alternative did not
seem very attractive. A second approach was to "instruct" CL to expect
a pointer on the stack rather than a data value. And how is this done?
By defining the return value as a char(2) (or greater) which indicates
a pointer is being used, and then substring out the first byte to get
the char(1) referenced by the pointer.
...
I don't believe I would necessarily classify this as a CL shortcoming;
for sure ILE CL is not considered a language of minimal usage that is
not being "fixed" and enhanced.
Bruce Vining (wondering what kind of response the messenger will get on
this one)
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.
