Re: CL Parameters sharing memory?

If it leaves trailing blanks in a character value, what is that? I think you misunderstand me - or I didn't say it well enough. CMD "effectively" strips trailing blanks. Even if you put enough blanks in a string in a parameter in the CMD of SBMJOB, those blanks are not looked at - you have to put an extra character at length plus1. My statement assumed that the programmer would put enough blanks into RQSDTA to pad out the value for the parameter on the CALL. RQSDTA, as I understand it, does not "effectively" strip those trailing blanks. The result with CMD is that parameters declared longer than 32 will likely have problems - the truncated value is sent to the command processor or whatever. And it is treated as described in the CL manual.

We are probably agreeing violently - time to stop - I will come up with a couple quick examples to demonstrate the behavior, sometime this week.

Vern

Tom Liotta wrote:

Vern Hamberg wrote:

Not sure which is more evil - RQSDTA does not strip trailing blanks.

I wouldn't quite say that it doesn't strip trailing blanks. I'd more likely say that the programmer doesn't strip trailing blanks. When the request string is created, the programmer makes choices such as *CAT versus *BCAT when manipulating variable values.

You can definitely still mess things up. The only point I want to make is that RQSDTA() allows you to make the request string be exactly what you want for the CALL command.

The CMD() can make additional choices after you give it control. Understanding the choices made within CMD() lets you take advantage of RQSDTA().

BTW, no one was more appreciative of CMD() when it appeared than I was.

Tom Liotta