Re: CL Parameters sharing memory?

LOL - mea culpa - keyword names - well, when on vacation and early in the morning.

It's been years since I used RQSDTA, if ever. I've got so used to putting a command out for calling things.

Just for the record - or the archive - here are the 3 solutions for character parameters longer than 32 when used in the CMD parameter of SBMJOB as given by IBM -

* Create the CALL command string to be submitted by concatenating
the various portions of the command together into one CL variable.
Submit the command string using the request data (RQSDTA)
parameter of the SBMJOB command.
* For CL character variables larger than 32 characters where
trailing blanks are significant, create a variable that is one
character larger than needed and substring a non-blank character
into the last position. This prevents the significant blanks from
being truncated. The called program should ignore the extra
character because it is beyond the length expected.
* Create a command that will initiate the program to be called.
Submit the new command instead of using the CALL command. The
command definition ensures the parameters are passed to the
command processing program as expected.


If I read the CL programming manual rightly, using a CALL on a command line with the value padded all the way for character parms > 32 long does work fine - trailing blanks are preserved, because it says -

"Character string constants of 32 bytes or less are /always/ passed with a length of 32 bytes (padded on the right with blanks). If a character constant is longer than 32 bytes, the entire length of the constant is passed. If the parameter is defined to contain more than 32 bytes, the CALL command must pass a constant containing exactly that number of bytes. Constants longer than 32 characters are */not/* padded to the length expected by the receiving program."

Hence the confusion in the CMD parameter - which we just have to accept and deal with as described above.

Vern

Tom Liotta wrote:

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