IBM: VisualAge Millennium Language Extensions

White Paper, "Tackling the Year 2000 with
IBM Millennium Language Extensions"

The IBM Millennium Language Extensions (MLE) technology supports automated date windowing in IBM's year 2000-ready COBOL and PL/I compilers. MLE enables you to indicate to the compiler which dates should be windowed. This white paper explains MLE in depth, and provides scenarios and examples that show how MLE may significantly reduce your source-code updates, and thereby improve your productivity.

IBM Millennium Language Extensions

The Year 2000 Challenge
What is this year 2000 challenge? Most programs and databases use two digits rather than four to represent the year in date fields. The century is assumed to be 19 and is not explicitly represented. This compact date format works well for the 1900s because most programs operate on the same assumption; but it doesn't work for the year 2000 and beyond, because programs typically interpret 00 as 1900 rather than 2000 and proceed to give incorrect calculations. For example, years after 2000, such as 01, 02, and 03, are interpreted to be numerically smaller than, and therefore preceding, years before 2000, such as 97, 98, and 99. Some programs might even interpret 00 as some value other than a year, such as "delete immediately," "never delete," or "invalid." Before you can fix your 2-digit year date data, you must select which approach to use for each application, and decide whether the Millennium Language Extensions (MLE) are applicable.

What is MLE?
MLE is short for Millennium Language Extensions, IBM's patent-pending technology that provides support for automated date windowing in its year 2000 ready COBOL and PL/I compilers. These extensions give you a mechanism to indicate to the compiler which dates should be windowed. It is a compiler-assisted solution for your windowed dates. Using Language Environment on MVS, OS/390, VM, or VSE gives you windowing support at runtime by supplying callable service routines to set and query a century window. But MLE provides even more assistance, essentially providing the logic that you would otherwise have to code yourself. With MLE, you have the ideal situation: the ability to fix programs with few, if any, PROCEDURE DIVISION changes. While century windowing is the quickest and most powerful feature, field expansion is also supported, making MLE the easiest way to implement permanent internal bridges.

When is MLE a Year 2000 Solution?
MLE can help you to implement two approaches for handling date data:

Inferring the correct century through a century window.
Expanding year fields to hold century information explicitly.

The pros and cons of each of these approaches can be found in the Millennium Language Extensions Guide GC26-9266-00, Chapter 2, "Using the Millennium Language Extensions" on page 10. For a solution involving either of these approaches, or any combination of the two, the millennium language extensions offered with the IBM COBOL compilers may significantly reduce your source-code updates, and thereby improve your productivity.

Inferring the Correct Century Using a Century Window
With this approach, you establish a 100-year interval, called a century window, within which you assume all 2-digit years lie. Programs can then infer the correct century, depending on where in the century window the 2-digit year lies. For example, if the range of your century window is 1956 through 2055, and the 2-digit year is greater than or equal to 56, the century is inferred to be 19; otherwise, if the 2-digit year is less than or equal to 55, the century is inferred to be 20. There are two types of century window: the fixed window and the sliding window. The fixed window doesn't change after it has been established; the sliding window moves forward with the system date.

Expanding Date Fields
With this approach, you copy the contents of a 2-digit year date field to another, larger, 4-digit year date field. The millennium language extensions can help you by automatically filling in the century part (the leading 2 digits) of the year in the receiving field, based on the century window.

You can use this technique for a number of tasks, two of which are as follows:

Write a one-time COBOL program to expand your files and databases so that all the date fields have 4-digit years. For a simple example of a program that does this, see "File Conversion" on page 85 in the Millennium Language Extensions Guide GC26-9266-00. After expanding the files and databases, modify the programs that use them to specify corresponding data declarations with expanded-format dates.
Change your existing programs to expand the date fields from the input records into Working-Storage fields, and use those work fields to process the dates in the main body of the programs. Then copy them back to the output records before writing them out. This technique is called internal bridging, and is described in the Millennium Language Extensions Guide GC26-9266-00 "Internal Bridging" on page 12.

Compilers that Support MLE
Before starting to change any of your programs to use MLE, you need to ensure that you have the correct level of software to support the changes. IBM provides support for MLE in the following compilers:

IBM COBOL for OS/390 & VM, with VisualAge COBOL Millennium Language Extensions for OS/390 & VM.
IBM COBOL Set for AIX.
IBM VisualAge COBOL.
IBM COBOL for MVS & VM, with VisualAge COBOL Millennium Language Extensions for MVS & VM.

For a full list of the associated product numbers and releases, see the Edition Notice on the inside front cover of Millennium Language Extensions Guide GC26-9266-00. If you are unsure whether your compiler supports MLE, you should consult your software support representative.

What You Gain from MLE
Using MLE, you can change your application data definitions in the Data Division to indicate which data items represent windowed or expanded dates, and, for windowed dates, how you want the window to be defined. The compiler can then automatically implement the associated windowing logic, in many cases without your having to code any changes in the PROCEDURE DIVISION. Because it is implemented directly by compiler-generated machine code, it is fully integrated in your code as a high performance windowing solution. So, where windowing is your approach of choice, MLE can help reduce the programming time and effort needed to implement a windowing solution and simplify subsequent maintenance of your application programs. MLE also enables a flexible and comprehensive mixing of windowed dates with expanded dates within a program, allowing you to:

Pick and choose which approach is best for each date data item within the program.
- Use the windowing feature to quickly extend existing programs to run through the year 2000.
Use the expanded date field feature for long-term migration and the eventual expansion of dates in databases and files.

You can use MLE to help with date field identification by identifying obvious date data items and letting the compiler diagnostics lead to you the ones that you missed. Using MLE may also reduce your testing effort, particularly in those cases where you have few if any manual logic code changes. It's rather like using pre-tested logic.

Limitations of MLE
MLE is not a silver bullet. It is important to understand that, whatever the merits of MLE, it does not render unnecessary all the year 2000 work at your enterprise. A windowing solution might not be an acceptable approach for all your applications. While it can relieve you of many of the logic changes where you do choose windowing, it does not relieve you of the assessment, planning, analysis, implementation, and testing activities. There might be cases where using MLE requires you to make manual logic changes. Also, the extensions are not intended to be a durable piece of language design, with a long-term usage. They do not constitute a fully-specified set of date-oriented data types, with rich semantics, enabling improved functionality for new applications or enhancements to existing applications. Their use should be limited to making year 2000 repairs only. In particular, the windowing feature is not intended for long-term use. The start of the window must be in the range 19001999, so this feature buys you time to get code through the year 2000 and to a long-term solution that can be implemented later. Because the extensions do not provide date data types, the non-year part of the supported date formats is denoted by Xs: no special processing is done for the non-year part. To do otherwise might change the meaning of existing programs. The only date-sensitive semantics that are provided involve automatically expanding (and contracting) the 2-digit year part of dates with respect to the 100-year window for the program.

Where MLE is Applicable
Any COBOL application that is compiled with one of the MLE-supporting compilers can use MLE, but consider these factors:

The status of the programs: they should be stable programs that you are repairing for 2-digit years only.
What language level is being used (MLE requires COBOL 85 Standard level).
What subsystems and files are involved.

Using MLE for Year 2000 Work Only
The millennium language extensions were designed to meet a number of objectives in resolving date processing problems. To use the extensions effectively in your environment, you should evaluate the objectives that you need to meet, and compare them against the objectives of the millennium language extensions, to determine how your application can benefit from them. The objectives of the millennium language extensions are as follows:

The primary objective is to extend the useful life of your application programs, as they are currently specified, into the twenty-first century.
Source changes to accomplish this must be held to the bare minimum, preferably limited to augmenting the declarations of date fields in the Data Division. To implement basic remediation of date problems, you should not be required to make any changes to the program logic in the PROCEDURE DIVISION.
The existing semantics of the programs will not be changed by the addition of date fields. For example, where a date is expressed as a literal, as in:
If Date-of-Birth Less Than 450101 ...
the programmer intended the literal 450101 to mean January 1, 1945, not 2045. The extensions retain this assumption about the program's original meaning, even though a windowed year value of 45 would be interpreted as the year 2045.

Source Conversion
The level of source code is an important consideration. If your programs have been compiled with the OS/VS COBOL compiler, you will have to convert the source, which is at the COBOL 68/74 Standard level, to COBOL 85 Standard. COBOL and CICS Command Level Conversion Aid (CCCA) can be a big help with the conversion, very often doing the entire job for you. Or, if you are going to use VisualAge COBOL for your year 2000 work, then its built-in facilities make source conversion easy. If your programs have been compiled with VS COBOL II Release 3 or later, with the NOCMPR2 compiler option, no conversion is necessary. You can mix MLE programs with unchanged older modules, and only those programs with date logic need to be recompiled. Note, however, that MLE is not available in the VS COBOL II compiler. Programs that use MLE must be compiled with one of the compilers that support MLE.

Sub-systems with No Windowing
COBOL programs with MLE windowing can be used with any of the subsystems that normally support your applications, such as DB2, CICS, and VSAM. You can even specify windowed date fields as keys for sorting and merging if your sort software supports date windowing. However, some subsystem-specific functions do not support date windowing, and you cannot simply use windowed date fields in these contexts. Some examples of functions that don't support windowing are:

VSAM file primary or alternate keys.
Search fields in database systems such as IMS or DB2.
Sort fields in DB2 (ORDER BY ...).
Key fields in CICS commands.

This can cause a variety of problems, from outright failure to confusion and errors from mismatched ordering.

MLE Pilot
A pilot project is always something to consider for your year 2000 work. You should plan to do some preliminary testing with MLE to determine its usefulness in your environment. Migration to a year 2000 ready compiler is required if you are not already using one and are interested in taking the windowing approach.

MLE Scenario
If you decide to use a century windowing approach as all or part of your solution and choose to use MLE, then you should:

Choose a fixed-window or sliding-window solution.
Choose a century-window start year or offset for each program.
Modify the data definition for each field by adding the appropriate DATE FORMAT clauses to the data definitions.
Compile the program with the appropriate options and resolve any ambiguous references to the data items whose definitions were modified in the previous step. These ambiguous references will be highlighted by diagnostic messages.

This process can be applied on a source module by source module basis. Any executable can be compiled and tested with full year 2000 support by using the compiler option to enable the new attributes. To test an application, use the following steps:

Run regression tests with 1900 as the start year (the default); this should give the same results as those prior to the changes.
Run date simulator tests with your selected start year.
After each executable is tested, it can be moved into production with the year 2000 support enabled.

Getting Started with MLE
Consider this short example which presents a problem and uses MLE in the solution.

A Simple Date Problem
Our example consists of a program which compares the date that a video tape was returned with the date it was due back to see whether to impose a fine. The two dates are stored in the file as 6-digit Gregorian dates; that is, YYMMDD.

1 Loan-Record.

5 Member-Number Pic X(8).
5 Tape-ID Pic X(8).
5 Date-Due-Back Pic X(6).
5 Date-Returned Pic X(6). ...
If Date-Returned Greater than Date-Due-Back Then
Perform Fine-Member.

If the tape was due back on September 14, 1998, the contents of Date-Due-Back are 980914. If it was returned on September 12, the contents of Date-Returned are 980912. Therefore, no fine is imposed, because Date-Returned is less than Date-Due-Back. If we go forward in time, we can see how this reliable program behaves in January 2000. If the tape is due back on January 2, 2000, but is returned on December 31, 1999, the contents of the fields are:

Date-Due-Back 000102
Date-Returned 991231

In this case, Date-Returned is much larger than Date-Due-Back, so the program imposes a hefty fine for being 100 years late.

A Simple Solution
If the program recognized that the year 00 was in fact 2000, not 1900, the result would be different. In the new scenario, the "If ... Then ..." statement would behave properly, viewing 991231 as 19991231 and 000102 as 20000102, resulting in correct logic path and no fine for the tape that was returned early, not late. IBM COBOL with MLE lets you do this quite easily, but you have to do a few things to make it work:

Decide on a century window, and tell the compiler about it. Take into account how far back your historical data goes and how far into the future your date data will be. If you decide to use 19502049 as your window, then COBOL evaluates the 2-digit year parts of your dates like this:
Values 00 through 49 represent years 2000 through 2049.
Values 50 through 99 represent years 1950 through 1999.
Use the two new compiler options to tell the compiler about the century window:
DATEPROC Tells the compiler to enable the windowing process. For our example, we'll use
DATEPROC(FLAG) to get all the date-related diagnostic messages.
YEARWINDOW Tells the compiler what the century window is. For our example, we'll use
YEARWINDOW(1950) to give us a fixed window of 19502049.
Tell the compiler which fields to treat as date fields, so it knows when to apply the century window and when not to. You do this by changing the COBOL copybook or source program, adding a DATE FORMAT clause to the date fields. Then the record layout looks like this:
Compile the program. Check the diagnostic messages to verify that the statements will still work correctly.
Test the program.
Optionally, recompile the program with DATEPROC(NOFLAG) when you put the new version of the program into production. This gives you a clean compile listing for your records.

To summarize, with MLE it's quite straightforward to introduce a windowed date concept into a COBOL program by deciding on a century window, changing some data descriptions, and recompiling the program.

Large-Scale Use of MLE
As you can see from the previous discussion, it's a simple matter to change one COBOL program to take advantage of automatic date windowing with MLE. But your installation's programs will be more complicated than this simple example, and you will need to implement changes to many programs at a time. For large-scale use of the MLE technology, automated tools are critical for a successful MLE implementation. With the introduction of MLE, IBM also introduced automation tools to provide a more complete automated windowing solution. To identify your date-related fields, use IBM's Maintenance 2000 (MA2000). Once your date fields are found, you can use the COBOL CICS Conversion Aid (CCCA) to automatically annotate the identified date fields with the correct MLE date format clause. In many cases, there is no modification required for the source code. More information on these tools can be found on the VisualAge 2000 Web site at www.software.ibm.com/ad/va2000/.

This section outlines the steps you should follow in converting a complete application, or a suite of related programs, to MLE - without the use of automated tools such as MA2000 and CCCA. Note that these steps are a guideline only; you will need to consider many other factors in formulating a conversion plan of this magnitude. Some other factors to consider are:

Your installation's change control system and methodology.
The requirement to impose a "freeze" on other changes while this process is taking place.
The availability of testing environments.
The level of interaction between applications.

With these factors in mind, you can formulate a conversion plan based on the following steps:

Choose an application or group of applications to be remediated using MLE.
Identify the century window to be used for the application. Take into account how far back your historical data goes and how far into the future your date data will be.
Identify the date fields that need to be expanded. For example, if a VSAM key is a date field, this field should be expanded rather than windowed.
Document which copybooks are used by which source programs.
Locate data items that contain dates in all of the copybooks and programs. This date identification should be accurate in that it should identify as many of the dates as possible. without identifying non-date fields as dates (false positives). This step should also try to identify the date patterns of these date data items.
Edit the copybooks and add DATE FORMAT clauses to the data definitions. You may have to look at the usage of the dates in COBOL programs to determine the date pattern to use.
Compile the programs that have the most date usage first, to allow the compiler to help complete the date field identification for the copybooks. Use the DATEPROC(FLAG) compiler option and resolve any compiler diagnostics that are produced.
Once the date fields are all marked with DATE FORMAT clauses in the copybooks, compile all of the programs in the application that use those copybooks. If more date fields are identified in the copybooks, then change these newly-identified fields and go back and recompile any programs that use those copybooks.
Keep track of other applications that share these copybooks. These other applications may be compiled with the DATEPROC option at a later date, or, if they have been remediated with another method such as manual windowing, they may need to have NODATEPROC added to their CBL/PROCESS statements to avoid the need to reanalyze them.

MLE for Your Year 2000 Solution
As shown in the scenarios and examples given, the millennium language extensions offered with the IBM COBOL and PL/I compilers may significantly reduce your source-code updates, and thereby improve your productivity. When windowing is your technique of choice, consider MLE for this critical part of your year 2000 solution.

@Macarlo, Inc.
@Macarlo's Shareware & Web
OS/2
Java Lobby Member
Java Site Accredited

[TOP] [HOME] [INDEX]