Re: Parameters Stepping on each other

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'.

Tom, I would agree with on the points about how the SBMJOB handles the
CMD parameters. For years we did not have the CMD parameter and we had
to format our own RQSDTA. Adding the CMD parameter was a joy. 

But about the command prompter handling the formatting of a variable, I
would disagree. 

Go to the command line and type a SBMJOB and then a call and put a
variable name in the call string. Will it work. No because all the
SBMJOB command receives is a string that it validates is properly
formatted. In fact, based on how you entered, it would simply attempt to
pass it as string. 

The command processor is called no matter which way you do it and the
question is simply how could the command processor know what a variable
was, in other words, it's type and size and the value in it? There is no
way it can. It is up to the program to handling the formatting and
building of the string to pass. 

If you do a SBMJOB in an RPG program, you just building the string
manually and calling QCMDEXEC or some other API to do the work. The
QCMDEXEC has no idea what you are passing to it. It just takes the
string, writes it as a request message to the external message queue and
calls QCMD. Everything in the system works the same way. I know this
because many, many years ago I wrote a command processor program that
did just that.   

CL is nicer for doing submits because it allows to prompt the command
and build everything and then at runtime, it formats the string. In
other words, it handling the string formatting and does validation. In
RPG, you have to build the string and if you screw up, boom.

I think my point would be here. Build any type of command in a CL
program and pass a string and the same formatting rules will apply.

A good example of this is STRQMQRY and the SETVAR parameters. You have
to build the parms with quotes because CL doesn't handle them correctly.
IBM requires that the strings be pass as quoted string. I was about to
say, I don't know why but then it dawn on me. For exactly the same
reason we are talking about here. If the strings are not quoted, the CL
runtime would trim them and IBM would get garbage. Hmm, I was planning
on passing the length of my variable in the list of parameters to my
Build Call command but this might just be an easier way to do it. The CL
runtime does all the work for me and I just tack it together.  

   DCL        VAR(&QUOTE) TYPE(*CHAR) LEN(1) VALUE('''')   

   STRQMQRY   QMQRY(XV0010_QM1) OUTPUT(*PRINT) QMFORM(XV0010_QM1)
SETVAR((MACRONUM (&QUOTE || +  
                 &MACROCHAR || &QUOTE)) (MACROTYPE (&QUOTE || &MACROTYPE
|| &QUOTE)))            

Since I am using an expression when building a parm, how could the
command processor execute the expression?

With ILE what I do, almost always, is to build a CL module to do the
submit and bind it to the RPG. Then I have the power of both. The CL
module performs a single function, receives a known set of values and
returns a known result. When I write programs, all programs are named to
support multiple modules. 

XV0008     - Top level. Instructions for binding.  
XV0008_M01 - RPG module.

So program with CL module is just. 

XV0008     - Top level. Instructions for binding.
XV0008_M01 - RPG module. 
XV0008_M02 - CL module to do submit. 

Now what I will agree with is if you prompt a command, it is passed to
command validator but unless you have the variable enclosed correctly,
you will get it back as a string and it will be passed to the command
processor as a string. We have all done that. 

PARM('&VAR1 *TCAT &VAR2') vs PARM((&VAR1 *TCAT &VAR2))

In the first example, the command is going to receive '&VAR1 *TCAT
&VAR2' because the CL runtime is going to look and say, oh this is just
string. Pass it through. In the second example it will recognize the
&VAR1 and &VAR2 as variable, will substitute the value of the fields and
then apply the rules for formatting a string in CL. 

I think the bottom line here is that it is the CL runtime that is
causing the problem. It's default behavior is to trim strings. 
If I build a string in RPG and don't trim it, I will get a string this
is the length of variable. 

        CmdString = '''' + Var50 + ''''; gives me

'Value                                '

It would just be nice if IBM gave us the ability to turn off string trim
in CL.