Re: CL Parameters sharing memory?

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

True enough - not a limitation - actually the system will guarantee a 
pad with blanks out to 32 characters - I think that's more precisely 
what is happening. This definitely happens when using a constant in a 
call from the command line. Not sure why the CMD parameter of SBMJOB 
strips things - does the RTGDTA parameter do things differently - I 
thought that I'd heard that might be one of the ways to get around this. 
But I prefer using a command front end.

Vern

Alan Campin wrote:
> It would not be correct to say that it has a 32A limitation. What is
> happening is that the SBMJOB parameter CMD is stripping the trailing blanks
> so it is passing
>
> CALL PGMB PARMS('Kurt Test' 'N') instead of CALL PGMB PARMS('Kurt
> Test                          ' 'N')
>
> so the receiving program receives garbage. The parameter length could be up
> to 32k I believe.
>
> If the parameter is 32 bytes or less you don't have a problem because the
> command process always creates any CL variable as a minimum of 32
> characters. Anything greater than 32 bytes is where you run into the
> problem.
>
> As indicated the solution is to define a command or to define the field as
> 46a and put an * in the 46 position so it does not blank compress the
> string.
>
> Personally I don't know why SBMJOB blank trims the parameters.
>
> On Mon, Dec 7, 2009 at 3:33 PM, Kurt Anderson
> <kurt.anderson@xxxxxxxxxxxxxx>wrote:
>
>   
> > Thanks Carel & Buck.
> >
> > I did know about the 15p5, but I guess the 32a limitation (wow, talk about
> > small) always flew by me.
> >
> > I do have a command front end, which is probably why the command works for
> > calling the CL, but that CL then subsequently submits another, and therein
> > lies the problem.  Thanks for the help.
> >
> > -Kurt