In have a printer file that looks somewhat like this:
Customer-data Units01 Units02 ....... Units11
-------------------------------------------------------------
Name/address/zip/.... Count01 Count02 ....... Count11
Name/address/zip/.... Count01 Count02 ....... Count11
: : : : : : : :
Name/address/zip/.... Count01 Count02 ....... Count11
------- ------- ------- -------
Totals Total01 Total02 ....... Total11
The Units, Count and Total fields are mapped into data structures overlayed with an array definition like this:
0014.00 D UNITSDS DS
0015.00 D UNITS01
0016.00 D UNITS02
: : :
0024.00 D UNITS10
0025.00 D UNITS11
0026.00 D UNITSAR LIKE(UNITS) DIM(11)
0026.00 D OVERLAY(UNITSDS)
: D*-------------------------------------------------------
0034.00 D COUNTDS DS
0035.00 D COUNT01
0036.00 D COUNT02
: : :
0044.00 D COUNT10
0045.00 D COUNT11
0046.00 D COUNTAR LIKE(COUNT) DIM(11)
0046.00 D OVERLAY(COUNTDS)
: D*-------------------------------------------------------
0054.00 D TOTALDS DS
0055.00 D TOTAL01
0056.00 D TOTAL02
: : :
0064.00 D TOTAL10
0065.00 D TOTAL11
0066.00 D TOTALAR LIKE(TOTAL) DIM(11)
0066.00 D OVERLAY(TOTALDS)
When I process a WRITE on the details line in the printer file after some processing I get a "Decimal data error".
I was very much surprised that it appears that the arrays COUNTAR and TOTALAR have data type "Packed" although all previous defined variables COUNT, COUNTnn, TOTAL and TOTALnn are "Zoned" and the data structures COUNTDS and TOTALDS are "Char".
Packed data was mapped in the output buffer for the printer file causing the "Decimal data error".
Why are these arrays suddenly in "Packed" data format?
Data structures all always character, since RPG doesn't have a BYTE data type.
You don't seem to be defining the subfields here, so they must be picking up there size and type from someplace else. Likely, the printer file. Has the printer file changed perhaps?
I suspect this isn't a zoned vs packed issue. But would need to see the rest of the definitions and the cross reference from the compile listing to really know what's going on.
Instead, it's likely due to the fact that the DS is not initialized.
From the manual
Since you don't have the
INZ
keyword on your DS, they are considered uninitialized and all the subfields of your DS are set to blanks. Which or course are not valid numbers.If the report normally runs ok, and prints data in all 11 columns. You could be seeing an error now if you're trying to run the report in such a way that not all 11 subfields are being loaded; thus leaving some with blanks. When the system tries to move the data to the output buffer of printer file, you get the decimal data error.
In short, add the
INZ
keyword to your DS.