Y2K from the Trenches
By Thibault Dambrine
There is very little time between now and December 31, 1999. Fortune Magazine recently predicted that the whole Y2K affair would be just as boring as any other year-end. Others like myself think the Year 2000 will be a competitive opportunity. By this I mean that on January 1 2000, there will be companies with 2000-ready systems and companies who will not be ready. Which ones would you think will lose business in these crucial first few weeks of January?
Dozens of software companies offer AS/400 Y2K conversion packages on the market today. The prices for these gems of painless heaven cost anywhere from a few hundred dollars to many thousands. As time marches on, many a shop will find themselves looking for such solutions, or, deciding the job is really not that big, will rather hire "peopleware" (as opposed to software) to get the job done.
One other non-negligible consideration that will enter in the "purchase a canned Y2K solution or do it by hand" debate is the learning curve of the canned software. If you are interested in exploring this avenue, a good place to start is the following web site: http://www.news400.com/products400/buyersguides/y2kbuyersguide/y2bg.htm.
Recently, I have taken this type of challenge. My assignment was to clean-up a Y2K situation in a small-to-medium size system. It took 1.5 months all together to fix up. My job consisted of making Y2K compliant a mixture of in-house and purchased software. Prior the Y2K changes, the software was deemed stable and required relatively little programming attention.
In this article, I will describe the techniques I used to quickly dig myself out of a hole deeper at times than I expected. These methods are one way to quickly get your bearings in a system where few people know the technical ins and outs. To do this job, I had my own two hands and a terminal. On this system, there was no Y2K conversion tool, no cross reference tool and no version control system either. All of this was not surprising, since this system was not maintained in-house. Basically, they gave it to me and said "make it work". The surprises came later onů.
Within the first week, I realized the technical documentation had not kept up with the state of the system I had in hand. There was no cross-reference, documentation or any programmer productivity tool available either, proficient users but no technical help. I needed a proper map of the system I was working on. In the following paragraphs, I will describe how I did proceed.
Creating Your Own System Map
When starting out on an unknown system, the first recurring questions to answer are the following: "What would be the impact of changing that object?" and "Where is this program called?"
The next question, when you know what you want to do to a program is to find its source. This in itself sounds simple enough until you encounter situations where version control was not implemented and where a lot of different programmers made small changes or short term visits in the system you are about to modify.
The Ripple Effect
Let's start with the beginning, to modify the database files to be Y2K compatible. Of course, when you modify a file, you have to know what programs you will also impact. The same applies to programs.
What will be the ripple effect of changing this file? Changing this program? The fastest answer to this question, I quickly found out, was to run a "Display Program Reference" or (DSPPGMREF) for all programs in all libraries. Note that this type of job takes time to execute and it is a good idea to submit this type of job in batch and at night when there is nobody to slow it down.
SBMJOB CMD(DSPPGMREF PGM(*ALL/*ALL) OUTPUT(*OUTFILE) OBJTYPE(*ALL) OUTFILE(DAMBRINE/ALLPGMREF))
This procedure will yield a file (in this example, the file name is DAMBRINE/ALLPGMREF) that will contain all references from and to all objects on the system. Having this information in an ordinary physical file, you can quickly find out with a query or a quick SQL or a QUERY where a given object is called or referred to.
One thing to keep at top-of-mind awareness is that every change you make in a system may have a more or less great ripple effect. To know quickly and accurately what exactly is the ripple for changing any given object (data area, program, physical file or anything else) is a definite advantage. You will not be taken by surprise.
Here is the simple way to know exactly what your ripple effect is: Let's imagine that the name of the program you are going to modify is "MDFYPGM". By listing every record in ALLPGMREF where the referenced object field (WHFNAM) is equal to "MDFYPGM", you will know exactly what objects are referenced by WHFNAM, in every library and in every category or type of object.
Here are the SQL steps to follow on the AS/400 to quickly get the information you are looking for:
SELECT WHLIB, WHPNAM, WHTEXT, WHFNAM FROM DAMBRINE/ALLPGMREF WHERE
WHFNAM = 'MDFYPGM'
Source File Hunting
In the absence of version control, a surprisingly common situation, you may also find yourself looking for the "right" source to modify for a program. Program source members have a way of growing duplicates, triplicates and so on in the most surprising way sometimes. Not all shops work with the original QRPGSRC for RPG, QDDSSRC for DDS and QCLSRC for CL's. Programmers are famous for making versions of a program that is buried in their own personal library, promote the change and forget the source. This situation can be messy but again, with the right tools, you can handle it with relative logic. It may happen that you find a object of type *PGM that calls three other programs but when you look at the "official" source member for this program, you can count only two program calls. What I am saying is that the object does not always behave as you would expect it to from looking the source you see in the obvious location. Most times, the proper source member is indeed somewhere in the system. Simply, it is not where you would expect it to be!
Assuming the best situation to start with, when modifying a program and looking for the source, the first place to look is as follows:
The Display Object Description (DSPOBJ) command with option *SERVICE will tell you where a program was compiled from originally. Here is an example of the command:
The following will tell you (at least) when and from what source member a program has been compiled.
The example shown here is a *PGM, but the point is also valid for files.
If you don't find the source member for your object to modify where you would have expected it according to the DSPOBJD command or if it does things that do not appear in the source, then you need to dig a bit deeper. The question is, where to look?
The simple answer to this question is "everywhere".
To get the full list of members (source and everything other physical file member also) in a system, you can submit the following command. Again, this may take a while, good idea to do this at night.
SBMJOB CMD(DSPFD FILE(*ALL/*ALL) TYPE(*MBRLIST) OUTPUT(*OUTFILE) OUTFILE(DAMBRINE/ALLMEMBERS))
Out of this, you get a file (in this example, the file name is DAMBRINE/ALLMEMBERS) containing all members in all files in the system. Having this information in an ordinary physical file, you can quickly find out with a query or with SQL where an individual file member name would be (i.e. in which source file). The advantage here is, again, to have the absolute certainty on how many versions of a given source-member there are in the system. This is especially good to have in a shop where no version control system is implemented.
A sample SQL command to look for this information would be as follows:
SELECT MLLIB, MLFILE, MLNAME FROM DAMBRINE/ALLMEMBERS WHERE MLNAME
Many times, the most challenging part is not how to modify a program for Y2K readiness, but really from which source member? By this, I mean which source member will be the one to get modified for Y2K and re-compiled with the changes.
If there are duplicate members, if the shop you are working in does not have strict promotion or version control for their source, this is something that will come up. To ensure you have all the weapons (read "knowledge") when you are in doubt as to which member to modify, it is good to be able to visit all (if possible) versions of the program. Compare critical areas like how many files are accessed in the existing object, how many programs are called. If you have several source versions, some calling more or less three programs, some accessing different files than the existing object, it may be an indication of an older source version. In the case of file names however, it is also important to verify if there are OVRDBF's that apply to this program. Many times, it all boils down to a judgment call based on good sources of information. At the end of the process, when the users sees the result, they are usually able to say "yes, this is what I expected" or "no, this is different than what we usually get".
Another situation that may spring up is the "case of the missing source". When dealing with a program, this may be (hopefully) as simple as getting a back-up restored. Sometimes, however, luck is not so good.
In the case of a file whose source is lost, there is more hope. With the Display File Field Description command (DSPFFD), you can display the format of a file and the description of each individual field that compose the record format. If you have it, the TAATOOL library also has a command called Display Format (DSPFMT) that shows the fields in a file in a format that is easier to read. With the Display Database Relations Command, (DSPDBR), you can find all related logical to a physical file and with the Display File Description (DSPFD), you can also display the key fields for each logical.
In the case of a CL program where the source member is lost, the "Retrieve CL PGM" command (RTVCLSRC) can save you.
In the case of an RPG or COBOL program, there is no such command and you would have to go to a source retrieval service (NEWS/400 carries ads for these types of services on regular basis).
Armed with all this information, you can at least navigate, plan, and ballpark the effort you will have to apply to make your Y2K project happen seamlessly (even if late).
Estimating the time it will take to Y2K a given procedure is many times a tricky question. It would be unwise to venture any estimate for the amount of work without a proper investigation. By this, I mean figuring out, from the root program in the procedure, all the calls to all the programs, all the files affected, and all the programs that in turn touch these files. Y2K projects are simple at first glance but often they take more time than expected.
Modifying a system for Y2K readiness is similar to any other type of modifications. You still have to plan, evaluate the amount of work to be done, check the impact of each change and test properly.
You will find that the level of difficulty for this task will be in direct proportion of how well documented, how consistent and how well managed the system you are modifying is.
To finish, here are some general tips.
General Tips about Y2K Changes:
a) The right version of the source is not necessarily where you would think it is. (Never assume you have the right version of the source or the program in your library list)
c) User Involvement is GOOD, especially when testing the modified software.
d) Testing and User Acceptance Testing (UAT)is Essential. Think of it as "your future career opportunities depend on this".
e) As much as possible, if you have a choice, do modify a YYMMDD (Year/Month/Day) date to a CCYYMMDD(Century/Year/Month/Day) date rather than creating a separate field for the Century. Having two fields instead of one usually means more effort down the road.
f) As much as possible store the dates in your database files as YYYYMMDD (as opposed to MMDDYYYY or DDMMYYYY). This allows to sort data on the date in chronological order with a logical file or even with an SQL or Query. You can always present the data in MMDDYYYY format to the user with minimal effort. If on the other hand you store your dates in MMDDCCYY format, you lose this built-in advantage and would have to create sub-field keys to achieve the same result.
Note that if you would like to print your SQL results (rather than seeing them on the screen) you can change the default of your SQL session to print the results by hitting F13 and making the appropriate changes.
Using SQL has one advantage over the traditional Query tool on the AS/400:. it is quick and you can get results nearly instantly, if you are making simple inquiries. This is a tool I only recently started to use but it is very powerful. The more you use it, the more you will find creative uses for checking data, selecting records out of a file for quick viewing etc.Back to Tylogix Home Page