13
Fri, Dec
4 New Articles

An Introduction to ILE RPG: Part 5

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Brief: In our final installment of this introductory ILE RPG series, we examine the support for date data types. ILE RPG can define date, time and timestamp fields corresponding with the DDS support for these data types. It also provides support for date arithmetic, conversion from one date type to another, and conversion to and from numeric and character fields.

Last month we saw the introduction of built-in functions, which can substantially reduce program development and maintenance time, in some cases reducing complex routines or called programs in RPG/400 to a single line of code in ILE RPG.

In this article, we look at one of the most exciting features of ILE RPG- support for date data types. Date data types have been available on the AS/400 since V2R2; but because they cannot be directly processed in RPG/400, their usefulness has been limited. ILE RPG provides full support for date data types and date arithmetic. This support makes it easy to calculate the difference between two dates or to increment a date by a number of days, taking into account the varying number of days in each month. For example, 1992 is a leap year. If you add 30 days to January 31, 1992, ILE RPG correctly calculates the result as March 1, 1992; if you add 30 days to January 31, 1993, the result is March 2, 1993.

The "Date, Time and Timestamp Data Types" sidebar (page 100) covers the possible formats for date fields in OS/400. Within ILE RPG, you can define fields or constants as date (D), time (T) or timestamp (Z) data types. For the rest of this article, we'll refer to such fields generically as date fields unless an example specifically applies to time or timestamp fields. The length of a date field is determined by the data type and the date format-it should not be coded as part of the definition.

The default format for date fields in an ILE RPG program can be specified in the Header specification (H-spec) using the DATFMT and TIMFMT keywords. (For more information on H-spec keywords, see "An Introduction to ILE: Part 1," MC, March 1994.) If these keywords are not used, the default format is International Standards Organization (*ISO) format.

Date Field Definitions

1 shows samples of defining date and time fields with initialized values. Since no H-spec exists in the program, date fields that do not include a DATFMT or TIMFMT keyword default to *ISO format; and the *ISO format must be used to initialize all date fields regardless of their format.

Figure 1 shows samples of defining date and time fields with initialized values. Since no H-spec exists in the program, date fields that do not include a DATFMT or TIMFMT keyword default to *ISO format; and the *ISO format must be used to initialize all date fields regardless of their format.

In the first example in 1, the D in position 40 defines the field eur_date as a date field. Since *EUR is specified for the DATFMT keyword, the date is internally represented in IBM European Standard format (i.e., dd.mm.yyyy) and is automatically defined as 10 characters in length. The INZ parameter initializes the field to 16.12.1994 (December 16, 1994). Even though the field eur_date is defined as a *EUR format date field, the value on the INZ parameter must be in *ISO format (i.e., 1994-12-16). Several other examples of date field definitions are included in 1.

In the first example in Figure 1, the D in position 40 defines the field eur_date as a date field. Since *EUR is specified for the DATFMT keyword, the date is internally represented in IBM European Standard format (i.e., dd.mm.yyyy) and is automatically defined as 10 characters in length. The INZ parameter initializes the field to 16.12.1994 (December 16, 1994). Even though the field eur_date is defined as a *EUR format date field, the value on the INZ parameter must be in *ISO format (i.e., 1994-12-16). Several other examples of date field definitions are included in Figure 1.

The T in position 40 defines the field hms_time as a time field. Since *HMS is specified for the TIMFMT keyword, the time is internally represented in Hours:Minutes:Seconds format (i.e., hh.mm.ss). The INZ parameter initializes the field to 30 seconds after 6:06 p.m. In a similar manner, the field usa_time is defined as a *USA format time field with an implied length of eight. While the internal format of this field is hh:mm AM or hh:mm PM, the value on the INZ parameter must be in *ISO format (i.e., hh.mm.ss).

Literals cannot be specified in a date format different from the default for the program. Therefore, the value for all date and time literals must be represented in the format specified in the H-spec or *ISO format if no format is specified. Date literals should be prefixed by D, T and Z for date, time and timestamp values. Using the *ISO format, D'1994-12-16' defines a date literal with a length of 10 and a value of December 16, 1994. T'18.06.30' defines a time literal with a length of eight and a value of 30 seconds after 6:06 p.m. Z'1994-12-16-18.06.30' defines a timestamp literal with a length of 26 and a value of 30 seconds after 6:06 p.m. on December 16, 1994. (If the microseconds portion of a timestamp literal is not specified, it defaults to '000000' and its length remains 26).

2 shows another sample of defining date and time fields with initialized values. In this sample, a DATFMT of *USA and TIMFMT of *HMS are specified on the H-spec.

Figure 2 shows another sample of defining date and time fields with initialized values. In this sample, a DATFMT of *USA and TIMFMT of *HMS are specified on the H-spec.

As in the prior sample, the field eur_date is defined as a 10-character, *EUR- format (dd.mm.yyyy) date field. But this time the initialization value must be provided in *USA format (mm/dd/yyyy) because of the DATFMT keyword specified in the H-spec.

When the LIKE keyword is used, the DATFMT and TIMFMT keywords are not allowed. The field eur_date2 is defined as a 10-character, *EUR-format (dd.mm.yyyy) date field that takes its format (but not its value) from the field eur_date.

The field usa_date is defined as an eight-character, *USA-format date field with a format of *USA&. The ampersand (&) changes the default separator character from a slash (/) to a blank. The value of the field usa_date will be 12 16 1994, while the value of the field usa_date2 will be 12/16/1994.

Default Values

We've already shown how date fields can be initialized to a specific value using the INZ keyword in the D-specs. You can also initialize a date field using the CLEAR operation code in the C-specs. The default initialization and CLEAR value is not all zeros, as might be expected. For date fields, the default value is January 1, 0001; for time fields, the default value is midnight; and for timestamp fields, the default value is midnight on January 1, 0001. In all cases, the format includes separator characters and is based on the DATFMT and TIMFMT parameters or the default *ISO format. If the DATFMT and TIMFMT keywords are not specified in either the H-spec or the D-spec, the cleared value of a date field is 0001-01-01; the cleared value of a time field is 00.00.00; and the cleared value of a timestamp field is 0001-01-01- 00.00.00.000000. The value set by *LOVAL is the same as the CLEAR value.

The value set by *HIVAL is December 31, 9999 for a date field, one second before midnight (23.59.59) for a time field, and one microsecond before midnight on December 31, 9999 for a timestamp field (9999-12-31- 23.59.59.999999).

Comparing Date Fields

Date data types can be used in factor 1 and factor 2 for many ILE RPG operation codes. As with other types of fields, you can compare date fields only if they have the same data type-date, time or timestamp. ILE RPG will automatically handle different formats-an *ISO-format time field with a value of 15.30.00 will compare equal to a *USA-format time field with a value of 03:30 PM. In the same respect, a *MDY-format date field with a value of 12/16/94 will compare equal to a *YMD-format date field with a value of 94/12/16.

Date Arithmetic

Arithmetic operations are where the new date data types really shine. Many RPG/400 programs use a complex subroutine that accounts for leap years and the varying number of days in each month to calculate the difference between two dates or to increment a date by a specific number of days. You can get the same results with much less effort using date fields and several new operation codes.

The Add Duration (ADDDUR) operation code can be used to add a duration to a date, time or timestamp field, resulting in a field of the same type. Factor 1 is optional and, if not specified, defaults to the result field. Factor 1 and the result field must be the same data type.

Factor 2 is required and contains two parts separated by a colon (:). The first part must be a numeric field, array element or constant with zero decimal positions. The second part is a code indicating the type of duration. The duration code must be valid for the data type of the field specified in the result field. For example, you cannot add a minute duration to a date type field.

The valid duration codes are *YEARS or *Y; *MONTHS or *M; *DAYS or *D; *HOURS or *H; *MINUTES or *MN; *SECONDS or *S; and *MSECONDS or *MS.

An error indicator can be specified in the less-than columns (73-74). The value of the result field remains unchanged and this indicator is set on if:

o The date, time or timestamp field in factor 1 contains invalid data. o Factor 1 is not specified and the date, time or timestamp field in the result field contains invalid data. o The result of the operation is invalid.

3 shows some samples of using the ADDDUR operation code. Since no H-spec is present, all date and time values are specified in *ISO format.

Figure 3 shows some samples of using the ADDDUR operation code. Since no H-spec is present, all date and time values are specified in *ISO format.

The first C-spec adds 30 days to the field start_date and stores the result in the field end_date. Both start_date and end_date are defined as date fields with an *ISO format and an implied length of 10. Since the field start_date is initialized to 1994-12-16, the field end_date will have a value of 1995-01-15 after execution of the ADDDUR operation code. If an error occurs, indicator 50 will be turned on. Indicator 50 will be turned off if no error occurs.

In the second sample in 3, one month is being added to the *USA format date field month_end. The field month_end is initialized to a value of 10/31/1994 in D-specs. Adding one month to the month portion of this date would result in an invalid date of 11/31/1994; but the result of the ADDDUR operation is automatically adjusted to the last valid day of the month. The field month_end will have the value 11/30/1994 after execution of the ADDDUR operation code.

In the second sample in Figure 3, one month is being added to the *USA format date field month_end. The field month_end is initialized to a value of 10/31/1994 in D-specs. Adding one month to the month portion of this date would result in an invalid date of 11/31/1994; but the result of the ADDDUR operation is automatically adjusted to the last valid day of the month. The field month_end will have the value 11/30/1994 after execution of the ADDDUR operation code.

In the next example, one year is added to the field employ_dat and the result is stored in the field anniv_dat. The field employ_dat is initialized to a value of 02/29/1992 in D-specs. Adding one year to this date without any adjustment would result in an invalid date of 02/29/1993 since 1993 is not a leap year; but the result of the ADDDUR operation is again automatically adjusted to the last valid day of the month. The field anniv_dat will have the value 02/28/1993 after execution of the ADDDUR operation code.

The next sample demonstrates the use of the ADDDUR operation code with time fields. The first calculation adds three hours to the literal in factor 1, which is set to midnight. The time constant is expressed in *ISO format using a period (.) as a separator character even though the result field end_time is defined in *HMS format using a colon (:) as a separator character. The next two lines of code add 22 minutes and 50 seconds to end_time, giving a result of 03:22:50.

The Subtract Duration (SUBDUR) operation code follows the same rules as ADDDUR to subtract durations from date fields. The result field is required and must be the same data type as factor 1 if factor 1 is specified. Several examples are shown in 4.

The Subtract Duration (SUBDUR) operation code follows the same rules as ADDDUR to subtract durations from date fields. The result field is required and must be the same data type as factor 1 if factor 1 is specified. Several examples are shown in Figure 4.

The SUBDUR operation can also be used to calculate the duration (or difference) between:

o Two dates. o A date and a timestamp. o Two times. o A time and a timestamp. o Two timestamps.

When calculating a duration, both factor 1 and factor 2 must be specified and must contain the same or compatible data types. A date and a timestamp are compatible as are a time and a timestamp. However, ILE RPG will handle any conversion between date or time formats (i.e., a *USA date subtracted from a *ISO date). The result field is also required and contains two parts. The first must be a numeric field, array element or constant with zero decimal positions in which the result will be placed. The second is separated from the first by a colon (:) and must be a valid duration code indicating the type of duration. The result will be negative if the date or time in factor 1 is earlier than the date or time in factor 2.

4 shows some samples of using the SUBDUR operation code. Since DATFMT(*USA) is specified on the H-spec, all date literals must be provided in *USA format. Because TIMFMT(*HMS) is also specified, all time literals must be provided in *HMS format.

Figure 4 shows some samples of using the SUBDUR operation code. Since DATFMT(*USA) is specified on the H-spec, all date literals must be provided in *USA format. Because TIMFMT(*HMS) is also specified, all time literals must be provided in *HMS format.

The first three examples are very similar to the examples for ADDDUR in the previous section. A duration is subtracted from a date, resulting in a new date; if necessary, ILE RPG automatically adjusts the result to a valid date, taking into account leap year and the number of days in each month.

The fourth sample demonstrates the use of the SUBDUR operation code with timestamp fields to determine the difference between two timestamp values. The field start_time is defined as a timestamp field with a value of 1994-05-12- 02.59.40, and the field end_time is defined as a timestamp field with a value of 1994-05-12-03.22.50. Micro-seconds default to all zeros. Since the duration code *SECS is specified on the result field, the field num_sec will have a value of 1,390 seconds after execution of the SUBDUR operation code.

In the last sample, the date field loan_date, which has a value of 12/16/1993, is subtracted from the date field due_date, which has a value of 12/16/2008. Since the duration code *M (months) is specified on the result field, the field num_mon will have a value of 180 months.

EXTRCT Operation Code

The Extract (EXTRCT) operation code can be used to extract a portion of a date field. Factor 1 must be blank. Factor 2 is required and contains two parts separated by a colon (:). The first part must be a date, time or timestamp field. The second part must be a duration code that is valid for the data type of the field specified in the first part of factor 2. For example, you can extract hours from a time or timestamp field but not from a date field.

The result field may be a numeric or character field. Before the EXTRCT operation is executed, the result field is cleared. Numeric result fields are right-justified while character result fields are left-justified.

The first three samples in 5 extract information from the field due_date which is defined as an *ISO format date field and initialized to 2008-12-16. The month is extracted into the character field char_month with a result of '12'. The day is extracted into the character field char_day with a result of '16'. The year is extracted into the numeric field num_year with a result of 1994.

The first three samples in Figure 5 extract information from the field due_date which is defined as an *ISO format date field and initialized to 2008-12-16. The month is extracted into the character field char_month with a result of '12'. The day is extracted into the character field char_day with a result of '16'. The year is extracted into the numeric field num_year with a result of 1994.

The second group of examples uses the field start_time, which is defined as a timestamp field and initialized to a value of 1994-10-22-02.59.40. The month is extracted into the character field char_month with a result of '10', and the hour is extracted into the numeric field num_hour with a result of 2.

Converting Date Formats

The MOVE and MOVEL operation codes can be used to convert date, time and timestamp fields from one data type or format to another. The valid conversions are:

o Date to date, timestamp, character or numeric. o Time to time, timestamp, character or numeric. o Timestamp to date, time, character or numeric. o Character or numeric to date, time or timestamp.

You can use the Move Array (MOVEA) operation code only to move date data type fields to a charactertype field, array or array element.

As with any move operation, when you use one of the MOVE operation codes to convert from one data type to another, the value in factor 2 will be moved to the result field.

Factor 1 is optional and is used to specify the format of factor 2, when factor 2 is not a date data type. Alternatively, factor 1 can be used to specify the format of the result field when the result field is not a date data type. All of the date formats are valid and, in addition, *JOBRUN can be used to indicate that the date format values from the job should be used. If factor 1 is not specified, then the DATFMT and TIMFMT values in the H-spec are used if specified; otherwise, *ISO format is assumed. Factor 1 must be blank if both factor 2 and the result field are date data types. In this case, ILE RPG will automatically convert from one date format to another.

When a MOVE operation code is used to convert a character field to a date type field, the character field must include the separators required by the format specified in factor 1. Conversely, when a date field is moved to a character field, the character field will contain separators based upon the format specified in factor 1.

Separators are not permitted when moving a numeric field to a date field, nor are they inserted when moving a date field to a numeric field.

6 shows some samples of converting dates using the MOVE operation code. In the first sample, the field start_num is defined as a zoned decimal field in which we are storing a date in YYMMDD format (941216). We want to add 30 days to the value in start_num. In RPG/400, this requires a subroutine that accounts for leap years and the number of days in each month; but, as 6 illustrates, it is a simple process in ILE RPG.

Figure 6 shows some samples of converting dates using the MOVE operation code. In the first sample, the field start_num is defined as a zoned decimal field in which we are storing a date in YYMMDD format (941216). We want to add 30 days to the value in start_num. In RPG/400, this requires a subroutine that accounts for leap years and the number of days in each month; but, as Figure 6 illustrates, it is a simple process in ILE RPG.

First, we use the MOVE operation code to convert the zoned decimal field start_num to the *ISO date start_date. Factor 1 indicates the field start_num is in *YMD format (e.g., YYMMDD). Then all we have to do is use the ADDDUR operation code to add 30 days to start_date and MOVE the *ISO date field start_date back to the zoned decimal field start_num. Again, factor 1 indicates the field start_num is to be formatted in *YMD format. The field start_num will have the value 950115.

In the next sample, the move operation code is used to convert a date from *USA to *EUR format. The field usa_date is defined as a *USA-format field with a value of 04/16/1916. The field eur_date is defined as a *EUR-format field. Moving the field usa_date to the field eur_date will result in eur_date having the value 16.04.1916.

The final sample demonstrates a potentially serious problem for those who store their dates in MMDDYY, DDMMYY or YYMMDD format. Dates in these formats must be in the range of 1940 to 2039. Attempting to move a value outside of this range to this format date will result in a run-time error. Since the *USA-format date usa_date has a value of 04/16/1916, which is before 1940, attempting to move this date to the *YMD-format date ymd_date will cause a run-time error.

Many people store their dates in packed decimal fields in CYYMMDD format where C represents the century (e.g., 0941216 represents 12/16/1994 and 1941216 represents 12/16/2094). *CYMD is not currently supported as a convert-from or convert-to date format. This is one of the most serious deficiencies in the ILE RPG language definition. Hopefully, IBM Toronto will recognize the major problems this will cause. Hopefully, this support will be added to ILE RPG before general availability of V3R1M0 or, worst case, be made available in the next release (or version?).

Summary

In this series of articles, we've only had time to take a look at some of the enhancements IBM has made to RPG in V3R1M0. For example, we haven't covered bound program calls; CLEAR and RESET operation code enhancements; date, time and timestamp built-in functions; and much more. Yet, we have seen that ILE RPG has introduced many radical changes to the RPG language definition:

o Numerous modifications were required to handle the change from 6- to 10- character symbolic names.

o Keyword notation has not only freed up space to accommodate longer fields in F-specs, it has also made the coding of H-specs and F-specs much easier for us and much easier for IBM to enhance in the future.

o E-specs have been eliminated with array and table definition moved to D- specs. Named constant and data structure definition has been moved from I-specs to D-specs.

o The new D-specs permit us to consolidate our data definitions in a single place in our programs. Substantial productivity gains should result from the introduction of the OVERLAY and PREFIX keywords and the ability to use length notation in data structures.

o Major changes to C-specs include six-character operation codes and free-form arithmetic and logical expressions. Our programs should be easier to code and maintain with the ability to code complex logic in a single EVAL, IF, WHEN, DOW or DOU calculation continued over multiple lines as necessary.

o Built-in functions can substantially reduce program development and maintenance time, in some cases reducing complex routines or called programs in RPG/400 to a single line of code in ILE RPG.

o The introduction of date, time and timestamp data types will finally let us easily address the year 2000. The ADDDUR and SUBDUR operation codes will enable us to replace entire subroutines or subprograms with a single line of code. ILE RPG is not the same old RPG. It offers the hope of making RPG a viable language into the twenty-first century.

Charlie Massoglia, president of Massoglia Technical Consulting, Inc. in Okemos, Michigan, has authored a number of midrange books. His cowboy hat is his trademark for his frequent speaking tours throughout the United States, Canada, Europe and Australia. Charlie can be reached at 517-676-9700.

Date, Time and Timestamp Data Types

DDS has supported date, time and timestamp data types for some time. Because these data types are not directly supported in RPG/400, they have been of little practical value for RPG programmers. ILE RPG is about to change that.

A1 shows the eight date formats currently supported for date fields. The date format controls the order and length of the month, day and year. In addition, the date format specifies the default separator character of slash (/), hyphen (-) or period (.). The year can be represented in two-byte (yy) and four-byte (yyyy) character format. The day of month (dd) is represented in two- byte format, while Julian day (ddd) is represented in three-byte format. The month (mm) is always represented in two-byte format.

Figure A1 shows the eight date formats currently supported for date fields. The date format controls the order and length of the month, day and year. In addition, the date format specifies the default separator character of slash (/), hyphen (-) or period (.). The year can be represented in two-byte (yy) and four-byte (yyyy) character format. The day of month (dd) is represented in two- byte format, while Julian day (ddd) is represented in three-byte format. The month (mm) is always represented in two-byte format.

The external length is the number of bytes of storage required to store the date field on disk without the separator characters. All date fields, regardless of date format, require four bytes of storage. The internal length is the number of bytes of storage required to represent the date in a program, on a screen or in a report including the separator characters. Date fields require between six and ten characters of storage for internal representation, depending upon the date format specified.

Leading zeros are required for all date formats except *USA.

ILE RPG supports five time formats, as shown in A2. The time format designates whether 12- or 24-hour format is used and whether seconds are shown. In addition, the time format specifies the default separator character of colon (:) or period (.). Hours (hh) and minutes (mm) are represented in two-byte format. Either the seconds (ss) are represented in two-byte format for 24-hour time, or AM or PM is represented in two-byte format for 12-hour time.

ILE RPG supports five time formats, as shown in Figure A2. The time format designates whether 12- or 24-hour format is used and whether seconds are shown. In addition, the time format specifies the default separator character of colon (:) or period (.). Hours (hh) and minutes (mm) are represented in two-byte format. Either the seconds (ss) are represented in two-byte format for 24-hour time, or AM or PM is represented in two-byte format for 12-hour time.

The external length of a time field is always three bytes. Time fields always require eight bytes for internal representation regardless of the time format specified.

Leading zeros are required for all time formats except *USA.

Fields with a timestamp data type always have the same format as shown in A3. Year (yyyy) is always four bytes, followed by month (mm), day (dd), hours (hh), minutes (mm) and seconds (ss) which are always two bytes. Microseconds (uuuuuu) is last with six bytes. The separator characters are always a combination of hyphens (-) for the date and periods (.) for the time.

Fields with a timestamp data type always have the same format as shown in Figure A3. Year (yyyy) is always four bytes, followed by month (mm), day (dd), hours (hh), minutes (mm) and seconds (ss) which are always two bytes. Microseconds (uuuuuu) is last with six bytes. The separator characters are always a combination of hyphens (-) for the date and periods (.) for the time.

The external length of a time-stamp field is always 10 bytes. Timestamp fields always require 26 bytes for internal representation. If microseconds is not specified when a timestamp value is used in ILE RPG, the compiler pads the value with zeros.


An Introduction to ILE RPG: Part 5

Figure 1 Defining Date and Time Fields with Initialized Val

 
  Format 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  HFunctions+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Comm 
  ents++++++++++++ 
  H 
 
  DName+++++++++++ETDsFrom+++To/L+++IDc.Functions............................Comm 
  ents++++++++++++ 
  D eur_date        S               D   DATFMT(*EUR) INZ(D'1994-12-16') 
  16.12.1994 
  D usa_date        S               D   DATFMT(*USA) INZ(D'1994-12-16') 
  12/16/1994 
  D iso_date        S               D   INZ(D'1994-12-16') 
  1994-12-16 
 
  D hms_time        S               T   TIMFMT(*HMS) INZ(T'18.06.30') 
  18:06:30 
  D usa_time        S               T   TIMFMT(*USA) INZ(T'18.06.30')        6:06 
  PM 
  D iso_time        S               T   INZ(T'18.06.30') 
  18.06.30 

An Introduction to ILE RPG: Part 5

Figure 2 Defining Date and Time Fields with Initialized Val

 
  *HMS Format 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  HFunctions+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Comm 
  ents++++++++++++ 
  H DATFMT(*USA) TIMFMT(*HMS) 
 
  DName+++++++++++ETDsFrom+++To/L+++IDc.Functions............................Comm 
  ents++++++++++++ 
  D eur_date        S               D   DATFMT(*EUR) INZ(D'12/16/1994') 
  16.12.1994 
  D eur_date2       S                   LIKE(eur_date) INZ(D'05/18/1995') 
  18.05.1995 
  D usa_date        S               D   DATFMT(*USA&) INZ(D'12/16/1994')     12 
  16 1994 
  D usa_date2       S               D   INZ(D'12/16/1994') 
  12/16/1994 
  D iso_date        S               D   DATFMT(*ISO) INZ(D'12/16/1994') 
  1994-12-16 
 
  D usa_time        S               T   TIMFMT(*USA) INZ(T'18:06:30')        6:06 
  PM 
  D hms_time        S               T   INZ(T'18:06:30') 
  18:06:30 
  D iso_time        S               T   TIMFMT(*ISO) INZ(T'18:06:30') 
  18.06.30 

An Introduction to ILE RPG: Part 5

Figure 3 ADDDUR-Add Duration Operation Code

 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  DName+++++++++++ETDsFrom+++To/L+++IDc.Functions............................Comm 
  ents++++++++++++ 
  D start_date      S               D   DATFMT(*ISO) INZ(D'1994-12-16') 
  D end_date        S               D   DATFMT(*ISO) 
  D month_end       S               D   DATFMT(*USA) INZ(D'1994-10-31') 
  D employ_dat      S               D   DATFMT(*USA) INZ(D'1992-02-29') 
  D anniv_dat       S               D   DATFMT(*USA) 
  D end_time        S               T   TIMFMT(*HMS) 
  D total_time      S               Z 
 
  CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm 
  ents+++++++++++++ 
   * 
   * Add 30 days to date 
   * 
  C     start_date    adddur    30:*days      end_date               50 
   * 
   * Add 1 month to date 
   * 
  C                   adddur    1:*months     month_end 
   * 
   * Add 1 year to date 
   * 
  C     employ_dat    adddur    1:*years      anniv_dat 
   * 
   * Add 3 hours, 22 minutes and 50 seconds to midnight 
   * 
  C     T'00.00.00'   adddur    3:*hours      end_time 
  C                   adddur    22:*min       end_time 
  C                   adddur    50:*seconds   end_time 
   * 
   * Add 1000 microseconds to a timestamp 
   * 
  C                   adddur    1000:*ms      total_time 

An Introduction to ILE RPG: Part 5

Figure 4 SUBDUR-Subtract Duration Operation Code

 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  HFunctions+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Comm 
  ents++++++++++++ 
  H DATFMT(*USA) TIMFMT(*HMS) 
 
  DName+++++++++++ETDsFrom+++To/L+++IDc.Functions............................Comm 
  ents++++++++++++ 
  D start_date      S               D   DATFMT(*ISO) 
  D end_date        S               D   DATFMT(*ISO) INZ(D'01/04/1995') 
  D month_end       S               D   DATFMT(*USA) INZ(D'10/31/1994') 
  D employ_dat      S               D   DATFMT(*USA) 
  D anniv_dat       S               D   DATFMT(*USA) INZ(D'02/29/1992') 
  D start_time      S               Z   INZ(Z'1994-05-12-02.59.40') 
  D end_time        S               Z   INZ(Z'1994-05-12-03.22.50') 
  D loan_date       S               D   INZ(D'12/16/1993') 
  D due_date        S               D   INZ(D'12/16/2008') 
 
  CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm 
  ents+++++++++++++ 
   * 
   * Subtract 30 days from date 
   * 
  C     end_date      subdur    30:*days      start_date             50 
   * 
   * Subtract 1 month from date 
   * 
  C                   subdur    1:*months     month_end 
   * 
   * Subtract 1 year from date 
   * 
  C     anniv_date    subdur    1:*years      employ_dat 
   * 
   * Calculate number of seconds between start and stop timestamps 
   * 
  C     end_time      subdur    start_time    num_sec:*secs     7 0 
   * 
   * Calculate number of days between dates 
   * 
  CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm 
  ents+++++++++++++ 
  C     due_date      subdur    loan_date     num_mon:*m        3 0 

An Introduction to ILE RPG: Part 5

Figure 5 EXTRCT-Extract Operation Code

 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  DName+++++++++++ETDsFrom+++To/L+++IDc.Functions............................Comm 
  ents++++++++++++ 
  D due_date        S               D   INZ(D'2008-12-16') 
  D start_time      S               Z   INZ(Z'1994-10-22-02.59.40') 
 
  CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm 
  ents+++++++++++++ 
   * 
   * Extract month, day and year 
   * 
  C                   extrct    due_date:*m   char_month        2 
  C                   extrct    due_date:*d   char_day          2 
  C                   extrct    due_date:*y   num_year          4 0 
   * 
   * Extract month and hours 
   * 
  C                   extrct    start_time:*m char_month 
  C                   extrct    start_time:*h num_hour          2 0 

An Introduction to ILE RPG: Part 5

Figure 6 MOVE with Dates, Times and Timestamps

 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  * No H-spec so dates and times default to *ISO format. 
 
  DName+++++++++++ETDsFrom+++To/L+++IDc.Functions............................Comm 
  ents++++++++++++ 
  D start_num       S              6S 0 INZ(941216) 
  D start_date      S               D   DATFMT(*ISO) 
  D usa_date        S               D   DATFMT(*USA) INZ(D'1916-04-16') 
  04/16/1916 
  D eur_date        S               D   DATFMT(*EUR) 
  D ymd_date        S               D   DATFMT(*YMD) 
 
  CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm 
  ents+++++++++++++ 
   * 
   * Add 30 days to date stored as a number in YYMMDD format 
   * 
  C     *YMD          move      start_num     start_date 
  start_date=1994-12-16 
  C                   adddur    30:*days      start_date 
  start_date=1995-01-15 
  C     *YMD          move      start_date    start_num 
  start_num=950115 
   * 
   * Convert a date from *USA to *EUR format 
   * 
  C                   move      usa_date      eur_date 
  eur_date=16.04.1916 
   * 
   * Cannot convert a date before 1940 or after 2039 to *YMD format 
   * 
  C                   move      usa_date      ymd_date                       run 
  time error 

An Introduction to ILE RPG: Part 5

Figure A1 Date Formats and Default Separators

 
  Date 
  Format          Date Format     Internal        External 
  Parameter       Description     and Separator   Length  Length  Example 
 
  *MDY    Month/Day/Year  mm/dd/yy        8       4       12/16/94 
  *DMY    Day/Month/Year  dd/mm/yy        8       4       16/12/94 
  *YMD    Year/Month/Day  yy/mm/dd        8       4       94/12/16 
  *JUL    Julian  yy/ddd  6       4       94/350 
  *ISO    International Standards yyyy-mm-dd      10      4       1994-12-16 
            Organization 
  *USA    IBM USA Standard        mm/dd/yyyy      10      4       12/16/1994 
  *EUR    IBM European Standard   dd.mm.yyyy      10      4       16.12.1994 
  *JIS    Japanese Industrial     yyyy-mm-dd      10      4       1994-12-16 
            Standard Christian Era 

An Introduction to ILE RPG: Part 5

Figure A2 Time Formats and Default Separators

 
  Time 
  Format          Time Format     Internal        External 
  Parameter       Description     and Separator   Length  Length  Example 
 
  *HMS    Hours:Minutes:Seconds   hh:mm:ss        8       3       18:06:30 
  *ISO    International Standards hh.mm.ss        8       3       18.06.30 
            Organization 
  *USA    IBM USA Standard        hh:mm AM or     8       3       6:06 PM 
                  hh:mm PM 
  *EUR    IBM European Standard   hh.mm.ss        8       3       18.06.30 
  *JIS    Japanese Industrial     hh:mm:ss        8       3       18:06:30 
            Standard Christian Era 

An Introduction to ILE RPG: Part 5

Figure A3 Timestamp Format and Separator Characters

 
          Internal        External 
  Format  Length  Length  Example 
 
  yyyy-mm-dd-hh.mm.ss.uuuuuu      26      10      1994-12-16.18.06.30.000001 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: