From: Tim Phinney To: All

I feel like I have a large barrier between the S/36E and native, namely decimal data errors. There are times when I must use numeric fields for passing data. Because of the zoned decimal vs. packed numeric fields difference, I have to be very careful when mixing and matching RPG36 and RPG programs. I now have a CL program which dies due to decimal data error when I try to pass a numeric parameter (my machine starts up in S/36E).

Can anyone give me some guidelines/suggestions of what to do and what not to do?

From: Ernie Malaga To: Tim Phinney

You may have heard this suggestion before, but here goes. If RPG36 program A needs to pass a numeric parameter to CL program B, have A move the numeric value to a character field. Then pass the character field to the CL program. The CL program can then move it to a decimal variable and use it as a numeric value. The code can be seen in Figures 7 and 8 (page 104).

The beauty of this solution is that it always works, no matter what languages you use between the S/36E and native.

TechTalk: Decimal Data Errors

Figure 7 RPG36 Program A

 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 C Z-ADD75 NUM 70 C MOVELNUM NUM@ 7 C CALL 'B' C PARM NUM@ ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 
 
 TechTalk: Decimal Data Errors
 
 Figure 8 CL Program
 
 B B: PGM PARM(&NUM-CHAR) DCL VAR(&NUM-CHAR) TYPE(*CHAR) LEN(7) DCL VAR(&NUM) TYPE(*DEC) LEN(7 0) CHGVAR VAR(&NUM) VALUE(&NUM-CHAR) : : ENDPGM