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
LATEST COMMENTS
MC Press Online