Re:Decimal data error parameter

>Last week, I did an original program model RPG compile using V3R2..
>After tests it was determined that I needed to recompile the program
>using IGNDECERR(*YES). But, when looking at this just compiled program
>via DSPPGM, I was surprised to see that the fix decimal data parameter
>was *NO. We just applied some PTF's over the weekend and I was hoping
>that this problem would be corrected. It still doesn't correctly show
>us how the program was compiled with this parameter. Am I
>misinterpreting these parameters or is there a bug here?   ... TIA

Dave,
        That's a feature.  DSPPGM will not show you the results of a 
compilation with IGNDECERR(*NO).  

Speaking from one who is also forced to compile this way (corporate
dictum; not my idea!)  I would strongly advise you to NOT DO IT!
You will get very bad, wierd things happening: things you will not
like. 

IGNDECERR does just that: it IGNORES the fact that you have an
error.  It does NOT NOT NOT NOT set the offending field to zero.
It does NOT NOT NOT fix the number.  It ignores the error.

Check out this code.  How many messages do you think you'll
get?  Can only be one, right?

F* Test IGNDECERR                                  
F*    Guess how many messages you'll get?          
I            DS                                    
I                                        1   50CHAR
I                                        1   50NUM 
C* Load decimal data error into NUM                
C                     MOVE '$#@!*'   CHAR          
C                     MOVEL'QSYSOPR' MSGQ   10 P   
C*                                                 
C           NUM       IFEQ 0                       
C           'Zero'    DSPLYMSGQ                    
C                     ENDIF                        
C*                                                 
C           NUM       IFGT 0                       
C           'Greater' DSPLYMSGQ                    
C                     ENDIF                        
C*                                                 
C           NUM       IFLT 0                       
C           'Less'    DSPLYMSGQ                    
C                     ENDIF                        
C*                                                
C                     SETON                     LR

Compile this guy and run it.  See what I mean?
THREE messages!

The IF statements always evaluate to true when you're
comparing a decimal data error field.  I am assured by IBM
that this is NOT a bug, and that the manual should
be believed when they say unpredictable results may occur.

How to avoid these?
Define your "numeric" fields as character and TESTN them.
If valid, MOVE CHAR to NUM.  If not, Z-ADD0 to NUM and 
tell somebody that you had to do that (report, display, whatever.)

I do a lot of work converting data from PC to /400, etc. and I
run into this a lot.  It is not worth the headaches to rely on
IGNDECERR(*YES) to get by.
All my code is written this way, and the corporate dictum be
damned.  It is bad advice to allow errors to remain in your data.

Buck Calabro
Commsoft

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---