parameter passing pitfall

Here's a little something I probably should have realized about passing by
reference, but had to learn the hard way.  I was debugging a program a
couple of days ago found out that the problem was having procedure
parameters out of order.  The parameters were defined as read only reference
(const) and I was accidentally stuffing a 25 character field into a two
character field.  It worked just fine except that the file update resulted
in some odd data.

Here's a sample prototype for a procedure that concatenates the two fields
in the order they're specified in the prototype without trimming any blanks:

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.
If you pass a two character field followed by a twenty character field,
you'll get what you expect.

I guess the moral of the story is to get your argument list right the first
time, although you might argue that converting the larger string to a
smaller one is a type cast that results in a loss of precision.  Forewarned
is forearmed. <g>
NOTICE:
All e-mail sent to or from this e-mail address will be received or otherwise
recorded by The Sharper Image corporate e-mail system and is subject to
archival, monitoring, review by and/or disclosure to Sharper Image security
and other management.  This message is intended only for the use of the
addressee and may contain information that is privileged and confidential.
If you are not the intended recipient, dissemination of this communication
is prohibited.