QCMDEXC question

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: david@midrange.com
+---