Y2K Implementation Guide

_________________________________________________________________________

INTRODUCTION

_____________________________________________________________________

This guide explains a detailed conversion process, and considerations which application designers should take into account when bringing applications into y2k compliance. Please refer to the Year 2000 White Paper for an overview of our recommended approach in converting such applications.

While APPX and SPEED II provide both facilities and tools to convert applications not originally written incorporating century into y2k compliance, it is the responsibility of the individual system administrator and application designers to perform the analysis necessary to successfully convert such applications. Customers remain responsible for their own applications, and analysis of code for y2k compliance. APPX Software Inc. may not have determined all possible impacts of year 2000 issues.

"Do I need to convert my applications?"

The answer to this is probably YES, if your application uses two-digit years (in other words, dates excluding century) anywhere. The savvy designer may read APPX literature and conclude, "They implement a pivot year, so even if I make no changes, my applications will continue to run fine, into the next century." However, the pivot year does not affect sort orders or key orders. A year part of "00" will still sort as being less than "97", if that field does not contain a century component. Potentially any application that relies on processing dates in ascending or descending order will not function as designed if those fields currently containing 2-digit dates are not converted to 4-digit dates.

Restructure, when converting a date field without a century part to a date field with a century part, will use the APPX_PIVOT_YEAR environment variable to automatically determine the century. If pivot year is not set, APPX will apply the century of the current system date. With pivot year set, APPX will calculate the century as explained later in this document.

This may not be desirable behavior in the case where a site hopes to use Pivot Year to put off making any application changes for a few years. These are only two examples of unexpected application run-time or design-time behavior which could result from an unconverted application. There are likely others as well, depending on your specific applications.

Important notes for SPEED II users:

The APPX development environment provides significant y2k conversion tools not available in SPEED II. It also requires no additional screen real estate, nor report real estate, to convert non-y2k-aware applications to y2k-awareness, unlike SPEED II, which does require changes in screen design. For these reasons, we recommend that strong consideration be given to upgrading existing SPEED II applications to APPX, to simplify conversion of your applications into y2k compliance.

Note: Wang Laboratories will require VS sites to upgrade to their VS/OS 7.53 or higher, in order to continue to be able to operate their VS hardware/operating system. Sites upgrading to VS/OS 7.53 will require upgrades to SPEED II release 7.0 or higher in order to be able to continue to operate their SPEED II based applications.

APPX Software does not anticipate providing in its future SPEED II releases any additional tools, outside of tools already in place, to assist in the applications analysis and end user restructure necessary to continue to operate into the year 2000.

_____________________________________________________________________

IMPLEMENTATION SUMMARY

_____________________________________________________________________

APPX Conversion Overview

Following is an overview of our recommended procedure to convert APPX applications into y2k compliance. The APPX Y2K conversion application's main menu contains at least one option that performs, or assists with the performance of, each listed step. The conversion process is described in greater detail later in this document.

1) Review list of fields defined as Date type, to familiarize yourself with potential areas of y2k concern in your applications.

2) Lock in the Century display mask on dates currently containing a Century component.

3) Change the System-wide display mask so that century is suppressed on data entry screens and reports.

4) Redefine in the Data Dictionary all dates currently beginning with YY to include a century component.

5) Update ILF code referring to date fields, as needed.

6) Verify Date field components and display masks, to make sure that you have made all the changes you intended to make in steps 2, 4 and 5.

7) Restructure end user data.

8) Identify non-standard date-related code in applications, review it, and bring it into compliance with y2k. (May require additional restructure steps).

SPEED II Conversion Overview

Following is an overview of our recommended procedure to convert SPEED II applications into y2k compliance:

1) Manually redefine in the Data Dictionary all dates currently beginning with YY to include a century component.

2) Manually reformat all INPUT and OUTPUT functions containing date fields to accommodate the extra size requirements of each date field due to the new century component.

3) Manually identify non-standard date code in applications, review, and bring into compliance with y2k.

4) Restructure end user data.

Note that SPEED II applications will require manual efforts to accomplish many of the above tasks. Additional screen and report real estate will be required to accommodate the added CC component of dates previously containing only YY. Once again, note that SPEED II users must upgrade to both SPEED II release 7.0 or greater, and also Wang VS Operating System 7.53 or greater.

Initial testing indicates that SPEED II release 7.2 and greater operates successfully under VS/OS 7.53.

_____________________________________________________________________

IMPORTANT CONCEPTS

_____________________________________________________________________

Date Masking in APPX

Date masking can be used to facilitate enabling applications for Year 2000. This means that date fields in large applications can be redefined to add centuries to those date fields currently excluding them, without the need to reformat any data entry, display screens, or report formats whatsoever, and without changing the application's operation from the end user's point of view.

Why This Works

In many cases, if a user enters the dates "12/31/97" and "01/01/00" (U.S. format), it is clear to both the designer and end-user that '1997' and '2000' are intended. APPX can implement this understanding at run-time through use of APPX date masking and a pivot year (described in the next section). No tools in addition to existing APPX tools are required to translate an application to take advantage of these facilities, although we will provide some tools to simplify the application of these techniques.

How This Works

Typically, dates in applications which weren't written to allow for dates beyond 1999, store and operate upon dates specified to include the year (YY), but not the century (CC).

Designers enabling applications for Year 2000 will use APPX's Data Dictionary to extend the 'scope' of these existing date fields to include the century, so that a full 4-digit year is stored for those fields. Then, by editing APPX's system-wide parameter 'Date Mask', the designer will cause dates including century to (by default) neither display nor allow editing of the CC component, on both data entry screens and reports. Although not displayed, the centuries stored in these dates will be programmatically operated upon and treated in a logically correct manner.

Of course, a date mask displaying a two-digit year is not always appropriate. For example, some domains or fields in an application, such as those containing birthdate, may require entry of dates from 1900 to 2000 and beyond. In that case, you would want to preserve the 4-digit-year date mask for those specific domains and fields. This is possible in APPX, since the system-wide date mask can be overridden at a number of different levels, down to the individual instance or occurrence of a date within application design:

System-Wide

Application

Domain

Field

Item (painted on Image)

The system-wide default date mask (in the U.S.) appears as:

06/05/0807 04:03 02.01 (mm/dd/ccyy hh:mm ss.tt)

This will change to ...

06/05/07 04:03 02.01 (mm/dd/yy hh:mm ss.tt)

The above date mask examples are suitable for APPX installations using U.S. style dates. International dates can be handled by a similar modification to their system-wide date mask, as appropriate.

Pivot Year in APPX

Related to date masking is the concept of a 'pivot year'. Pivot year controls the 'assumed' century, in circumstances where APPX must determine the century of dates taking on new values. Pivot year is implemented in APPX releases 3.2.83 and greater.

Pivot Year environment variable in APPX

By default, the pivot year is turned off. When Appx must supply a century, the century of the current system date is used.

The pivot year is set by establishing, through your OS Shell or by means of 'appx.env', by setting the environment variable APPX_PIVOT_YEAR. Dates containing two-digit years will calculate a century based on the current system date and the value of APPX_PIVOT_YEAR.

The calculation used to determine the century is explained later in this document in the section titled "Pivot Year Algorithm".

Similarly, a century will be synthesized when evaluating certain ILF statements as well:

IF, AND, & OR

If pivot year has been set, then the century is always synthesized for each operand that does not include a century. In the case that neither date contains the century, it will be synthesized for both prior to the comparison.

If the pivot year has not been set, then when only one operand includes century, only the common components of the date will be compared.

CNV TXT

When the destination is a date and the source does not include century, a century will be synthesized for the destination field.

DATE ADD

When the destination is YYMM and you add months or days, a century will be synthesized in order to correctly handle leap years. (APPX needs to know a century in order to determine whether or not a specific year is a leap year, which includes an extra day in February; if century is not taken into account, we don't know whether '00' is a leap year or not, and resulting DATE ADD calculations may be incorrect).

SET DAY

When source does not include a century, a century is synthesized. (Before the Y2K-enhanced version of APPX, '19' was always hardcoded as the century).

DATE BTW

When one operand contains century and the other does not, and unit is years, months, or days, a century will be synthesized for the field not containing a century.

SET statement

When the destination field includes century but the source does not, a century will be synthesized for the destination.

If a user enters "12/31/97" and "01/01/00" into date fields including a century, the combination of masking and a pivot year of 50 will cause these to be recognized as, stored as, and operated upon as "12/31/1997" and "01/01/2000".

This default of the system date's century can be changed prior to starting APPX, by setting the environment variable APPX_PIVOT_YEAR. If you are using a UNIX script to start up APPX, and want a revised setting to be in effect for all users, system-wide, you might want to include a line of the form

export APPX_PIVOT_YEAR=15

in your APPX startup script. If you use an appx.env file to set APPX environment variables, you would use a line of the form

APPX_PIVOT_YEAR=15

When you change this variable's value, it will not be in effect for existing APPX sessions. APPX users will have to logout and log back in again for the pivot year to be in effect for them.

Refer to APPX documentation on the use of the appx.env file to easily store and manage APPX environment variable settings on a system-wide or per-user basis. Care should be taken when over-riding this variable on a per-user basis, since it means that APPX applications will potentially behave differently for different users. While this may be appropriate in some situations, it is likely to be inappropriate in others. As a safety feature, if you do set the pivot year value, you may want to embed some ILF code in the application's main menu to verify (using rt_getenv) that the APPX_PIVOT_YEAR environment variable contains a value that you, the designer, expect.

Note: As stated earlier in this document, PIVOT YEAR does not change the operation of sorting. A two-digit year field of '00' will still sort as less than '97' regardless of pivot year setting. Also, Restructure inserts the century automatically when expanding a 2-digit year to a 4-digit year. If you have APPX_PIVOT_YEAR set, APPX will use the pivot year to determine what century to insert when changing a 2-digit year to a 4-digit year. If not set, restructure of a file containing a field with a two-digit year being converted into a four-digit year will result in the current system date century being inserted as the CC portion of the date in the new file.

Pivot Items environment variable in APPX

The environment variable APPX_PIVOT_ITEMS was added in release 3.5.2. This item limits pivot logic to masked date items in input processes without affecting ILF code. With APPX_PIVOT_ITEMS set to a value between 1 and 99 and with APPX_PIVOT_YEAR not set, pivot year logic will be applied to dates input with the century component masked out. Pivot year login will not be applied to those same dates when used with ILF code, such as DATE ADD or CNV TEXT.

Note:APPX_PIVOT_YEAR affects both ILF code and masked display items. When set it will apply pivot year logic in both cases.

Setting APPX_PIVOT_YEAR and APPX_PIVOT_ITEMS to different values may produce unpredictable results. APPX Software. Inc. recommends setting one, but not both of these environment variables.

Non-modifiable pivot year in SPEED II

Releases of SPEED II prior to 7.3 use a default pivot year of '20', which cannot be changed. These releases also do not provide a date-masking facility. This means that all SPEED II dates converted from YY only to CCYY will have to be edited and displayed in their entirety.

As of Release 7.3, Speed II supports both pivot year date logic and date masking for input and output processes. The pivot year logic is applied the same as outlined above for APPX. Please refer to the Speed II 7.3 Release notes for a complete explanation of the pivot date logic in Speed II.

APPX Tools supporting review and modification of date field attributes

Given the hierarchy of Date Mask overrides (System, Application, Domain, Field, Item), APPX Software will provide enhanced Domain and Field editors to assist in examining and modifying date field attributes. These editors will support:

1) Rapid identification and editing of the "scope" and override mask for date fields and domains.

2) Integrated Cross-Reference, allowing rapid identification of all locations where date fields are used.

3) Option to generate override masks for fields already containing century components.

4) Option to examine and add century component to date Domains and Fields currently defined to include YY, but not CC.

5) Option to identify and edit date Domains and Fields which may already contain override masks.

Departures from APPX-Standard ILF Date Handling Techniques

Because of the robustness and integration of APPX date field types and operations, the majority of APPX date operations will require no additional programming considerations when a date field is changed to include a century component. However, there are some common exceptions that arise when date values are stored in, or compared with, non-date fields.

1) ILF statements containing a date field on one side and a non-detailed on the other.

Once a date field "crosses the line" from date type fields to manipulations involving non-date fields, each instance must be examined in context, to determine what additional impact (if any) such a crossover may have.

The "Field Cross Reference" utility in the APPX Y2K application will optionally identify all occurrences of ILF statements which contain a date field and a non-date field. These utilities will allow the designer to catch the first point at which the date logic might go south (the first SET or CNV TEXT above), and then provide Xref Navigator and Report to help them track it down.

2) Storage of dates in field types other than APPX date field types

An example of this (shown in greater detail later in this document) is found in the original TOM Software C-apps, D-apps, and the current APPX Software T-apps. These applications utilize PARAM CALENDAR MONTH, PARAM CALENDAR YEAR, and FILENAME POST YEAR as two-digit numeric fields. They also utilize FILENAME POST MONTH as 2-character alpha fields (because they may be EY or 13).

These cases also must be examined in context, to adapt ILF behavior to accommodate y2k considerations.

The "Field List of Non-Dates Using Keywords" in the APPX Y2K application will select fields of a non-date field type that (IN)clude in their fieldnames the text strings MONTH, MTH, YEAR, YR, and any/or other text string the y2k converting designer will want to look for.

This utility will present a list of fields matching these criteria to the designer, who can then select some or all of them for further examination.

Ultimately, the application designer is responsible for analysis of (and, if necessary, modification of) code to accommodate the addition of century components to date fields previously defined excluding the century component.

_____________________________________________________________________

STEPS TO CONVERT APPX APPLICATIONS TO Y2K COMPLIANCE

_____________________________________________________________________

Make sure you have a good backup of both your applications and data prior to beginning this process.

Following are details of implementation, including suggested steps to convert applications to y2k compliance, and a more explicit specification of the pivot year algorithm:

You can use this list as a checklist of objectives to be accomplished during each step of the conversion process. Each step listed below, except the last one, corresponds with an option on the Y2K application menu, which is accessed with OPT-1 Y2K, from the main APPX menu. It is strongly suggested that you follow along with this guide while performing the activities on this menu, since this document contains explanations of those steps and additional considerations for the designer.

See the instructions on installing the Y2K utility application at the end of this guide.

A designer might think that the quickest path to a Y2K solution might be to forego restructures and simply insert ILF code checking whether a field's year part is greater or less than the pivot year, then taking different actions as a result of the comparison.

APPX Software does not recommend embedding pivot-year based logic in ILF code. Such logic adds considerable complexity to applications. Since it must be custom-coded for each process, it is possible that the designer could miss inserting the relevant ILF code in one or more processes that need it, resulting in incorrect operation of those processes.

1) Review list of fields defined as Date type, to familiarize yourself with potential areas of y2k concern in your applications.

APPX tool used: "Date Field Listing", OPT-1 on Y2K application main menu

From the Y2K menu, select Option 1, "Date Field Listing" to run this report. Since you want to see all Date fields, do not constrain by date modified (that feature is present because it is used later).

This report contains a line for each Field of type Date. It lists the field name, file name, domain application (if field is dependent on a domain in another application), field type, date format, and date mask. Print this report out for future reference during the y2k conversion process. (In fact, you may want two copies -- one as a record of your starting point, and another to cover with highlighter and pencil marks as you work.)

2) Use Data Dictionary (DD) domain custom date editor to "lock in" masks for date domains already defined with century components.

APPX tool used: Domain Date/Mask Editor, OPT-2 on Y2K application main menu

This step is necessary to prevent the global date mask edit (step 4 below) from hiding the century component of edits and displays of fields referring to domains which are already defined to present 'CC' on screens and reports.

Use the Domain Date/Mask Editor to specify a date mask including the century for all existing date fields including a century component.

The DD editors used in steps 2 and 3 present scrolling lists of only those date domains and fields currently defined with a century component. To quickly set an override date mask for a domain or field, the designer can SELECT a field in CHANGE mode, then use OPT-5 to quickly specify a date mask including century.

3) Use Data Dictionary (DD) field custom date editor to "lock in" masks for dates already defined with century components.

APPX tool used: Field Date/Mask Editor, OPT-3 on Y2K application main menu

This step is necessary to prevent the global date mask edit (step 4 below) from hiding the century component of edits and displays of date fields already defined to present 'CC' on screens and reports.

Similar to step 2), here you use the Field Date/Mask Editor to specify a date mask including the century for all existing date fields including a century component.

4) Update the system's global Date Mask and parts of the APPX environment which rely on it.

APPX tool used: System Administration utility

4A. In System Administration, System Setup, System Parameters, change the global Date Mask to exclude the century component.

In the U.S. for example, the global Date Mask is typically ...

06/05/0807 04:03 02.01

This would be changed to

06/05/07 04:03 02.01

... excluding the '08' CC component.

4B. After making this change, you must fully exit APPX (not just to the main menu; completely quit the program) and re-enter APPX, before doing any more work inside the APPX environment. This is to make sure that the cached Date Mask is reset properly.

4C. Delete all application EMs (Executable Modules, APPX's "p-code") and debug files. This is necessary to avoid EM regeneration problems later. For example, in UNIX, if your application code is stored directly under your APPXPATH (this is usually the case), you would login as user 'appx' and do the following:

        cd $APPXPATH
        rm {version}/{application}/Em/*
        rm {version}/{application}/Dbg/*

Important! If some of your design files' {version} is '00', and you are running an APPX version prior to 3.4, you must be careful not to delete any of the "0app" EMs. ($APPXPATH/00/0*/Em). To do so would disable APPX, which you would then have to reinstall or restore from a backup.

5) Use the DD Domain editor to change the 'scope' for date domains whose uppermost component is Year ('YY'), to include a century ('CC') component.

APPX tool used: Domain Date/Mask Editor, OPT-5 on Y2K application main menu

(Note: recording the date/time of when you begin making these changes may be useful to you later in step #9.)

The DD date editors allow presentation of a scrolling list of only date domains. Dates with YY as the highest component will typically be expanded to include century as the highest component.

The DD editors allow the designer to append 'CC' to any date whose highest level is currently 'YY'. Selecting a date domain in CHANGE mode, then pressing OPT-4, will automatically make this modification. If you also want to change the date to display a 4-digit year, OPT-5 will append 'CC' to the date's definition and set a date mask that displays the century. These dates will then be stored and operated upon including a century. But because of the default change in step #4 above, they will typically be edited and displayed with the century excluded unless the designer specifies an override date mask as with OPT-5.

6) Use the DD Field editor to change the 'scope' for date fields whose uppermost component is Year ('YY'), to include a century ('CC') component.

APPX tool used: Field Date/Mask Editor, OPT-6 on Y2K application main menu

The DD date editors allow presentation of a scrolling list of only date fields. Dates with YY as the highest component will typically be expanded to include century as the highest component.

The DD editors allow the designer to append 'CC' to all dates whose highest level is currently 'YY'. Selecting a date field in CHANGE mode, then pressing OPT-4, will automatically make this modification. If you also want to change the field to display a 4-digit year, OPT-5 will append 'CC' to the date's definition and set a date mask that displays the century. These dates will then be stored and operated upon including a century. But because of the default change in step #4 above, they will typically be edited and displayed with the century excluded unless the designer specifies an override date mask as with OPT-5.

7) Verify changes made so far, by reviewing the list of Date Fields again.

APPX tool used: "Date Field Listing", OPT-7 on Y2K application main menu

This will let you review the changes you have made, to verify that they are correct and to make sure that you have made all the changes you intended to make to date fields and domains, during the conversion process.

8) Use the APPX "Restructure" utility to reformat existing datafiles to include century components in the enduser data.

APPX tool used: End User File Management, OPT-8 on Y2K application main menu

If you want the 4-digit years for all dates currently in the file to begin with the current system date century, run Restructure with APPX_PIVOT_YEAR not set.

Restructure will use a century of '19' for date fields expanded from high-order = Year to high-order = Century (assuming the system clock is currently set before 1/1/2000). Note: This step makes the assumption that every date field which has been expanded to include century should have '19' as the century for any dates stored in those fields at the time the restructure is performed. If this is not appropriate for some of your date fields, you will have to manually set the centuries other than '19' through a custom Input process or a custom Update you create.

If you want the 4-digit years for all dates currently in the file to begin with '19' or '20' based on some pivot value, then set APPX_PIVOT_YEAR before going into APPX to do the restructures.

Since this step restructures data files which may be very large, you should verify that you have sufficient disk space to perform the largest of these restructures and that you have a sufficient time window for doing them during which no one will need to access the affected files.

9) Identify non-date fields interacting with dates, and make necessary code changes to ensure continued proper operation of programs.

APPX tool used: Field Cross Reference browser, OPT-9 on Y2K application main menu

These non-standard manipulations include but are not limited to ILF SET or CNV TEXT assignments, between just-modified-to-include-century date fields on one side of the assignment, and non-date field types on the other side, as discussed earlier in this document.

These occurrences, hopefully few, require manual examination and analysis in order to (possibly) modify ILF code so that it will work properly with dates expanded to include century.

To begin using the cross reference tool, you can either manually type in the names of fields you want to cross reference, or using OPT-1, you can have the system add date fields for you. Using this option,you can select date fields in the current application or date fields from all applications defined for the current version. You may also find it useful to limit your selection to only those date fields that you have added a CC component to. This can be accomplished using the modification date field. When finished selecting fields to be cross-referenced, press END and APPX will present you with a list of options. These are:

Browse results interactively: Use the browser on-screen, with levels of detail hyperlinked to the actual locations in which the field is found in code, on images, etc.

Produce report: Produce a cross-reference report on paper.

Limit to ILF only: List only occurrences of this field in ILF statements, not on images.

Limit to ILF with Date and Non-Date: List only occurrences of this field in ILF statements, where the field is interacting with a non-date field.

Show fields that are not referenced: If "Limit to" criteria are specified, fields which do not occur in the specified context(s) are not displayed. Selecting this option will display the date field name in the resulting list, even when there are no 'hits' per the criteria specified.

10) Identify fields of non-date type which may be used as dates.

APPX tool used: "Field List of Non-Dates Using Keywords" report, OPT-10 on Y2K application menu

This report is useful for finding fields which are not defined as dates, but which may be used for date-related operations. It looks for fields whose names contain any of a set of keywords, such as "MM", "YEAR", "CC", etc., but which aren't date fields. There is a default list of keywords to look for, which can be modified prior to running the report. If you know of other standard keywords you might have used to name non-date fields that might hold date components you may add them to this list.

The report goes through the data dictionary and prints out a list of all non-date fields whose names contain one or more of those keywords. It lists the file in which the field occurs, the field type, field format and mask (if any) for each field on the report. The results can be used as a starting point for analysis of the application, regarding non-standard usage of fields for date-related processing.

If you identify any nonstandard usages of dates for date-related processing, it may be necessary to perform analysis and design modifications to bring such usages into compliance with y2k requirements.

For example, ASI's "T-apps" (and its predecessors) use a 2-digit numeric field to represent 'Post Year', and then deletes data based upon this field. The use of a numeric rather than a date type field here creates a risk of incorrect data being deleted.

As described in "Example of T-app Non-Date Field type Considerations" below, we recommend expanding such fields to include the century. This allows existing application logic to function as it did before, but performing calculations and comparisons based on 4-digit rather than 2-digit years.

If the designer elects to change 2-digit numerics to 4-digit numerics to accomplish this, then it is necessary to write an UPDATE to add '1900' to existing historical data.

Alternatively, the designer might perform a two step process of changing the 2-digit numeric years into 'YY' type datefields, restructuring, then changing the YY type datefields into CCYY type datefields. (In addition to having to restructure twice, some ILF verbs (COMPUTE, CALC, IF) might also have to be changed into date-specific verbs (DATE ADD, DATE BTW).

We recommend that designers avoid using any form of a "Pivot Year" variable to modify existing ILF code, as experience shows that this will likely introduce considerable complexity into code using it. This would render such code difficult to debug and support.

11) Make any necessary changes to date masks on INPUT or OUTPUT images.

APPX tool used: none

In step 4, the global date mask was set to, by default, not display the century component of date fields. In steps 5 and 6 the field level date mask can be used to override this default for specific fields.

In particular instances, you may want to specify a mask for a field painted on an image which applies specifically to that image and not to other images where this field appears. This step may be optional, depending on application design issues.

_____________________________________________________________________

IMPLEMENTATION DETAILS

_____________________________________________________________________

'Pivot Year' Algorithm

Algorithm pseudo-code

The "pivot algorithm" used to determine the correct century at various points in the APPX runtime environment would function as follows:

Choose a two-digit pivot year (assume 50 unless specified by environment variable)

Whenever APPX needs to synthesize a century, it does the following:

      retrieve the current date

      if the current date's year is greater than the pivot
      {
           if the target year is less than the pivot
                use the current century + 1
           else
                use the current century
      }
      else
      {
           if the target year is less than the pivot
                use the current century
           else
                use the current century - 1
      }

Examples

The following examples illustrate the results of this algorithm:

Today's   Year
 Date    Entered  Result  Description
-------  -------  ------  -----------
1997       02      2002   Current year > pivot, target < pivot
1997       96      1996   Current year > pivot, target > pivot
2001       02      2002   Current year < pivot, target < pivot
2001       96      1996   Current year < pivot, target > pivot

Explanation

APPX uses this algorithm any time we need to synthesize a century. Most commonly, this occurs in data entry processes, but it is necessary at other times as well. For example, consider the following SET statement:

SET TAR WORK DATE CCYYMM = TAR WORK DATE YYMM

This assignment statement requires us to synthesize a century for the WORK DATE CCYYMM field, since the source field does not contain one. Prior to APPX release 3.2.8, we use the current century. In 3.2.8 and after, we will use the pivot algorithm instead.

Non-Date field types used to support date operations

Normal SPEED II and APPX date operations (using 'date' field types) are easily handled using the APPX and SPEED II conversion procedures described above.

There may occur instances where the original application designer implemented operations on dates, using field types other than Date (Alpha or Numeric). In such a case, additional analysis and possible recoding may be necessary.

Detecting non-date fields used in a date-related manner

Steps 9 and 10 in the "Steps to Convert APPX Applications to y2k Compliance" section above will identify some of these. The underlying idea of the Step 9 utility is that if you are implicitly converting a date field type to or from a non-date field type at run-time, and that date field's High-Order component is 'YY', then the designer should examine that assignment and its use in the context of the application. The designer should use the particular instance identified as a starting point, but should not limit his/her analysis to just that one use of the field if it is used in other parts of the application as well.

The SPEED II / APPX Cross Reference utilities (including APPX's cross reference navigation ability) can be used to examine the use of that non-date field type in the context of the application, to determine possible impact of the expansion of the 'YY' date field to include 'CCYY'.

The possibility of a non-date field type being used to perform date operations, without that date field interacting with a date field type must also be considered. If the application designers who originally developed and/or are familiar with an application are available, then their knowledge of the possibility of such operations is obviously important to the identification of such fields. Due to the application-dependent nature of these types of usage, it is not possible for APPX or our generic conversion tools to detect such usage. However, we do provide a report, used in Step 10 of "Steps to Convert APPX Applications to y2k Compliance". This report allows designers to quickly search through APPX applications, looking for field names containing keywords "likely" to indicate that a non-datefield may be being used for date-related application processing.

An additional technique to determine the presence of such fields is to print SPEED II or APPX Data Dictionary technical documentation to the screen or to a file. Then use standard manual search techniques to identify fieldnames containing the strings "Month", "Year", "Period", etc., which are not date field types. The SPEED II / APPX cross reference utilities can then be used to examine these fields in the context of their use in the application, in order to determine the impact, if any, of their needing to include the Century considerations in their logic.

Revising applications containing non-standard date operations

1) Expand the non-date field in the DD to incorporate a logical 'CC'. (The "Neron" method.) This method requires restructure of enduser data, and the writing of an UPDATE process to populate '19' into existing centuries (since restructure doesn't automatically fill in a century when non-DATE type fields are increased in size), but minimizes changes required in ILF code. The field type (for example, NUMERIC) would not change -- merely the length of the field. Some changes to ILF code may be required to compensate for the longer field length, depending on how the field is used in the application.

2) A two part DD redefinition and restructure: First, change (for example) a field such as "MTD POST YEAR" from a two digit numeric to a YY thru YY date. Then restructure enduser data. Then change in the Data Dictionary this YY date field into a CCYY date field. Restructure enduser data a 2nd time. APPX or SPEED II will automatically insert a '19' or '20' into the 'CC' component (depending on whether, and how, you have APPX_PIVOT_YEAR set, as explained earlier in this document), APPX will allow masking out at the system level of the 'CC' for display/editing purposes, and changes required to ILF code should be minimized.

_____________________________________________________________________

EXAMPLE OF T-APP NON-DATE FIELD TYPE CONSIDERATIONS

_____________________________________________________________________

An example of non-date fields used to perform 'YY' operations can be found within the APPX T-App applications. Any applications derived from the APPX C-apps, D-apps, or T-apps should be examined for similar uses of non-date fields.

Example of T-app non-date field type considerations

Following are two examples of non-date fields that are used for date type operations, logically using a 'year' attribute, but storing the value in a field APPX does not automatically recognize as a date field. The examples below deal with the manipulation of the following T-app Data and Work fields, that are stored as either alpha or numeric field types:

TAP MTDPOST POST YEAR
TAP PARAM CALENDAR YEAR
TGL WORK CALENDAR YEAR
TGL POST CALENDAR YEAR

Technique: Print Tech Doc, then use SEARCH tool to find in context occurrences of fields in question.

The following example was taken from the APPX T-apps applications. It shows how the APPX approach of restructuring data files to expand fields (of any type) containing year information to include century usually results in proper operation of code past year 2000 without any changes to ILF.

Background:

PARAM CALENDAR MONTH and PARAM CALENDAR YEAR and FILENAME POST YEAR are two-digit numeric fields. FILENAME POST MONTH is 2-character alpha (because it may be EY or 13)

MTDPOST is the application's monthly General Ledger distributions; TRANHIST is the application's Transaction History file.

Example 1: Deleting last month's records from MTDPOST.

T-APPS Update process: DELETE MTD POSTINGS
Process Control File: MTDPOST

Part of the original code for this process looks like:

Record Frame - Seq No- 100
Description: Month-to-Date Postings
Event Point: Start of Frame
...............
(Original Code)

    IF     TAP MTDPOST POST MONTH      EQ     EY
T   SET    TAP WORK CALENDAR MONTH N   =      13
F   SET    TAP WORK CALENDAR MONTH N   =  TAP MTDPOST POST MONTH
    *
    IF     TAP MTDPOST POST YEAR       LT TAP PARAM CALENDAR YEAR
T   DELETE TAP MTDPOST
    *
    IF     TAP MTDPOST POST YEAR       EQ TAP PARAM CALENDAR YEAR
    AND    TAP WORK CALENDAR MONTH N   LE TAP PARAM CALENDAR MONTH
T   DELETE TAP MTDPOST

...............

In order for this code to work accurately for years greater than 1999, one would expand TAP MTDPOST POST YEAR and TAP PARAM CALENDAR YEAR to include the century. The existing application logic would continue to function as it did before, now performing the comparisons above based on 4-digit rather than 2-digit years.

Note: One (but not necessarily the only) exception to the general rule of being able to convert an application to Y2K compliance without ILF code changes would involve cases where the field containing year information is converted in ILF to an ALPHA, and string operations dependent on length or position of certain date-parts (like SET TEMP) are used on that field. Changes to ILF, and perhaps even other field lengths, may be required to update applications using such techniques to Y2K compliance. Since it is not possible or practical for APPX Software tools to conclusively identify all places in an application where operation may be affected by Y2K conversion, designers are encouraged to carefully examine applications in order to detect processing, particularly in ILF code, which may require special handling.

_____________________________________________________________________

INSTALLING THE Y2K UTILITY APPLICATION

_____________________________________________________________________

To acquire the Y2K utility, you must install APPX release 3.3 or higher.

The Y2K application has two components:
Application Files found in $APPXPATH/00/Y2K
Data files, found in $APPXPATH/Y2K

Installation Steps

1. Add a Y2K/00 record to your APPX Applications file
   Enter Y2K in the "Test Database Id" field.
2. Add a Y2K record to your APPX Databases file
   Enter Y2K 00 in the "Startup Application" ID and Ver fields.
3. Run create files for application Y2K/00.
   3) System Administration
   3) Database/Applications
   5) Design File Management
   3) Create Files
   You should receive the message "File Already Exists" for each file.
4. Run create files for database Y2K/ application Y2K
   4) Database Management
   3) Create Files
   You should receive the message "File Already Exists" for each file.
5. You should now be able to launch the Y2K utility application by selecting option-1, "Select Database" from the APPX main menu, and entering a "Database Id" of Y2K.

As with any software product, APPX and SPEED ii have undergone a series of improvements and enhancements with each release. APPX Software. Inc. recommends that our clients updrade to the latest release to take advantage of fixes and enhancements related to date issues. Please refer to the release documents for more information on these items. For a list of APPX date-related items, please refer to our Date Related Fixes. You may also wish to refer to the other documents listed on our Y2K Information page.

Comments:

Read what other users have said about this page or add your own comments.