A Bevy of BIFs: Dealing with a Bad Date
April 15, 2009 Susan Gantner
In an earlier tip, I talked about how %Date simplifies our logic by converting our “date” values stored in numeric or character fields into true dates. In that tip, I mentioned that using %Date could potentially result in an error message in the event your “date-like” fields contain an invalid date value, such as zero or blank or a month value of 25.
Here I’ll cover how to avoid getting run time errors due to bad date values. Since many of the “date-like” fields we deal with in our applications come from screens, database fields, HTML or XML documents, etc., converting them to date fields safely can be problematic.
There are two primary ways to avoid run time errors due to bad date values. You can either test the value before you attempt to convert it, or you can monitor for an error condition and deal with it if it occurs. Both are relatively simple to do. Choosing between those two options depends on whether you are optimistic or pessimistic about the chances of the field values in question being valid.
If you think most of the date-like fields you will process are likely to contain valid values the majority of the time, then your best choice may be to use the optimistic approach of monitoring for bad values. That way, your program doesn’t run any “extra” logic to test the contents of the field. It only runs the extra logic if and when the data is found to be bad. With the pessimistic approach, your program needs to run the testing logic for every field every time, which will be slower, especially in cases where only a small portion of the data is bad. But I suspect it’s the approach most RPGers would think of using first.
Let’s be pessimistic in our first example. We’re assuming that a high proportion of input dates will be bad, so we’ll test them using RPG’s TEST operation code. When using it with dates, we need two operation code extenders: “D” to specify that it’s a date value we’re testing for and “E” to specify that we’ll use %Error to determine the result of the test. “Factor 1” contains the format the data in the “date-like” field is expected to be and “Result” contains the field being tested. (If you’re not coding in /Free, you should note that there is no Factor 2.) The code looks something like this:
Test(DE)*YMD Number; If %Error; If Number = 0; OutputAge = 'Unknown'; Else; OutputAge = 'Error'; EndIf; Else; OutputAge = %Char(%Diff( %Date() : %Date(Number:*YMD) : *Years)); EndIf;
Now for the optimistic approach. Using MONITOR, I’ll simply run the logic I need to run to do the date calculation. If my optimism is well founded, most of the time the calculation will run without error and without any pre-testing of the field value. I’ll monitor for the exceptional cases by comparing to a status code that means a bad date value was encountered. That status code happens to be 112. (You can find status code values in the ILE RPG Reference manual in Chapter 5.) In this example, I’m including a D spec that defines the named constant that I’m referencing in the On-Error statement. I could have simply coded the value 112 in the logic, but I don’t want programmers coming after me needing to look up what “112” means!
D BadDateValue C 112 Monitor; OutputAge = %Char(%Diff( %Date() : %Date(Number:*YMD) : *Years)); On-error BadDateValue; If Number = 0; OutputAge = 'Unknown'; Else; OutputAge = 'Error'; EndIf; EndMon;
So, that’s how you can deal with bad dates in your RPG code. Wouldn’t it be nice if dealing with bad dates in real life were as simple?
Susan Gantner is one of the most respected System i gurus in the world and is one of the co-founders of System i Developer, an organization dedicated to RPG, DB2, and other relevant software technologies for the System i platform that hosts the new RPG & DB2 Summit conference. Gantner, who has worked in IBM’s Rochester and Toronto labs, left IBM to focus on training OS/400 and i5/OS shops on the latest programming technologies. She is also a regular speaker at COMMON and other user groups. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page.