David and Mark, After some investigation prompted by David's initial note, here is what appears to be happening. Back in V3R1 ILE CL became available, and when implementing CALLPRC used C functions as a test vehicle for return values (RPG and COBOL did not support return values until later releases). Now return values can be implemented by either placing the actual value on the stack, or by placing a pointer to the value on the stack. In the case of C, character values (1 byte), short integers (2 bytes), and integers (4 bytes) are returned by value; character strings, arrays, etc. are returned by pointer indirection. So when CL was instructed to expect a 1 byte char function return value, that basically meant to move the value off of the stack and into the variable. When CL was instructed to expect a 2 byte (or longer) char string, that basically meant to use the pointer on the stack to move the value out of storage and into the variable. So far, everyone is "happy". 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. While one might argue the pros and cons of choices 1 and 2 above, #2 was selected for what appeared to be valid reasons at that time. Hopefully the above will help explain what is happening, and to answer the question of "how short is short" -- it appears to be one byte. 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) > >David > >At 08:43 AM 1/19/98 -0700, you wrote: >>Mark, >> >>When a CLLE program calls an RPG program you can get a machine check >>MCH3601 on the end procedure statement. This happens most of the time >>when you specify a return variable that is short. The work around is to >declare >>the variable with a longer length and substring out the first part. It is >not very >>consistent. Programs may run for months. One day change the program, >>without touching the parms, next day it starts getting MCH3601. It >happens more >>than 50% of the time with 1 byte return variable, say for instance an >error flag. > > DO you have specifics as to how short is considered short? Also, how much >longer will fix it? > >>We were really surprised when the response from support was that it was >>no longer a bug. The APAR was closed and they changed the status to a >>"restriction with a work around". Apparently not enough people use CLLE >>to make it worth while to fix. They gave us no commitment that it will be >fixed >>in any future release. We are currently on V3R7. > > This is the type of bug that the code does "not work as advertised." I'm >guessing that it will be fixed soon w/o a lot of fanfare (maybe shortly >after the next COMMON.) > > -mark > +--- | 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.