Main BASIS Page
Main Advantage Page
This Issue's Table of Contents

BASIS Helps Citicorp Protect Its Data

By Brian Hipple
SCS Partnership accelerates GUI Migration Table of Contents Large File Performance

hen Citicorp requested my presence to assist them in upgrading to the latest version of Visual PRO/5® and taking advantage of the highly recoverable file format BASIS now offers, I was a little anxious, to say the least. I was going to be traveling to Nairobi, Kenya, and to Warsaw, Poland, and I was going to convert files for one of our largest customers. The pressure was on!

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
1. Installation/contingency plans: The golden rule of upgrading is that you always want the ability to start over again if something goes wrong. Make backups! Back up the current executables, data files and configuration files.

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
After almost 24 hours of flying, I arrived at my first destination, Nairobi. After only sleeping for a couple of hours, I got a call to go into work. Citicorp's Nairobi Citibank branch had experienced a corrupt file. The file was an MKEYED file, so we converted the file to the highly recoverable format and upgraded the Visual PRO/5 executable and the executables for the PRO/5 Data Server for Microsoft Windows NT. The next day, we upgraded all of the Citibank branch's MKEYED files to the highly recoverable format. There were about 3 gigabytes of data files, which took about three hours to convert.

Men of the Maasai tribe in Kenya perform a traditional dance for guests.

A pride of lions play on the Serengeti Plain.

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
In Warsaw, the stakes were much higher. While the Citibank site I visited in Nairobi was a branch office, the Warsaw site was a regional data center processing millions of transactions each day for numerous countries. By the time I had arrived, Citicorp engineers had already made contingency/backup plans, validated the data to be converted, and had a team of managers, developers and system administrators on-hand. We executed the conversion strategy on the test system first. We installed the latest version of PRO/5, the BASIS ODBC Driver and the BASIS License Manager on the test system. Using the mrebuild utility, we converted about 10 gigabytes' worth of MKEYED files into the highly recoverable format and changed the SETOPTS bits in the configuration file. Now came the moment of truth. Citicorp engineers deliberately corrupted eight large files. Using the new BASIS _scanfix utility, we scanned the files for corruption, and all eight files were caught by the utility as corrupted and were recovered!

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!

In Poland, BASIS engineer Brian Hipple and Marek Dryjanski, Production & Projects Manager for the Warsaw Regional Data Dentre of Ditibank S.A., worked together to convert the center's data files to the highly recoverable file format available now in BASIS products.

With the help of BASIS, Citibank engineers in Nairobi Kenya, successfully converted their data files to the highly recoverable file format. Pictured from left to right ar Mike Okoko, Network Facility Operator for Citibank N.A.; Inder Amol Aingh, Associate Consultant for Citicorp Overseas Software Limited; and Erick Muriuki, also a Network Facility Operator for Citibank N.A.

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.


SCS Table of Contents Large File Performance

Subscribe to The BASIS Advantage Magazine!

Copyright 2000, BASIS International Ltd. All rights reserved.
Terms of Use