Re: CL Parameters sharing memory?

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

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