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.
IDMS & 6-digit dates - No need to expand, please read
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.
Tuesday, December 16, 1997 4:57 PM
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:
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:
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.
Back to Client List.
Back to HSL.