Re: CL parameters over 32 length

[mlazarus <mlazarus@xxxxxxxxxxxx>]

Bradley,

 There's an even easier way to use your technique, without resorting to 
changing the called program.  Pass the string as one (or more) longer 
than your program's definition.  So if the receiving parm's length is 40 
just append a character anywhere from 41 and onward.  It will 
automatically be ignored by the program and the trailing blanks will be 
preserved.

 -mark

On 7/5/2018 8:31 AM, Bradley Stone wrote:
> What I've done in the past is place a character in the last position of the
> long string so that the data isn't corrupted.  Then in the CL I just
> substring from 1 to (length-1) to get the actual value.
>
> Bradley V. Stone
> www.bvstools.com
> MAILTOOL Benefit #2<https://www.bvstools.com/mailtool.html>: The ability
> to specify a "From" and/or "Reply To" email address!
>
> On Thu, Jul 5, 2018 at 3:04 AM Erwin Donker<erwin.donker@xxxxxxxxxx>  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
> >
> >