|
I took a deep breath, collected my thoughts and tried to figure out how to best approach this situation. I wanted to come up with a conversion strategy that would be as simple and as risk-free as possible. I decided on the following:
The Conversion Strategy
2. Verify data integrity: Most of you are probably familiar with the term GIGO, Garbage In Garbage Out. Basically, it means don't begin with bad data or you will end up with bad data. Write a program that reads each record and make sure you do not get any occurrences of ERROR=7. If applicable, run reports and verify their results. Whether it's a GUI or a character-based application, validate each screen of data. 3. Upgrade executables: BASIS highly recoverable file type only became available in Feature Release 2.10 and later of PRO/5®, Visual PRO/5, the PRO/5 Data Server® and the BASIS ODBC Driver®. 4. Convert files: To use the highly recoverable files, MKEYED files need to be converted to the highly recoverable format. To convert your existing data files to the highly recoverable format, use the mrebuild utility that ships with current product. 5. Change configuration: The config.bbx must be modified to set SETOPTS byte 7 bit $20$ in order to create new highly recoverable file-format files when the MKEYED verb is used. 6. Run tests: Run tests that read each record, then look at the output. The next step is to purposely corrupt and then recover the data files. To corrupt a file, you can open it with the ISZ=-1 mode and write random information into the key and data area. The mrebuild utility can be used to scan and recover the corrupted records in the file. Time the results. 7. Validate test results: Compare results of reports, GUI applications and character-based applications to pre-conversion results. 8. Put into production: Move all executables, converted files and configuration files into production. In preparation for my trip, I tested this migration path by converting BASIS's own internal accounting system files to highly recoverable files. It went off without a hitch! I was ready for my trip to Citicorp.
Into Africa
The conversion was successful, and I had the chance to relax and do some sightseeing. My wife and I went on a safari to the Serengeti Plain. What an experience! We saw every animal imaginable: lions, monkeys, zebras, hippopotami and giraffes. The most fascinating part of the trip for me, though, was visiting the people from the African tribe of Maasai. They wore red blankets, carried spears and lived in stick and grass huts. It was like stepping back in time! Upon returning from the safari, I found a small glitch back at Citibank. The first byte returned from the FID verb returned a $46$ instead of $06$, which indicates it is a highly recoverable file. Citibank had applications that checked this value, thus breaking some of the applications. The highly recoverable conversion had to be backed out until the value the FID returned was changed or the Citibank applications were changed. It was decided that BASIS would change the return value of the FID from $46$ to $06$ by setting SETOPTS byte 8 bit $80$ in the config.bbx file.
Upping the Ante
Over the next month, Citicorp engineers ran reports and the applications and compared the results to the pre-conversion results. No problems! Citicorp engineers also performed timing tests on how long it took to recover files. The results were that it took about one hour per gigabyte. Since that time, back at BASIS, we've been able to optimize this utility and it is taking about half of that time. A few months after I returned home, Citicorp developers successfully upgraded and converted their entire production system on their own and have had no serious problems since!
The real key to the successful outcome of both these trips was the planning of a conversion strategy before we implemented highly recoverable files. While the highly recoverable format can protect critical data files in any size company, planning for the conversion, even in a small company, is important. Knowing that the data you start with is correct, having reliable backups and running thorough tests helps in quickly resolving any glitches unique to a company's application that might crop up in the conversion.
| |||||||||||
| |
| |||||||||||
| |
Copyright 2000, BASIS International Ltd. All rights reserved. Terms of Use. |