Project 2000

Century Support Products for CA-IDMS


Currently, Project 2000 provides six products that provide a smooth transition for century conversion. They are
Schema/Set Analyzer Date Converter
ADSO Source Analyzer Culprit Source Analyzer
Date Simulator Y2K BIFs

Project 2000 Date Ager.

The year 2000 is coming. Are you ready?

Schema/Set Analyzer

To resolve the century problem, we first need to know exactly where the problem is. Therefore all sets and indexes (user or system owned) that have a date as a key must be identified. Obviously, the key to a set may contain several date fields. All date fields in the key, that are represented by a two digit year, will be a problem. Be careful. One record can participate in many different sets and indexes.

The HSL Project 2000 Schema/Set Analyzer is a batch application that directly reads the data dictionary. All schemas in a dictionary or selected schemas can be analyzed. Wild cards can be used to specify which schemas to analyze.

The Schema/Set Analyzer has very flexible user-defined criteria to specify character strings that, when encountered in a data element name, are and are not indicative of a date. For example, you can identify sets sorted on data elements whose names include DATE but not if the DATE is part of UPDATE; or sets sorted on data elements whose names include CC but not if the CC is in the word ACCOUNT or ACCT; MO but not in AMOUNT; etc. Element names can be parsed into tokens (split at hyphens). Each include/exclude criteria can be applied at the beginning of a token, at the end of a token, anywhere within the token, or only when the entire token exactly matches the string. (For example, find sets sorted on data elements whose names have a token with DT at the end - this would identify CONTRACT-EXPIRDT but not REPORT-WIDTH). The criteria can also be applied to the entire element name. A scripting language allows any sequence of include/exclude criteria to be applied at the (beginning, end, middle, entire) token/word. This allows you to reduce the number of false-positives without excluding legitimate date references.

The data element specified as the sort key in the schema definition may be a group item whose name does not reflect any date usage. However, that group element may contain subordinate elements whose names are indicative of dates. The Schema/Set Analyzer identifies these sets.

Whenever a set that is sorted on a date field is identified, all elements in the sort key (including subordinate elements) are listed including the picture clauses of the elements. This allows quick identification of elements that already have 4-digit years.

Date Converter

Using a proprietary date representation, the Project 2000 Date Converter make existing applications century compliant without a restructure. Dates will be century compliant in the existing field.

What date formats does the Date Converter Support?

Project 2000 supports ANY two digit date format -
YYDDD (Julian Dates)

For example -

Suppose you have purchase order numbers that are YY plus a number, and that field is a key field in a sorted or index set, can we fix it???

You bet!

Universities often have a record with a key of YY plus a one byte semester number (971, 972, 973, 981, 982, 983,. . . ). Can the Date Converter make your life easier???


We have had a number of phone call about the issue of date formats, so let me make this perfectly clear -


Wait a minute what about the MMDDYY format?

Remember, only when dates are sorted with the YEAR as the major key will they be a problem.

What does using the Project 2000 Date Converter mean?

Database records will not need to be expanded
No unload/reloads
No restructures
No increase in buffer utilization and I/O
Page sizes do not need to be changed
Buffer sizes do not need to be changed
No additional DASD costs
Every program and dialog will not need to be re-compiled and tested
Indexes will not need to be re-built

Using the Project 2000 Date Converter provides for a seamless conversion for database administration, and a minimal impact on the applications.

Does Date Converter support VM, VSE, XA, ESA?

What releases of CA-IDMS are supported?

What are the hardware/software requirements?

What is not supported?

These are easy questions.

You must have IDMS (any release, any operating system, any hardware platform). We do recommend you be on at least release 12.X of CA-IDMS, but it is not a requirement of the Date Converter. If you don't have CA-IDMS click here.

So, what is required to implement the Project 2000 Date Converter?

HSL supplies all required programs and documentation. One database record type is modified at a time. The conversion to century compliant applications can occur gradually.

Using the Project 2000 Date Converter all sort orders (sets & indexes) are preserved. The data base is not changed. A data base procedure will hash and unhash the date values as necessary. The hashing date values is transparent to the database and the applications. If a program walks a sorted set (or index) the records will be retrieved as follows:

981231 - Dec. 31, 1998
991231 - Dec. 31, 1999
001231 - Dec. 31, 2000
011231 - Dec. 31, 2001

Most programs function properly with little or NO modification!! All of your current products and tools are unaffected. Everything works FINE!!!! The dates are hashed and unhashed using a database procedure. The records are returned to OLQ, DMLO, etc. in there original format. The way the data is stored on the disk is the only thing that is different. Actually if we think about it, that hasn't changed either - it is still just ones and zeros.

OK - What about CALC records?

What about them? If you are asking do they need to be converted, the answer is - NO. Sure we can do them, but what's the point? For example, let's assume you have a CALC record with a date key (YYMMDD). A key value of "000101" will work just as effectively as "20000101". The more things that you change, means the more things that can go wrong!

OK - Well what about overhead?

Good question! Since every time a database record is called the database procedure is called to hash and unhash the date, there must be some overhead. (There is no such thing as a free lunch!). First all the database procedures are written in assembler (a requirement for 14.0). In benchmark tests on an IBM 9121 Model 511 single processor each call intercepted by the Date Converter database procedure incurred .000016 CPU seconds (that's sixteen millionths of a cpu second!!!!) A million database calls will cost 16 cpu seconds. Obviously, all computers are different, and your numbers may be different. The point is there will be NO significant performance change!

What must be changed?
  • Since the dates are being returned to the applications in the original format any program that compares dates must be modified. Project 2000 provides subroutines that can assist in date comparisons routines.

  • Programs that perform date calculations MAY need to be modified. If a program adds a positive number to a two digit year, the high order position will typically be truncated. For example 98 + 3 = 01. In this example no programming changes would be necessary.

  • Dialogs or programs that issue a

    RETURN DB-KEY INTO db-key-v FROM index-set-name (USING index-key-v)

    will need to be modified. Obviously, these programs will only need to be modified if the key (index-key-v) is a date field. To facilitate these modifications, the Project 2000 Date Converter provides a subroutine that must be called prior to issuing the command. If the RETURN command returns a symbolic-key to the application program, the same procedure will be required.

  • Programs that contain an internal sort will need to be checked. Since all dates are being preserved in their original format, if a program sorts on a two digit year the sequence will be wrong. It is suggested that these programs be modified to add a one position high order century indicator to the sort sequence.

  • Since dates are being preserved in their original format, special attention will need to be made for batch programs that extract and sort on dates. Typically, this might be an extract, sort, and print. The initial reaction might be to modify the extract program to add a century indicator to the date field. This would require modifications to both programs, the JCL, and the sort utility. Fortunately, many software companies have recognize that if the sort utility could identify that it was sorting a date, they could accommodate the century much like Project 2000. IBM's standard DFSORT utility is one such product. Click here and check out IBM's web page on century support for DFSORT. Other software companies are following this same concept. Check with your vendor. What this means is no program changes!!! Change one JCL statement and the batch application is century compliant.

NOTE -Although some program changes may be required in the scenarios cited above, most of these changes are minor. Keep in mind using the conventional conversion methodology of re-structuring the data base EVERY PROGRAM MUST BE MODIFIED.

How do we implement the changes?

Good question!! This is the best part!

First, since the database procedure does not change any existing records (records with years less than 2000), it could be put into production today. It is completely invisible to the users, the database, and the application programs. We recommend that you first install it in your test CV, and verify that the dates are returned in the correct sequence (97, 98, 99, 00, 01, 02, 03, . . .).

Secondly, since the database hasn't changed the record formats are all the same. A few programs will need to be modified to call the Project 2000 sub-routines for date comparisons, date calculations, etc.. These programs can be changed, tested and migrated to production independently. Obviously, to minimize the work effort and to assure all programs are modified, it would be logical to coordinate the changes, perhaps by application.

If you have ever re-structured a large application you can appreciate this implementation strategy. If you re-structure the database - all programs, dialogs, work records, maps, elements, database changes, tables, etc. have to be migrated and implemented at precisely the same time. Have you ever tried to juggle 5,000 balls?

This probably sounds too good to be true - so take a few minutes and review what some of our customers are saying about the Project 2000 Date Converter.

Click here to review some customer comments. Most of these people have finished their Y2K effort.

Still in doubt?

Do you want more references?

Give us a call (1-800-779-2802) or email us and we will send you more references AND their phone numbers - CALL THEM!!! Your conversion cost will be significantly lower (est 75% LOWER!!!) and you will finish ON TIME!!

After you license the Date Converter - if you are interested in getting some help to convert your applications, contact Sirius Solutions. Sirius has helped a number of our customers (Valley Lab, United Technologies, Allied Signal, University of Miss.), become Y2K compliant. Check out their web page and give them a call (970-870-6724).

ADSO Source Analyzer

The Project 2000 ADSO Source Analyzer can be used to identify dialogs that need to be modified. This product is a batch application. When the ADSO Source Analyzer is targeted at a dictionary all process code within the dictionary can be reviewed or by using a masking feature only selected process code will be reviewed.

Using changeable selection criteria, the source analyzer performs a string search for the selection criteria. When code is discovered containing the selection criteria, the line is displayed with the various picture elements.

Current features in the product include:

  1. Very flexible user-defined criteria specify character strings that are and are not indicative of a date when encountered in a data element name. For example, you can find all references to data elements whose names include DATE but not if the DATE is part of UPDATE; or all references to data elements whose names include CC but not if the CC is in the word ACCOUNT or ACCT; MO but not AMOUNT; etc.
  2. Data element names are parsed into tokens (split at hyphens), and each include/exclude criteria can be applied at the beginning of a token, at the end of a token, anywhere within the token, or only when the entire token exactly matches the string (e.g., find all references to data elements whose names have a token with DT at the end - this would identify CONTRACT-EXPIRDT but not REPORT-WIDTH).
  3. Picture of each data element is retrieved from the data dictionary; for group elements, pictures of subordinate elements are retrieved from the data dictionary; this allows quick identification of elements that already have 4-digit years, and allows identification of data elements that are formatted for external display.
  4. Date-related data elements are identified on maps (as well as in process source); report shows screen position (to help identify if it's just a current date displayed on corner of screen), external editing automatically applied by mapping facility, and any map edit modules that may be validating or formatting the date.
  5. Execution time and CPU consumption is largely dependent on number of include/exclude strings specified
  6. Comments and quoted strings can be included or excluded
  7. Choice of printing all lines with date references annotated (useful during implementation to see how the date-related logic fits into the overall program flow), or printing only affected lines (useful for analysis), or printing summary information only (useful for impact analysis and project estimating)
  8. Dialogs can be selected for analysis based on a mask that can include wild cards (e.g., scan all dialogs whose names start with MRP)
  9. If a module is used by several dialogs, it is analyzed and listed only when first encountered - subsequent uses of the module encountered in the same execution reference the first occurrence of the process, but do not show detail.
  10. Program is designed to directly look for specific character strings that indicate dates, not to build a cross-reference of all data items (a la Viasoft/Alliance) and then trace data item names back to programs. This is a dialog-centric analysis (show all date references in a group of dialogs), not an element-centric analysis (show all dialogs that use this data element). The data dictionary allows reporting to show what records contain an element and what programs use those records.

Recent enhancements . . . .

  1. Unlimited number of process modules can now be scanned in a single execution
  2. The new release is VERY context sensitive. The ADSO Source Analyzer can now identify HOW data elements are used (in move statements, in calculations, in greater/less than comparison, etc.). This is very useful for identifying if a change is needed for correct functioning in the Year 2000 (e.g., moving a 2-digit year field to a 2-digit year field doesn't really cause any problems, but checking to see if one 2-digit year field is greater than another 2-digit year field DOES cause a problem, and calculations involving 2-digit years are a problem).
  3. When a statement is on multiple lines, the entire statement containing the date reference is now printed.
  4. The new release is lightning FAST.

Sounds good. Tell me more about some of the reports.

Analysis Reports
For each analyzed dialog, the ADS Source Analyzer report includes the following sections (each can be suppressed, if you so desire).

Component List - A list of components (records, maps, subschemas and processes used by the dialog). In this section, an * preceding a record, map or process name indicates that it was already analyzed as part of another dialog in the same execution. (Statistics from the earlier analysis will be included for this dialog). An @ preceding a module name indicates that it is defined duplicate times within the same dialog. (It will only be analyzed once and statistics from the analysis will only be counted once).

Statement sequence listing - A list of references to date-related fields in the sequence in which they appear in the program. First, complete COBOL-like definition of all date-related fields are printed. Next, information about date-related fields found on maps is printed. Then, statements with date-related record elements, literals, BIFs or system-dates are printed in the sequence in which they appear in the dialog. The entire statement is printed, not just the line with the date reference. Each date-related field is annotated, its picture clause is displayed (for a group element, pictures of subordinate elements are displayed), and an explanation of how the date field is used is shown.

Dataname sequence listing - This section lists all of the date-related record elements alphabetically and for each, shows all statements that reference the record element. The record element is annotated within the statement, and an explanation of how the element is used is shown. Following the record elements, a listing of system date fields, date BIFs and date-related literals are displayed, along with all statements that use those items.

Dialog recap - The dialog recap lists all dialog components and provides statistics for date-related references by component, and a total for the entire dialog.

Run recap (only at end of entire run) - This section presents totals for the entire run. Statistics from records, maps and processes that were encountered multiple times are only included once.

Diagnostic Reports
Diagnostics are printed to the DDNAME of SYSOUT. These diagnostics include statistics about storage utilization, and indicate the progress of the execution. Any error messages also appear on this report. Much of the information listed on this report can optionally be suppressed.

Error messages occur when the ADS Source Analyzer cannot analyze a statement. This often occurs in dialogs where process source has changed, but the dialog has not been successfully regenerated.

Click here for the installation manual.

Culprit Source Analyzer

The Project 2000 Culprit Source Analyzer can be used to identify Culprit programs that need to be modified. This product is a batch application.

Using changeable selection criteria, the source analyzer performs a string search for the selection criteria. When code is discovered containing the selection criteria, the line is displayed with the various picture elements. If a selected field is moved to another field (i.e.. MOVE XXXX-YEAR TO MISC-INFO) then the source will be re-scanned and the new field (MISC-INFO) will be reported. This process (Date Field Explosion) will be repeated as often as necessary.

Date Simulator

Product Brief
Installation Instructions
Customer Comments
Date Simulator PTFs
Julian/Gregorian Date Converter
The Julian/Gregorian Date Converter is a FREE COBOL
utility program. This program converts dates (Julian to
Gregorian or Gregorian to Julian). This program also
determines the day of the week. This is particularly useful
if you have been using the ACCEPT DATE or the
ACCEPT TIME commands. These are illegal verbs
for CA-IDMS DC COBOL. For more information on the
problems with these verbs click here.

Product Brief

After the programs have been modified, use the Project 2000 Date Simulator to test the application. The Date Simulator allows you to test the application with "artificial dates and times". You can set the Date Simulator by a given userid, task code, dbname, dbnode, lterm id, and/or DCUF test number. Users can always test with the current date/time .

With the Project 2000 Date Simulator two types of "CLOCKS" are available - RUNNING CLOCKS and STOPPED CLOCKS. A "RUNNING CLOCK" means the date and time are constantly changing (the date/time are offset from the real date/time by a specified increment or decrement of time). A "STOPPED CLOCK" means the date and time are always the same. You can establish multiple clocks. For example, you might want to establish several "STOPPED CLOCKS" (DEC1599, FEB2900, AUG0801 - my birthday, etc.). When a programmer uses one of those clocks it is always the same date and time -02/02/29 12:00:00 (YY/MM/DD HH:MM:SS). You probably also want to establish several "RUNNING CLOCKS", (i.e. 2YRUN - two years from today and running, 6MORUN - six months in from today running, ESTRUN - Eastern Standard Time Running, etc.).

The last example ESTRUN, is another very cool concept. Assume your data center is in Edwardsville, Illinois (central time zone in the United States), and you have users in different time zones around the world. Today all of the users have the same date and time (central time). However with the Date Simulator you could set up different clocks for the different time zones, the ESTRUN clock is one hour ahead and running, the MNTRUN clock (mountain time zone running) is one hour behind and running, etc.). That's right - you can have clocks that have dates and times prior to the current date. Next identify which users are in each time zone, and now each user has their correct date and time.

NO - You can not set the date backwards to completely avoid the year 2000 problem.

Some task codes may be defined that will never return a simulated date/time. For example, programmer/analysts must be able to test program modifications with a simulated date/time. When a bug is discovered and the programmer/analyst enters IDD to make the appropriate corrections, the date-last-updated in the dictionary should reflect the real date/time. Excluded tasks will always receive the real date/time regardless of the current clock in effect for the user. The following tasks are currently defined as excluded tasks;


Century testing is accomplished without working weekends or affecting other applications.

Other commercially available products allow individual batch jobs to execute with a pseudo-date/time. While these may be used to start up an entire CA-IDMS CV with a pseudo-date/time, the entire CV session for all on-line tasks and CV batch jobs that update the database will execute with the pseudo-date/time. There are serious ramifications regarding journaling, logging, back-up and recovery, etc. Date Simulator honors all CA-IDMS journaling, logging, back-up and recovery, etc. without any special consideration.

Are there any problems we should be aware of?

The biggest problem seems to be customers executing obsolete code. The ACCEPT DATE and ACCEPT TIME commands in COBOL are illegal verbs for CA-IDMS DC COBOL. Even though they work, they lead to a supervisor call (SVC), which inhibits system performance and may crash the CA-IDMS/DC system (see the CA-IDMS DML Reference -- COBOL for additional information). Unfortunately, the alternative -- the GET TIME INTO usertime DATE INTO userdate command returns the date in Julian. As a public service to the entire CA-IDMS community, HSL is providing, free of charge, the following routine which will modularly replaces the ACCEPT DATE and ACCEPT TIME command.

One other item to watch out for is OLQ SORT. OLQ is not in the excluded task list. When performing an OLQ SORT CA-IDMS writes scratch records with a date and time stamp on each record. Since time doesn't usually stand still (unless your in a line) the records are in ascending order, without duplicates. If you use a Date Simulator "STOPPED CLOCK", OLQ gets a little confused. Do not use a "STOPPED CLOCK" with OLQ SORT.

Date Simulator and zIIP. Date Simulator does not work in environments running with the zIIP option turned on. If a client uses zIIP, they must turn that option off in the test environment for the time periods that Date Simulator testing will occur. While zIIP must be on in test environments for certain "system tests", it can just as easily be turned off at mutually exclusive times when Date Simulator testing will occur. Date Simulator was not designed to be used in a production environment when the full benefit of zIIP processing can occur.

Click here for the Julian/Gregorian Date Converter. It's a freebie.

Click here for the Project 2000 Date Simulator installation instructions.

Click here to review customer comments.

Click here for the current PTFs for the Date Simulator.


The Y2K BIFs are here!!

Project 2000 Date Ager

The Project 2000 Date Ager is a tool that will physically age the dates on your data base. This is particularly important since all of the records have current date information (97, 98, 99). To effectively test the applications the dates need to be moved forward 2 or 3 years so they cross the century barrier (99 - 00). To do this we first need to identify all of the date fields. The Project 2000 Schema/Analyzer has been modified to identify all date fields. This utility will now report on all date fields (not just key information). The Schema/Analyzer will identify the location of each date field in a record and the format (display, comp3, etc.). Don't worry - be happy - If you license the Date Ager - you get the Schema/Analyzer for

After we have identified all of the records that contain date fields, you need to consider which fields you want to age. Perhaps, you don't want to age all date fields. For example, you may not want to change birth dates or service dates . . . however it might be cool to knock 3 or 4 years off your age. Dates can be moved forwards or backwards.

You also can age different fields by varying amounts. For example, you may decide to generally move all dates forward 3 years, but certain fields should only be advanced by 18 months. Dates can be shifted by specifying any combination of years, months and days. The Date Ager can process any date between Jan 1, 1601- Dec. 31, 2399, and it can process almost any imaginable date format, including dates with 2, 3, or 4 digit years. If you have two digit years and are using a windowing technique (see the HSL Project 2000 Date Converter), you can specify the beginning of the 100 year window.

The Date Ager can handle thousands of different date formats. The Date Ager supports display, packed, and both full word or half word binary dates. Date fields that have imbedded characters are also supported, for example "/" or "." (08/08/52 - my birthday;-).

The Date Ager also supports date fields that are the number of days from an arbitrary origin. Some companies have an arbitrary "start date" for example, of Jan 1, 1940. Date fields are just "counters" of the number of days following the "start date".

Date fields that contain information other than dates are also supported. For example, purchase order numbers might consist of YYMM plus a six digit sequential number of the following format "YYMM******".

The Date Ager handles all of the normal date formats plus thousands of unusual formats. Personally, I have never seen dates stored on a data base like this, but if you have it we can handle it:

Sunday, the 15th day of April, 2001

Some times date fields contain information that are not dates. For example, assume we have a field called SHIP-DATE (format YYMMDD), in our SHIPMENT-RECORD, and SHIP-DATE is a key field in either a sorted set or index. It is not unusual to have SHIPMENT-RECORDS with SHIP-DATE values of low-values, spaces, all zeros, valid dates, all nines, and high values. The Date Ager recognizes that these are not real dates, and this data is not not changed.

The Date Ager is a local mode batch application. It sweeps each area, re-calculates the new dates, and updates the record. It is fast and extremely efficient. Note - Be sure to have a good back up of your data base before executing any local mode application.

If a date field is a key in a sorted set or index, a typical program would execute for an extremely long time. As each record is modified, it must be repositioned within the set, and the index entries would be moved to different SR8 record occurrences. The HSL Date Ager circumvents this problem by temporarily changing the set definitions to unsorted. Since a constant value is being added (or subtracted) to each record (days, months, or years), the relative sequence of the records after the aging process is the same as the original sequence. By temporarily overriding the set order, the repositioning of records within the set is avoided. While modifying the records, the HSL Date Ager also creates a file that can be used directly by the standard IDMS MAINTAIN INDEX utility to update the symbolic values in index structures with the adjusted dates. Each database area is swept only once and repositioning of records occurs only when a date to be aged is part of a CALC key. (In this case, it is necessary to reposition the record so that is chained into the CALC set of record's new target page).

The Project 2000 Date Ager is compatible with all releases of IDMS from 10.2 through 14.0, and runs under any mainframe operating system. It is fully compatible with and complimentary to the HSL Date Converter, HSL Date Simulator, and all other HSL Project 2000 tools.

Click here for the Project 2000 Date Ager PTFs.


Click here to return to the Project 2000 page.

Click here for pricing information.

Click here to return to the HSL main page.

Hybrid Systems Ltd., Inc.
200 University Park Drive
Edwardsville, IL 62025

E-mail: HSL