Do yourself, and your company a favor - read the entire letter. Linda has thoroughly studied the IDMS Y2K issues, and has an experts grasp of the problem.

Subject:	IDMS & 6-digit dates - No need to expand, please read
From:	HALL Kate
Date:	1997/12/17

I have been forwarding Y2K questions and comments to our resident Y2K expert. She has spent quite a bit of time on Y2K and has responded to the list with some of our strategies and experiences. You'll find that some of the "commonly understood" information - like "you have to expand 6 digit dates, restructure, expand the database....." - are not true.

Enjoy!

Kate Hall

From:	OSOWETSKI Linda
Sent:	Tuesday, December 16, 1997 4:57 PM
To:	'IDMS-L@UGA.CC.UGA.EDU'
Subject:	IDMS & 6-digit dates - No need to expand, please read

Hello IDMS Users,

The intent of this note is to pass on Y2K information to the IDMS community. There seems to be a lack of knowledge amongst us as to what's currently available in the market for IDMS. Having 12 months of Y2K IDMS experience under our belts, I felt that our team had experience and knowledge which could assist you.

The main issue is whether or not you have to expand to 6-digit dates in an IDMS database. The answer is "NO". This note will cover:

• 2-digit years for CALC keys (using HSL's Date Converter)
• 2-digit years for indices (using HSL's Date Converter)
• 2-digit years for sorting (using Syncsort, DFSSORT, & HSL's date hashing / unhashing routines available with HSL's Date Converter)
• 6-digit IDMS date BIF's (yes, they do handle year 2000 dates)
• aging both IDMS database files & non-database files
• date simulation (batch & online)
• and anything else I can think of

Yes, the information below is my opinion only, but that opinion is backed by the practical experience of our project team which currently stands as 12 dedicated staff. We completed our analysis and estimates in Jun '97 and have been converting code since that time.

I'd like to take a moment to introduce myself so you can make your own judgement as to whether or not the information listed below is credible. My name is Linda Osowetski, Managing Consultant for MCI Systemhouse, currently located in Houston, TX. I have 12+ years of IDMS experience with 6 different clients. I am currently managing a Year 2000 project for one of our clients which commenced in Jan '97 and is on schedule for completion in Dec '98. The project includes 2 IDMS applications totaling 3000 days of effort to become Y2K compliant. These applications use 6-digit dates, meaning 2-digit years, and no, we are not expanding dates.

6-Digit Dates in IDMS Database Records
---------------------------------------------------------------
HSL's Date Converter solution / product does indeed work with CALC and index keys via a DB procedure. We have thoroughly tested the product and have it successfully running in our production environment. The hashing algorithm executed via the DB procedures handles all situations in IDMS where a date is embedded in a key, including indexed sets. The details of the product are provided on HSL's web page - www.hslinc.com - and every IDMS Y2K person should be reading this. I strongly recommend this product unless your database is very small. The product not only works fantastically, but it is cheap, is backed by excellent support staff, and is very simple to install and support.

If you have any questions you should be contacting HSL (1-800-779-2802) directly. Phil Loethen is Director of Marketing (& very knowledgeable about the technical aspects of their products) and John Holtmann is Director of Technical Support (he'll be able to answer any question a DBA can throw at him). Again, I strongly recommend that every IDMS shop be familiar with this tool.

NOTE: HSL's Date Converter product also includes common routines for 6-digit date comparisons and determining century (based on your chosen century window of course). These routines are "free" with the Date Converter so why would you code them yourself? (See "Sorting with 6-Digit Dates" for information about HSL's hashing & unhashing routines also available with their Date Converter product.)

Sorting with 6-digit Dates
----------------------------------------
I'm sure you are all aware that Syncsort's DISKSORT and IBM's DFSSORT both have century windowing features in their latest releases which handle 2-digit year sorts. This should cover all file sorts where the location of the date fields can be identified.

If you have a sort file where the date in the sort key may not always be in the same position (we have this situation in our client's shop), then DISKSORT & DFSSORT will not work. However, there is a viable solution using HSL's hashing & unhashing routines which are available as part of their Date Converter product. These routines use the same logic as the DB procedures which allow 2-digit Y2K years to sort after 2-digit pre-Y2K years.

Our example: "n" extract programs creating "n" files which are all being merged together and fed through a single Syncsort step. The sort key is a 100-byte field. Except for the 1st 22-bytes, the remaining contents of that sort key are different for each merged file and dates can exist anywhere & everywhere in those remaining 78 bytes. (Once sorted, the files are split back into separate files and fed into "n" reporting programs.) We are handling the situation by having the extract programs "hash" the date(s) (using HSL's date hashing routines) prior to writing them to the output file. This allows the single Syncsort step to correctly sort "00" after "99". Then, each of the associated reporting programs "unhash" the date(s) (again, using HSL's routines) prior to writing it to their report / file / etc..

IDMS 6-digit Date BIF's
------------------------------------
After many discussions with CA, implementation of a number of apars (to our Release 12.0 environment) and a lot of testing by 2 of our analysts, the 6-digit date ADS/O built-in-functions now work. This includes DATEDIF, DATEOFF, GCDATE, CGDATE, JCDATE, etc.. CA is using the century windowing technique using "69" as the break-point. The only downfall to their solution is that their window is hard-coded. However, for those shops who are using 69 or less for their break-point, this will not be a problem. Contact your CA rep for the apars.

Aging Data Files (IDMS & non-IDMS)
---------------------------------------------------------
Unless you have a small shop or have few dates in your database, you should be shopping for a date aging tool. We are having much success with the following products:

• For $10,000 (U.S.) we purchased Advanced Software Product Group's (ASPG, 1-800-662-6090) Date/2000 File Aging product. It ages dates forward or backward, in days, months or years. It also updates the file in place. We have been using the product successfully now for 2 months.
• Our client already had CA's Datamacs/II CA-IDMS product which facilitates creating, modifying, unloading, and re-loading an IDMS database.

Using these 2 products together, we were able to have an analyst age 300+ dates on 100+ IDMS records (including the database unload from production & reload to test) within a 6-7 day period. Add a few more days to create standard JCL to execute the process and document the procedures for the other analysts. Now that this is set up, it takes an analyst less than an hour to age a database (excluding run time for unloading / loading, etc.). Is saving us a significant amount of effort.

For aging a non-database file, ASPG's product offers a panel to guide you through the process.

NOTE: CA's Datamacs product does arithmetic on numeric fields, but not date arithmetic. Therefore it cannot handle aging days, months, or years which involve crossing the century.

Date Simulation (Online & Batch)
----------------------------------------------------
The only product I know of on the market which runs in the IDMS-DC environment is HSL's Date Simulator. It will control date simulation by userid, task code, dbname, dbnode, lterm, and/or DCUF test number. It will also allow specific tasks (such as IDD, ADSC, MAPC, etc.) to be defined as excluded. Very flexible.

NOTE: Tool does not simulate dates retrieved via ACCEPT STATISTICS (& it shouldn't) as this date is used by the IDMS journals. NOTE: Vendors of other Date Simulators have tried to tell me that they can handle IDMS by controlling it at the CV level. This is NOT acceptable as this will corrupt your journal files!

For batch date simulation, there are many tools on the market which will work. Before you select one, just ensure that the tool can "exclude" jobs from date simulation (such as your IDMS CV jobs, production jobs, etc.) to assist you in controlling your testing. We are using Compuware's Xpediter/Xchange product as our client had Xpediter (batch COBOL debugging tool) installed and their simulation tool is invokable from Xpediter.

Other Information
----------------------------

• Testing Environment: My opinion on the requirement to set up separate IDMS CV's and MVS lpar's is that they are not required for Y2K application testing. Our project has successfully been able to disassociate the application changes from much of the underlying systems environment (including the operating system, DBMS software, etc.). This has removed a number of the dependencies and therefore significantly reduced the effort required to manage testing and implementation. We have been able to do this by maintaining our 6-digit dates and thereby not requiring to retrieve the century from COBOL, ADS/O, Culprit, etc., or MVS. So although we require our IDMS Release 12 platform to be upgraded prior to 2000, prior to that we can convert & implement our application changes independent of IDMS. As a result of this and the availability of the date simulation tools, we do not require a separate CV or lpar. However, we are planning to do use our client's test lpar in early '99 to test all upgraded system software to ensure that the products themselves will function in the next century.
• Actual Century Flip: Because the change in century will only occur once for the lifetime of the programs (I hope I can successfully predict that none of these programs will be running in 2099!), we have had the client agree with no running of online or batch systems during the change of century. This has eliminated our need to code for this once-in-a-life-time condition. Our client will shut down the entire data center on Dec 31/1999, around 22:00. Once online systems are brought off-line, no batch jobs will be initiated. On Jan 1/2000, around 01:00, systems will be brought up 1 at a time, IPL's will occur, and batch jobs will be slowly initiated. We are all lucky that Dec 31/1999 falls on a Friday night (except for the systems which run 7 x 24).

Back to Client List.

Back to HSL.

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

US 1-800-779-2802
Canada 1-618-692-4719
E-mail: HSL