Version A.00.00
(PC client V2.2, Win 3.1 or later)
G.R.Helm, Inc.
4993 Golden Foothill Pkwy., Ste. 1
El Dorado Hills, CA 95762
Phone 916.933.9669
FAX 916.933.9696
email: sales@grhelm.com
Web: www.grhelm.com

TimeShift 2000 includes HP 3000-based transformation software and the Windows-based software. It supports one configuration per account, and as many databases as exist. The demo version will only update one-third of your data or 1,000 records, whichever is less.

TimeShift for the HP 3000 runs on all HP 3000 Series 900s, MPE/iX 4.0 or later. The software also requires that you be using the Reflection terminal emulator software from WRQ.

The software is tier-based ranging from $990 to $8,000 with a 25 percent discount on multiple CPUs. Support is 15 percent of the purchase price per year and includes phone in, electronic support and new releases of the software. All prices are in US dollars.

As the year 2000 gets closer, we are seeing more and more ways to test and solve our Y2K problems. This month we look at TimeShift 2000. TimeShift provides two main functions. The first is in-depth analysis of dates within your database, which includes things like finding your date fields, tallying the types of dates it finds, including “special” or “invalid” dates. The other is to “age” the dates in the database by a value such as days or years. What this does is allow you to actually test your changes, whether they are bridging or date expansion, with actual data in the date range required to verify your tests.

This aging process is critical to making sure that you are going to have your programs respond correctly. Even doing virtual dates will only help partially, because your data will still be in its original form. I believe there are three basic problems that need to be addressed in terms of Y2K compliance:

1) Date range retrieval that crosses centuries
2) Date math that crosses centuries
3) Sorting files or sorted keys, on dates that don’t include the century

So as you can see, it’s important to have data that allows you to properly address these issues, and that’s what TimeShift will do — not to mention finding many of the invalid dates that you might have in your database.

How does it work?

What TimeShift does is to use some fairly clever JCL to try to find all the databases in the logon account of its collection job stream. It will then generate a schema file — using either Adager, DBGeneral or QUERY, in that order — of the database. It then scans through the schema, finding all the fields that contain any of the strings contained in the TSPARM file. This file ships by default with the following values: DATE, DTE, YMD, MDY, YEAR, YY. You can add your own values, too.

This automatic scanning is very convenient, and reduces the work on your part. This step also produces a report giving you some statistics about the dates and how they are spread in your system (See Figure 1 below for an example).

Figure 1

TIMELOOK Shawn Gordon PAGE 1
VER A.00.00 TIME LOOK ANALYSIS 06/23/1998 14:27

DATA SET ITEM DATE DATA
BASE DATA SET TYPE DATA FIELD DEFINED FORMAT OFFSET
-------- ---------------- ------ ---------------- ------- ------ ------
TRACE; RUN-STAT-D DETAIL RUN-DATE X6 YMD 01

YMD DATE RANGE--
LOW: 980417 HIGH: 980623

DISTRIBUTION OF YEARS--
0 :01 0 :21 0 :41 0 :61 0 :81
0 :02 0 :22 0 :42 0 :62 0 :82
0 :03 0 :23 0 :43 0 :63 0 :83
0 :04 0 :24 0 :44 0 :64 0 :84
0 :05 0 :25 0 :45 0 :65 0 :85
0 :06 0 :26 0 :46 0 :66 0 :86
0 :07 0 :27 0 :47 0 :67 0 :87
0 :08 0 :28 0 :48 0 :68 0 :88
0 :09 0 :29 0 :49 0 :69 0 :89
0 :10 0 :30 0 :50 0 :70 0 :90
0 :11 0 :31 0 :51 0 :71 0 :91
0 :12 0 :32 0 :52 0 :72 0 :92
0 :13 0 :33 0 :53 0 :73 0 :93
0 :14 0 :34 0 :54 0 :74 0 :94
0 :15 0 :35 0 :55 0 :75 0 :95
0 :16 0 :36 0 :56 0 :76 0 :96
0 :17 0 :37 0 :57 0 :77 0 :97
0 :18 0 :38 0 :58 0 :78 97 :98
0 :19 0 :39 0 :59 0 :79 0 :99
0 :20 0 :40 0 :60 0 :80 0 :00

BLANK: 0 ZEROS: 0 NINES: 0 UNKNOWN: 1
TOTAL: 98


You now have a file that will be downloaded to the PC and used to do granular configuration of how you want to age each date field on an individual basis (see Figure 2 and Figure 3 for an example of how the PC client program looks). After you make whatever changes you are interested in — deleting, adding, specifying aging parameters — you click on a button to put it back on the HP 3000.

After the data is on the HP 3000, you stream another job that reads this driver file and executes the changes.

Features

The analysis reports TimeShift creates during the load phase will be helpful in determining how you want to configure the aging process. While they give you very nice, concise summary information, there doesn’t seem to be a way to get any detail information for “invalid” dates the software might find.

Putting the actual configuration program on the PC certainly makes it nicer to go through and quickly switch between databases, and configure each individual item. Since you are in a grid, you can easily add and delete items from the list of prequalified items. Pre-qualifying the data information puts less burden on where to find everything, and makes what could be a very tedious task a lot easier.

Installation and documentation

The installation on the HP 3000 side is very clean and only requires a single pass on the tape. On the PC side, there is an installation program which puts the software onto your computer, but it doesn’t create a program group, or give you an option of placing the icon on the desktop. The instructions explain how to do it, but it’s a bit tedious, and the icon for the program didn’t work, either. All of which is trivial, but it looks like it should be cleaned up.

The TestDrive

I tested a simple example of a single database, one that had a single dataset with a single date field. I also tested an extreme example, one with a half-dozen databases with a variety of date fields. As mentioned earlier, TimeShift tries to use Adager, DBGeneral or QUERY to create an item search list to find potential date item fields. I have Adager on my system, so it tried to use that. But in my extreme example I had databases with b-trees on them, which some versions of Adager before 980731 can’t handle without a special JCW being set beforehand. I hadn’t set the JCW, so this caused Adager to gracefully exit with a message about the b-trees incompatibility, so TimeShift’s collection job was unable to complete successfully.

I’ve let G.R. Helm Inc. know about this, and they are going to fall back on a pure QUERY collection in this event. That means TimeShift will produce its reports without dependency on any database tools, but you can still use the third-party database tools which do supply you with information QUERY does not. (G.R. Helm says they have modified the JCL so if a collection job cannot complete, the job will not abort, but will fall through to the Query section of the process.) On a side note, Adager versions 980731 and later now handle b-trees without a special JCW being set.

I decided to finish my tests on my simple example, one whose date was stored in an X6 in YYMMDD format. After TimeShift collected the data and generated the report in Figure 1, I activated the PC program and brought the config file down as seen in Figure 2. I then configured an offset of four years (Figure 3) and sent the file back up to the PC.

I noticed that TimeShift makes use of the OLE methods that have been exposed in the Reflection terminal emulator, to upload and download the config file. This means you can only have one copy of Reflection running, and it needs to be logged into where the file is located.

After the file was uploaded I launched the aging job, which processed my data in a couple of seconds. I then ran my interface program to see what the data looked like; Figure 4 below shows an example of my aged dates after running a dataset through TimeShift.

Figure 4

J O B T R A K / 3 0 0 0 DAY RUN 06/24/98 C.03.01

Job Name Run Date Time End Exec Min Streaming User
FULLBACK.JCL.SYS 06/04/02 6:30 AM 510 MASTEROP,MANAGER.
BACKJOBS.JCL.SYS 06/04/02 6:30 AM 0 MASTEROP,MANAGER.

TOTAL TIME: 510
TOTAL JOBS: 2

(N)ext, (P)rev, YYMMDD (020604) or <CR> to continue

As you can see, the dates all properly ended up in the year 2002. I was able to successfully examine and shift my database in time, showing that TimeShift does what it claims to do.

Conclusions

Data aging is a critical part of thoroughly testing your applications, and something that everyone should look at. G.R. Helm has done a nice job with TimeShift 2000, and goes beyond straight data aging by providing a nice, detailed analysis of your data.

There are a number of limitations in the current release that might make the software less than ideal for some situations. You can only age dates that are in a database, no MPE or KSAM file support, and you can only age dates that are actual IMAGE fields. In other words, you can’t do byte offsets into buffers to age an embedded date.

If you don’t have either of those two requirements, and you are serious about your Y2K testing, then a product like TimeShift is something you should definitely give consideration to.

Shawn Gordon, whose S.M. Gordon & Associates firm supplies HP 3000 utilities including a Year 2000 product, has worked with 3000s since 1983.

Since we submitted our software for this review in June, we have made several enhancements and corrected many of the problems pointed out in this review. To start with, we have changed the PC software installation to create a "program group" and to also include a desktop icon. In addition, we have made many other enhancements to the PC client application to improve the overall functionality and user interface.

We have also enhanced the JCL on the HP3000 side to retain the use of Adager or DBGeneral; however it now forces the utilization of Query as a backup should one of these two other products fail or be unavailable.

In the 'Conclusions' section, the author makes the following statements: "You can only age dates that are in a database, no MPE or KSAM file support, and you can only age dates that are actual IMAGE fields. In other words, you can't do byte offsets into buffers to age an embedded date." This last sentence is somewhat misleading, since Time Shift does deal with embedded dates and always has. Please note that the 'Offset' values shown in figures 1, 2 and 3 are used specifically to indicate the starting location of where the date is embedded in the field defined by the item picture. If, for example, the item picture is an X10 and the date is embedded in the last 6 bytes of this field, the offset value would be 5. The aging would then be applied to the date embedded in these last 6 bytes, without affecting the data stored in the first 4 bytes of the field. This feature applies to dates embedded in either character or numeric type fields.

Lastly, regarding the statement about the limitation of aging dates in MPE and KSAM files, this is currently true however we are completing an enhancement to perform this function which should be available sometime in November.

I wish all your readers success in a timely completion of their Year 2000 remediation efforts!

Gordon Helm