my *DEC parameter is not passing value correctly

[CarrieGig]

I have a two digit company number 07 that when moved from the CHAR to the DEC changes to 7 and that is then passed to the RPGLE but the value is 00

DCL VAR(&COMPA) TYPE(*CHAR) LEN(2)
DCL VAR(&ORD) TYPE(*CHAR) LEN(7)
DCL VAR(&COMPN) TYPE(*DEC) LEN(2 0)

CHGVAR VAR(&COMPN) VALUE(&COMPA)

SBMJOB CMD(CALL PGM(SL_CRTPOR) PARM(&COMPN &ORD)) +
JOB(KFTAUTOPO) LOG(4 0 *SECLVL) LOGCLPGM(*YES)

from the CL dump:
&COMPA *CHAR 2 '07'
&COMPN *DEC 2 0 7
&ORD *CHAR 7 '7000178'

from the RPGLE dump:
NAME ATTRIBUTES VALUE
_QRNL_PRMCPY_#PCOMP POINTER SPP:E49EE3BEF2001646
_QRNL_PRMCPY_#PORDNO POINTER SPP:E49EE3BEF200164E
_QRNL_PSTR_#PCOMP POINTER SPP:E49EE3BEF2001646
_QRNL_PSTR_#PORDNO POINTER SPP:E49EE3BEF200164E
#PCOMP PACKED(2,0) 00. '0000'X
#PORDNO CHAR(7) '7000178' 'F7F0F0F0F1F7F8'X

[Scott Klement]

Here's the thing... the SBMJOB command causes the CALL command to run in a completely separate job, it no longer has any connection to your CL program.

The CALL command in the new job doesn't know that your CL variable from the calling program was 2,0 -- it has no way to know what you INTENDED to do. All it knows, in the new job, is that you're passing a value of 7. The CALL command also doesn't know what parameters the program its calling is expecting. All it knows is that you told it to pass the number 7.

The way the CALL command works (this is true from the command-line as well, where you type CALL manually) is that all numbers are passed as a 15,5 packed value. So it is building a 15,5 packed field, putting the 7 into it, and passing that to the RPG program.

under the covers, a 15,5 packed containing the number 7 would be x'000000000700000F'. The RPG program is attempting to receive that into a PACKED(2, 0) -- so it is only looking at the first 2 bytes, which are x'0000' and ignoring the rest.

IMHO, the best solutiion is to create a *CMD object, and submit that. A *CMD object can configure the parameter as a packed(2, 0), so you don't have to rely on the CALL command's behavior of treating it as a 15,5

Of course, another alternate would be to change the RPG program to accept a 15,5, or write a CL program that receives a 15, 5, then converts it to 2,0 and calls the RPG, or anything else like that.

[CarrieGig]

Scott, thank you for you explanation, it makes so much more sense to me than how IBM explains it in manuals... I'll give the *CMD thing a try, because the RPG is already in use and called elsewhere so I can't change its parameters.

[CarrieGig]

Again thanks! changing the SBMJOB to call the Command instead of the program has been a success!
/* SBMJOB CMD(CALL PGM(SL_CRTPOR) PARM(&COMPN &ORD)) +
JOB(KFTAUTOPO) LOG(4 0 *SECLVL) LOGCLPGM(*YES) **/
SBMJOB CMD(AUTOPO COMPN(&COMPN) ORD#(&ORD)) +
JOB(KFTAUTOPO) LOG(4 0 *SECLVL) +
LOGCLPGM(*YES)