If you use the Submit Job (SBMJOB) command in a CL program to submit to batch a CALL to another CL program, be aware that the SBMJOB command can corrupt the parameter data if:

the parameter data being passed is in a character variable,

the character variable is longer than 32 characters, and

the character variable ends in one or more blanks.

To try one case on for size, see Figures 1a and 1b, which list programs X and Y.

When you CALL program X from the keyboard, program Y runs in batch and sends three messages to QSYSOPR. The first one contains the letter A (plus 29 blanks), the second message contains the letter B (plus 29 blanks) but the third message contains the letter C plus a lot of garbage. The funny thing is that if you change program X so that it CALLs program Y (instead of submitting to batch), all three messages arrive clean and proper into QSYSOPR.

Editor's Note: We believe that operating systems should work in a sensible manner, without requiring the user (or programmer) to remember exceptions to the rules or strange behavior patterns that violate common sense. Therefore, we reported this as a bug to IBM Level 2 and were told, in a nutshell, that this is the way OS/400 works. They faxed us a printout of the closure of APAR SA05183, dated July 31, 1989 (someone else was bitten by the same bug, apparently). The document includes the following text:

When the CALL command is being used as the argument for the SBMJOB command, it operates as a noncompiled CALL command (interactive CALL). Therefore, the rules for passing parameters in the embedded CALL code are the same as if the CALL command is run from the Command Entry screen or the command line. These rules apply whether or not the SBMJOB command is being invoked inside the CL program, any other High Level Language program or from the command line.

The following rules apply to passing parameters if the CALL command is invoked via the SBMJOB command issued by a CL program:

Character string constants of 32 bytes or less are always passed with a length of 32 bytes (padded on the right with blanks).

Constants longer than 32 characters are not padded to the length expected by the receiving program. In this case the calling program passes the exact number of bytes.

Character strings, resulting from variables substitutions, of 32 bytes or less are passed with a length of 32 bytes (padded on the right with blanks).

If the resulting string is longer than 32 bytes, the exact number of bytes up to the last nonblank character is passed to the receiving program, not padded to the length expected by the receiving program.

Neither the variables length defined in the calling program nor the receiving program have any effect on how the parameters are passed.

Numeric variables (whether passed as constants or passed as variables declared as numerics in the calling program) are passed in packed form and with a length of (15 5). Thus, the receiving program must declare the decimal field with a length of (15 5).

These limitations are unreasonable and should be eliminated. The SBMJOB command is old and probably has undergone very little change since Release 1 of CPF, the System/38's operating system, circa 1980. We think it's time IBM made a complete overhaul of some of this ancient code.

In the meantime, we need to circumvent the problem. See Figures 2a and 2b. They implement a character string one byte longer than necessary, which we set to a nonblank character in order to force the parameter data to end in a nonblank character. Alas, there's no circumvention for numeric parameters other than passing them as character and converting them to decimal inside the submitted program. Didn't we say it stinks?

TechTalk: Nasty, Nasty, Nasty!

Figure 1A Program X

 Figure 1a: Program X X: PGM DCL VAR(&STRING) TYPE(*CHAR) LEN(90) DCL VAR(&PART1) TYPE(*CHAR) LEN(30) DCL VAR(&PART2) TYPE(*CHAR) LEN(30) DCL VAR(&PART3) TYPE(*CHAR) LEN(30) CHGVAR VAR(&PART1) + VALUE('A ') CHGVAR VAR(&PART2) + VALUE('B ') CHGVAR VAR(&PART3) + VALUE('C ') CHGVAR VAR(&STRING) VALUE(&PART1 *CAT &PART2 *CAT + &PART3) SBMJOB CMD(CALL PGM(Y) PARM(&STRING)) ENDPGM 
 
 TechTalk: Nasty, Nasty, Nasty!
 
 Figure 2A Program Y
 
 Figure 2a: Program Y Y: PGM PARM(&STRING) DCL VAR(&STRING) TYPE(*CHAR) LEN(90) DCL VAR(&PART1) TYPE(*CHAR) LEN(30) DCL VAR(&PART2) TYPE(*CHAR) LEN(30) DCL VAR(&PART3) TYPE(*CHAR) LEN(30) CHGVAR VAR(&PART1) VALUE(%SST(&STRING 1 30)) CHGVAR VAR(&PART2) VALUE(%SST(&STRING 31 30)) CHGVAR VAR(&PART3) VALUE(%SST(&STRING 61 30)) SNDMSG MSG(&PART1) TOUSR(QSYSOPR) SNDMSG MSG(&PART2) TOUSR(QSYSOPR) SNDMSG MSG(&PART3) TOUSR(QSYSOPR) ENDPGM 
 
 TechTalk: Nasty, Nasty, Nasty!
 
 Figure 2A Program X, revised
 
 Figure 2a: Program X, Revised X: PGM DCL VAR(&STRING) TYPE(*CHAR) LEN(91) DCL VAR(&PART1) TYPE(*CHAR) LEN(30) DCL VAR(&PART2) TYPE(*CHAR) LEN(30) DCL VAR(&PART3) TYPE(*CHAR) LEN(30) CHGVAR VAR(&PART1) + VALUE('A ') CHGVAR VAR(&PART2) + VALUE('B ') CHGVAR VAR(&PART3) + VALUE('C ') CHGVAR VAR(&STRING) VALUE(&PART1 *CAT &PART2 *CAT + &PART3 *CAT '*') SBMJOB CMD(CALL PGM(Y) PARM(&STRING)) ENDPGM 
 
 TechTalk: Nasty, Nasty, Nasty!
 
 Figure 2B Program Y, revised
 
 Figure 2b: Program Y, Revised Y: PGM PARM(&STRING) DCL VAR(&STRING) TYPE(*CHAR) LEN(91) DCL VAR(&PART1) TYPE(*CHAR) LEN(30) DCL VAR(&PART2) TYPE(*CHAR) LEN(30) DCL VAR(&PART3) TYPE(*CHAR) LEN(30) CHGVAR VAR(&PART1) VALUE(%SST(&STRING 1 30)) CHGVAR VAR(&PART2) VALUE(%SST(&STRING 31 30)) CHGVAR VAR(&PART3) VALUE(%SST(&STRING 61 30)) SNDMSG MSG(&PART1) TOUSR(QSYSOPR) SNDMSG MSG(&PART2) TOUSR(QSYSOPR) SNDMSG MSG(&PART3) TOUSR(QSYSOPR) ENDPGM