EXPERT PAGES

Michael E. Dragoo, FLMI, CCP, began his career in the Air Force as an electronic technician, where he claims he was good at theory but couldn't fix things because he is afraid of electricity. He worked as a programmer developing banking systems for the First National Bank of Waco, then moved to American Income Life, progressing from programmer to Chief Information Officer. In the process he designed and built many of the systems discussed in these Field Notes and played a key role in making American Income a technologically cutting edge company generally recognized as having the lowest unit costs in the industry. He joined American Amicable Life as CIO in 2000. He has an AAS in Information Systems, graduating with Highest Honors from McLennan College.

Policy Audit - Policyholder file system - Correspondence system - Master screens

POLICY AUDIT Q. Mike, one of your early high impact systems was policy audit. The completion of a policy audit of a life insurance policy requires the listing of every money transaction affecting the policy, often from inception many years before. That means every premium payment, every loan, and so on. How was that done when you started?

Originally (circa 1975) policy audits were manually constructed by looking at paper reports. The policy master record contained the last accounting date, which was used to find the first paper report. The first paper report showed the previous date and that pointed you to the second report, and so on. These paper reports were the old continuous feed green bar, one transaction per line, bound in volumes, about 6 inches thick, that might contain a week or more of transactions. The basement was literally full of these volumes. Early on we switched to computer output microfiche, COMfiche, which helped with the storage, but not the laborious tracking.

Q. What happened if one of the paper reports couldn't be found?

If a report got lost, you audit trail just ran into a dead end.

Q. That sounds like a huge amount of data, and on line storage wasn't like it is today. Disk drives were expensive, and pretty limited. How did you approach that?
As a side note, it would have been possible to improve the system before on line systems were available. You could have sorted the archived data by policy number and redo the fiche. Of course, then you would have the problem the law book publishers have. When you get too many update steps, you have to do the fiche in toto all over again.

Knowing that we had archived the accounting on tape files for several years, we thought that it might be possible to make that data available online. This must have been about 1980 - we waited until the online systems had been implemented. However, our first attempts were disappointing when we discovered that a single year's accounting audit filled 29 tape reels. It wouldn't be physically possible to load that much data to online disk files. So - we scratched our heads and came up with some data compaction ideas. We put all numeric data in binary fields or used binary numbers for table look ups, even a date compaction algorithm that only used 2 bytes. This reduced the amount of data required to define an accounting entry to half the space, which was still too big. So then we developed a push down technique that did not repeat data that stayed the same from transaction to transaction. This worked out well in that for most policies we could store a year's worth of accounting in 100 bytes or so instead of the original 500 bytes.

Q. You ended up with a single screen with all the records for a single policy number, available to every clerk instantly. So the audit was reduced from hours and even days (and in the dust) to seconds. You must have been popular in POS!

After we pulled audit extracts they were combined into a single record for each policy. Actually, in the original version of audit we screwed up by adding new records at the end of the policy record. This caused us to view the audit from oldest to newest. Kind of dumb! At some point we rewrote so that the records were constructed newest to oldest.
We started out with only accounting audit (actual money transactions) and added file maintenance audit later, when we got smarter. File maintenance was a little harder to do because we had to generate the data from several sources. There wasn't an archive file already in existence like there was for accounting.

Q. When you moved to American Amicable, how were they doing audit? There were two companies, as they also had Occidental Life, which was still on Life70, and not yet converted. Did you approach it like you had at AIL?

AA personnel would follow the audit trail using InfoPAC for AA (an early mainframe based repository somewhat difficult to use) and fiche for OLIC. A programmer and I wrote programs to extract accounting info from the archives, build policy audit records and display policy audit records. We even incorporated L70 OLIC data created prior to the conversion. Policy audit is now essentially the same as it is at AIL including policy maintenance as well as accounting. We have added agent audit, which gives both for the agent file, analogous to the policy file.

POLICYHOLDER FILE SYSTEM Q. The system we called “file tracer” was another that evolved over the years. In the late 1970s we were still using the paper policyholder file folder. To check out a file you filled out the out card and took it to the file room. If the file was there it was pulled and the out card substituted on the shelf. If the file was missing, there was supposed to be an out card there to indicate who was supposed to have it. When one or two clerks requested files for a whole department, you had no idea where the file really was, and there were a lot of "not found" files. We decided we needed a system where files could be ordered by the individual user without leaving her desk, managed so that the computer knew where the files were at all times. What was the first step?

I wrote a mainframe CICS program capable of keeping track of our paper files. The record contained the policy number and the department/desk code (dp/dsk) of the person who last ordered the file and the date. To initialize the file everyone stopped at one time and loaded the files in their possession. If there was no record the file was assumed to be in the file room. I provided a transaction for file transfer when this was done without returning the file to the file room. The record retained last three order or transfer transactions. If a file was in the file room when an order transaction was made, the file was ordered and the record updated. If the file was out, the terminal returned the record of what department/desk was last shown to have the file.

We ran a batch program 4 times daily to print a 3x5 card for each file ordered within the last period, sorted by dp/desk, then by the terminal digit order used in the file room, facilitating pulling the file and immediate delivery to the specific desk shown on the order. . As a result, the time from ordering a file to receiving it was between 20 minutes and 2 hours 20 minutes depending on where you were in the cycle when you ordered the file.

To retrieve a file, the 3x5 card was placed in a pocket in a larger plastic holder (the size of the old out card) which was then substituted for the file as it was pulled. That holder also had a pocket into which paperwork could be placed until the file returned. Originally we provided an on line transaction to update the record when the file returned, but there were so many transactions it created a bit of a bottleneck. We were using MICR encoding for direct billing return documents so that we could read them with a MICR slot reader, so we adopted the same technique for the 3x5 cards generated for file requests. We MICR encoded them so the return was recorded by dragging the cards through a slot reader set up as a keyboard wedge.

Q. It looks like you obtained the advantages of a microfilm system without the cost or the inconvenience of fiddling with all those little films. People do prefer paper files, and since you would know immediately when you ordered a file if it was out to someone else, and to whom, you could go negotiate for it. Almost as good as supporting multiple users at the same time. But what about the big advantage of film, storage space?

We moved files that were not likely to be needed to cheap off site storage. The computer created a purge list, sorted in the terminal digit order of the file room, of the policy numbers that were inactive, such as lapsed or canceled policies, and the files were placed in boxes in the order they appeared on the list. By entering the first number in the box and the last, the computer transfered all of the numbers to the box. The box had a dp/dsk code, just like it was someone's desk. When someone ordered a file that was in the box, the terminal would show the file out to a "desk", for example, to ST/AAF, which would be the 7th box in the set ST, meaning storage. We know where the ST set was, as well as the FB (fileroom, basement). If a requested file showed out to storage, a supervisor had to agree the file was needed, and twice a week trips to storage never failed to locate a file.

Q. In most companies sending a file to storage pretty much means it is lost forever, or very expensive to find, so the choices are either film, or spend the time to select and keep only the critical parts of a file. This system made it cheaper to store a file forever. And I can see that once a file was retrieved from storage, there would be no reason to try to put it back where it was. It could just go to the file room and wait for the next purge, and the next box. That system is still in use by AIL, but when you went to AA it was deja vu all over again, wasn’t it? Paper files, hand written out cards and a line at the door. What system did you install there?

We put in the exact system we had invented for AIL. The only significant change was printing the out card in the file room, on demand. When the file clerk had filled the previous orders, a transaction printed the cards for all the orders since the last printing. The creation of EFile, which eliminated the paper file entirely going forward, rapidly reduced the activity in the file room. Today it is not staffed full time, and the orders for old files are printed as they are ordered.

CORRESPONDENCE SYSTEM Q. When you and I started at AIL there was no correspondence system, there was some use of preprinted form letters with blanks to fill in by typewriter, but most were free hand compositions by persons not uniformly literate. The programmers were using an IBM word processor called SPIN and SPM libraries as a program repository. It was before the age of email, and we had revised SPIN to be MPIN, our paperless internal correspondence system. Since we were already writing "letters" to each other electronically, it wasn't a great leap to make it LPIN, a correspondence system. MPIN is an interesting step in its own right. What changes did you make to SPIN to get that system?

The software was called SPM (Source Program Maintenance), an IBM product used for text editing - for which we had the source code. Our programs were stored in a library which was accessed via the transaction SPIN. After someone had the foresight to recognize that it might be possible to communicate with each other using the 3270 terminal, we decided that an SPM library was a logical place to store messages. So we created an SPM library to be accessed using the transaction MPIN. Basically, I could type a message in T/CBC (T being a password) and you could view that message and post a reply to T/MED. We modified the SPM programs to process the MPIN library and added some code to pick up date and dp/dsk for the message line(s) and we were talking to each other electrionically. Later, it was thought "wouldn't it be neat if we could send ourselves messages, you know - a reminder system". So we made provision for a reminder book T/??CBC, wrote some batch programs and using SPM utilities sent ourselves a message. Pretty cool stuff for 1980.

Q. The rules really made it work. Anyone could open my program space, T/CBC (all passwords were T), and type a message in it, but to delete or change anything was taboo. Only I was supposed to do that. People could and did spend time reading the space to see what else was going on, so it lacked the privacy aspect of later email, but that wasn't all bad. We sometimes put "confidential" stuff in just to get the word out on something, confident that the grape vine was snooping. From writing to each other we went to writing to others, with LPIN, the letter system. We decided to create full letters, one per program space, but you had a lot to do to make that actually send letters.

We made the decision to create full letters with fill-in spaces for the individual information. Each letter had a name, such as CV02 for a cash value letter, version 2. When the letter name entered, the on line system made a copy of that letter from the LPIN library and displayed it on the screen. The clerk completed the manual fill-ins, made any desired changes in the standard language, and the modified letter was returned to the LPIN library. A batch program picked those forms off and sent them to the batch letter program for printing.

Q. I have a list here of a lot of your creations, let's call them subsystems, since they were simple in concept, created in just a few days, but were huge time savers. The volume was so great at AA that many eliminated the work of one or more entire persons. There was the combined agency screen, for licensing a new agent, that reduced the time from about 25 minutes to 1 minute. The clerk had been using many different screens, with a lot of duplicative input.

There were multiple agent database being maintained in the on line CICS environment. Even in the LifeComm programs, multiple agent records were maintained (1 per level), plus additional trailers had to be defined for licenses, personal info, and heirarchy situations. So a clerk setting up a new agent number had to code LifeComm Master records, Agent Advancing record, AP&P record. It could have been as many as ten screens. The systems guru (CBC) sythesized a single screen from all the disparate screens and I programmed an on line application that updated all of the records from this single source of information. Very big time saver, not to mention the side benefit of making sure that records were consistent, and that all of the records were completed. I think it is important to point out that programmers and users alike are prone to associate screens with records, which limits your horizons.

Q. It is important to note that these multiple screens came ready made with LifeComm and the other systems, so every company would have the same situation until they made their own solutions. Did you use this concept, one screen to feed many standard screens, or the reverse, one screen gathering data from many standard screens, in other areas?

I think the new agent process was the only one that was that bad. However, we did write several screens that would overview the application. For policyholder service we created a single screen that collected all the data on a policyholder that they were likely to need on a telephone call. That included details of the coverage and premium, names and addresses of all the parties, and the agent information on the case. The agent overview screen was somewhat like the mirror image of the combined agent input screen. It included all of the personal data, plus licenses and status, as well as insurance coverage information. This was the go to screen if you were on the phone with the agent.

Q. Just about everything in an insurance company is controlled by a number. The policy number, the agent number, the group number and so on with vouchers and vendors. And each system has to have controls to find the next available number and make sure there were no duplicates. Prior to letting the computer assign numbers, the policy number was controlled by the paper file, which was purchased with sequential policy numbers printed on the folder. That was an extra expense, but was the least troublesome of the various systems. What was involved in automatic assignment?

I use a single database to control number assignment for all systems. Of course, this requires that all numbers for all systems be essentially numeric, except for prefixes and suffixes. The database looks like this.

The program is a routine in each system that inquires on the database, locks the file (to avoid duplicate retrieval, retrieves the next available number, adds one to the database and rewrites the record for the next requestor.

With the policy numbers we needed to sequential ones for multiple policies in the same family, so we created the facility to retrieve more than one number at a time, and placed the inquiry in a transaction designed to spread a single CWA check over multiple policies, making sure the money came out even, and was all used.