Look at the two programs in Figures 7 and 8. At first glance, you would think that PGM2 would have the following two parameter values: &X (containing the value 'FIRST' followed by trailing blanks) and &Y (containing the value 'SECOND' followed by trailing blanks). Wrong?&X and &Y will contain a mess!

Usually, when a program calls another program directly, the system passes character parameters by address. This allows the called program to access the same data passed by the calling program. However, when a program submits another one to batch, the system makes a copy of the parameters. Unfortunately, this copy contains only the used part of the parameters or the first 33 bytes, whichever is less. Past that point, the results are very unpredictable. This area usually contains hexadecimal garbage.

To avoid this problem, I usually declare the parameter variables in the calling program one character longer than in the called program and put a nonblank character in the last position. For example, in PGM1, this is what I would code:

 DCL VAR(&A) TYPE(*CHAR) LEN(501) CHGVAR VAR(%SST(&A 501 1)) + VALUE('.') 

As a result, the system is forced to make a copy of the whole variable. There is no problem if a character parameter is defined longer in the calling program than in the called program. This solves the problem by ensuring that the correct data is passed between the two programs.

? Sorin Caraiani

TechTalk: Passing Parameters to a Batch Job

Figure 7: Program PGM1

 PGM DCL VAR(&A) TYPE(*CHAR) LEN(500) DCL VAR(&B) TYPE(*CHAR) LEN(500) CHGVAR VAR(&A) VALUE('FIRST') CHGVAR VAR(&B) VALUE('SECOND') SBMJOB CMD(CALL PGM(PGM1) PARM(&A &B)) ENDPGM 
 
TechTalk: Passing Parameters to a Batch Job
 
Figure 8: Program PGM2
 
 PGM PARM(&X &Y) DCL VAR(&X) TYPE(*CHAR) LEN(500) DCL VAR(&Y) TYPE(*CHAR) LEN(500) . . . ENDPGM