Suggestions regarding a CVTDAT oversight!

We have a canned manufacturing package where users often requests reports via Date Ranges.  The way the dates are validated are by using the CVTDAT command from within CL.  We just experienced a flaw in the logic where it will allow an improper date range due to the CVTDAT logic.  Here is the senerio:

On the Report Submit screen, the user mis-keyed the following:
Beg Date: 02/22/40
End Date: 03/27/04

In the Validate CL:
0071.00 /* Validate Dates If Not Zero */                                        
0072.00                                                                        
0073.00              IF         COND(&#BIVDT *NE 0) THEN(DO)                    
0074.00                         CHGVAR     VAR(&BDATEA)  VALUE(&#BIVDT)        
0075.00              CVTDAT     DATE(&BDATEA) TOVAR(&BYYMD) FROMFMT(*MDY) +    
0076.00                           TOFMT(*YYMD) TOSEP(*NONE)                    
0077.00                         MONMSG     MSGID(CPF0000) EXEC(DO)              
0078.00                                    CHGVAR     VAR(&IN61) VALUE('1')    
0079.00                                    GOTO       CMDLBL($TGERR)            
0080.00                         ENDDO                                          
0081.00              ENDDO                                                      
0082.00                                                                        
0083.00              IF         COND(&#EIVDT *NE 0) THEN(DO)                    
0084.00                         CHGVAR     VAR(&EDATEA)  VALUE(&#EIVDT)        
0085.00              CVTDAT     DATE(&EDATEA) TOVAR(&EYYMD) FROMFMT(*MDY) +    
0086.00                           TOFMT(*YYMD) TOSEP(*NONE)                    
0087.00                         MONMSG     MSGID(CPF0000) EXEC(DO)              
0088.00                                    CHGVAR     VAR(&IN62) VALUE('1')    
0089.00                                    GOTO       CMDLBL($TGERR)            
0090.00                         ENDDO                                          
0091.00              ENDDO                                                      
0092.00                                                                        
0093.00 /* Validate Date Range  */                                              
0094.00                                                                        
0095.00              IF         COND(&BYYMD *GT &EYYMD) THEN(DO)                
0096.00                         CHGVAR     VAR(&IN63) VALUE('1')                
0097.00                         GOTO       CMDLBL($TGERR)                      
0098.00              ENDDO

The Problem:
The CVTDAT command converts the Beg Date to (19400222) and the End Date to (200402327) which allows the dates to pass and then the RPG program bombs out because the buckets are not big enough to handle the calculations.

This logic is throughout our entire system.  Does anyone have a suggestion to correct this problem other than modifying every CL that validates dates submitted for reports?  There are many!  Any input would be appreciated!
Regards ... sulzener
sulzenerAsked:
Who is Participating?
 
TgerdesConnect With a Mentor Commented:
One way to get past this problem is to create your own CVTDAT command processing program!  

1. first do this comand DSPCMD CVTDAT and find out what the name of the program is that is run when the command is used!

2. Create your own program that is called when the CVTDAT command is executed.  In your new program edit the input for invalid date range and send a warning back to the user!  Or better yet just fix the date to a range that you will accept!
0
 
daveslaterCommented:
Hi
if you need to do in Cl  yot could perfoem a sinsible test like

 PGM                                                                          
              DCL        VAR(&BYYMD) TYPE(*CHAR) LEN(8)
              DCL        VAR(&EYYMD) TYPE(*CHAR) LEN(8)
                                                                             
              DCL        VAR(&FYEAR) TYPE(*DEC) LEN(4 0)                      
              DCL        VAR(&TYEAR) TYPE(*DEC) LEN(4 0)                      
              DCL        VAR(&DIFF) TYPE(*DEC) LEN(4 0)                      
 /* EXTRACT YEAR FROM DATES IN NUMERIC FORMAT */                              
              CHGVAR     VAR(&FYEAR) VALUE(%SST(&BYYMD 1 4))                  
              CHGVAR     VAR(&TYEAR) VALUE(%SST(&EYYMD 1 4))                  
 /* CALULATE DIFFERENCE */                                                    
              CHGVAR     VAR(&DIFF) VALUE(&TYEAR - &FYEAR)                    
 /* REPORT ERROR IF MOR THAN 2 YEARS */                                      
              IF         COND(&DIFF *GT 2) THEN(DO)                          
              CHGVAR     VAR(&IN63) VALUE('1')                                
              RETURN                                                          
              ENDDO                                                          
 ENDPGM                                                                      


Dave
0
 
sulzenerAuthor Commented:
Thanks tgerdes.  That sounds like the only way to approach it in order not to modify all programs.
0
 
tliottaCommented:
One minor variation... rather than creating a replacement command-processing program, create a validity checking program. Leave the command processor in place. And don't forget to verify that the validity checking program is still in place after OS/400 upgrades (or PTFs that affect the CVTDAT command).

An added library in the system portion of the library list could be best for this. Create a duplicate of CVTDAT into the new library and add the validity checker to the duplicate. This can also avoid any potential problems with either IBM or 3rd-party programs that qualify QSYS/CVTDAT and expect to execute an unmodified version of the command.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.