Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

Suggestions regarding a CVTDAT oversight!

Posted on 2004-03-24
4
Medium Priority
?
456 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

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

Question has a verified solution.

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

Geo-targeting is the practice of distributing content based on a person’s location, as best as you can determine it. Let’s look at some ways you could successfully use this tactic. The following tips and case studies could lead to meaningful results.
With so many activities to perform, Exchange administrators are always busy in organizations. If everything, including Exchange Servers, Outlook clients, and Office 365 accounts work without any issues, they can sit and relax. But unfortunately, it…
Video by: ITPro.TV
In this episode Don builds upon the troubleshooting techniques by demonstrating how to properly monitor a vSphere deployment to detect problems before they occur. He begins the show using tools found within the vSphere suite as ends the show demonst…
Have you created a query with information for a calendar? ... and then, abra-cadabra, the calendar is done?! I am going to show you how to make that happen. Visualize your data!  ... really see it To use the code to create a calendar from a q…
Suggested Courses

604 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