Google

Site Web

Migration RPG Year 2000 Compliance Guide

This document describes the changes made to Migration RPG to make the product Year 2000 compliant. Beginning with version 7.0, Migration RPG is fully Year 2000 compliant.

It is important that the users read this manual and understand the implications of the changes made in Migration RPG 7.1 to accommodate dates beyond December 31, 2004, before installing and using the updated compiler. Making Migration RPG software applications Year 2000 compliant will most likely involve modifications to the user's RPG source code. At the very least, RPG applications should be examined and the impact of the expanded date fields assessed before the programs are recompiled under Migration RPG 7.1.

MSI can provide assistance in making Migration RPG applications Year 2000 compliant. If you need assistance or if you have questions concerning Migration RPG 7.1 and Year 2000 compliance, please contact us.

This document assumes the reader is familiar with Migration RPG and RPG programming concepts.

Overview of Migration RPG Year 2000 Compliance

Year 2000 compliance is very simple in concept. Instead of accessing only the last two digits of the year when acquiring the system date, a program will access the full four-digit year. Thus, when using the UYEAR reserved field to acquire the year, the program will now see 2003 instead of just 98. Likewise, assuming the current date is October 1, 2004, and the system is using a month-day-year format, when using the UDATE reserved field to acquire the full system date, the program will now acquire 10/01/2003 instead of 10/01/98.

This small change may have far reaching consequences in programs which do date manipulations and comparisons. Year 2000 compliance also affects the data files which store dates and the command procedures which pass date information to programs. MSI strongly recommends that you conduct a thorough assessment of your RPG applications and their use of date fields before installing and using Migration RPG 7.1.

Migration RPG 7.1 provides Year 2000 compliance by expanding the UDATE field from 6 digits to 8 digits, the UYEAR field from 2 digits to 4 digits, and the TIME opcode output string from 12 digits to 14 digits. These expansions allow the system date fields to accommodate a Year 2000 compliant 4-digit year.

To provide support for the old 6-digit date format, Migration RPG has added the reserved fields $UDATE and $UYEAR and the opcode $TIME. The $UDATE field contains the system date in the old 6-digit format. The $UYEAR field contains the last two digits of the year in the old 2-digit year format. The $TIME opcode supports the old 12 digit output format. The $UDATE and $UYEAR fields and the $TIME opcode can be used to simplify program updates in places where Year 2000 compliance with a 4-digit year is not needed.

Developing a Year 2000 Compliance Strategy

Before installing Migration RPG 7.1 and using the Year 2000 compliant compiler, it is important to implement a Year 2000 compliance strategy. MSI recommends the following basic steps to make your applications Year 2000 compliant:

  1. Identify all of the active program and procedure code in your software applications.
  2. Examine the active program and procedure code and identify all uses of dates within the code.
  3. Examine all of the data file layouts and identify date fields.
  4. Examine each date usage in the programs and procedures and determine if the usage is impacted by the century change. For example, a date field which simply prints the date in a report header is most likely not seriously impacted by the century change. However, date fields which are used in comparison or calculation operations are impacted by the century change. Comparing the 4-digit years 2003 and 2000 versus the 2-digit years 99 and 00 produces very different results.
  5. Identify the date usage which must be updated in the programs and procedures. Use this information to determine whether the date fields in the data files must be modified.
  6. If file modifications are necessary to support the expanded date fields, determine which programs must be modified to accommodate the modified file layouts.
  7. Use all of the information gathered in the preceding steps to develop a Year 2000 update plan.
  8. Implement the Year 2000 Update plan.
  9. Test the updated applications thoroughly before putting them into production.

MSI can provide assistance in developing and implementing a Year 2000 Update plan. If you would like assistance in making your applications Year 2000 compliant, please contact us.

Date Field Modifications

The following sections describe the changes made to the system date fields and the date edit code within Migration RPG to achieve Year 2000 compliance.

Expanded UDATE Field

Under Migration RPG 7.1, the UDATE field has been expanded from 6 digits to 8 digits. This allows the UDATE field to store a date which contains the full 4-digit year. In the past, the UDATE field would store the date October 1, 2004 as 100198. Under Migration RPG 7.1, the UDATE field stores the date as 10012003.

UDATE Update Implications

Locate all references to the UDATE field in your Migration RPG programs. Check each reference for the following issues:

  • If the UDATE field is being output, is the output field large enough to accommodate the expanded date?
  • If the UDATE field is being moved to another field, is the receiving field large enough to accommodate the expanded date?
  • If the UDATE field is being moved to a data structure, will the data structure definition accommodate the expanded date?
  • If the UDATE field is deliberately being truncated, will the truncation work correctly with the expanded date?
  • If the UDATE field is being used in a comparison operation, will the operation work correctly with the expanded date?
  • Are all of the fields that the UDATE is associated with in a program Year 2000 compliant?

Expanded UYEAR Field

Under Migration RPG 7.1, the UYEAR field has been expanded from 2 digits to 4 digits. This allows the UYEAR field to store the full 4-digit year. Whereas in the past the UYEAR field would store the year 2003 as 98, under Migration RPG 7.1, it stores the year as 2003.

UYEAR Update Implications

Locate all references to the UYEAR field in your Migration RPG programs. Check each reference for the following issues:

  • If the UYEAR field is being output, is the output field large enough to accommodate the expanded year?
  • If the UYEAR field is being moved to another field, is the receiving field large enough to accommodate the expanded year?
  • If the UYEAR field is being moved to a data structure, will the data structure definition accommodate the expanded year?
  • If the UYEAR field is deliberately being truncated, will the truncation work correctly with the expanded year?
  • If the UYEAR field is being used in a comparison operation, will the operation work correctly with the expanded year?
  • Are all of the fields that the UYEAR is associated with in a program Year 2000 compliant?

Y Edit Code

Under prior versions of Migration RPG, the Y edit code performed a very simple edit. It edited any field as follows:

nn/nn/nn

Under Migration RPG 7.1, the edit performed by the Y edit code is a bit more complex. Since a 4-digit year is now incorporated into the date, there are two possible date edit formats:

nn/nn/nnnn - or - nnnn/nn/nn

The date edit format which is used by the program is determined by the date representation selected in columns 19 and 21 of the program's Header Specification. The following three date representations are recognized by Migration RPG:

mm/dd/yyyy (default)
yyyy/mm/dd
yyyy/dd/mm

The Y edit code is smart, in that it adjusts the field formatting to accommodate fields which are less than full-sized. Prior to Migration RPG 7.0, a full-sized date field was 6 digits long. The formatting of fields less than 6 digits long looked like this:

6 digit: nn/nn/nn
5 digit: nn/nn/n
4 digit: nn/nn
3 digit: nn/n
2 digit: nn
1 digit: n

Under Migration RPG 7.1, a full-sized date field is now 8 digits long. The Y edit code is still smart about how it edits fields less than 8 digits long. However, depending upon the date representation setting in columns 19 and 21 of the Header Specification, fields edited by the Y edit code may appear as one of the following:

8 digit: nn/nn/nnnn nnnn/nn/nn
7 digit: nn/nn/nnn nnnn/nn/n
6 digit: nn/nn/nn nnnn/nn
5 digit: nn/nn/n nnnn/n
4 digit: nn/nn nnnn
3 digit: nn/n nnn
2 digit: nn nn
1 digit: n n

Y Edit Code Update Implications

Examine all Migration RPG programs for use of the Y edit code. Check each usage for the following issues:

  • Is the output field large enough to accommodate the expanded date field?
  • Will the edit performed by the Y edit code still produce the desired results? Pay particular attention to non-date fields which are edited using the Y edit code.

TIME Opcode Modifications

The following sections describe the changes made to the TIME opcode output to make the output Year 2000 compliant.

Expanded TIME Output

The total size of the TIME opcode output string has been expanded from 12 digits to 14 digits. Under the non-Year 2000 format, the TIME opcode output a time and date string in one of the following formats:

hhmmssmmddyy
hhmmssddmmyy
hhmmssyymmdd

The format of the date in the output string is determined by the date representation selected in column 19 of the Header Specification.

Under Migration RPG 7.1, the TIME output string has been expanded to 14 digits to accommodate a 4-digit year. The Year 2000 compliant TIME output string formats look like this:

hhmmssmmddyyyy
hhmmssddmmyyyy
hhmmssyyyymmdd

The TIME data actually passed to the program is based on the size of the numeric field defined in Factor 3 of the TIME statement line. If the field is defined as 6 digits, only the time is moved to Factor 3. If the field is defined as 14 digits, both the time and date are moved to Factor 3. If the field is defined as 4 digits, the hour and minutes of the time are moved to Factor 3, and so forth.

TIME Opcode Output Expansion Implications

Expansion of the TIME output field impacts programs that use more than 6 digits of the output string. Programs using the date portion of the TIME output string will need to be checked to ensure that the expected data is still being placed in the field defined in Factor 3. Programs that acquire the year via the TIME opcode will need to be modified to accommodate the Year 2000 compliant 4-digit year.

Support for non-Year 2000 Code

The following sections describe the support provided within Migration RPG 7.1 for non-Year 2000 compliant code.

6-Digit Date Support - $UDATE

The old style 6-digit date is still supported within Migration RPG 7.1. This has been accomplished by creating the new reserved field $UDATE. $UDATE corresponds exactly to the old 6-digit UDATE field used in versions of Migration RPG prior to 7.0.

2-Digit Year Support - $UYEAR

The old style 2-digit year is still supported within Migration RPG 7.1. This has been accomplished by creating the new reserved field $UYEAR. $UYEAR corresponds exactly to the old 2-digit UYEAR field used in versions of Migration RPG prior to 7.0.

$UMNTH and $UDAY Fields

To maintain consistency in naming conventions under Migration RPG 7.1, the reserved fields $UMNTH and $UDAY have been created. These fields correspond exactly to the reserved fields UMONTH and UDAY.

6-Digit Date Edit Code - U Edit Code

The old style date edit code is supported under Migration RPG 7.1 using a new edit code, the U edit code. The U edit code corresponds exactly to the old Y edit code used in versions of Migration RPG prior to 7.0.

REX Utility Date Format Change

The REX Utility is used to set the external indicators U1 - U8 and the user-defined system date for Migration RPG programs. The /DATE qualifier is used to enter the user-defined system date. Under versions of Migration RPG prior to 7.0, the format used to enter the system date was mmddyy. Under Migration RPG 7.1, the Year 2000 compliant format used to enter the system date is mmddyyyy.

$ REX /DATE=102398   !Non-Y2K compliant date format
$ REX /DATE=10232003 !Y2K compliant date format

This example shows how the REX utility was used to entered a user-defined system date under versions of Migration RPG prior to 7.0 and how the REX Utility is used to enter a Year 2000 compliant user-defined system date under Migration RPG 7.1.

REX Date Format Change Implications

Examine all Migration RPG procedures for use of the REX Utility with the /DATE qualifier. Check each usage to ensure that the date format is correct. 6-digit, user-defined system dates entered using the REX Utility under Migration RPG 7.1 will not be processed correctly.

External Indicator and User-Defined Date File Layout (S3X$EXT)

The external indicators (U1 - U8) and user-defined system date are stored in a 170-byte, fixed-length, single record, sequential file. The file is referenced by the logical name S3X$EXT. The user-defined date is entered into the S3X$EXT file by the REX Utility using the /DATE qualifier.

Under versions of Migration RPG prior to 7.0, the 6-digit, user-defined system date was stored in positions 9 - 14 of the S3X$EXT record. Under Migration RPG 7.1, the 6-digit date is still stored in the same positions. However, the S3X$EXT file has been modified under Migration RPG 7.1 to also accept the 8 digit, user-defined system date. The 8-digit date is stored in positions 51 - 58.

When the user-defined system date is entered using the REX Utility, it is entered in the Year 2000 compliant format mmddyyyy. The Year 2000 compliant date is stored in positions 51 - 58 of the S3X$EXT file. The date is also truncated to 6 digits and stored in the old mmddyy format in positions 9 - 14 to provide support for non-Year 2000 code.

S3X$EXT File Layout

The following table describes the S3X$EXT file layout under Migration RPG 7.1.

Position(s) Description
1 U1 - External Indicator
2 U2 - External Indicator
3 U3 - External Indicator
4 U4 - External Indicator
5 U5 - External Indicator
6 U6 - External Indicator
7 U7 - External Indicator
8 U8 - External Indicator
9 - 14 6-digit date, mmddyy (Non-Year 2000 compliant)
15 - 50 Reserved for future use
51 - 58 8-digit date, mmddyyyy (Year 2000 compliant)
59 - 170 Reserved for future use

S3X$EXT Update Implications

All procedures and non-RPG programs which reference the S3X$EXT file should be identified. Each S3X$EXT file reference should be checked to see if it accesses the user-defined date field in positions 9 - 14. If it does, the reference should be checked to ensure that it is Year 2000 compliant. References which need to be Year 2000 compliant should access the 8-digit, user-defined date in positions 51 - 58.

All data fields associated to any S3X$EXT user-defined date references in procedures or non-RPG programs should also be checked for Year 2000 compliance.

Top of Page Success! Tech Tips Partners