Steven
Durfey
Supervisor Tech Support & Operations
Weber Marketing Systems, Inc.

The following comments are from Linda Osowetski, MCI Systemhouse Y2K Project Leader, they are paraphrased from a December 17, 1997 positing on the IDMS-L. Do yourself a favor - read the entire letter. Linda has thoroughly studied the IDMS Y2K issues, and has an experts grasp of the problem. Click here to review the entire letter.

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

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.

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

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

Linda Osowetski
MCI Systemhouse
Houston, TX