?
Solved

Suggestions regarding a CVTDAT oversight!

Posted on 2004-03-24
4
Medium Priority
?
451 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
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 2000 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

Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

What's worse than having your data encrypted by ransomware? Getting attacked by a so-called "wiper," which simply destroys the data and offers you no hope of ever seeing it again.
Hey fellow admins! This time, I have a little fairy tale for you. As many tales do, it starts boring and then gets pretty gory. I hope you like it. TL;DR: It is about an important security matter, you should read it if you run or administer Windows …
In this video, Percona Solution Engineer Rick Golba discuss how (and why) you implement high availability in a database environment. To discuss how Percona Consulting can help with your design and architecture needs for your database and infrastr…
How to fix incompatible JVM issue while installing Eclipse While installing Eclipse in windows, got one error like above and unable to proceed with the installation. This video describes how to successfully install Eclipse. How to solve incompa…

743 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