Century Support Products for CA-IDMS
PROJECT 2000 SOLUTIONS
Century Support Products for CA-IDMS
PROJECT 2000 SOLUTIONS
| 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
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.
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.
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???
What releases of CA-IDMS are supported?
What are the hardware/software requirements?
What is not supported?
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.
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:
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.
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.
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).
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:
Project 2000 supports ANY two digit date format -
YYMM
YYMMDD
YYDDD (Julian Dates)
YYMM (COMP-3)
YYMMDD (COMP-3)
YYDDD (COMP-3)
YY - ANYTHING!!!
ANY KEY FIELD THAT HAS A 2 DIGIT YEAR (PACKED OR DISPLAY FORMAT), CAN BE CONVERTED AND MADE
CENTURY COMPLIANT WITHOUT A DATABASE RE-STRUCTURE!
Does Date Converter support VM, VSE, XA, ESA?
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
So, what is required to implement the Project 2000 Date Converter?
OK - What about CALC records?
981231 - Dec. 31, 1998
991231 - Dec. 31, 1999
001231 - Dec. 31, 2000
011231 - Dec. 31, 2001
OK - Well what about overhead?
What must be changed?
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!
Recent enhancements . . . .
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.
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.
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.
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.
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;
| ADSA | HELLO | OLM | SIGNOFF |
| ADSAT | IDDM | OLMT | SIGNON |
| ADSCT | IDDMT | OLP | SSC |
| ADSCXCTL | IDDT | SYSGENT | SSCT |
| ADSG | INITCLK | SHOWCLK | SYSGEN |
| ADSGT | LOGD | S | USECLK |
| BYE | MAPC | SCHEMA | USXMAP |
| DMET | MAPCT | SETCLK | |
Century testing is accomplished without working weekends or affecting other applications.
Note:
Are there any problems we should be aware of?
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 Project 2000 Date Simulator installation
instructions.
Click here to review customer comments.
Click here for the current PTFs for the Date Simulator.
The
Click here for the Project 2000 Date BIFs PTFs.
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.
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
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.
1-800-779-2802
Click here for the Julian/Gregorian Date Converter.
It's a freebie.
Y2K BIFs are here!!
i.e. - 98/07/04
Sunday, the 15th day of April, 2001
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 
Dates can be moved
forwards or backwards.
formats. Personally, I have never seen dates stored on a data base like
this, but if you have it we can handle it:
Hybrid Systems Ltd., Inc.
200 University Park Drive
Edwardsville, IL 62025
1-618-692-4757
E-mail: HSL
