Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


A Personal History of Systems and Computers: Part 7

Dan can be contacted at [email protected].

On a snowy Saturday in March 1971, my new wife and I flew to Miami so that I could interview with the American Bankers Life Assurance Company. I had just spent a year at a small insurance company in Harrisburg and its fortunes were going from bad to worse. American Bankers, on the other hand, was a successful company that used IBM's CFO policy administration system and other software with which I had experience. I had been recommended for the position of systems and programming manager by my former employer in Texas.

We landed in the sunshine at Miami International Airport. I had been told to look for a big guy wearing Bermuda shorts and a sport shirt. I spotted my soon-to-be boss and friend, Howard Arner, when we claimed our luggage. Howard took us to our accommodations at the Four Seasons hotel on Biscayne Bay and that evening we dined at a fancy restaurant with Howard, his wife, and a couple from American Banker's agency department. Howard and I met for breakfast the next morning and sealed the deal. Three weeks later, I was in Miami working for American Bankers.

I soon discovered that at Howard's instigation the company wanted to both enter premium transactions and provide their customer service representatives with policyholder information online. We started by establishing a project team and taking an inventory. Our IBM representative told us that American Bankers was already paying for four IBM 2260 CRTs and the DUCS (Display Unit Control System) third-party software. The team went searching for the CRTs. We quickly found three of the 2260 terminals. They were scattered on different floors and were supposed to be used as an alpha-lookup resource. We were told that the lookup results were often unreliable and that the system hadn't been used for months. The fourth terminal, however, was missing.

The project team voted to invite someone from the computer operations department to join us. We gave our new team member the job of following the four coaxial cables that led from the computer room to the CRTs. The next afternoon our new team member called us to an impromptu meeting in the break room on the seventh floor. There, under a tablecloth, was our missing terminal. It had become part of the coffee service. The team decided to relocate that 2260 from the seventh floor to the computer room so that it could be used for testing.

The remaining items on our inventory were the IBM 2311 disk drives. American Bankers used IBM's DOS operating system which resided on a disk pack labeled DOS01. Another 2311 typically had disk pack DATA01 mounted unless, of course, someone was testing something. Then disk pack TEST01 replaced DATA01.

The IBM 2311 disk drive resembled nothing so much as a top-loaded clothes washer with a see-through lid. The 2311 was loaded with an IBM 1316 disk pack which looked like six revolving pizza plates, stacked one on top of the other, with a rod inserted through the middle. The disk pack was enclosed by a clear plastic covering. When the disk pack was outside of the 2311 drive, it had a top that screwed into the center rod so that the pack could be carried without touching the recording surfaces. The operator opened the disk drive, inserted and locked the disk pack in place, unscrewed and removed the top of the disk pack, closed the top of the disk drive, and turned the 2311 on. With the 2311, the IBM 360 mainframe had 7.25 million bytes of random access memory.

We had located the hardware for our project. Now we needed software.

The DUCS terminal control program that American Bankers was leasing was an IBM type 3 offering. An IBM customer had written DUCS and IBM distributed it but did not maintain it. I spent a few weeks looking a the DUCS assembler listings to determine whether we wanted to use it for our project but, in the end, the fact that DUCS was unsupported led us to CICS (Customer Information Control System).

Although CICS was released as a corporate program product in 1969, American Bankers was still an early-adopter. The version that we used became known as macro-level CICS for the obvious reason that COBOL and assembler programs invoked CICS services by using macros. Command-level CICS was released later and supported both macro-level and command-level calls to the control program.

We also needed a random access file handler. At the time, CICS file control supported only BDAM and ISAM files and we chose ISAM. The project team decided to write COBOL programs to format the screens, validate the data, and prepare premium batches. The file handling programs would be written in assembler language. With our architecture in place, the project team began to prepare detail deign documents. And then we hit a snag.

While we were inventorying and architecting, Howard was dealing with IBM about the hardware that would be needed. American Bankers was using a 64K IBM 360 model 40 and all of the available literature assured us that our mainframe would be able to support DOS, CICS, file handlers, and application programs in the foreground while we continued to run batch jobs in the background. Perhaps not, our IBM SE advised. It was true that if we held to strict coding conventions for the application programs, kept our disk records small and unblocked, and installed but a few terminals, it might fit on our machine, but IBM was unsure that we could achieve response times below 10 seconds with such a configuration. Their advice was to upgrade the memory to 128K and to install 2314 disk drives. American Bankers was committed to the effort and ordered the equipment upgrades and the project continued.

We decided that we would start with a full complement of eight 2260 terminals attached to a single control unit. The company already had four terminals and a control unit so we ordered four additional CRTs and an upgrade to the controller. We called a meeting with the user department managers, one from premium accounting and one from customer service, to determine where each 2260 would go and when the managers wanted to begin testing.

"We can get the equipment delivered and ready to go in two weeks," I told them. "Have you decided who in your departments will use the new terminals?" I asked.

Awkward silence.

"Can premium accounting start first?" the customer service manager wanted to know. "Mr. Landon sure gets upset when we get customer complaints."

"Now wait a minute," the premium accounting manager said. "You won't have any customers if we don't get their premiums posted."

With this vote of confidence I interrupted them. "We can keep half of the new terminals in the computer room for awhile. How about you each just take two of them? We can train your staff here and then move the other terminals upstairs when you're ready," I compromised.

With reluctance, they agreed. I later found out that each of them went to their department's senior management in protest only to be sent away.

We decided to install the 2260s over a weekend so that we would cause as little commotion as possible. When one employee who had been selected to learn the new system arrived the following Monday, she found a new CRT on her desk. She turned around and went home. She came back to work only after being assured that she wouldn't be replaced by some mechanical know-it-all.

American Bankers did go online. Although we didn't achieve sub-second response times for another six months and a further system upgrade, the premium system was more accurate than before and it eliminated the need to keypunch thousands of premium transactions each month. Customer service improved. The only remaining disagreement between the managers of the user departments was over which one would get the next shipment of terminals.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.