RE: Parameters Stepping on each other

rpg400-l-request@xxxxxxxxxxxx wrote:

  6. Re: Parameters Stepping on each other (Alan G. Campin)

It isn't CL programs it's the SBMJOB CMD() parameter being used to

submit a CALL command. It's irrelevant what language is used to execute
SBMJOB. The >> CMD() parameter was added to the SBMJOB command to make
it easier to prompt a SBMJOB command in a command-line environment. In a
compiled program, the >> CMD() parm may be inappropriate.

Actually, it is the CL runtime that is causing the problem. SBMJOB know
nothing of variables. The CL runtime evaluates the variables and as part
of that it trims the string to eliminate blanks. It then runs the
command with the formatted string. 

Alan:

I'm no expert on the internals of SBMJOB. I've posted on this issue a number of 
times hoping that someone with _real_ info can correct what I assert or verify 
it. Maybe this time...

Because SBMJOB is a CL command, there is a valid technical foundation for 
speaking of the CL runtime. Maybe that's what you mean by "CL runtime". 
However, the SBMJOB command being executed in an ILE RPG program will give the 
same result as the same command string in an OPM CL program. It has nothing to 
do with whether or not the CL program is trimming blanks. It is the command 
prompter/analyzer (or whatever component) that gets invoked by using the CMD() 
parm that causes the 'problem'.

The CMD() parm value is not what gets submitted. The CMD() parm value is 
formatted internally within SBMJOB, and that formatted value is used to supply 
the RQSDTA() value. Eventually, the RQSDTA() value is what gets submitted. 
(AFAIK, "submitted" means that the RQSDTA() value gets written as a *RQS 
message on to a special kind of message queue that's known as a "job queue".)

Because of the formatting between CMD() and RQSDTA(), it doesn't matter whether 
trimming happens in a CL program. 

It is the processing inside of SBMJOB for the CMD() parm itself that does it. 
As long as CMD() is used, it doesn't matter whether trailing blanks are 
included withing the CMD() command string.

It occurred to me that a simple solution for this would be for IBM to
give us a command that could only be executed in a program and would
have no parameters. It would simply say "Turn Off String Trim".

On the next command, which I assume would be a SBMJOB, it would look at
flag to know if to should keep the string at there full length instead
of trimming and then would turn it back on. 

TRNOFFTRM

SBMJOB 

Keep in mind that a lot more than trimming blanks can happen. Escaping quotes 
can happen. Parameter dependencies can be checked. Essentially everything that 
the command prompter at a command line can do happens, even in RPG. If you turn 
it off, then you're right back to where it all started -- the RQSDTA() 
parameter. Turning it off is no different from just putting the string into 
RQSDTA() in the first place.

With trim on and a 50 byte variable with 10 characters you would get:

SBMJOB CMD(CALL PGM(XYZ) PARM('YYYYYYYYYY'))

With trim off:

SBMJOB CMD(CALL PGM(XYZ) PARM('YYYYYYYYYY
'))

And that's what happens when you use RQSDTA():

 SBMJOB RQSDTA('CALL PGM(XYZ) 
PARM(''YYYYYYYYYYbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb'')')

Of course, that's a direct string. The string could be built in a variable and 
the blanks would still be preserved as long as the quotes are in the variable.

As an alternative, I was thinking of just creating a command called
BLDCALSTR (Build Call String) that would except the program name and a
list of parameters and would return a formatted call string with the
values the length of the actual data rather than the trimmed length.
Maybe something to do this weekend. 

And if you place that string into RQSDTA(), it'll work just as the SBMJOB 
command was designed to work. Just handle quotes and numerics properly. You can 
use pretty much any definition of numeric parms that you wish; they don't need 
to be (15 5) as long as you format the RQSDTA() string correctly.

It'd probably be a very useful ILE RPG procedure (to keep us on-topic in this 
list.)

Tom Liotta