The ability to retrieve the date of the last day of the month has been a long-standing issue with developers--years of compile-time tables with that strange number in them: 312831303130313130313031. And what happens during a leap year?

Using this kind of routine today is as reliable as using a ceramic drain tile. It'll last a while, but it's too dependent on conditions being static into the foreseeable future.

Like the PVC piping we use in our homes today, the more modern RPG constructs are designed to be easier to use and long-lasting. Today, we use the built-in operation codes and OS/400 APIs that support integrated date processing.

The built-in date operation codes that support date manipulation that I use most include the following:

• TEST--Test a field for a valid date or time value
• ADDDUR--Add a period of time to an existing date, time, or timestamp value
• SUBDUR--Subtract a period of time from an existing date or time field, or calculate the period of time between two date or time values

The EXTRCT (extract) operation code is also useful, but I rarely use it. In fact, I can only think of one instance where I used it--in the development of this issue's ENDOFMONTH procedure. The EXTRCT opcode (strangely spelled wrong on purpose by IBM) extracts a component of a date or time field. So if you need to know what the day is in a date field, you extract the day using EXTRCT.

The TEST opcode is very cool. It checks a field for a valid date or time value. The field's data type can be character, numeric, date, time, or timestamp. The TEST opcode supports several operation extenders:

• DE--Check for a valid date value
• TE--Check for a valid time value
• ZE--Check for a valid timestamp value

The DE operation extender is used when checking a non-date field for a valid date value. Also, Factor 1 of the TEST opcode must contain the format of the data in the field being tested. For example, if the value in the Result field is in MDY format, *MDY would be specified in Factor 1. Figure 1 shows the code you'd use to check a non-date field for a valid date value. Similar support is provided for time and timestamp values using the TE and ZE operation extenders.

Figure 1: Testing a non-date field for a date value

The E operation extender is all that's needed for true date or time data-type fields. Because these fields are already known to the program as date fields, you don't have to tell the TEST opcode what you're checking the fields for. Also, since the DATFMT keyword has specified the data format, specifying the format in Factor 1 would be redundant and is, therefore, not allowed. Figure 2 shows the code you'd use to check a date field for a valid date value.

Figure 2: Testing a date field for a date value

The syntax of the TEST opcode can be confusing because of a few benign restrictions placed on it. When a non-date or non-time data-type field is being tested, you must specify the corresponding D, T, or Z operation extender. This makes perfect sense. However, when you specify a true data, time, or timestamp data-type, you cannot specify the D, T, or Z operation extender--not even the correct one. So for example, Figure 3 would produce a compile-time error:

Figure 3: Invalid TEST opcode syntax

What's wrong with this picture? Nothing in my mind, but the compiler doesn't like anything specified in Factor 1 when a real date, time, or timestamp value is being tested. It also doesn't like the operation extender being specified. So only the Error extender (E) can be specified.

When I'm teaching RPG IV, I find this point always perplexes the students. Why not allow both Factor 1 and the operation extender when the Result field is a valid date, time, or timestamp field? After all, the compiler allows you to specify the length of a date field and gives you an error only if the length is wrong. You can't set the length of a data field, so specifying a length is as redundant as specifying the D operation extender. I can't explain the logic behind these requirements. It's just a fact that we have to accept.

The E operation extender is required in order to avoid using response indicators. That is, the %ERROR built-in function only reacts to opcodes that use the E operation extender (don't get me started on why I think that was a questionable design decision). So if you omit the E operation extender, %ERROR will not reflect the results of the TEST operation code.

The ADDDUR (add duration) operation code allows you to add a period of time to a date, time, or timestamp value. The period of time is specified as the duration. You specify the duration in Factor 2 followed by a duration code. The duration code tells the compiler (actually, it tells the opcode) what you're adding to the date field. Are you adding days, months, years? Whatever it is, it is specified in Factor 2 along with the duration itself.

The SUBDUR (subtract duration) operation code allows you to do either of the following:

1. Subtract a period of time from a date, time, or timestamp value. The period of time is specified as the duration. You specify the duration in Factor 2 followed by a duration code. The duration code tells the compiler what it is that is being subtracted from the field.
2. Calculate the duration between two date data-type values (date, time, or timestamp). The result is the duration between the two values and is specified in the Result field followed by the duration code. In this form of the opcode, the duration code indicates the number of days, months, years, hours, minutes, or seconds between two values. You specify which one of these you want by placing the duration code adjacent to the field name in the Result field.

One of the greatest things that SUBDUR does is calculate the number of days between two date values. Just this one, accurate feature provides a level of productivity that I would have loved to see back in the early days of RPG III.

Duration codes are, for the most part, self-explanatory and include those shown in Figure 4:

Figure 4: ADDDUR and SUBDUR duration codes

Either form of the duration code may be specified for the ADDDUR and SUBDUR operation codes. Please note that, unlike *ZERO and *ZEROS or *BLANK and *BLANKS, only the singular form of the duration codes is provided.

ENDOFMONTH Procedure

To illustrate the use of all these integrated date and time operation codes, I came up with a procedure that performs an important task. I've always needed the ability to calculate the last day of the month, given the current date. The ENDOFMONTH procedure does just that. Given a date as input, ENDOFMONTH calculates the last date of the month for the input date.

end-of-month = EndOfMonth( myDate )

The ENDOFMONTH procedure accepts any valid date value or field as input (in any date format). The return value is a valid date value (*ISO format) that may be assigned to any date data-type variable (in any date format). The return value is the date of the end of the month calculated by the input date.

For example, if the input date is January 29, 2002, the date that is returned will be January 31, 2002. Figure 5 contains the source code for the ENDOFMONTH procedure. Figure 6 shows the ENDOFMONTH procedure prototype. As always, you can look for updates or fixes to this or any other source I've published in Midrange Developer by viewing the related discussion forum for any given article.

Figure 5: ENDOFMONTH Procedure Implementation

Figure 6: ENDOFMONTH Procedure Prototype