Solved

Suggestions regarding a CVTDAT oversight!

Posted on 2004-03-24
4
429 Views
Last Modified: 2008-02-01
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
0
Comment
Question by:sulzener
4 Comments
 
LVL 14

Expert Comment

by:daveslater
ID: 10675297
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
 
LVL 1

Accepted Solution

by:
Tgerdes earned 500 total points
ID: 10707874
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
 

Author Comment

by:sulzener
ID: 10724213
Thanks tgerdes.  That sounds like the only way to approach it in order not to modify all programs.
0
 
LVL 27

Expert Comment

by:tliotta
ID: 10737814
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

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

Suggested Solutions

Performance in games development is paramount: every microsecond counts to be able to do everything in less than 33ms (aiming at 16ms). C# foreach statement is one of the worst performance killers, and here I explain why.
We have come a long way with backup and data protection — from backing up to floppies, external drives, CDs, Blu-ray, flash drives, SSD drives, and now to the cloud.
Internet Business Fax to Email Made Easy - With eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, fr…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now