Re: CL Parameters sharing memory?

Vern Hamberg wrote:

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.

Heh... RQSDTA() rather than RTGDTA(). AFAIK, the name RQSDTA() refers to the *RQS request message that is queued. Its default is RQSDTA(*CMD) which apparently refers to what gets processed through the CMD() parameter.

Unfortunately, what comes out of the CMD() parameter doesn't have to match what goes into it. That's especially true when the command is CALL where there is no clear data typing of its parms and default types and lengths must be assigned.

If RQSDTA() is used, you construct the request message yourself. You control the rules of formatting. It's certainly not as easy as CMD(), but you get out of it exactly what you put into it.

> But I prefer using a command front end.

Well,... yeah. That way you can make the CMD() parameter work for you. It's designed to allow prompting of commands. Maybe its biggest problem is that when IBM added it to SBMJOB, they didn't reject CALL; then we'd still be using RQSDTA() like we used to.

Tom Liotta

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
wrote:

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.