return to main page
return to 1950s Team Bios page

1401 Stories and e-mails

Purpose of this page - provide stories of the unit record world and the 1401.
More stories IBM 1401 1950s Team Bios, including goals, architecture, design, software, production, marketing teams, stories, ...
Here are more stories about other machines.

Contents: (newest near the top (here))


Letter to T J Watson Jr. printed on IBM 1403 with film ribbon - added May 21, 2013

Background: We had been talking about the 1403 printer, ribbons, and how a "one pass film ribbon" could give beautifully formed printed characters without the smudges and imperfections due to the fabric of the usual printer ribbon. Also on what special print jobs such expensive film ribbons would be used.
Frank King provided one occassion ;-))

Yes, A Senior CE and I installed a 1401 (4K) Reader Punch and Printer at "The Data Center" in Greensboro NC. We started at 08:30 and had completed the diagnostics and turned the system over to the customer at about 12:00.

The customer had prepared a letter to T J Watson Jr. and O M Scott (President of Field Engineering). He had it punched up and ran it on the 1403 using a mylar single pass ribbon. Our field manager came in to see how we were doing, with plans to take us to lunch. The customer showed the letter to our manager and said, "If I had money for a stamp I would mail it to IBM Headquarters." I think that's the fastest I had ever seen my field manager move to get money into the data center manager's hand.

Needless to say a few weeks later we got an award from IBM.

The problem was that the salesmen in Greensboro started telling customers we could install a 1401 system in 4 hours. The reason that was not true, was because it was a simple system (only three boxes), we had no bugs, lots of manual labor help from the operators and we had just installed a 1401 tape system a couple of weeks before. Also, the room had been pre-prepared. The Senior CE was Sam Rushton and my manager was Clete Waldmiller.


1401, from 305 RAMAC to 360 - from Milton Thrasher June 24, 2011

I just finished listening to the wonderful 2 hour video of how the IBM 1401 came about. It was created in November 2009 to coincide with the 50th Anniversary of the Announcement. I was an IBM Salesman on the Bell Telephone Labs at Whippany, NJ out of the Newark Branch Office. I had installed one of the first IBM 305 Ramacs before becoming their salemen. We had a team of Roy Marsan, leader and Walt Smith and I on the team.

I had a 2 week assignment when an SE to go to the IBM Endicott Lab to learn about the IBM 1401 sufficient to see if one of the more complicated punch card jobs could be programmed on a 1.4K system. I was able to do it in only a few days while the wiring of the 604/407 application had taken me over 3 months to wire it with control panels. One of the big features of the IBM 1401 was the elimination of congtrol panels!

This 2 hour presentation was done at the IBM Computer Museum where they rehabed two IBM 1401s and told that story as part of the presentation. See it at See the photo attached.

I particularly enjoyed hearing Chuck Branscomb telling the business environment in which IBM 1401 came about. He personally was a key player as he had shot down the German Bull Gamma fighter that the French Labs had proposed called the WAM - World Wide Accounting Machine.

Later, I was a Systems Engineering Manager in the IBM Elizabeth, NJ Branch Office where the IBM 1401 wasthe key product that we were involved with. I found a set of macro programs that Ed Czerkies had created at IBM Corp Hdq at 590 Madison Avenue, NYC. He called it his "shoe box" as it took a full box of IBM 5081 cards for all of them (about the size of a shoe box). I had my SEs introduce them to their accounts. That was important because the Honeywell 200 "Liberator" became a big threat to the IBM 1401. Because their software could not convert the "shoe box" macros, those IBM 1401s were saved. They called my shoe box of card the "Captivator".

When I went to IBM Eastern Region to be the IBM Systems Engineering Techniques Development Manager, I produced a number of IBM aids to make the installation work a lot easier. They were mostly one card programs and tables that SEs carried in their suit pockets or attachee' cases. When the IBM S/360 came along, I produced the IBM PAT/360 program by copying the IBM 1401 PAT System for remote program testing.

You can see why I was so pleased to learn this background information about a system that we all knew and loved and remember fondly.


Milton Thrasher
941 966-9172

Early ?1st? 1401 Application - from Milton Thrasher June 20, 2011

Best of all was my week or 10 days with the IBM 1401 Development team under Fran Underwood. I was able in a matter of a few days program a Telephone Directory Billing application that with the same deck of card produced print slips for the typesetters in the 22 yellow page directories of NJ Bell Telephone.

The original job was done on 604/407s with lots of additional storage and co-selectors. It took me over 3 months to wire up the application that was originally developed in Ohio Bell at Youngstown, OH. I was able to do it all in a 1.4 K IBM 1401 that proved the viability of that small of memory.

While doing that work, I met the development team and was very impressed with their creativity and responsiveness to suggestions.

Now that I am retired, I play a lot of tennis and found Earl Bloom here in Sarasota, FL who is also retired and plays tennis. He worked with Fran Underwood and others of the IBM 1401 Development Team. We both were at the IBM Centennial as you will see in my Photoshow. Earl Bloom got several patents for IBM while working with that group in Endicott.

You probably know that Fran Underwood recently had another birthday.

The IBM Centeninial at Tampa, FL PhotoShow is at

Milton Thrasher

Simon Barratt - Memories of a 1401 Operator
From: SJB's Laptop < sjblaptop @ yahoo . co . uk >
Subject: Memories of a 1401 Operator
Date: February 6, 2011 8:24:55 AM PST
To: Robert Garner < robgarn @ mac . com >
Cc: ...

Good Day, Gentlemen

I operated, and supervised the operation of, the IBM UK Service Bureau 1401 system. Reading all the material on the restoration site, a couple of things struck me.

We had a program that played music through a radio tuned off-station (I can't remember what the tune was). To see if we could decipher how the program worked, we did a core dump. Imagine our surprise when we discovered a whole bunch of constants containing such things as BAKED BEANS, TINNED WHOLE CARROTS, etc.. Obviously, the program had been written as some sort of stock control application, and the programmer (or someone) had discovered its music-making capabilities.

I presume you are familiar with the record Music From Mathematics, played by IBM 7090 Computer and Digital to Sound Transducer, originally on the Decca label in 1962.

Secondly, I read that there were problems with the 1403, with its new ribbon, leaving trails of ink down the page, or producing images that were less than clear (ghosted?). When we had that problem, we checked that the chain timing was set correctly for the thickness of the paper that we were printing on. With 5-part paper, the hammer had to be fired a fraction earlier in order to hit the slug as it went past. If the next job was on one-part stationery, the timing dial had to be adjusted accordingly. It was sometimes only noticed after half-a-dozen pages had been printed.

One of our jobs in the IBM Glasgow service bureau was to run off the walking lists for two of the local councils' electoral rolls. We had to use special smooth 17"-wide paper, and woe-betide us if the print quality was less than perfect!

The fact that the timing could be so precise always intrigued me. Further, I worked out that the chain was actually moving across the page at around 15mph. Correct?

By the way, does anybody want a copy of the IBM song book?


Simon Barratt


from and about Alan Kay
01/09/2013 & 2/10/2014 - Alan Kay's early 1401 memories (5 mins/day, training, custom OS, Meta II, Autocoder, Fortran), Burroughs machines
I did my Air Force stint between my second and third year of college, had been doing a lot of science and math from a young age, and was a double major in math and biology when the "junior birdman" interlude happened starting in 1961.

Looking back -- and I'm sure most of the people who worked on computers back then will agree -- it was the variety of approaches that was striking. Part of this was from general experimentation in both hardware and software, and part was that one generally learned to program in machine code for most of the machines one worked with back then, and this required understanding their architectural approachs.

The first programming I did was PCAM machine boards (mostly 407 and 101, etc.), and that was interesting. The first three programmable computers I learned -- 1401, Burroughs 220, and Burroughs B5000 -- were all quite different. The next two were somewhat similar and more orthodox -- IBM 7094 and CDC 3600 -- but the next one -- CDC 6600 -- was quite unusual again.

I stated in the "Early History of Smalltalk" that I didn't understand or appreciate the really deep features of the B5000 when I learned it in the AF, I was taken with the byte codes and the stack, etc. It wasn't until I went to grad school in 66 after seeing Sketchpad and Simula that I realized just how radical and amazing the B5000 was.

Bob Barton happened to be at Utah when I was in grad school but he didn't like to talk about the past. However one could get him to talk about "possibilities for the future" and that would reveal a bit about the past. (I actually found out more by talking with his wife Wanda ...)

I was in pure math -- algebras -- and the idea of generic operations over abstract types is central to why algebras were invented. This idea was present in a file system written for the B220 that was there when I arrived, it was inherent in the B5000 (but I didn't see it used), and it was a direct principle in Sketchpad (also ca 1962).

One of the most interesting -- to me anyway -- juxtapositions is to compare the B5000 against any HW or SW of the early 60s -- the distance in concept and power is vast and breathtaking.



> From: Robert B Garner < robgarn @ mac . com >
Subject: Alan Kay's early 1401 memories (5 mins/day, training, custom OS, Meta II, Autocoder, Fortran), Burroughs machines
Date: November 5, 2008
To: ...

1401 software folks,

This evening at the CHM there's a panel session on "The 40th Anniversary of the Dynabook" featuring Alan Kay and Chuck Thacker. The Dynabook was Alan's 1969 vision of a compact notebook with a flat screen, keyboard, and wireless network. (sound familiar? ;-) The Xerox PARC Alto workstation (co-designed by Chuck in 72) was also know as an "intern Dynabook."

As I learned from "Dealers of Lightning" history on PARC, Alan cut his programming teeth on a 1401 at an Air Force base in early 60's! I exchanged some email with Alan about his experiences, which I'm forwarding/sharing here.... I've cc'd Alan on this email...

On Feb 13, 2008, at 5:06 AM, Alan Kay < alan . nemo @ yahoo . com > wrote: Yes, an 8K 1401 was the first computer I programmed for real and extensively, while an enlisted man in the Air Force in 1962-63. I have many memories of leaning over the card reader with my code printout, trying to get the operator to look at various core locations (they would not let any programmer get near the HW), and you could only get 5 minutes a day of actual running/debugging with an operator.

We actually wrote an OS for this machine that resided in the upper 1K that would do batch processing and a few other utilities (thanks to Autocoder for the tailored macros that could be generated).

Of the many cool programs written for the 1401, my favorite is Val Shorre's Meta II translator (which was written in itself) from UCLA ca.. 1964. I did not find out about this until I got to grad school in 1966.

On Feb 14, 2008 at 12:01 AM, Robert Garner wrote:
I found the 1964 ACM paper "META II a syntax-oriented compiler writing language" by D V Schorre here:

META II is a compiler writing language which consists of syntax equations resembling Backus normal form and into which instructions to output assembly language commands are inserted. Compilers have been written in this language for VALGOL I and VALGOL II.. The former is a simple algebraic language designed for the purpose of illustrating META II. The latter contains a fairly large subset of ALGOL 60. The method of writing compilers which is given in detail in the paper may be explained briefly as follows. Each syntax equation is translated into a recursive subroutine which tests the input string for a particular phrase structure, and deletes it if found. Backup is avoided by the extensive use of factoring in the syntax equations. For each source language, an interpreter is written and programs are compiled into that interpretive language.

On Feb 14, 2008, at 4:32 AM, Alan Kay < alan . nemo @ yahoo . com > wrote:
The two most interesting things about Meta II were:
- it captured the idea of top-down recursive descent parsing as a "programming language for BNF", with a few key insights and a very simple design.
- This allowed it to be written in itself extremely compactly in just a few lines (this is included in the Meta II paper) which allowed any reader to make a Meta II for themselves in just a few days and bootstrap it onto their computer. Once you did the bootstrap, you had a meta-language for computer languages and also to improve itself.

Many systems came out of this architecture. One of the most famous is "Tree Meta" (where what is generated is an abstract syntax tree that could be further processed for optimizations and better direct code generation). This was made and used by Engelbart's programmers to make the higher level language that Engelbart's famous hyperlinking media system was programmed in. BTW, 2008 in Dec is the 40th anniversary of Engelbart's big demo ("the mother of all demos") in San Francisco.

Re: The IBM 1130. Another machine I have many memories of. It was the base computer for bootstrapping my thesis project of "The Flex Machine" (done with Ed Cheadle). The 1130 could have been the first real PC but IBM managed to avoid it by some really crazy choices in both architecture and approach (I presume that its predecessor, the 1800 (which I'm not familiar with) started the craziness.)

On Feb 22, 2008, at 11:35 AM, Alan Kay < alan . nemo @ yahoo . com > wrote:
I should add a few things ...

In the US Air Force in the early 60s, the "programmers aptitude test" was made up by IBM. I was at James Connolly AFB in Waco, Texas (a "training AFB") and was told that "no one at James Connolly had passed this test". Naturally, I was curious. The test was interesting, and basically a kind of IQ and problem solving aptitude test that took a few hours to get through.

Those who passed the test were transferred to Randolf AFB, the mother ship of Air Training Command. The accounting for this Command was mostly a huge PCAM (Punched Card Accounting Machine) "floor" about the size of a football field, filled with 101s, 407s, etc., all programmed by wiring up "boards" (which was a highly interesting pursuit in itself, given that quite a bit of parallel process thinking was required). There were also two computers: a physically large Burroughs B220, which was a "decade" machine in which 4 bits were used for each digit of a ten-digit word; and, there was an 8K 1401. Both of these machines were unusual by today's standards, but there were many architectural experiments back then so all programmers expected to learn a very different kind of logic and machine code for each of the 10 or so machines they were likely to encounter.

The vendors also ran the training for these machines. The 1401 training was one intensive 40 hour week conducted by IBM, at the end of which one was now a programmer. Actually one was a "coder". "Programmers" were people who designed "data processing" schemes and expressed them in flow chart form. These flow charts were turned into actual data processing by organizing and wiring punch card machines. These practices were carried over to 1401 programming and most of this was devoted to taking the manila folders of flowcharts for PCAM and getting the new 1401 "coders" to make these schemes doable with the 1401.

This only worked for simple tasks. And soon, the coders were doing more and more of the design.

There was no OS on the 1401 (later we made a 1K one that fit in the top of memory and could completely handle all the batch jobs in a 24 hour day, tell the operator what tapes to mount, etc.)..

The smartest guy there, Rachon Andre Douglas, was a staff sergeant who (as with about 30% of the programmers) had been a Russian linguist in Europe. He was my best friend while I was there, and I always expected to hear great things about him. But I lost track, and haven't been able to locate him.

Debugging was desk-checking. One could get 3-5 minutes max each day with the machine. Only the operator was allowed to touch it, and they had placed the card reader between the programmer and the console (good for holding one's listing) to prevent temptation. So the programming and debugging strategy was very different.

The crown jewel of 1401 programming was Autocoder, which was a really good macro system for its day (and pretty much any day). There was also an essentially unusable FORTRAN (zillions of passes, especially on an 8K byte machine), and RPG (which did work pretty well). COBOL was just starting to happen and was not used at ATG.

A much nicer language Balgol (Algol 58, a really nice design and implementation) ran on the B220, but still, most programming was done in assembly for speed and space. I invented an interesting sorting scheme for this machine, which had the usual property that the tape drives only ran at one speed (slow) and there was no faster rewind speed (as there was on the 1401 and most other tape drives of the day). This meant that merge sorting of large files was a killer, work got done only 50% of the time. I came up with a "Fibonacci" like scheme that could always be sorting, merging and rewinding.

The best learning I had while at ATG for my 18 months, was to learn the B5000 (which was not yet delivered, but there was plenty to read and think about). This was perhaps the greatest single HW design of all time, and it was certainly revolutionary in its day, in a time of unusual machines. It was really unusual (and truly great).

"Mystique and Lore" from Keith Falkner Jan 27, 2011
Dear Robert,

My first permanent job was in 1963, at IBM. As soon as I learned how to program the 1401, I started developing commercial programs for many customers in Ontario. Among them were life insurance companies, manufacturers, department stores, an air transport organization, and probably others I forget.

I learned to wire panels for 602, 402, and 407, and casually learned the simpler ones, such as 088, 513 and the interpreter (557?). The only application I wired for profit was a series-50 602. Abitibi Paper needed a "crossfoot verification". I had to verify that seven figures in each card accurately presented A+B+/-C+D+E+/-F=G. It turned out that this was exactly at the upper limit of a series-50 602's processing power, so I had no room for error.

But I was involved earlier in a company moving from UR to EDP. This was my first job ever, a summer job in 1959; I was a high school graduate! In 1959, Canada Life, one of Canada's major insurers was part way through a lengthy file-verification process. Many thousands of cards went through a 108 Card Proving Machine, in an attempt to weed out errors before the computers arrived. I built a lot of muscles there, horsing hundred-tray files from end to end of the building and back again, then merging corrected cards back into those same files. When shortcomings in the 108's wired program needed correction, someone else had to do that, and I ran other UR machines, so I guess I know most of the card machines rather well. I do not put these skills on my resume, but you know, maybe I should.

As to "Mystique and Lore", that is a matter of individual involvement and motivation. I have greatly enjoyed most of my jobs, and I thought of the 1401 as a friend and co-worker.

Once upon a time, a company named Royal Insurance moved from Montréal to Toronto, and its programs moved from the Montreal Datacentre to the Toronto Datacentre, and they landed in my lap. They were AWFUL, universally examples of rotten rotten code, and I recall feeling sorry for the poor 1401 that had to follow these garbled orders and make endless stupid mistakes.

Here's an example of the illogic I found: Most months, a certain monthly program was supposed to detect a certain type of policy and punch two cards, but in October it was supposed to punch four cards, but the operators were aware that it punched four cards for the first situation, but only two for each following one, and used an 80-80-rep program to make up the deficit. Why? Here's why.

Usually, during initialization, we had
but in October, we had instead
The above code was executed once.

Then, when some cards were needed, we had
(logic to create the card)
   S    @1@,NOPUN
   MZ  @0@,NOPUN
   C    @0@,NOPUN

So how did we get two cards in, for example March? NOPUN counted from 2 to 1 to 0, giving us two cards. Next time through, NOPUN counted to -1 and had its zone stripped, and then it counted back to zero, again giving us two cards.

In October, NOPUN counted from 4 to 3 to 2 to 1 to 0 giving us four cards. Next time through, NOPUN again counted to -1 and back to zero, giving us two cards.

The author of this abysmal code was Joe Clenman, and he must have been aware of his shortcomings, because he put a lot of 7-byte NOP instructions amid his code, to simplify patching. So I called him NO-OP Joe (but of course I never met him, because his boss tricked him into retiring -- "It's the only way you can get the three-week vacation that you want for your honeymoon, Joe. I will be able to hire you back after you return from your honeymoon.") Note that there was no promise to rehire Joe, and FERSHOOER there was no such intent in the boss' mind. He thanked Joe for asking for his job back, and ushed Joe right out of the building.

And man, did I have a lot of detective work to do in order to determine from Joe's sloppy coding what the damn programs were supposed to do. I must have got some of it almost right, because within a year, Royal Insurance signed for some new applications, specifying that yours truly write the code.

Now, if I can recall these details after the span of 47 years, I think that recall shows that I cared a lot about the machine and the work it enabled me to do. We had musical programs, you know. I do not mean Turkey in the Straw or She'll Be Coming 'Round the Mountain on the 1403; I mean songs that were broadcast to a radio placed in the guts of the computer. They were tinny and trite, but of course so were the radios.

Back to Auto-Loder. One day, a few minutes after quitting time, I was trying to debug something, when a nearby phone rang, and a supervisor (not a programmer) answered. It appeared that a customer was explaining what had gone wrong, in very exhaustive detail. I could hear only the supervisor's side of the conversation, but I determined to gather enough information to solve the problem, and in fact I did. So I heard the supervisor cordially say good-bye to the customer and hang up. You know exactly what the supervisor's next word was, but he brightened up a lot when I came into his cubicle and presented three coding sheets with an Auto-Loder program that I expected to solve the problem. It came fairly close the first time we tried it, and worked completely within an hour. I think the supervisor and I sold a lot of programming when the solution was presented, but I got my reward by seeing the proper reports come out. By chance, this supervisor was my boss in 1985 and 1986, when I worked for a major Canadian Laboratory (which my grandfather had worked for in the early twentieth century!).

I have a long motorcycle ride in the next two days, so I will amuse myself on I-75 by recalling more of these anecdotes, and I'll pass some along next week.

I'll include one on vandalism!
(I made it up to the victim.)


High Humidity and Crack Cores story from Rick Dill Aug 4, 2009
in response to worries about humidity control at CHM
At this point, local humidity control is probably not an issue. We are looking at over 40 years in which the transistors with slight leaks in there "hermetic" seal accumulated moisture under conditions a whole lot more harsh than the bay area. The transistors which might fail next have most of the moisture already inside and it won't come out easily without at least a vacuum bake (NOT RECOMMENDED).

While I haven't seen the restoration room it simply isn't Houston in the summer. It was there that IBM encountered a one in something like 500 million failure of cores under high humidity. It turns out that the cores were manufactured in Poughkeepsie in a room with ceiling tile that slowly flaked residue. If a tiny flake got into the cores pre-fired ceramic mix, it would get pressed into a core by the pill forming machines IBM used. If the flake was completely surrounded by ceramic, it caused no damage. If, however, it was exposed at the surface, then in very humid environments it would expand and crack the core. The system redundancy was able to handle a few cracked cores, but in Singapore and Houston, among other places, the CE's would come in late at night and replace all the cores in a system without ever letting on to the customer about the problem.

The engineering solution was to create the most dirty clean room I ever saw. The ceiling tiles were replaced with HEPA filters,but the room was still involved in pressing cores out of black ceramic which was everywhere in the clean room. So long as the ceiling tiles weren't shedding, the cores were as reliable as one would expect from a small piece of ceramics.

That, of course, brings up the demise of cores in IBM just as the details of the physics was understood and the technology advancing at a tremendous pace.

Anyway, lowering the humidity in the restoration room is a useless exercise, at least as far as leaky transistors goes.

Rick ... no I actually never worked on core memories, although for a brief period we thought about magnetic logic using multi-aperture cores. The challenge was to build an alternate technology 1401, but management never got the program off the ground. It was fascinating to think about, but certainly not the right direction to go in.

IBM 1401 Makes its Debut in San Francisco from Jan Barris, Aug 2, 2009
or "Grace Under Pressure" ;-))
A true story by Jan Swanson Loper Barris

It was 1960 and the IBM 1401 was to be demonstrated for the first time in public at the Data Processing Management Association’s National Convention. The Binghamton DPMA Chapter, of which I was an active member, decided to send me to the convention as a delegate. I had never been to the West Coast so the appeal of San Francisco and the chance to see the customers react to our “great new machine” was exciting. I really wanted to go, but I knew the trip would be expensive.

Fortunately, Jim Greene of Product Marketing and Noel Cappetini (Cappy) Manager of Product Publications thought it would be a good idea to have someone in San Francisco available in case there were any problems with the demonstration program which had been written, I believe, by Product Marketing. I had worked with the development team as the Lead Writer on the 1401 Reference manual and had knowledge of how the hardware worked and could write simple programs in machine language. After several phone calls and some fancy negotiating by Cappy, Jim Greene and the President of the DPMA decided to split the cost of my trip 3 ways and I got the approval to go.

I decided to leave a couple of days early the Friday before the convention so I could do some sightseeing in San Francisco. Just after my plane left the Broome County Airport, there was a tremendous storm and Endicott was flooded. The 1401 that was to be shipped to San Francisco was under water on the loading dock at the Endicott Plant.

Unbeknownst to me, the powers that be located another 1401 in Chicago and sent it to San Francisco. When I arrived at the Fairmont Hotel on Saturday morning, the customer engineers were assembling the Chicago 1401 at the demonstration site. They were using Product Marketing’s demonstration program to test the system. Nothing worked! I watched them get more and more frustrated as they were sure they had done their jobs correctly.

Finally, I asked a pivotal question. “How many bytes of core does this machine have?” They investigated and informed me that the machine was a 2K version. Well, I knew that the demo program was written for a 4K machine and told them so. What were we to do? There wasn’t time to send the program back to product marketing and the system had to be ready to be demonstrated on Monday.

Shortly, the systems engineer from the branch office that was in charge of operating the demonstration machine appeared on the scene hoping to do a trial run. We told him of our problem and he volunteered to help me reprogram the demo. (He was single and had the whole weekend free.) Between the two of us we figured out how to make the machine look good with only 2K available for the program.

We put a legend in core storage and gave one command after the other -- seek, print, punch and write to tape. There was no space left for error routines, so we simply left them out. On Sunday we punched up the code and ran a system test with the customer engineers looking on with great relief. Needless to say the 1401 performed magnificently. All the input output devices operated at top speed. We decided that this would make an excellent demonstration and went out for dinner at the Gaslight club.

On Monday the convention attendees gathered for the great unveiling of the 1401. I stood in the front row between Shel Jacobs, the 1401 Marketing Lead and Al Barr, the Manager of Product Planning—both from Endicott. The local demonstrators had no experience with the 1401 and put the cards in the card reader upside down.

Red error lights flashed galore. But, with no error routines to stop the system it just kept going. The tape reels spun, the RAMAC search arm moved quickly, the cards punched in rapid succession and the printer spewed out reams of paper as fast as possible. It was an impressive sight! Shel and Al were proud as they could be.

Then, Al Barr turned to me and said “Did you have something to do with this, Jan”? I nodded.

1401 PowerUP, Time & Life Building from Jud McCarthy May 1, 2005
A little background: A major show case for IBM of their wares was at the Time Life Building in a prestigious section of Manhatten.

Robert: In reading the correspondence between you and Chuck Branscomb, concerning the 1401 and the transmission from punched cards to magnetic tape and on to disk systems, reminded me of a story as it applied to installing the first 1401 System at the Time and Life building in NY City. The following dialogue especially jerked my memory.

"I'm assuming that the tape systems (and then later 1405/1311 disk systems) did move thousands of unit-record accounting machine users to another "new world" without storing data on zillions of punched cards.  My blurb says (this factoid from the 1971 THINK magazine article on 1401):
"A year later, the first 1401 was delivered to Time-Life, which transferred 40 million cards to just several hundred magnetic tape reels. Unforeseen by all involved, 1401 tape (and later magnetic disk) systems effectively ended the era of storing data records on countless punched cards. "

The Story:

After working on the original Development Engineering team of the 1401 and spending time early on, assisting 1401 Manufacturing to debug the first units on the line, I was asked to fly down to NYC to assist in setting up the first 1401 system in the Time & Life building. As a young snotty nosed kid and one of the low men on the totem pole, I was more than excited and anxious to accept the challenge.

The mission was to get there and prepare the raised floor area in the basement of the Time & Life building for installation, prior to the arrival of the system. On arrival of the system we were to unpack all the system units, string the large power and signal cables under the raised floor, and get it set up and tested before 7:30 AM the next morning. The system finally arrived very late afternoon and we proceeded to set it up and get ready to put power on. Our estimate was that we would be ready for "power on" at midnight, and were told that a person would be there to assist us, but we were not to plug the power cable in until he arrived. At midnight, we were ready for power, but no one showed up to plug the power cable in. At 2:00 AM were getting wrestles and had a maintenance person start making phone calls. He told us someone would be in, in about ½ hour. By 4:00 AM, we were afraid we would not make the 7:30 AM system ready dead line, and that customers scheduled to view a functioning system that morning would be more than disappointed.

Being responsible for the 1401 power system, I then took it upon myself and went over and plugged the system in. We commenced to bring the system up and get it functioning. At 6:00 AM a big man came in with clip board under his arm yelling "Who the hell plugged in this system?" Of course everyone looked at me. He came over to me and looked down and said " Are you the one who plugged the power in ?" After I confessed, he took out his pen and clip pad and yelled "Give me your name and who you represent, no one is supposed to plug the power in except me." Being very naive and scarred to death, I took out my little Think Pad that I was keeping notes on and simply said "OK, but please give me your name and where were you at midnight, when we were told someone would be here to handle the power?" He hesitated for a minute, with everyone watching, and said in a loud voice "Have you got this system up and running?" After I said "Yes, we are just about finished" he walked around the area, making gestures with his arms, while checking every thing out and turned and said. "OK, if you have any problems, let me know" and went into a nearby office.

I never thought anything about it, until later that morning when the system was perking along. That’s when the resident IBM Senior CE, who had helped with the set up, explained that I had just encountered the local union official and could have shut IBM down for the next month or more. Sometimes being young, naive and ignorant of the real world can be an advantage.

"Slight of hand ;-))" from Jud McCarthy May 1, 2005

Here is an interesting 1401 Development story from Byron Rucker (1401 Development Engineer) that involves B.O.Evens and Chuck Branscomb. Regards ----- Jud

PS: I believe Byron will be one of the mini 1401 reunion attendees in Endicott on 8/6/2009.

-----Original Message-----
From: Rosa M Rucker - rmaygolf at juno dot com
Subject: Re: 1401 tape and chain printer support

Jud - I transferred to Glendale in January of 1959. I worked with Walt Shaffer on the attachment interface to the TAU unit.

We got two very early 729 tape drives (Serial No.'s 2 and 7) off the 729 tape line.

Apparently they were delivered to the dock in the upper building, but Branscomb decided they must be for the 1401 so they got moved (late at night) to the lower building.
I understand B. O. Evans was on the line with Poughkeepsie trying to determine when he was going to get his tape drives for the 7070 program. We had tapes up and running very early. I do not remember the A, B, C model designation.


Comment by Ed Thelen --
Yeah Sure - and if not - we will put them to good use while we can - hate to see them idle ;-))
How to make "the system" work for you ;-))

ManufactNote-A from Jud McCarthy April 5, 2009

Rob: As I re-think about it, the A Level Model was most likely used in Europe. Again, Earl Bloom can confirm this. The C Test units were built by Manufacturing at the Endicott North street facility. Not counting the basement, they were built and tested on the second floor of Building 46 on the North East corner of the building. Building 46 was on the North side of the railroad tracks on the South West corner of McKinlney Ave & Watson Boulevard. The 1403 printers were built and tested on the first & second floor of Building 41, that was on the North West corner of North Street & McKinnley Ave. You could walk from the second floor of Building 46 (1401 test area) through a passage way right into the 1403 test area on the second floor of Building 41. Frank Silkman's team assembled & tested the memory units on the third floor of Building 46.
--- Regards --- Jud

Soft Spot from Alan Kay March 13, 2009
I have a very soft spot for 1401s (especially tiny little 8K ones like my first machine ever in the Air Force in 1962).



Howard Oels - 09/24/2012
Stan Paddock found this on Ed Sharpe's "Southwest Museum of Engineering, Communications and Computation" web site.

My Early Days With IBM and Sorbus - by Howard Oels

from Simcha Druck 12/13/2007
I worked in a service bureau in New York that had both a 1401 (with 1406) and a 360/40 in the late 60s. It was John Felix Assoc. and had become a subsidiary of Interpublic (the advertising company). The 1401 was a great machine to use. And it kept running under the most adverse conditions.

I recall one time when there is a voltage drop and the 360 and its equipment shut down. We had no lights in the computer room. In the darkness, with the lights off and the 360 down, the 1401 kept merrily running, its lights and its 729s being the only illumination in the room. The 1401 was an IBM version of the Energizer bunny - it just kept running and running...

Robert Garner asked about running the Mod 40 in emulation mode

Our 360/40 ran about 60% native and 40% emulation. We had an FE who wrote code for us that allowed us to run the emulator without re-IPLing. I don't recall exactly what it was but we were able to run 1401 Autocoder jobs mixed in with native 360 DOS COBOL and BAL jobs in a single job stream. There was a module sitting out somewhere on SYSRES that was executed from the // EXEC card which then switched on the emulator. When the 1401 job was done, it had a standard DOS // END card and the module restored native DOS. It was a tremendous boon for us to be able to run straight through and mix the jobs together without re-IPLing.

from John Van Gardner 12/12/2007 - WireWrapping BackPlanes
Yes on 25000 series, the card sockets were reserved and a lot of the wires were already there. You can tell this by looking at the tie down list on ALD page There are 20 tie downs listed for the Overlap feature in the left hand column. These were supposed to be white wires and were used to prevent floating inputs from causing trouble. It was a lot easier and cheaper to let the Gardner-Denver put the wires in when the board was manufactured. This was a big help in reducing field installation time.

I used to watch them wrap boards in Poughkeepsie. These machines had 2 wrap heads and 2 positioning pins all under control of servos. There was a reel of yellow wire about 3 feet in diameter and 18 inches wide feeding into the machine. It would strip the wire on both ends and the positioning pins would go down over the via pins bending the wire there and wrap heads would wrap the to and from pins. It was very fast and hard to really see what was going on. This machine wrapped one end of the wire in a clockwise direction and the other end was counter-clockwise. We had a manual unwrap tool in our tool bag that one end was for unwrapping clockwise and the other end for counter-clockwise. We could tell if a wire was put on at the factory as all our field tools wrapped clockwise.

They had a 1401 connected to a special built machine that looked like a pizza oven. The board was place in it with the pins up and a contact panel lowered to contact each spring loaded pin. The 1401 would put a voltage on a pin and scan all the others to see where it went. This would detect opens and shorts. It didn't take the 1401 long to scan every pin in the board. If any errors were found they were printed out on a B1 typewriter. There was a woman there that corrected any mistakes. If she made more than 3 corrections the board had to go through the pizza oven again.

Comments by Ed Thelen
We used Gardner-Denver machines at General Electric Computer Department in the 1963 era. They were used to wire all the backplanes of all the product lines. Ours must have been a slower model as you could definitely see what was going on, and the wrap direction was the same direction as field wiring.

Interesting items:

  • Each machine had an attached IBM 026 key punch to read the cards instructing the machine where to put the wires. If I recall correctly, there was one card per wire? About 40 of the 80 card columns were read, the rest of the card was rapidly skipped. It appeared that the machine did not pause for the reading of the next card - I imagine that the keypunch was reading the instructions for the NEXT wire while the Gardner-Denver machine was wiring THIS wire. Overlap operation ;-))

  • I do not recall a wire checking machine. I suspect that any mis-wirings were left to the floor techs to discover and fix??

  • I suspect that John's "Pizza Oven" was what folks would call a "Bed-Of-Nails" tester. One contact per position to be checked - or more generally a complete matrix of "nails" contacting points for continuity or what ever.

from John Van Gardner 12/11/2007 - date of 1401 Overlap
This morning I decided to look through all my personal letters from IBM and found the one attached. Then I looked at my story about Process Overlap and saw that I had written about the suggestion award:

After they all finished talking to each other they turned to us with a load of questions. We had been the first field personnel to install the feature and the first to trouble shoot the bugs. They were very interested in the circuit I had designed to sync my scope and restart the machine. I told them I was going to submit it to the suggestion department for consideration. They told me to be sure and mention in the suggestion that I had divulged the idea to them. (October 31, 1962 I won a $50.00 Suggestion Award number D03556 for my Process Overlap Address Sync service aid.)

IBM suggestions would be rejected rapidly but acceptance could take a year or more. We now know that 1401 Process Overlap predates October 31, 1962.

from Bill Worthington 8/13/2007
This is an interesting look back into the 1950s.  I didn't have a chance to spend time with Karl during my February visit to the Haus zur Geschichte der IBM Datenverarbeitung.  His name was mentioned.  I'll have to save that for another trip to Böblingen.

I came onto the picture as a 1401 programmer in 1960.  The bank's 1401 actually came in the summer of 1961.  Back then, 6-12 months between order and installation was standard to "give you a chance to get your programs in shape so that the computer could be put into production when it arrived."  So, we made many trips from Providence to the IBM Datacenter in Boston to test programs before the actual arrival.  We did have a 1412 MICR Check Sorter which was demonstrated in the customer lobby at the bank's headquarters.  All the programmers had to take tours of duty showing how capable it was as a stand-alone sorter.

I too am fascinated and intrigued by Karl's saying:
- Cost objectives:
The costs of electronics technology with ferrite core memory and stored program control were still  barely acceptable for the Unit Record market in the mid 1950ies.. Its low cost end actually could not be reached with the 1401, particularly in Europe. But thanks to the booming high end Unit Record market in USA this did not matter. Instead, a low cost version 1430 was planned to be developed but this submerged in the /360 design processes for several years. Eventually the /360 Model 15 and later the /3 took care of this.
I wonder if the 1430 he refers to is the (US?) 1420 system which was a latecomer to the 1400 family.  It was a low-cost implementation that was sold in the US in the 1960s (post 1440 and 1460's being available).  As I recall it was focused on the banking industry and may have had a check sorter (1240?) built on to it.

I think his last sentence may refer to the System/3.  I remember running a comparison benchmark of the S/3 vs. a S/370 Model 115 when I was in the Poughkeepsie Systems Center that created quite a stir.  The jobstream was one Rochester used and was mostly RPG.  I converted it to run under DOS/VS using an MFCM attached to the S/370-115.  The Model 115 came out ahead which was not expected.  I got my hand slapped because we did not review the results with Rochester and, instead, published a Technical Bulletin.  Once Rochester saw what had happened, they demanded and got the withdrawal of the Technical Bulletin.  Lots of copies had made their way out.

I also don't recall a /360 Model 15.  The Model 25 was the smallest S/360 model that we had to sell in the US.  It had up to 48K of memory and we did get an OS/360 system running on it even though the spec for OS/360 said it required 64K.  But this is another story.

Regards, Bill

Robert B Garner wrote:

More fascinating, first-hand, nascent 1401 history on the WWAM group
from Karl Ganzhorn, one of its members, attached and pasted below...

Please send any follow-up questions to me and I'll forward to Karl.

Emerson ==>  Karl suggested you might know how to find
Francis Underwood's email address or contact info?


- Robert

IBM Almaden Research Center, San Jose, CA
Office:  408-927-1739
Mobile: 408-679-0976

----- Forwarded by Robert B Garner/Almaden/IBM on 08/13/2007 04:08 PM ----- (Karl Ganzhorn)

08/07/2007 05:18 AM

Robert B Garner/Almaden/IBM@IBMUS

1401 History_3

Dear Robert,
attached please find my comments to your questions <Garner807.doc>.
Rebards, Karl


                                                                                August 6, 2007.

Subject: 1401 History_3.

Dear Robert,

Thank you for your e-mail of August 6. Here are some answers to your questions:

- Anecdotes:
You may use them for publications except ...

- Origin of the name WWAM (needs a lengthy explanation):
In the early 50ies IBM’s Unit Record product line was different in USA and WTC due to the war separation. But the need for faster calculation and printing was recognized in both areas. During and after World War II the development of Unit Record punched card machinery had followed different routes: In France J. Ghertman and his engineers had designed calculator punches like the 626 and especially a new accounting machine Type 421, functionally similar to the 407, all in relay technology with plugboards for wireable data flow, storage allocation in electromechanical counters and control functions. In Germany a series of special features for the 421 accounting machine were designed.
IN 1951 the Corporation had encouraged several European IBM companies (France, Germany and United Kingdom) to establish engineering competencies in electronics. In France J. Ghertman, in Germany Walter P. Scharr and in UK J. Elliot (an outside hire) were implementing this directive.
By 1954 it was recognized  in USA, in France and in Germany independently of each other that electronics had to be investigated also for use in Unit Record machines, replacing the clumsy relay technology. In USA several engineers around Jim Ingram became active, in France John Ghertman and his excellent engineers were searching ways and in Germany I had been given the task to seek ways for introducing electronics and physics into IBM’s product line technologies.
In early 1955 the Corporation set an objective for a common future product line for the Unit Record markets in the world. In the following early deliberations the name of “World Wide Accounting Machine” emanated.
For the first time a multinational engineering task force was conceived, the WWAM task force, with participants from USA, France and Germany. Walter Scharr, head of the German engineering department, was asked to host the first workshop of the WWAM task Force (about 6 weeks) in Boeblingen, Germany. Both Watson brothers, Tom and Arthur, took an active interest.  

The strongest market pressure emanated in France from the national competitor Bull who had an electronic machine out in the European market.

- Two Address Concept:
In the early days of computers 1-, 2- and 3-Address schemes were investigated all over the world. The most frequent calculation in Unit Record  applications consisted of a card stack with various information on each card. The stack was sorted in subgroups. Each type of information had to be added to an individual counter (accumulator). I.e. a varying number of accumulators was required to which the respective numeric information could be added/subtracted. This represents a multiple two-address operation. The French idea was to establish any storage cell to act as an accumulator to which the contents of an input word could be added. This way multiple accumulator registers could be avoided. Calculation went directly from the card input to memory. (Today every pocket calculator has this function, namely “memory +”). Estrems and Papo just combined this calculator function with a variable word length in memory allocation. (By the way, 8 years later in /360 one of the machine instruction formats represents exactly the 2-address format required for the “Add to memory” operation.)

- Plugboard Control:
The plugboard used to be the generally accepted means of control in all Unit Record machines (405, 407, 421, the earlier German D11, etc.). By plugging wires the information flow, the memory allocation and all functional control signals were determined. In the early design deliberations for WWAM this concept was never even questioned. It was Underwoods independent mind touching this holy cow in 1956/57.

- Stored Program control:
The WWAM concept also had in mind that for the world-wide customer community the established way of handling control by plugging wires on a plugboard should be maintained. The 1401 finally took away with this, based on Underwood’s design proposal, which meant a breakthrough in the Unit Record world.

- Controversial issues in WWAM conception?:
Decimal arithmetic was never questioned for the wide spread accounting business.
Fixed versus variable word length was a long debate. Primary reason for variable word length: Saving expensive magnetic core memory capacity. (Even three years later the 1401 came out with a lowest cost memory version of 1400 characters!).

- Cost objectives:
The costs of electronics technology with ferrite core memory and stored program control were still  barely acceptable for the Unit Record market in the mid 1950ies.. Its low cost end actually could not be reached with the 1401, particularly in Europe. But thanks to the booming high end Unit Record market in USA this did not matter. Instead, a low cost version 1430 was planned to be developed but this submerged in the /360 design processes for several years. Eventually the /360 Model 15 and later the /3 took care of this.


I hope this helps you with some of your questions.
Best regards,

from Gary Mokotoff 1/17/2007

You have created a noble project to resurrect the work of the IBM 1401
development group of 40 years ago. But there is a missing piece. I propose
that Dave Macklin, John Wertheim (co-author of Autocoder) and myself, write
a history of the 1401 development group and how it operated then. It is a
fascinating story full of interesting tales. 

We were the "first" programmers at IBM. The 1401 RPG compiler was written by
an ex-industrial engineer and ex-airline stewardess. RPG was developed,
ostensibly, to make it easy for people who knew how to wire the IBM 407
accounting machine to upgrade to the 1401. The 1401 Fortran arithmetic
phases of the compiler was written by an 18-year-old genius, Stan Smillie,
whose favorite expression at that time was "no sweat." There was Linda
Heitner, a champion contract bridge player who used to talk about bridge in
the office and program the 1401 at the bridge table (driving her husband
crazy). Linda, I believe, wrote the object-time floating point subroutines.
Etc., etc.

I do have some artifacts from those days including newspaper announcements
of the 1401 as well as an ad that appeared in Time magazine.

Are you interested?

Gary Mokotoff

-----Original Message-----
From: David Macklin [] 
Sent: Wednesday, January 17, 2007 8:21 AM
To: Robert Garner; Gary Mokotoff-
Cc: Ed Thelen; Van Snyder; Robert B Garner; Robert Garner; Ronald Mak; Dan
McInnis; Bill Worthington; David Weaver
Subject: Re: [1401_software] Serial compilation and the 1401 FORTRAN

Many thanks, Robert, for keeping me informed. I am copying Gary Mokotoff 
who coded most of Autocoder and
FORTRAN (and has rediscovered many relevant listings, which he has made 
available to the Restoration project..)

Gary is now a world-famous geneologist, in which pursuit he has invented 
a most clever way of reconciling the bizarre spellings of Eastern 
European names and places..

I'm well and still programming in APL2 for the PC.

David Macklin

----- Original Message ----- 
From: "Robert Garner" 
To: "David Macklin" 
Cc: "Ed Thelen" ; "Van Snyder" 
; "Robert B Garner" ; 
"Robert Garner" ; "Ronald Mak" ; 
"Dan McInnis" ; "Bill Worthington" 
; "David Weaver" 
Sent: Wednesday, January 17, 2007 1:13 AM
Subject: Fwd: [1401_software] Serial compilation and the 1401 FORTRAN 

> David,
> Happy New Year!
> I hope all is going well with you.
> The 1401 restoration has been making steady progress.
> Question:  Did you see this email about Van Snyder keying in the
> source for Autocoder?
> Regards,
> - Robert
> Begin forwarded message:
>> From: Van Snyder 
>> Date: January 13, 2006 1:33:35 PM PST
>> To: 1401 Restoration Software Discussions
>> <>
>> Subject: Re: [1401_software] Serial compilation and the 1401
>> FORTRAN compiler
>> Reply-To:, 1401 Restoration Software
>> Discussions <>
>> Ed:
>> David may be pleased to know that I keyed in the Autocoder source 
>> code
>> from the listing in the CE manual, and then assembled it with the
>> Autocoder cross-assembler I wrote, getting almost the same deck, the
>> only difference being the strategy for assigning "set word mark"
>> instructions that result from DA fields to individual "load cards."
>> I had to make a few minor changes in the source, to make my assembler
>> handle it:  Mine can't do macros (other than CHAIN) yet, and it
>> handles
>> SFX a little bit differently.  These could be easily undone to 
>> produce
>> an "exact" copy of the version 3.0 Autocoder source code.
>> I am happy to send it to him if he's interested (or indeed to anybody
>> who is interested).
>> Van
>> On Fri, 2006-01-13 at 03:34 -0800, Ed Thelen wrote:
>>> David Macklin (87 years old) visited the museum,
>>>   accompanied by his son, a valley resident.
>>> David was involved with
>>>     later phases of SPS
>>>     AutoCoder
>>>     1401 FORTRAN
>>>     APL
>>> An image of David is at
>>> I have just added an OCRed version of
>>>    (link by Robert Garner - thank you ;-))
>>> maybe most easily accessed via
>>>      C:\0-Net\1401Project\new.html
>>> Cheers
>>>    Ed Thelen
>>> P.S. I do not have a current e-mail address for Mike Albaugh
>>>        Who is the docent interested in APL?  David published an
>>> APL book.
>>>        David says the tape FORTRAN version contains the card
>>> version images (mostly)
>>>               maybe we could restore a card version from the tape.
>>> Does Van Snyder have the tape?
>>> ________________________


Predict Home Run Race from Jim Foley Sept 15, 2006


Roger Maris vs Mickey Mantle Home Run Race in 1961 The Statistical Tab Co. was asked by the “Today Show” to predict the winner of the race to beat the Babes record of 60 homers. Their office was located in the shadow of what would be the World Trade Center in lower Manhattan, a big hole in the ground at that time. Their prediction was reported daily from the 1401 Computer Room with a live TV broadcast on the Today Show. Frank Blair was the news anchor on site. I would make my way into New York from New Jersey on the first Ferry from Hoboken at about 4 am.

My job was to make sure things ran smooth. Things went fine for the first few days until one day we hit a glitch. From that day forward the analysis results were run before the telecast and the results were re-fed into the 1403 printer. For the live show as the camera zoomed in to display the result I would crouch behind the printer and hit the escape button. Real Time at its best.

1st Computer to Satellite? from Jim Foley Sept 15, 2006

The IBM 1961 – The first commercial IBM modem developed at the Glendale Labs in upper NY State. I received my training at the lab sometime late 61 or early 62.

My territory moved way uptown to just south of Canal Street. I was assigned to the ATT Hdg Building and their 1401 near the top floor. After being cleared for “Secret” I was told that were going to use their administrative 1401 and the 1961 modem to originate computer data to sent to the Telstar Satellite and return them. A full wrap around test was the plan. I chose of all things the 1403 ripple print program that was used to clean the print chains. I worked with the ATT techs for some weeks lashing the 1961 box to their analog multiplex converter with the lash up to Andover Maine for the transmission to the satellite. The original Telstar had one innovative transponder to relay data, which was a television channel or multiplexed telephone circuits. The test to Andover was successful with my ripple print pattern humming away after a two to three minute loop delay.

The day came for the test, Telstar would be in range for about a half hour. I Ran the patter through the IBM 1961 modem to the ATT multiplexer and off to Andover. We then waited. Nothing, nothing back to my waiting 1403, 5 minutes, 10 minutes, 20 minutes, then finally at about 26 minutes later came the sweet hum of the 1403. This was probably the first computer communication to a satellite and I had the cleanest print chain in the US.

Side Saddle Printing" from Milton Thrasher

I knew Fran Underwood from my assignment to evaluate the IBM 1401 to see if its 1.4K memory was adequate to do useful work. Four of us Systems Engineers were involved: Bruce Campbell from IBM Boston was one of the others.

I was able to write a program in 2 days to do Yellow Page advertising billings with the same deck of cards that were used to print slips for the type setters without having to resort the cards. That application had taken me several months to wire for a 604 Calculating Punch and 407 Accounting Machine, both of which had to have extra memory to do it. It was exactly the proof they needed for a significant application.

Earl Bloom worked under Frank Underwood and developed the printer chain slugs for the IBM 1403 printer.

Earl was not aware of the “side saddle” printing approach I developed for printing 8 column listings per page of telephone number changes for the “Intercept Directories” at New Jersey Bell Telephone. Telephone operators were given printed lists of telephone number changes daily so that if you called a number that was changed, you would be routed to their switch board so that they could tell of the new number from their directory. I remember that Walter Smith was the IBM salesman for NJ Bell who brought the problem to me. I have copied him in hopes he can recall some other aspects to this solution.

The problem in printing the directory on the 8K IBM 1401 4 Tape System was that there was not enough memory for the 8 columns of from and to phone numbers on a page. A 16K IBM 1401 was either not available or too expensive. I had heard of a printer on the IBM 704 at Bell Labs that was able to do printing with wires at 90 degrees from normal So, I used that idea by turning the type slugs 90 degrees from the normal to print one column, then read in the next column and print it until the page was filled with 8 columns before advancing to the next page.

This approach allowed our IBM Newark, NJ office to sell some IBM 1401s. The idea was then circulated to other phone companies including NY Telephone where more IBM 1401s were sold.

I received a congratulatory and thank you letter from Tom Watson, Jr for this effort. It was at a time when IBM was looking for novel applications that helped sell equipment. This may have influenced my being promoted to Manager of Systems Engineering Techniques Development Manager in the Eastern Region at 425 Park Avenue, NY a few years later.

Foiling Honeywell "Liberator" from Milton Thrasher

I have a story about my shoe box full of IBM 1401 Autocoder macros that I called the “Captivator” because the Honeywell 200 “Liberator” program could not convert the IBM 1401 Autocoder created programs if they included the macros from my shoe box.

I got the macros from Ed Czerkies, an IBM 1401 Installation Manager at IBM Corp Headquarters at 590 Madison Avenue, NYC I circulated them all over North Jersey and the prevented a lot of Honeywell 200 sales.

UpdatingPunchedCards provided by Stan Paddock

PS: I got this story some 20 years ago from somebody who worked in the building where this happened.
A large insurance company in Boston was expanding their data processing section.

They brought in a girl from accounting to learn data processing.

Every insurance company had very large actuary tables. This girl's job was to make finite adjustments to this table. She was given the list, and shown how to find the punch card to change. She was asked if she knew how to change the card and she said yes.

A couple of months later, she stated she wanted to quit. She would give no reason for quiting and wanted to leave that day without the customary 2 weeks notice. Nobody could figure what happened to cause this immediate exit.

A few weeks later, they noticed the numbers were not coming out as expected.

When they evaluated the girl's changes, they found that she had pulled each card, erased the letters with an eraser, and neatly wrote in the new data.

When she realized what she had done wrong, she could not bare to face the embarrassment.

Ok, Another true story.

In a particular IBM 370 job shop, there was a job that always abended at the end of the job. While this did produce a memory dump, the job had completed correctly. With other irons in the fire, the programming group took their time fixing the problem.

The day after they fixed the problem, the user called up and said "Where is my numbers report?"

the Computer Wanted It

provided by Simon Wheaton-Smith via Judy Strebel
I offer for you my own story, humorous, and it linked the IBM 1401 and 306/30 in a "what hath Babbage wrought" context.

As background, my name is Simon Wheaton-Smith. I wrote the PATCHES spooling system for the 360 and SHADOW, later SHADOW II a teleprocessing system marketed by Altergo. I also wrote the ITT COurier Doomsday system of multi terminal diagnostics, and later the Computer Associates GDDM compatible graphics package....

Many years ago I worked at Thos Cook in Lonmdon. We had converted from the 1401 to a 32k 360/30. We used the 1401 emulator however when we converted from BOS to DOS (I wrote the BDOS converter also), the emulator was not an option. The available simulator from IBM that could run under DOS had no sterling feature so I wrote a 1401 simulator under DOS for the 360/30.

As time progressed and as we were converting from 1401 to 360 DOS and from BOS to DOS, we had a review of where we were and of our inefficiencies.

I asked Ron Bray, my boss, why computer supervisor Olive took a deck of cards every day, part of our foreign debits accounting system, and manually punched in stuff, and then manually wrote with a ball point pen syuff on the cards. This was about 100 cards a day. David Soal was the analyst, he said he had no idea.

My boss called Fred Taylor who was the operations manager and we met, he had no idea. He called Olive and asked her to bring the cards with her. I took one look and broke out laughing. The cards began in column 40 with a, "L", six digits, some "," and ended with "1040".

For many years, Olive had been doing something that "the computer wanted". It turns out that yeas earlier on the 1401 part of a self loading deck was left in a punch buffer, and the foreign debits program used gangpunching, and the self loading stuff wound up on the data cards, completely irrelevant and a mistake. But Beryl, the operator at the time, took them to Olive and said "the computer did it". Olive said "it must be important", so for many years, Olive decided to save the key punch girls the effort, and she manually reproduced faithfully that mistake. About 100 cards a day, 5 days a week, 52 weeks a year, and years.

Simon Wheaton-Smith MBCS, CITP

return to
main page