Re: FIXNBR(Decimal Data Error.)

"Venkatesh, Vijayendra (Cognizant)" wrote:
> 
> Hi,
> Iam using FIXNBR opcode (RPG4) on the H-spec to  ignore the invalid zoned and 
> packed values(decimal data error).
> This necesaiates the file sttructure to be defined on the I-Spec, and the 
> file has to be defined as  primary file.
> Instead of  defining the file as primary and defining that file  data fields 
> on I -Spec,Can't we define the same fields on the D-Spec and use the FIXNBR 
> opcode.

You are not required to use a primary file for FIXNBR(*INPUTPACKED) - it
works with a full-procedural file too.  But it does only apply to
I-Specs.  It is not possible to read into a data structure and then have
FIXNBR(*INPUTPACKED) apply when you use the invalid packed fields in the
DS.

In my opinion, using FIXNBR is not a good idea.  By using it, you are
ignoring all decimal data errors, not just the ones you are planning to
ignore.  I think it would be better to correct the source of the decimal
data errors.

But if you want to read your file into a data structure, it should be
possible to check the decimal fields for bad data directly by looking at
the bytes containing the values.  Or, if you are on V5R1, you could use
a MONITOR group to check your decimal fields.

Here's a procedure for checking packed data (untested).

P badPacked      B
D badPacked      PI             N
D   packedval                 16A   VARYING CONST

D                DS
D   packed                    30P 0
D   packedOver                16A   overlay(packed)
D hexZeros       S            16A   inz(*ALLX'00')

 * Copy the packed data to the end of "packed"
c           evalr   packedOver = hexZeros + packedVal
 * Test it by adding zero to it
c           eval    packed = packed + 0
 * No error occurred, so it's ok
c           return  '0'

c  *pssr    begsr
 * An error occurred, so it's not ok
c           return  '1'
c           endsr
P badPacked      E