Re: Parameters Stepping on each other

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. 

 

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 

 

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

 

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.