Re: CL Parameters sharing memory?

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