Re: decimal data error (packed field?)

["Brigitte Caura" <Caura@xxxxxxxxxxxxx>]

Hello Tim,

Be sure you have initialized the Datastructures before using them.

If for some reason that can't be fixed, this can't be done (conversion? move
of another DS?), redefine the subfield with a character field.
Then you can test if the field isn't blank. If there can be other values in
it, this becomes more complicated.
If your sure there can be alphameric values uppercase in it, but nothing
else you could test for 'subfield not blank and less then "A  "
 alternative, less than x'A000').
Not good programming practice, but this might help some conversion
problems...

If this can't be done ... you simply will get your Dec.Data error...

BTW: if you redefine a packed subfield with a character field, be sure the
characterfield is defined before the packed decimal, otherwise the
initialization of the DS will put the field to blank, after putting the
field to packed zero!

Luc

.
-----Oorspronkelijk bericht-----
Van: Pete Hall <peteh@inwave.com>
Aan: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
Datum: woensdag 28 oktober 1998 6:10
Onderwerp: Re: decimal data error (packed field?)


>At 17:47 10/27/1998 , Tim Truax wrote:
>>Hello,
>>What is the best way to test a field that is coming from a data
>>structure (field is described as  P 0001 0003 0 XAMT on the data
>>structure)?  When I access this field by doing a   Z-ADD XAMT     CAMT
>>7/0,  I am getting the DDE on this statement.
>>What is the method to use to be sure that my field has numeric integrity
>>BEFORE I do the Z-ADD to CAMT.
>>I thought about using TEST,  but this is a packed field.
>
>Tim,
>
>When I was doing conversions, I used to run into this quite a bit, although
not with packed subfileds (S/36 didn't have them). The error was usually
caused by a subfield being referenced before the structure was initialized,
usually because the first record hadn't been processed yet. Usually, I could
make the problem go away by initializing the numeric subfields in the
*INZSR. If that didn't work, then it was necessary to trace how the data was
being modified and fixing it at the source of the problem.
>
>
>
>Pete Hall
>peteh@inwave.com
>http://www.inwave.com/~peteh/
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
david@midrange.com
>+---
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---