Re: *INPUTPACKED ignored for arrays ?

["Timothy Adair" <tadair@xxxxxxxxxxxxxxxx>]

Thanks for the reply.  I definitely need to clean up the data but right now 
it's more important to come up with a viable solution to this type of 
problem.  I have hundreds of old QS36F files, many which have blanks in 
numeric fields (some of them packed).

BTW, is it possible to have a trigger on an old program-described file? 
I've never tried that.




"Raul A. Jager W." <raul@xxxxxxxxxx> wrote in message 
news:mailman.23757.1271718392.2580.rpg400-l@xxxxxxxxxxxxxxx
I sugest a two step solution:

1- Wite a program using the file as Update Primary, compare each record
with blanks (or each element) and move paked zeros in place.

2- Write a trigger that does the same.


1 will rapidly clean your file, 2 will keep it clean.

Raúl
__________________________________________________________
Timothy Adair wrote:
> I have an RPG IV pgm (not ILE) that is reading in an old QS36F
> program-described file.  This file has a "field" that is actually a
> 30-element packed numeric array (7,0).  For records with valid data in 
> this
> array, everything is fine; but I have some records with spaces (hex
> '4040404') in this array, and when it hits one of these, the program gives 
> a
> decimal-data error (understandably so).
>
> I have specified the compile option of FIXNBR(*INPUTPACKED) but the 
> program
> is not fixing the data at input-time.  Does *INPUTPACKED not work for 
> input
> arrays?  It seems to work for single fields.
>
> And yes, I know, I need to fix the data.  I intend to but that doesn't
> guarantee I won't encounter more of these in this file (or other files).
> I'd like to nail down a viable solution now.  We will be converting to
> externally-described files eventually but for now this is the situation I
> have to deal with.
>
> And yes, I have tried every conceivable combination of overlays & arrays 
> to
> program around the problem.  Every attempt either wouldn't compile, or 
> gave
> the DD error when run.