I too have struggled with this through the years, so a while back I
researched this issue and discovered a piece on the internet that
explained it. I wish I could find it again, but I've had no luck. Here's
what I remember, I'm sure others will improve on my answer.
Parameters are passed by reference. Parameter values don't get passed,
rather pointers to memory locations do. The calling program is in
charge. When you write the calling program (and therefore control the
parameter definition) the calling program knows the attributes of the
parameters and passes them correctly. But the command line processor is
not in our control. It assumes the length for parameters. As I recall,
it's 32 characters for Char and 15,5 (perhaps 15,7) for numeric. This is
what leads to the mismatch that is causing you the grief you describe
below. Program to program should be fine. Command line to program, not
so much.
I don't believe anything has changed, in my experience it has always
worked this way.
Joe Hatchell
From: Erwin Donker <erwin.donker@xxxxxxxxxx>
To: "midrange-l@xxxxxxxxxxxx (midrange-l@xxxxxxxxxxxx)"
<midrange-l@xxxxxxxxxxxx>
Date: 07/05/2018 06:23
Subject: CL parameters over 32 length
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Hi,
We have a CL program that uses 3 input parameters. The first parameter is
*CHAR length 50, the second parameter is *CHAR length 44 and the third
parameter is *CHAR length 512.
When this CL program is called with values that are smaller than the
parameter length (for instance 23 characters for the first parameter), we
have noticed that the value of the second parameter gets added tot he
first, starting at position 33.
I have searched the internet and have found that this behaviour is
intentional. From what I understand, *CHAR parameters are padded with
blanks up to 32 characters. Whatever was in memory after position 32
becomes part of the value of the first parameter.
I have also found several suggestions as workaround fort his issue, som y
question is nota bout how I can solve this problem. What I really don't
understand is why this CL program has worked for months without any
problems and then suddenly starts showing this behaviour. The program has
not been changed, the calling program has not been changed. We did apply
PTF's but this was 1 week before the CL program started showing this
behaviour so I don't think the PTF's are causing this. So basically what I
want to know is, why does using CL parameters over 32 characters sometimes
work, and sometimes not?
Another question out of curiosity, this "problem" has been around at least
since 1998 and probably much longer (1998 was the oldest information I
found online). I see many people having issues with this, so why has IBM
never changed this?
Erwin Donker
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
op:
http://www.denhaag.nl/disclaimer
midrange.com
