RE: parameter passing pitfall

>D combine         PR            22A
>D twochar                        2A   CONST
>D twentychar                    20A   CONST
>
>If you call it with a twenty character field
>followed by a two character field, the result
>will be the first two characters of the
>twenty character field followed by the contents
>of the second field followed by 18 blanks.

Not always!  Given:

D fld1                          20A   inz(*all'x')
D fld2                           2A   inz('12')
  combined = combine(fld1: fld2)

"twentychar" is not _guaranteed_ to hold anything except '12' in the first
two columns.  The remaining 18 are undefined, and are whatever happens to
fall after fld2 in memory.  To see why this is so, envision how the call is
processed.

mainline
variable   address length contents
fld1        1      20     xxxxxxxxxxxxxxxxxxxx
fld2       21       2     12
otherVar   23      80     Credits don't equal debits

when we do an
  eval combined = combine(fld1: fld2)
the machine passes the address of the fields involved, so:
  eval combined = combine(1: 21)

When "combine" runs, it maps it's variables to the memory locations passed
in, so

combine
variable   address length contents
twochar     1        2    xx
twentychar 21       20    12Credits don't equal debit

It's very similar to mis-matching variables within a data structure.  My
personal extra credit assignment was to explain to somebody why they were
guaranteed to get 18 blanks if the procedure was a main() and was called
from the command line.  Hint to lurkers: what's the default size of literals
in QCMD?
  --buck