Hi,
Thanks everyone for your replies. The initial problem that was reported to me involved a CL that was called by a COBOL program. When I investigated, I debugged the CL by calling it from the command line with the same parameters.I now understand (thanks to your replies) that calling it from the command line will cause this issue, while calling it from within another program should not.
Out of curiosity I will do another debug tomorrow from the COBOL program and see what happens then. But to quickly fix our problem I will create a *CMD object as Rob suggested.
Thanks!
Erwin Donker
-----Oorspronkelijk bericht-----
Van: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Namens Vernon Hamberg
Verzonden: donderdag 5 juli 2018 14:37
Aan: Midrange Systems Technical Discussion
Onderwerp: Re: CL parameters over 32 length
Hi Erwin
You ask why it used to work and now it doesn't, all of a sudden. And
that nothing has changed.
I suggest that you have been lucky. Probably what has been in memory has
been blanks. That is never guaranteed but can happen. An upgrade of the
OS could change alignment of parameters, maybe resulting in this change
for you. Or whatever happens in memory now.
You did not say how you have been calling the program - are you using
QCMDEXC or SMBJOB? Both of those behave as others have described doing
the call from a command line.
I do want to gently challenge your calling this a "problem"- it is long
documented - I'd say since 1980 or so, when System 38 came out (1978?).
This is a strongly-typed system as parameter definitions go - and that
typing includes size. We don't have the kind of parameter passing that
appends a null automatically, so one has to ask, what length would be
good as a default when the size is not known? This is similar to the
default for numeric values (packed 15,5) - that's definitely not what I
want when my parameter is packed 5,3 - but what other default
declaration would work better? No matter the choice, something will not
match.
Been there, done that, no T-shirt for this one, man!
Cheers
Vern
On 7/5/2018 2:58 AM, Erwin Donker wrote:
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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op:
http://www.denhaag.nl/disclaimer
midrange.com
