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: email@example.com +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.