Millennium Language Extensions

Table of Contents

  • When is MLE a Year 2000 Solution?
  • Inferring the Correct Century Using a Century Window
  • What is MLE (aka Emily)?
  • What You Gain from Emily
  • What You Do Not Gain from Emily
  • Where Emily is Applicable
  • Try out Emily's Wings
  • Emily Scenario
  • Getting Started with MLE
  • A Simple Date Problem
  • A Simple Solution
  • Windowing with Language Environment
  • When is MLE a Year 2000 Solution?

    The three main approaches for handling date data are:

    The pros and cons of each of these approaches and a description of the methodology and tools offered with VisualAge 2000 can be found in the Inventory and Assessment material. For those date data for which century windowing is your choice, the Millennium Language Extensions (MLE) offered with the IBM COBOL compilers may significantly reduce your source-code updates, and thereby improve your schedules.

    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 two-digit years lie. Programs can then infer the correct century, depending on where in the century window the two-digit year lies. For example, if the range of your century window is January 1, 1956 through December 31, 2055, and the two-digit year is >= 56, the century is inferred to be 19; otherwise, if the two-digit year is <= 55, the century is inferred to be 20.

    There are two types of century windows: the fixed window and the sliding window. The fixed window doesn't move after it has been established; the sliding window moves forward with the system date.

    What is MLE (aka Emily)?

    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. Conceptually, 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. MLE is pronounced "Emily" and is referred to as such in this section.

    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 Emily provides even more assistance, essentially providing the logic that you would otherwise have to code yourself.

    With Emily, you have the ideal situation: the ability to fix programs with no PROCEDURE DIVISION changes. While century windowing is the quickest and most powerful feature, field expansion is also supported, making Emily the easiest way to implement permanent internal bridges.

    What You Gain from Emily

    Using Emily, you can change your application data definitions in the DATA DIVISION to indicate which data items represent windowed dates and how you want the window to be defined. The compiler can then automatically implement the associated windowing changes, in many cases without your having to code the associated logic changes in the PROCEDURE DIVISION. Because it is compiled in the context of you program, it is the best performing windowing solution. So, where windowing is your approach of choice, Emily might help reduce the programming time and effort needed to implement a windowing solution and simplify subsequent maintenance of your application programs.

    Emily also enables a flexible and comprehensive mixing of windowed dates with expanded dates within a program, allowing you to:

    You can use Emily to help with date variable identification by identifying obvious date variables and letting the compiler diagnostics lead to you the ones that you missed.

    Using Emily 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.

    What You Do Not Gain from Emily

    Emily is not a silver bullet. It is important to understand that, whatever the merits of Emily, it does not render unnecessary all the year 2000 work at your enterprise: a windowing solution may not be an acceptable approach for all your applications. While it may 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. And there will be cases where the limitations of Emily require 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 1900-1999, 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 two-digit year part of dates with respect to the 100-year window for the program.

    See the MLE Guide for the COBOL contexts in which you cannot specify a windowed date.

    Where Emily is Applicable

    Any host application running under Language Environment and any workstation application using IBM COBOL or PL/I products can use Emily. But consider three areas:

    Using Emily for Year 2000 Work Only

    To use Emily effectively, you need to keep in mind some key principles used in developing these extensions:

    1. The programs with which you use Emily, that are to be re-compiled with date semantics, should be fully-tested and valuable assets of the business. The only relevant limitation is that any two-digit years in the programs are restricted to the twentieth century.

    2. The primary objective in using Emily is to extend the useful life of these programs, as they are currently specified, into the twenty-first century.

    3. The source changes must be held to the bare minimum, preferably limited to augmenting the declarations of date data items in the DATA DIVISION.

    4. A secondary objective is to support limited kinds of maintenance and enhancement, especially to allow dates with two-digit years to be used in conjunction with expanded year dates. This could assist you in incrementally introducing expanded dates into your applications.

    5. Dates with four-digit year parts are interesting only when used in combination with windowed dates. Otherwise, they behave as non-dates, where dates are permitted at all.

    Source Conversion

    The level of source source code is an important consideration. If your programs have been compiled with the OS/VS COBOL compiler, you will probably have to convert the source, which is at the ANSI 68/74 level, to ANSI 85. The CCCA, COBOL and CICS Command Level Conversion Aid (5785-ABJ), can be a big help with the conversion, very often doing the entire job for you. If you are going to use VisualAge COBOL for your year 2000 work, you can use the conversion facility in a snap.

    If your programs have been compiled with VS COBOL II or later, no conversion is necessary. You can mix Emily programs with unchanged older modules, and only those programs with date logic need to be recompiled.

    Sub-systems with No Windowing

    The Millennium Language Extensions permit the specification of windowed dates for sorting and merging, in conjunction with sort products such as DFSORT. However, the following subsystems do not support windowed dates:

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

    See The MLE Guide for details.

    Try out Emily's Wings

    A pilot project is always something to consider for your year 2000 work. In particular, you may want to take Emily for a spin to further investigate its viability and merits for your use. Be aware that this may involve a migration if you are not already using a year 2000 ready compiler. But, you were going to do that anyway for your windowing, right?

    Emily Scenario

    If the century window approach can be used, then Emily is applicable. If Emily is applicable:

    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.

    Test:

    Getting Started with MLE

    If all this seems a bit daunting, here is a brief sample to show how simple it can be to get started using Emily. First a look at a specific problem, then how to use the features of Emily for a simple solution.

    A Simple Date Problem

    Let's say your program compares the date that a video tape was returned with the date it was due back, to see whether to impose a fine. These two dates are stored in the file as 6-digit Gregorian dates; that is, YYMMDD. The program looks like this:

        01  Loan-Record.
            05  Member-Number   Pic X(8).
            05  Tape-ID         Pic X(8).
            05  Date-Due-Back   Pic X(6).
            05  Date-Returned   Pic X(6).
            ·
            If Date-Returned Greater than Date-Due-Back Then
               Perform Fine-Him.
    

    If the tape was due back on 14 September 1998, the contents of Date-Due-Back will be 980914. If it was returned on 12 September, the contents of Date-Returned will be 980912. So no fine is imposed, because Date-Returned is less than Date-Due-Back.

    But let's go forward in time and see how this reliable program behaves in January 2000. If the tape is due back on 2 January 2000, but is returned on 31 December 1999, the contents of the fields will be:

    Date-Due-Back
    000102

    Date-Returned
    991231

    As you can see, Date-Returned is much larger than Date-Due-Back, so the program will impose a hefty fine for being 100 years late.

    A Simple Solution

    But what if the program recognized that the year 00 was in fact 2000, not 1900? Then 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.

    Fortunately, IBM COBOL allows for this, but you have to do a few things to make it work. Here's what you have to do:

    1. Decide on a century window, and tell the COBOL compiler about it. A century window is a period of 100 years that the compiler uses to determine the century in which a two-digit year falls. Take into account how far back you historic data goes and how far into the future your date data will be. If you decide to use 1950-2049 as your window, then COBOL evaluates dates like this:
      If the year is between 50 and 99, then it's really 1950-1999.
      If the year is between 00 and 49, then it's really 2000-2049.
      You use two compiler options to tell the compiler about the &cwin:

      DATEPROC
      Tells the compiler to enable the windowing process. You specify this as either DATEPROC(FLAG) to get some helpful diagnostic messages, or DATEPROC(NOFLAG).

      YEARWINDOW
      Tells the compiler what the century window is. There are two ways of doing this:
      • For a fixed window, specify it as a four-digit year. For our example, we'll use YEARWINDOW(1950) to give us a fixed window of 1950-2049.
      • For a sliding window, specify a minus sign and a two-digit number. For example, YEARWINDOW(-48) gives us a sliding window that starts 48 years before the year that the program is running. So if the program is running in 1998, the century window is 1950-2049, and in 1999 it automatically becomes 1951-2050, and so on.

    2. Tell the compiler which fields to treat as date fields with two-digit years, so it knows when to apply the century window and when not to. You do this by changing the COBOL source program, adding a FORMAT OF DATE clause to the date fields that you want handled in this way. So the record layout now looks like this:
          01  Loan-Record.
              05  Member-Number   Pic X(8).
              05  Tape-ID         Pic X(8).
              05  Date-Due-Back   Pic X(6) Format of Date is yyxxxx.
              05  Date-Returned   Pic X(6) Format of Date is yyxxxx.
      
      More about the FORMAT OF DATE clause later, but for now it's enough to know that it has two or four Ys and some Xs. Two Ys means that the field is an MLE date window, which means that COBOL will apply the century window to the date.

    3. Compile the program. It's best to use DATEPROC(FLAG) for the first few compiles, because the compiler gives you a diagnostic message for every time the program refers to one of your new FORMAT OF DATE fields. So you'll get a diagnostic for the IF statement, but we were expecting that. But there might be somewhere else in the program where it uses Date-Due-Back, so you need to check that these statements will still work properly.

    4. Test the program.

    5. 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.

    So you can see that it's quite simple to introduce a windowed date concept into a COBOL program. All you have to do is decide on a century window, change some data items, then recompile the program.

    Windowing with Language Environment

    Two code examples using a Language Environment century window (sliding window) are shown in COBOL window example .