Whether you have been asleep at the switch or simply too darn busy is irrelevant. The fact that you are reading this article means that you are one of the many shops that have put off the Y2K problem until the last possible second. Spending time and money on a project whose only purpose is to keep you up and running makes the job an easy one to avoid. Procrastination on the Y2K bug is rampant and industrywide. But obviously, you are running out of time, and we hope that you will find the utility in this article useful.
Divide and Conquer! We took on our own Y2K demons a couple of years ago. The task was daunting, and it took us over a year before we accomplished our desired goals. As software vendors, we then had all those conversions left to perform...and we are still working on those.
In those early days, we noticed that there were not too many vendors who had solutions to help solve the Year 2000 problem. How things have changed! You cannot open the pages of any AS/400 trade magazine without stumbling upon advertising for one of the many Y2K solution vendors. If you have shopped around for your Y2K solution, you know that the solutions are not cheap. In fact, many of the solutions are simply not affordable to a small shop on a limited budget.
It is for that reason that we decided to publish an abbreviated version of our own Y2K tool to help the small shops get over the hump. This tool should not be confused with the much more complete Y2K solutions that are on the market. It does not take inventory of your source, look for missing objects, or identify unused programs. It simply finds date fields in your database.
Eat What You Catch As a general rule, there are two ways that Y2K tools find the dates in your database. Either they examine the data itself, looking for data patterns that appear to be dates, or they look at the attributes of the data base to see if user-defined criteria appear in the field names, column headings, or text descriptions. There are deficiencies in either methodology, so the best Y2K tools employ both. A tool that looks only at the data will not help you if the file does not have any data (for instance, externally described data
structures). A tool that looks at field attributes will not be that helpful to you if column headings and field level text are not provided. The tool described in this article is the latter method, which is to say that it looks at the attributes of your externally described database files to find your date fields.
One of our good friends at IBM calls this type of Y2K tool a name catcher because that is how the tool works. It looks at the field level text, column heading, field name, and field size of your externally described data files to see if the attributes match the established search criteria. If a match is found, the name of the database file and field are added to a “possible date” database that will include all fields determined to potentially be dates. This database may then be used to help you manually perform your Y2K project.
Obviously, this tool will not be able to help you if your files are not externally described. All of the search criteria used by this tool reside in the compiled object, not in the source. Generally speaking, this is better because you do not need to worry about whether your analysis included out-of-date source code. This problem will pop up later in your Y2K analysis.
Perform Your Inventory First Before you get started, you need to make sure that you are not missing source code for programs within your application. You also need to make sure that none of your source code has been changed since the program was last compiled.
We published an article in the January 1997 issue of MC (see “In Search of Source”) that included a utility that would help you identify missing and out-of-date source code for your programs. We also published a utility in the October 1998 issue (see “Programmer’s Toolbox: Where in the World Is My Source Code?”) that would help you to find missing source code, as long as it still resides on your system.
The point is that performing an initial source code inventory is an important step in your Y2K project. Modifying an application with out-of-date source code will result in programs that do not function properly.
Looking for a Date The components for the Build Date Field Database (BLDDATFLD) command, which are too lengthy to print in this article, can be downloaded from the Midrange Computing Web site at www.midrange computing.com/mc/99/02.
Once you have downloaded the necessary components, compile them as specified in the header information for each source member you download. When completed, you will be ready to perform your date field analysis. You can see an example of the command in Figure 1. If you choose to utilize the extended job parameters (by pressing F10), you will see a panel that is similar to that shown in Figure 2.
The table in Figure 3 was composed to describe the various command parameters. As you can see, most of the parameters are reasonably self-explanatory.
The BLDDATFLD command runs the BLDDATCL CL program, with validates the user command entries. If the entries are deemed valid, the CL program will submit itself to the job queue. The F10 command key will allow for extended job parameters, which allow the user to control the job logging and job queue, as well as to schedule the desired job runtime.
The submitted BLDDATCL CL program then calls the BLDDATRG program, which will perform the search for date fields using APIs. Potential date fields will be written to the DATEFLDS database file, as shown in Figure 4. The name of each file containing one of the date field candidates will be written to the DATEFILE database file (see Figure 5).
You’ve Got a Date! What you decide to do with this possible date database is up to you. You may want to run simple queries over these files and use them as a guide to help you change your code. Or you may want to take a stab at writing your own impact analysis report by comparing data in these files to the source code in your applications.
You may have noticed that this tool could be used for a variety of other applications as well. How you use it is limited only to your own imagination.
In any case, do not get the impression that we have provided you with an industrial- strength Y2K tool. We have not. But we have provided you with a tool that can be used to help you take inventory of your database and find out where the dates are in your system.
Build Reference Files (BLDDATFLD)
Type choices, press Enter.
Database files libraries . . . . Name
+ for more values
Replace existing work files? . . N Y, N
Include all fields this size . . 0000 Character value
Field name search criteria . . . Character value
+ for more values
Description search criteria . . Character value
+ for more values
Column heading search criteria Character value
+ for more values
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Figure 1: Build Date Field Database (BLDDATFLD) command
Build Reference Files (BLDDATFLD)
Type choices, press Enter.
Job queue . . . . . . . . . . . *JOBD Name, *JOBD
Message logging:
Level . . . . . . . . . . . . *JOBD 0-4, *JOBD
Severity . . . . . . . . . . . *JOBD 00-99, *JOBD
Text . . . . . . . . . . . . . *JOBD *JOBD, *JOBD, *MSG...
Schedule date . . . . . . . . . *CURRENT Character value
Schedule time . . . . . . . . . *CURRENT Character value
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Figure 2: Page 2 of the Build Date Field Database (BLDDATFLD) command
Option Description
Files library Name of the library where your database files reside. You can use the plus sign (+) sign to indicate that you would like more than one file’s library to be searched at once.
Replace existing work files If you have already run the tool but would like to replace the data in your analysis database key a Y. Otherwise, the matching date fields found will be added to any existing data in the analysis database. Include all fields this size This filter is used to designate that all fields with a certain field size may be assumed to be date fields. In other words, if all of the date fields in the database are six-digit numeric fields with zero decimal positions (regardless of the date format), you could key a 6 into this field and all matching fields in the database files would initially be assumed to be date fields. Field name search criteria The field name search parameter is another one of the elements used to define the search criteria that are used to identify possible date fields.
If you want to include all fields t hat happen to have the characters DAT somewhere within the field name, you key DAT into this field. All fields in the system that have the characters DAT anywhere within the field name are assumed to be dates. They are, therefore, added to the date database. On each of the search criteria parameters, you can key a plus sign (+) on the command and search for more than one set of wildcard parameters.
Description search criteria The description search option allows you to specify a character string or strings that may appear in the description text.
Description text was specified in the Data Description Specifications (DDS) when the file was built. Any fields in your database that have matching text found anywhere within the field text are automatically included in the date database. For example, if you want to include all fields with the word DATE in the description text, simply key the word DATE into the Description search criteria parameter, and fields that match the criteria are assumed to be date fields. Column heading search criteria Finally, the last search criteria prompt is for a character string that may appear in the field column heading. Just like the field text parameter, keying in a character string here causes fields with a column heading that includes your search character string to be included in your date field database.
Figure 3: Description of options for the BLDDATFLD command
*************************************************************************
* TO COMPILE:
* CRTPF FILE(XXXLIB/DATEFLDS) SRCMBR(DATEFLDS) SIZE(*NOMAX)
*************************************************************************
R DATREC
DTFLD 10 COLHDG('FIELD NAME')
DTFILE 10 COLHDG('FILE NAME')
DTLIB 10 COLHDG('LIBRARY NAME')
DTDIGS 7 0 COLHDG('DIGITS')
DTDECS 2 0 COLHDG('DECIMALS')
DTDESC 50 COLHDG('DESCRIPTION')
DTDTAT 1 COLHDG('DATA TYPE')
K DTLIB
K DTFILE
K DTFLD
Figure 4: Data Description Specifications for the DATEFLDS physical file
*************************************************************************
* TO COMPILE:
* CRTPF FILE(XXXLIB/DATEFILE) SRCMBR(DATEFILE) SIZE(*NOMAX)
*************************************************************************
R DFTREC
DFFILE 10 COLHDG('FILE NAME')
DFLIB 10 COLHDG('LIBRARY NAME')
DFDESC 50 COLHDG('DESCRIPTION')
DFCSTS 1 COLHDG('CONVERSION STATUS' )
TEXT('C/COMPLETE')
DFFFMT 10 COLHDG('FILE FORMAT')
K DFLIB
K DFFILE
Figure 5: Data Description Specifications for the DATEFILES physical file
LATEST COMMENTS
MC Press Online