Go to Antique Computer home page

Stories
about People and Machines

Well OK, and a little software too ;-))

Proposed Purpose - Capture the life and times of the era.
- Other sites with Stories
Proposed format:

Listed usually most recently arrived at the top (near this point) until a better organization makes itself evident.

Click on high-lighted name to send e-mail to that person.

Table of Contents - latest near top -
Stories about the B5000 And People Who Were There by Richard Waychoff - link added Sept 2016
Odd CRT Terminal - from Michael Albaugh July 2016
Telephone 411 support, with IBM 360 Mod 50 - from Hal Murray July 2016
Stretch crew car thieves ?? - from Jack Worlton Nov 2015
a COBOL joke - from Keith Falkner - Feb 11, 2014
Monrobot - one of many "lost" in history - from Donald Caselli - July 6, 2013
Magnetic tape media problems - from Dana Roth - July 5, 2013
7094 II Move and CoreMemory problem - from John Van Gardner - Mar 17, 2013
IBM - Customer Choice of Colors - from John Van Gardner - Mar 02, 2013
Doing computers in the State of Washington - from Jordan Stedman, - Feb 17, 2013
Video Oral Histories of William Jolitz (FreeBSD) and Herb Kanner (research how computers might handle the number of significant digits after a computer performs mathmetical calculations.) - from Bill Selmeier - February 2, 2013
Coding for a new computer, with no other computer for cross-assembler - from LaFarr Stuart - January 9, 2013
Who invented the Internet ;-)) not really antique, but ... - link from George R Ahearn - July 23, 2012
Young, frisky, and learned to fix the IBM-650 from the manual
and the 22-6284-1 650 CE Manual_of_Instruction he learned from :-))
- from John Falk - July 4, 2012
Short Stories I Can Tell from Jay Jaeger - March 25, 2012
The Flash that Snapped the Tapes from Keith Falkner - Mar 24, 2012
Printer Tales - worn ribbons from Ed Thelen Oct 18, 2011
Extra Circuits from Hans Franke Oct 14, 2011
an IBM 1403 OOPS and printer tales - 2011
1401 and on - from Lee (& Carol) Veal Feb 19, 2011
Lest we forget - Analog Computers - and EAI - from George Shrier Jan 17, 2011
A view of ENIAC and UNIVAC "The Kathleen McNulty Mauchly Antonelli Story" a short autobiography by the wife of John Mauchly, a co-developer of ENIAC and UNIVAC from Jim Reed
Harry Huskey on "You Bet Your Life" from Dag Spicer
Macro Assemblers - on-line telemetry analysis from Ed Thelen July 2008
An IBM Career - design of 1401, work on floppy disk, ... from Francis O Underwood April 2008
Programmer "English" from Dick Weaver March 2008
Invisible Ink has its uses from Stan Paddock September 2007
How the IBM S/360 Green Card Came About from Milton Thrasher June 2006, June 2011
Memories of Early Computer Days link to James Humberd
IBM Stories from John Van Gardner from John Van Gardner
Please send Assembler Coding Sheet Milcia Cruz
IBM 101 - "and counting" from Alfred Hexter
Pioneer Business Programming Gerry Jean

Links to other collections - of tall tales ;-))


a COBOL joke - from Keith Falkner - Feb 11, 2014
COBOL joke

In 1996, we COBOL programmers were all looking over our shoulders and cringing under the pressure to update masses and heaps of programs that had been handling the calendar year with two digits. As 2000 approached inexorably, we were busily adapting these programs to use four digits instead, and devising algorithms that would reliably infer the first two digits by considering the current year and the given last two digits.

Let me tell you, it was dull stuff. But we did it.

There was a programmer who rebelled. He was so bloody tired of dealing with trite and sloppy code that he decided to take refuge … in the future! He figured that by 2004, all programs would routinely use four digits for the year, and any bugs left over from the conversion effort would be long since eradicated. He built a suspended-animation chamber, and programmed it to keep him alive, but unconscious for eight years.

Unfortunately, his programming skills did not match his engineering skills, and his program was, as we said, not Y-2-K compatible. The result was that he stayed in suspended animation, not for the intended 8 years, but for 8000 years. He emerged in the year 9996!

He found a civilization that was still running COBOL programs, but had nobody to maintain or upgrade them, until his reawakening. So he was welcomed most earnestly, and had no choice but to earn his living by converting all the COBOL programs in the world to handle the five-digit year that would soon be upon them.

None of the existing COBOL programs was Y-10-K compatible!

Monrobot - one of many "lost" in history - from Donald Caselli - July 6, 2013
Reference - MONROBOT-III, MONROBOT-V, MONROBOT-VI, MONROBOT-IX, MONROBOT-XI, MONROBOT-MU

I recently discovered your website was able to find some word references to Monrobot but nothing of any historical significance.

You may know that Monroe Calculator Co. of Orange, NJ was the designer and manufacturer of the Monrobot XI computer in 1959. I was introduced to the Monrobot XI in 1965 by way of Peter George Petropolis in NJ who had founded a software company known as Systems Design, Inc. His focus was on programming the Monrobot XI to process back office work for the stocks & bonds industry as well as other financial institutions. One major accomplishment was programming the Monrobot XI to calculate a basis price extending out beyond 40 years. I worked at Monroe in Orange for one year and then joined up with Peter Petropolis and others who were forming Computer Property Corp in Hanover, NJ. Computer Property Corp acquired the entire Monrobot XI line with spare parts, etc. There were 350 installations of the Monrobot XI at the time they took over.

...

I would travel to some of the installations over the few years that we operated. I improved the assembler so that source programs could be kept and processed with the 8 channel paper tape and produce object 8 channel paper tape output that would be executable programs. I also developed a dis-assembler that was able to accept an 8 channel object paper tape as input and produce an 8 channel source paper tape that could then be input to the assembler. This was done so that modifications could easily be made to programs that were being sent to Systems Design, Inc. from installations around the USA, and there was one in Toronto, Canada, and I spent a little time with that installation.

Two IBM Model B typewriters could be connected. Two IBM 026 keypunch machines could be connected. There was a magnetic card, the size of an 80 column Hollerith Card, that held 96 32-bit words, known as the Monro-Card.

I do not know of a physical Monrobot XI in existence. I have some original documents and manuals from Systems, Design, Inc. and some photos, which I posted on flickr.com These photos should be able to be found by using the search keyword monrobot

...

There is a computer museum at Camp Evans in Wall Township, NJ which is part of infoage found on the Internet as infoage.org The museum is M.A.R.C.H. known as mid-atlantic retro computer hobbyists. There are other museums at Camp Evans and can be visited at times shown on their website infoage.org In May, 2011 I gave a short presentation regarding the Monrobot XI and distributed a small booklet that I printed regarding a little history of the Monrobot XI. - Cover of a presentation The purpose was to explain that the Monrobot XI computer was able to be installed at a particular place or office and be used to process various data and produce printed reports, checks, etc. instead of sending the data to a data center which would take a few days whereas the Monrobot XI would produce results immediately in an office.

British Overseas Airways in New York City and the American Stock Exchange were good examples of successful Monrobot XI operations regarding payroll processing. Of course there were 90 stocks and bonds installations, 35 installations for fuel oil delivery companies and many others. So this was the type of history that I was interested in presenting.

...

Donald O. Caselli
900 Darmstadt Avenue
Egg Harbor City, NJ 08215
609-685-1528
dorestec@msn.com

Magnetic tape media problems - from Dana Roth - July 5, 2013
A little background from Ed Thelen:
When I was fixing computers for General Electric in the early 1960s, one of our plagues to smooth running computer sites were the crappy tape drives and the crappy magnetic tape media. See my tale here.

Introducing Dana:
In the mid 1960s, Dana worked for Control Data on CDC 6x00 equipment - see his comments here under "More "Cordwood Modules" - MTBF and other tricks ;-)) - from Dana Roth July 5, 2013"

The tape certifier had a microscope. New tapes had excess oxide (and other oddities) and needed to be cleaned before certifying. As the tape was being tested, a bad area (from many sources like contamination, bad mylar, etc.) would position below the microscope and could be usually repaired. There was a counter on the tape certifying machine which counted errors. Too many and the tape was sent back for replacement.

The issue, of course, was why so many bad tapes. The government site had about 800 tape mounts a day and 25,000 volumes on-site and were serious about data. I understand it to be a lot of remote sensing from satellites keeping track of minerals etc. The 66X tape drives were flying at 200 inches per second, so I became an expert on tape subsystems pretty quickly. I suspect that manufacturing companies sampled tapes to reduce overhead costs. The GOC had a good tape librarian to ensure quality (and beat up on the vendors)!

One day CDC flew me down to Dallas TX (on the hottest day in May), Mobile Oil site to work on tapes. They had a quarter million tapes on-site, which looked like a gymnasium filled from floor to ceiling, all seismic data, from all over the world. The tapes were in rough shape (peanut butter on them and the like) and a single process job would run for three days, processing seismic data. A tape would break into the second day and they would have to restart the job. They had three CDC 6000’s in one room, with some special “stunt boxes” that allow for some serious number crunching. We helped develop an algorithm to uniquely address each block on tape (similar to disk) and take checkpoints in case a tape or drive would break. They could then repair a tape and move it to another drive, seek to the broken spot and continue in mid-job, saving days of processing. Tapes had to work, even if bad. In hindsight, maybe that’s why oil is so expensive (a 72 hour job @ $30,000/hr.)!

Tape abrasion was a problem and CDC went to glass heads that were pre-grooved so as not to distort the tape passing over the head.

On the GE front, one day a computer operator miscued a tape (the system was actually self loading but operators threw the tape on the drive) on a 667 tape drive. He opened the door to check how the tape loading was stuck. A General Electric AC motor capacitor exploded and coated him with PCB oil. In those days, the oil wasn’t well known to be a carcinogen, as it is today. CDC bought him a set of new clothes. I got to change out all the remaining capacitors and had them properly disposed of. What a mess!

—- dana

7094 II Move and CoreMemory problem - from John Van Gardner - Mar 17, 2013
When Lockheed won the contract to build the C-5 in October 1965, they knew they were going to need more computing power. At the time Math Analysis had a 7094 they owned and one they were leasing from Greyhound Leasing. The California division had a directly coupled 7094 II that they were replacing with something else. On September 25, 1966 they decided to bring it to the Georgia Division.

At this time there was no computer room to put it in and we did not have anyone trained on the Mod. II. Lockheed began building a computer room in an old cafeteria down in tunnel 2 of the plant. I ordered a set of manuals for the Mod. II and spent a whole Labor Day weekend reading them.

On Monday we found out there were no 7607 data channels coming with the machine as it had been directly coupled to a 7044. IBM found 2 channels in a warehouse in St. Louis, MO, but they did not have the feature that allowed attachment to a Mod. II. I called Poughkeepsie and had someone read me the wiring list and SMS card list for the change. I recorded the phone conversation on an IBM Executary dictation machine our salesman, Bill Bull, had given me when it broke (just a bad relay). Poughkeepsie shipped me the SMS cards by air.

Lockheed put the 7094 II and all the tape drives on their L-100 (Civilian version of the C-130) and flew them to us. By the time the machine arrived Lockheed had built a small section of the raised floor with a temporary ramp in the middle of the old cafeteria in tunnel 2. We positioned the frames and began wiring the channels. It was freezing cold as none of the equipment was powered up so I worked with my coat on. The painters were painting the ceiling with a roller and when I got home I had paint all up my backside. It ruined a good suit.

After we got all the construction out of the way everything went as a normal installation. I was able to trouble shoot all the bugs we had and from the day Lockheed decided to bring the machine from California to the day we turned it over to them it was 18 days.

I had one interesting bug on this machine about 3 months before it left. They had a program that was a matrix inversion problem. It gave different answers every time they ran it. I found out that if you turned off the overlap switch it would run correctly but slower. Lockheed had a young blond mathematician named Stuart Austin who worked with me on the problem and she found out that one of the instructions in an index loop, that added up a column of numbers, was picking up a bit in the decrement field of the instruction.

The 7094 II used an air-cooled split array memory with a cycle time of 1.4 microseconds. I scoped the memory and found that the location of the instruction was being half selected many consecutive cycles during the loop. I talked to Poughkeepsie and they said, that was sometimes caused by a core that had a chip out of it, and it would flip with half current. They said the only way to fix it was to replace the core plane in the array and it would cost $35,000.00 for them to send someone to do it. We knew the machine was due to go out in 3 months and that the program would run if you turned off interleave so I decided to try and fix it. I took a current probe and looked at the current pulse on the half selected driveline and decided to add a resistor in series with the terminator for that line. If I remember correctly I think the terminator was a 250 ohm Non-inductive resistor so I added a 25 ohm in series and looked at the scope. I could not tell the difference in the current pulse. I tried the program and it failed. I had already replaced the 250 ohm resistor just in case so I took the original 250 ohm and added it in series and the current pulse dropped about 10%. The program worked fine. I ran all the diagnostics and bias test and it worked. Well, so much for ohms law. I had forgotten I was trying to send a square wave pulse down a long wire with lots of inductive kickback. The machine ran fine until it left and a 250 ohm resistor saved $35.000.00. Stuart Austin went on to program the CDC computer at the wind tunnel where she met and married Johnny Johnson. They both later went to work for IBM as System Engineers..

IBM - Customer Choice of Colors - from John Van Gardner - Mar 02, 2013
Here is some tourist information about the colors. It all started when IBM offered the customer a choice of color on typewriters. There was set of standard colors some of which I remember: Classic Blue, Flame Red, Garnet Rose, Light Gray, Pearl White , Raven Black, Sky Blue, Sunrise Yellow, Willow Green. In 1971 orders for new typewiters was down and IBM started taking trade-in IBM machines on new orders. These machines were sent to the plant and completely dissassembled and cleaned. All worn parts were replaced and these machines run down the assembly line and adjusted to meet new machine specs. All of these machines were painted Charcoal Brown and sold to employees only at a large discount. I bought an Executive with a wide carriage and carbon ribbon for $220.00 plus $6.60 GA sales tax. IBM deducted $9.44 from each pay check untill it was paid for with no interest charged. A new Executive like mine would have cost $525.00. I still have it somewhere in my attic.

In 1955/56 when I was in 704 school in Poughkeepsie they had a computer room on the back of the plant with a 702 that they actually did the plant's payroll and other data processing. It was a nice looking room that they showed potential customers on tour. The whole front was plate glass windows they could look through. There was a desk for a receptionist with a yellow typewriter and yellow telephone. The receptionist had long blond hair like Betty Grable and always wore a yellow sweater. Every day at lunch I would go by there to see if she ever wore anything but a yellow sweater. I never saw her in anything but yellow if she was there. I wondered if that had been written into her job description.

When Lockheed at Marietta, GA got their 705 Model 3 they paid $3,000.00 for an RPQ to get their's painted Garnet Rose. That was the first colored system I ever saw. Later on Martin Aircraft in Orlando, FL got a 704 system with each box a different color. When the 7000 series machines came along I was working on a 7094 in a test cell at the Poughkeepsie plant and the next cell had a 7074 that was going to the U.S. Justice Dept. and it's main frame was blue and it had 7340 Hypertape Drives with red and white vertical panels. You could not look over to that test cell without thinking about the American flag.

When Customers began to get multiple systems they would get different colors and refer to them as Old Red or Old Blue.

Van Gardner


from Stan Paddock, March 4, 2013


Back in the late 1960's, I worked for an IBM refurbishment center.
 
I thought it was a bit strange when a 
    complete 1401 system came in covered with wood grained contact paper.
 
A savings and loan company in Los Angeles 
    wanted to spruce up the system as it was visible from the lobby.
 
IBM gave them the ok to adorned the system 
    if they paid to have the contact paper taken off the machine.
 
I pulled my share of the paper off 
    before the machine was sent to be destroyed.

Doing computers in the State of Washington - from Jordan Stedman - Feb 17, 2013
I'm a bit of a dark horse here: I got my start in computing by pinning plug-boards for a still-functional Burroughs E-101 in the fall of 1966 – then writing ML (no SOAP) for an imaginary IBM-650 – all at Lincoln H.S. in Seattle. Then I had a brief chance to write some assembler code for an IBM-1620 at WWSU where my uncle taught. Finding a keypunch brought me into contact with Herb Burke, who then owned the IBM-709 from Lockheed Sunnyvale via the Univ. of Wash., operating it as a small service bureau in Seattle – "Puget Sound Computer Service" – where I worked from age 17 to 25. That machine and its sister from WSU – plus a 7094 that I personally reinstalled back in the '70's – are now part of Paul Pierce's collection. (That's "my" 709 in the top photo on his home page.)

We did a few interesting things at PSCS: extended the OpSys and Fortran IV compiler, plotted/drafted maps of defoliant ("rainbow agent") spray missions over Vietnam under contract to the National Academy of Sciences – and resold some used "DecTapes" acquired in a bankruptcy sale (and useless to our purposes) to a couple of young high school students for "a project": the late Kent Larson and a fellow named Bill Gates.

From there I went on to an IBM-360 shop (Prodata Systems, Inc) where I wheedled my way into system admin and datacenter manager, piloting upgrades through a National Semi ECL chip-level knockoff of a 3158-3, an IBM-4341/12, 4381/12 and 9221-191, dozens of OpSys upgrades, and build-out of 500-device network using CICS and 3270 terminal technology in both BiSync and SNA/SDLC. We were one of the first implementers of IBM-3380E DASD in Seattle (Wow! 5GB in a large 'refrigerator"!) and an early adopter of 3480s. It was all ultimately ported to a Flex ES emulator running on a Dell server with 120 GB of RAID under UnixWare.

I have some interesting stories from my interactions with IBM FEs from that time. – one in particular (Glenn "Jake" Jacobson) actually gave me a "key" to the boxes [key-ring Allen wrench] in testimony of his trust that I knew how to open them up and put my fingers in without breaking anything. He also taught me how to secure and move a string of 3380 DASD and then unlock and restart them without assistance: I paid him back by getting him some interesting employee file commendations and a Christmas bonus. [Interesting story here: one year the company offered this FE a Christmas fruit basket, and he refused it based on strict IBM policy that forbade gratuities. Cup of coffee was okay – but not a fruit basket. So I dug out the name of his manager and I think his manager’s manager, and sent a letter expressing that in lieu of the refused fruit basket we were sending a check in Jake’s name to the local food bank org, Northwest Harvest. About a week or two later, Glenn caught me and said “wow – that letter was WAY better than any chintzy little fruit basket!” I never did learn precisely what he got out of it, but I gather is was manifestly spendable!]

I also did some interesting development projects, creating an application infrastructure under DOS/VSE-->VSE/ESA that would now be recognizable as a rudimentary O-O "com-layer" [~20k lines of COBOL and several thousand in HL-Assembler.] Then I took ownership of first a NetWare infrastructure and then Windows NT at 3.5.1-->4.0-->2000-->2003. I was the primary contact and one of the certified employees for Prodata's MCSP agreement with Microsoft for several years.

Prodata (f. 1958) was sold in 1997 and subsequently downsized pretty literally into a garage – and I was forced to look for other work in 2010 so I have been taking vendor contracts at Microsoft since. Currently I am working under contract as a member of the MSIT Identity and Access Management – Domain Controllers team – an admin in all AD domains in MS Corp and providing specific support to Microsoft Retail Store. Well, I can't really say much more about that – except hundreds of domain controllers scattered around the world, running on G8 servers each with 2x8 hyper-threaded cores (32 LProcs) 128 GB of DRAM and about net 1.2 TB of RAID-1+0+S storage.

This industry has changed a lot in 45 years, but I am still kicking! (and still broke... sigh)

Jordan Stedman, Shoreline, WA
jlstedman@frontier.com (pref) or jlstedman@live.com
http://www.linkedin.com/profile/view?id=16464785
206-227-9988 (mobile)

Coding for a new computer, with no other computer for cross-assembler - from LaFarr Stuart - January 9, 2013
Cyclone, an IAS machine
by LaFarr Stuart

When I got to Iowa State (a graduate student in statistics), the Cyclone had been running for a year. It was a duplicate of the ILLIAC, using 5-level paper tape, and its' memory was Williams Tubes (41 of them for 1024 40-bit words of memory and one as a monitor that could be dialed to display any bit position of the 1024 words). There was no parity or error checking in the hardware.

During the summer, (before I arrived) they replaced the memory with 4 banks of 4096 words of core memory; and 8-bit paper tape I/O. This caused a major change in the address decoding in the hardware, (2 instructions per 40 bit word, each instruction was 8-bit op code and 12-bit address.) The older memory only used 10-bit address, and much of the software used the 2 high order bits, which were ignored by the hardware, as flags or whatever.

After the changes the "New Cyclone" had zero software, and the instructions were being being upgraded when I arrived. But three new Flexowriters were working, and the 8-bit paper tape reader and punch were being connected.

Getting a computer going, without another computer to make a cross-assembler, run a simulator, and develop software on, was an interesting experience few have had; and nobody will have in the future.

Our input/output was Friden Flexowriters that had no electrical link to the Cyclone whose only input/output was paper tape. We did not use Octal on the Cyclone. We used a form of hexadecimal, that did not use letters of the alphabet for digits greater than 9. It used characters like: , . ; for them. Our Flexowriters were slightly customized to have on one key we called "subten" it was a little "10" lower than most letters; and its hex value was 15. The intended output use of that key was to print large decimal values using a power of ten notation.

Young, frisky, and learned to fix the IBM-650 from the manual - from John Falk - July 4, 2012
     I, Ed Thelen, paint the environment of the mid 1950s through early 1960s computer era - and maybe sales/service life in general -
Sometimes
  • Some Application Engineer was handed a box of manuals and an airplane ticket, say on Friday afternoon.
    He is told to fly to Chicago to teach a class on XXYYZZ the following Monday morning.
    Victim - "But I know nothing about XXYYZZ !?!"
    Boss - "Are you going to waste this weekend ??"

  • A new peripheral is sent to a customer site, with schematics and a VERY preliminary manual.
    The local FE is told to install and maintain it best he can.
    I had that happen several times with G.E. - long nights -

    OK - I was well trained on every system that I was sent out to repair -
    Nike Fire Control system, General Electric 225 computer system.
    But not everyone was so lucky -

    But train yourself to understand and maintain a whole vacuum tube based computer system ???


    from John Falk - July 4, 2012

    My first assignment as a new IBM Customer Engineer was MGM Studios which ran 24/7.
    I used this manual [see below] to teach myself how the 650 worked.
    IBM form 22-6284-1 - IBM 650 Data Processing System - Customer Engineering Manual of Instruction - 5.2 MB .pdf file .
    A plus about having MGM for an account was eating in the Commissary with the stars and going out in the back lot to watch filming of Ben Hur

    Yep. and they gave me a parking place in the Exec lot where I could park my plymouth next to Rolls and other cars I didn't recognize.

    One day I stepped out of the building where Data Processing was and into the little street and Debbie Reynolds almost ran over me in her station wagon. Was all apologetic and dressed in her grundgie clothes.

    The guards name at the gate was Ken Hollywood and I learned years later that he was brother of girl I went to high school with in Venice.

    I was 21 and lived 2 miles from MGM and took all night and weekend calls at home directly from MGM.

    Upgraded the 650 to 4K drum and replaced the 533 with rare 543 reader and 544 punch units. Those were the predecessors of the 1402 read and punch feeds.

    When I went to 1301 school in San Jose I ended up teaching the 1402 Punch feed part because of the many hours I spent with the 544.

Short Stories I Can Tell - from Jay Jaeger - March 25, 2012
     For example, the weekend after I was hired at the University of Wisconsin School of Business as an operator on their IBM 1410 (which they had acquired after the UW Registrar upgraded to a 360), I went in to practice a little. Machine just would not cooperate. Red lights and error printouts on the 1415 Selectric console like crazy. I assumed I was doing something terribly wrong, but I left a note, and headed off to my girlfriend's apartment. I got a call that afternoon -- in fact the machine was really broken, and the errors were all real.


     That same 1410 had an annoying trait: when it first powered on, the 1403 printer would show a sync check for nigh unto 10 minutes until it "warmed up". Well "formed up" would be more to the point. One day our CE and the crack CE that knew the 1410 inside and out decided to try and figure out what the heck was wrong. They were at it with their scope on the 1414 I/O Synchronizer that the printer was attached to for hours. Finally they kind of shook their heads and laughed a bit. The 1414 had a bunch of electrolytics with leads that fit over wire wrap pins -- probably several per row of cards (presumably bypass capacitors as a guess). It turned out they had all been installed BACKWARDS -- either on "day one" or as part of some CE change earlier in its lifetime. Oops.


     That same 1410 had a special interface built for it so that we could communicate with the UNIVAC 1108 main academic computer on campus. The special interface was hooked into the 1410 as though it were a telegraph. 8^) It used balanced line drivers to get the half-mile to the main computer science building. Bruce Orchard (who passed away a year or so ago) wrote a program to make the 1410 look to the UNIVAC 1108 as though it were a UNIVAC 1004 RJE station. We had far and away the best 1108 printouts in town (the normal UNIVAC printers were drum printers -- wavy lines like you wouldn't believe).


     Another related story. Our 1410 CE also did 360/370 work. One day another programmer from our 1410 shop that I was working with to do a student records system on a 370 at the Wisconsin Alumni Research Foundation (WARF) entered the WARF building where we did our work on second shift. The scene was of the CE working hard under a 3330 drive (one of the ones that you thru a switch and the drive slid out like a shelf). Turned out one of the day shift 370 operators (or maybe a programmer -- who knows) and put a TAPE LABEL on a 3330 disk pack, and spun it up. Well, of course that label soon separated itself from the pack -- and took out most of the heads.


     (The other 1410 story I already told. The UW Computer Sciences department received a donated IBM 1410 from Oscar Mayer here in Madison. I set the thing up using the CE instructions, and it pretty much ran right off the bat. One of the CEs got the Selectric console working, pro bono. The machine was later stored, and over the winter the temperature in the building dropped due to some HVAC / construction work. I set up the 1410 again in another room the next summer. The machine worked, but some of the wires in the core had apparently snapped, and some storage locations no longer functioned properly.)

The Flash that Snapped the Tapes - from Keith Falkner Mar 24, 2012
Not every photograph of a running computer system is a success. In the mid-1950s, Confederation Life had a fine 704 system on Bloor Street in Toronto Ontario Canada. A professional photographer, using a press camera with an immense flash bulb, took a picture of that system at the end of a long sort run, while four tape drives were doing a high-speed rewind.

The strong flash of light confused the tape drives: they interpreted the light pulse as evidence that the beginning-of-tape marker had passed, and immediately put on the brakes that are meant to stop a low-speed rewind quickly. The four tapes snapped, and the photographer was politely ushered out of the room while the operators commenced recovering from the accident.

Printer Tales
worn ribbons - from
Ed Thelen Oct 18, 2011
Trying to assure that the correct marks
   actually get printed on the paper is always a serious problem.

One day ( in 1962 ) I got an irate call -
   The dollar amounts on a long billing run were mostly invisible  !!!
   The printer ribbon on the G.E. printer had gotten worn on one side.
      (Typically the left side)
   The worn ribbon had pulled/drifted to the left,
        leaving the right hand side print hammers with no ribbon.
   The billed dollar amounts were on the far right of the forms, invisible.

   There wasn't a thing I could do other than recommend:
         - more frequent ribbon changes, - expensive to the customer -
         - manually rewinding the ribbon "left to right" to balance wear -
                  ( a messy tedious process
                     I demoed how to do it - once !! )
         - more operator care and observation

( The IBM 1403 printer downstairs had the
    printer ribbon automatic lateral reposition system
   and likely would have printed completely across the forms.
   - another black eye for G.E. ) 

Extra Circuits - from Hans Franke Oct 14, 2011
Reminds me of a printer we got around 1979. The incident Van [ next letter below ] notes might not have been so rare at all. Otherwise the HFÜ or Hammerflugüberwachung (literally Hammer Flight Control) wouldn't have been invented in the mid 60s.

Back then (at least for Siemens) banks where the largest customers for /360ish machines (even before government). Of course they had a need to make sure that every number send out would also end up on paper. So every hammer had not only a coil pushing it, but also a secondary coil where the moving rod created a little blip as feedback. A rather delicate circuit (*1) now compared the timing, signal strength and form to what was expected for a working hammer hitting a typeface thru paper and ribbon. It was a little masterpiece of analog technology.

Anyway, long story short, we got the printer in 1979, after years of service at the Munich Tax Office, for free. It's been a great improvement from the 1960s drum printer we used before. We even accepted the 2-5 false alarms per month we got, no matter how careful the printer was adjusted.

Hans

*1 - you got to keep in mind that 95% of all circuitry in such a printer was analog and you got literally hundreds of pots to fiddle with timing parameters - in fact, it was impossible to adjust it right, since most values influenced each other - I once spend almost a day to adjust one ... Well, OK, to be honest, I wasn't inclined to do any other work waiting for me, but that's a different story


Hans' comment about Ed's ribbon story (above) - "Oh, and an addition, the Printer also had a sensor to determine if the ribbon is still centered (otherwise printer got stopped) and a sensor to make sure it's wet (resistance thru the ribbon)"

an IBM 1403 OOPS - from Van Gardner Oct 13, 2011
( the 1403 was probably the world's best "line" printer, BUT ;-))
In the late 1960s when Lockheed was building the C-5 there were over 30,000 people working there.
The second most important computer program that had to be run each week was the one that printed the pay checks.
The most important job was the report sent to the Air Force to justify each man hour spent on each project . The Air Force had to accept this report before they would deposit the money in the bank to make Lockheed's checks good.

It was a very detailed report that listed each empolyee and the hours spent at each cost center by shift worked. The report was printed on full width paper with Shift number printed in the last 7 print postitions at the top of each page. One night after the job had been run and printed one of the operators came screaming into the CE room shouting, "Come look what that 1403 had done to our report". When I looked at it I saw that the F had been left out of each shift number.

The hammer bar that fires against the back of the paper to print the letter in front of the paper was broken. This hammer bar was supported by two vertical flat leaf springs and the front one was broken . The 1401 checked that the hammer fire pulse was sent but had no way of knowing the hammer did not move.

It was an easy fix to replace the hammer but the whole job had to be reprinted.. Ever since then when I see one of those bumper stickers that says "IT HAPPENS" I think, "It really does".

Van Gardner

an IBM 1403 OOPS - from Keith Falkner Sept 25, 2011
Some day I want to ride my motorcycle from Florida to [Computer History Museum, Mountain View] California to see those wonderful 1401 computers in operation. I have greatly enjoyed the simulators I have downloaded and programmed since joining this forum.

Here's a simple anecdote that concerns a 1403, which was being driven by a System/360, not a 1401. A man whom I considered clever and insightful was idly looking at a thick report, which consisted of many columns of large numbers. He seemed a bit puzzled, and I asked what concerned him about the printout. He said, "There don't seem to be a lot of sixes in this report."

Well, the pages of the report were numbered, so I turned to pages 16, 26, 36, etc. Sure enough, a substantial number of those sixes were incorrect, all the same digit (but I forget what that digit was). As I knew which 1403 had recently been serviced, I went to that machine and stopped it, then tried to corral all the printouts that it had produced since the Customer Engineers had turned it back to us for use. Then I requested the assistance of a Customer Engineer, who studied the print train and reported that it had been incorrectly assembled.

I think that we (which means IBM's Toronto Downtown Datacentre) were particularly lucky to catch that error before any erroneous reports reached our customers. My colleagues and I tipped our hats to our perspicacious colleague for a long time thereafter.

Techie tip - The printer was a chain printer, with the individual characters as individual slugs of metal. An option for speeding printing highly numeric data was to place multiple series of numbers along with a single alphabet on one chain. This almost doubled the speed of the printer when successive lines were all numeric.

The NUMBERS Report - from Stan Paddock - Sept 25, 2011
A real case from way back when.

In a large shop there was a COBOL program that did not terminate correctly. The customer did not complain that there was a memory dump at the end of his report. While the printouts were ok and also the files, the programmers left the program to be fixed at a later date.

When they did fix the program, the customer called and wanted to know "Where is my NUMBERS report?"

Reduce the printer load - from Ed thelen - Sept 25, 2011
Long ago - in Silicon Valley - when Fairchild Semiconductor was a big player

The mother of my children began programming at Fairchild. Her introduction was to ask internal users if they needed all the copies of the reports they were getting.

The universal answer was "YES" even though she could see stacks of computer printed reports gathering dust in corners of offices - seemingly never opened.

After rounds of attempts to reduce the huge printer work load for internal reports, management decided to charge the receiving departments by the page for reports delived to them.
The printer work load for internal reports was quickly cut in half. ;-))

She was asked to modify some report, and she made and verified the mods. The Programming Standards Committee found that the text of her COBOL comments field in the program started in a non-standard column. She had to wait another two weeks for the program to be re-examined by the Committee. - You might imagine that internal users complained a lot about slow responses to requests for report changes.


1401 and on - from Lee (& Carol) Veal Feb 19, 2011
re: 1401 Restoration

Fascinating stuff.

I learned to program using Disk Autocoder on a 12K 1401 with 2 1311 disk drives, a 1403 (600lpm) and 1402 card reader/punch. I had enrolled at Tyler Jr. College in the fall of '66; in the first semester, our class worked through wiring tab equipment boards (548 Interpreter, 512 Reproducing Card Punch, 085 Collator, 402 Accounting Machine, we had an 082 Card Sorter but no board wiring was required for it) , but then in the 2nd semester we started programming the 1401.

Unfortunately, I never programmed a 1401 in a commercial environment. Because of my detailed levels of study of the 1401, I was fairly easily able to teach myself the S/360's Assemble Language. In 1968, I was drafted into the Army. I started out operating a UNIVAC 1005 4K Card-based (non-disk, non-tape) which had an assembly language called SAAL (Single Address Assembly). There was no facility in the computer for a memory to memory move. Everything was loaded to a register, then operated on memory to register then stored back in memory. The longest data move was 132 characters to the print buffer. Unlike the good ol' MLC and MRCM instructions in the 1401 which were limited only by the placement of word marks or record marks and the amount of memory installed. Every instruction in the 1005 was exactly the same length, unlike the 1401's various instruction lengths which helped to conserve the core memory.

In the 1980s my wife was working for a trucking company in Mesquite, Tx, which was using an NCR Criterion system, the next generation after NCR's Century 100 system. Because of my experience with 1401 architecture and Autocoder, I was able to help her debug a few Neat/3 programs that no one on the trucking company for which she worked had been able to figure out. She was a newbie on the programming staff, so they dumped the program on her. Every time they ran the errant program, it would go into an idiot loop and never come out of it. By studying the program listing she'd brought home, I was able with help from her to get a grasp of the instruction set of the Criterion. She was clueless about the use of index registers, since she'd never programmed a 1401 or any other system that used them the way the 1401 and Criterion did. So, we had what's now called a teaching moment so that she'd know why the changes would work and why the original code was going into an 'idiot loop'.

The Centurion it turned out had several 5-character index registers similar to the three 3-character index registers in the 1401 (as I recall, I think the 1401's were in the memory locations from 81 thru 100 above the end of the card read area (1-80) and below the card punch area (101-180). Anyway, one of the NCR index register was being initialized to point to a table, but it was never being incremented in the table look-up routine to point to the next entry in the table. Ergo, the 'idiot loop'. The first time a 'look-up' was needed, the program would go into an endless loop. The table was hard coded into the program with an argument and several other elements that could be used in various parts of the program.

My wife took the corrected Neat/3 program back to work, made the changes that I'd helped her with. My wife fixed a program that much more experienced programmers had failed to debug and fix. Several other 'unfixable' programs were brought to (dumped on) her. She fixed 'em all. She was a smart cookie and a quick study. I don't remember if she ever told them what she did to fix them, but the other programmers should have been able to see the corrections. For that matter, they should have been able to see what was wrong with the coding in the first place. I mean a student of the 1401 figured it out, and I'd never actually seen a Neat/3 program before my wife brought one home for me to look at.

I thanked my early 1401 education.

Good job...

Lee Veal


I remember the 1311 disk drives and how they amazed me. I was blown away by the disk packs having a whopping capacity of 2M characters, 6 platters, 10 surfaces, 20 100-byte fixed-length sectors on each of 10 tracks in a cylinder and 100 cylinders on the removable pack. The ones we used at Tyler Junior College did not have the 'direct seek' feature installed on them, so if a seek from cylinder 10 to cylinder 11 was commanded, then the 1311 had to reset to cylinder 0 and then count out to cylinder 11. Runs of Disk Autocoder for assembling our class assignments really worked the 0 drive. I ran across a manual of RPQ features for the 1401, 1311 and other gear. The programming, as I recall, for the direct seek feature, was not supported in the stock IOCS within Disk Autocoder and there were special disk commands that the programmer had to hard-code in the program in order to take advantage the direct seek feature.

I also loved the macro facility of Disk Autocoder, I even wrote a couple of rudimentary macros. They were far beyond the class-assigned programs, but the prof for the class knew that I was completing my assignments way ahead of my classmates, so, I think he was the one who gave me the 'macro-language' manuals. The only macro-language command I can remember now is 'BOOL', I hope you can cut me some slack, that was back in the late 1960s.


Lest we forget - Analog Computers - and EAI - from George Shrier Jan 17, 2011
I saw your antique computer web site, so I thought I'd pass on a bit of frustration, even though it's doubtful you can do anything about it. Maybe you have more contacts than I do, but it's probably already too late.

If you look at computer books from the 50s, you'll see introductory fluff about how there are two kinds, analog and digital, but THIS book will discuss digital, etc. In fact, analog computers retained a hardcore following for quite some time, especially among oldtimers who were familiar with the tricks of that particular trade.

"General purpose" analog computers focused on the solution of simultaneous ordinary differential equations, i.e. problems in which a finite number of mutually interacting variables had to be tracked through time. "Programming" a machine meant repatching a plugboard. Programs were saved by physically removing the plugboard and putting it on a shelf.

The big player in this business was EAI, Electronic Associates. After a long delay, EAI realized in the early 80s that the business would keep shrinking if they didn't reinvest in it. They then constructed "SIMSTAR", the last and greatest of all analog computers and the first and only one programmed in software. A compiler would process the user's CSSL program (these languages for specifying differential equations are still in use - for digital computers) and "autopatch" the computer, without any physical movement of wires being necessary.

SIMSTAR sold for several million dollars(!), was the size of two very large refrigerators, and was bought by about fifty customers over the years. I arrived in late 1991 or early 1992, at which time two machines were on premises: The first was an early prototype that was not quite compatible with later machines. The second was the final machine ever built, which was purchased by the U.S. Army in 1990, but which they hadn't yet taken delivery of.

In appearance, the circuit boards were quite dissimilar from those of digital computers. By the time I came, one of the oldtimers told me that the internal expertise was already gone, and that the company would probably have been unable to build another one if an order came in. He himself was keeping very busy scrounging spare parts for old products that were still in use on every continent.

Every obscure corner of digital computer history has been thoroughly fussed over, so it astonished me how little knowledge or interest there was in SIMSTAR. Maybe ten years ago, I wtote Emails to so-called "curators" of computer museums warning of the danger that all these machines would be scrapped; they merely volunteeered to take a SIMSTAR off my hands if I sent them one!!!

All I ever had was contact info. I knew someone familiar with the entire customer list, because he was the salesman and oversaw maintenance of all machines in the field.

Footnote: I came to EAI as a contractor writing a(n optimizing) compiler for the "Digitally Implemented Analog Computer", later called "Starlight". This was meant to be the successor to SIMSTAR. It was a 20MHZ machine that was abandoned right after it had been successfully completed. It also ran a CSSL. Do you remember that ENIAC had 20 registers, but no memory, except for read-only constants that could be set on switches? What kind of problems need a KFLOP of horsepower but no memory? The answer of course, is systems of ordinary differential equations, e.g. trajectory computations.

Likewise, Starlight had no RAM, but rather 2048 registers plus ROMs for storing the program and lookup tables of function values for doing interpolations. Physically, of course, this was all RAM, but it was not writable at execution time. User programs were branch-free, basically giant basic blocks of arithmetic for updating each time step. Ah, what enjoyable stuff!

Alas, Starlight is extinct too. Five copies were sold to a Japanese distributor, but then EAI decided to become a service company doing contract circuit board manufacturing. It abandoned computers altogether.

If you find someone interested in SIMSTAR, I can try to help you find G.V. Aryama, who was the salesman I referred to.


Ed Thelen commenting - Ah - you have reached a sympathetic ear ;-))

The first computer I got my hands on was a military analog computer which provided computing services for the Nike AntiAircraft Missile System. (about 1954).

Twelve years later, working for Control Data Corporation (CDC) - Special Systems Division - among other interesting work, we interfaced with EAI and other analog computers making "hybrid" systems. But the hand writing was on the wall - digital computers were getting fast enough and less expensive. And you could change problems in seconds rather than hours, and had outstanding accuracy and stability and ... CDC also offered a program called "MIMIC" which permitted an analog oriented person to write in that mind set and do "analog computing" on the CDC 6xxx series. For instance, you didn't worry about finding a Runge-Kutta integration routine - you merely gave the integration inputs and initial conditions - ... and magic happened - at good speed too ;-))

"Signs of the times" - the Nike systems (above) were retrofitted in the mid 1970s to all digital - using a militarized DEC PDP-11 - which, including peripherals, took up 1/2 of one of the 4 cabinets of the analog computer. The other three cabinets were used for hanging coats ...


A view of the ENIAC and UNIVAC story

via Jim Reed, a grandson of Kathleen McNulty Mauchly Antonelli, June 2009
"The Kathleen McNulty Mauchly Antonelli Story" including a view of ENIAC and UNIVAC. A short autobiography by the wife of John Mauchly, a co-developer of ENIAC and UNIVAC


LaFarr Stuart and I (Ed Thelen) went to this conference and met "Kay" - a very interesting and fun person.
    a bio on wikipedia

I asked Kay how she felt about John Atanasoff.
(The court found that John Mauchly had gotten ideas from John Atanasoff but had not mentioned that in the patent. This was one of the reasons for invalidating the Eckert-Mauchly patent.)
Kay stated that " no one mentioned that name in her house."


Harry Huskey on "You Bet Your Life"

from Dag Spicer - old e-mail -
This is absolutely brilliant: Harry Huskey on "You Bet Your Life" (host: Groucho Marx!), ca. 1950.

Huskey starts at about 15:00 in...

Wow! http://gizmo.org/crypt/chm/youbetyourlife500510no4932door_otrcat.com_.mp3

dag --


Macro Assemblers - on-line telemetry analysis

from Ed Thelen July 2008
There was quite a discussion as to whether an assembler with macro capability was a "compilier" in the IBM 1401 world. Some folks figuring an assembler was a "one line, one machine instruction" language.

From a slightly broader perspective -

The term "Macro Assembler" was widely used, so widely that folks usually assumed that any assembler released by at least any of the "Seven Dwarfs", ie General Electric, Control Data, RCA, and others included "macro capability". And the assemblers released for the IBM 360s definitely had "macro capability".

It was a little like "monitor" for your computer now - you now (since about say 1990) ASSUME it has color capability. ;-))

The only assembler, released by a manufacturer that I ever worked with that I am not SURE had macro capability was the assembler for the LGP-30 in 1958.

Ed Thelen

P.S. a little tale -

About 1968 I was working on a project to use 5 CDC 1700's doing on-line telemetry data conversion to engineering units feeding a CDC 6500 which munched the data and presented it in graphical form (on black/white monitors) to Grumman engineers conducting and monitoring the prototype test flights.

(This way, different flight tests could be requested or delayed during flight depending on what the engineers saw. More testing could be done more safely per day. Like crash your prototype, and you have a huge costly delay. And killing your test pilot isn't so cool either.) (We heard this system was for the E-14, later the F-14 "Tom Cat".)

A friend who was interfacing with the 1700s decided to write a cross assembler for the 1700s that ran on a 6xxx computer. It was, of course, written in FORTRAN and of course had "macro capability" because the existing 1700 assembler had "macro capability".

The 1700 group, a contentious competitive group, said the macro capability didn't work. "Show me" - well, they had taken an entire 1700 tape diagnostic program, framed it as a macro, and the 6xxx based 1700 cross assembler has run out of macro memory - (FORTRAN at the time did not have a UNIX malloc command ;-)) and my friend had assumed "reasonable" macro size and usage.

The 1700 group kept POO-POOing the offered cross assembler so my friend trash canned it.

Of course, no good deed goes unpunished ;-))

Later, on site for installation, with 1700s that didn't have disks or tapes, the 1700 group asked for the cross assembler - but my friend had left the company. The rest of us were willing to let the obnoxious 1700 group stew in their own juices :-))


An IBM Career - design of 1401, work on floppy disk, ...

from Francis O Underwood April 2008

In response to questions by Robert Garner.

Here are some facts that you don't know:

  • Born 6/16/1926 - Now going on 82 years!
  • Cornell University, - Major in Mech eng., minor in Aero eng.
  • Joined IBM in 1948, Retired in Jan. of 1980. (32years).
  • Was C.E for a couple years in Washington, D.C
  • Engineering saved me from that by transferring me to Endicott about 1951.
    Taught Engineering training program, circuit logic and computer architecture.
  • Worked in ASDD [Advanced System Development Division] for awhile when WWAM [World Wide Accounting Machine, generated specs for IBM 1401] storm was brewing.
    I was not involved at this time.

Ralph Mork was Director or V. P. of IBM's Military division at that time In Owego NY. When the WWAM program was in dire need for some serious attention from USA, Ralph was relieved of his job and given the task of directing an Endicott effort. I never understood why this happened, because Ralph had no relevant experience and no personnel was assigned to him.

This turned out to be very fortunate for both me and IBM. He looked around for help and found only me. I proceeded to do my thing [designing a processor which became the 1401] with no management from Ralph. I was completely on my own, and I think Ralph had no idea what I was doing, but he was very adept at shielding me from distracting interference. Thus, I was free to get the job done. I also give a lot of credit to Jim Troy, Manager of the Endicott Lab. When it was time to compare different approaches from France, Germany and San Jose, Jim was always there for me. He really understood what I was doing.

When my [1401] design was finally accepted, a management team was assembled, Jim Ingram was my manager, then came Chuck Branscomb and the Bob Evans, all great people and very good at their jobs. At some point, the 1401 project had grown and I was given a group of 100 or so to manage without any management training what so ever!!! Sheesh! So as you might imagine, I made a couple of management errors. For instance, I was given a Secretary with a poor attendance record: 600 hours of sick leave per year. She persisted in this behavior so I fired her, The firing was quickly nullified and I was chastised. A couple of years later I discovered that she was promoted to manager of her own department. No explanation given.

After the 1401 was announced and selling like chocolate chip cookies , five of the most deserving members of the effort were given first class trips with their spouses to anywhere they wished to go, for up to three weeks, first class all the way, all expenses paid, no questions asked!.

I had previously let IBM know that I wanted to work in CA, so when the 1401 was well on its way Chuck Branscomb was transferred to San Jose to head up a new development of Education Systems. He had me transferred to work on Process Control. (eventually, the 1800). Then I moved to Education Systems. Meanwhile, back at Endicott, people working on early 360 systems needed an IPL device (Initial Program Load) in place of what we now call BIOS.

Somehow, I got the job, along with a bright Engineer named Bob Treseder. We came up with the first (in IBM) idea of a floppy disk We conceived of cutting disks from tape stock and stretching it over a plastic substrate. I designed the mechanism. That was the start of the IBM floppy disk. I went on to design a prototype of IBMs first PC as a component of the Secondary Education system. The floppy disk was a part of it. Integrated circuits hadn't been invented yet so the system was slow and expensive. I had some ideas for great improvements and tried to convince management to create a subsidiary to pursue the development of Intelligent Terminals and to use a different pricing formula.

The pricing formula at that time was outrageous and certain death for small, high volume systems. This idea went all the ay to the top and was violently rejected. "IBM doesn't do things that way and never will". Ha. The floppy disk idea was eventually rejected by the 360 development people because of the availability of improved circuitry. The development was transferred to another department where the idea of enclosing the disk in a paper envelope was created. This was a good one. Too good in fact because it could replace card as I/O devices.

This was a serious threat to IBM's multi-billion dollar card business. IBM issued a clear directive to all development that no system was ever to include floppy disks, either as I/O devices or storage. Unbelievable, huh?

Alan Shugart was my direct manager while all this was happening. He was no dummy, so he left IBM (presumably with all the documentation) and started Shugart Associates!! The rest is history as they say.

IBM didn't get serious about PCs until all this happened and I had retired. When I retired, I had my own Engineering Consulting business. for eight years. During that time I designed about 15 Scrap-metal recovery plant installed around the world. I also designed disk drive testers and wrote some two million lines of code to run them.

You mentioned that you went cross-country skiing. Ever do downhill skiing? I spent the next 15 years designing ski lifts for CTEC. Finally retiring for the forth time in 2003.

Well, looking back on all I have written today, I suppose I have told you more than you wanted to know. =-)

Fran,


Programmer "English" from Dick Weaver March 2008
Robert B Garner wrote:
> Dick,
>
> Thanks for your great feedback (as always).
>
> Were you an English instructor?
> Don't you know that programmers can't write and shouldn't even try!?  ;-)
>
> I'll incorporate your feedback this evening and resend.
>
> - Robert


English instructor?

No. It all dates back to a curious event at IBM. Seems there was an IBM employee (I've forgotten who) with a photographic memory who commuted in a car pool and, to occupy his mind while commuting, decided to review an IBM language manual, marking outright errors in red, could be done better in blue, simple edits in green, and so on.

When he was finished, the now very colorful manual was put on the shelf in his office. One day his manager noticed the manual, saw what he had done, and asked for permission to send it to the language development group. So the manual arrived at our publications department, who brought it to me saying they could not possibly process about a thousand comments as a "Reader's Comment Form" and what should they do.

We had a quick conversation: me "This is the answer!", pubs "But what's the question?", me "Why is our manual so hard to use". We launched a rewrite. The exact details are vague now, but over about a year (there was other work going on) the 300 page language manual was rewritten to about 200 pages. I did the rough markup and a cut and paste (at a time when real scissors and real glue were used) on the floor at home (some text may have been deleted by our cat); a writer did the rest.

I became a lot more careful about manual wording (and still made errors) and the writer, in an environment where pages produced was one measure of his productivity, had a productivity of minus 100.

My English remains bad, but I'm now a nut about not saying things more than once and always using the identical terminology and phrases (exactly what we were taught NOT to do in high school English).

dick w


Invisible Ink has its uses - by Stan Paddock September 2007
All IBM 519's had a device that could print on one end of a card up to nine numbers on one line or the other. What printed was under the control of the wiring of the control panel. One day one of the operators handed me a card and said that the end-printer was printing incorrectly. I could see nothing there and I said ?don*t you mean not printing at all.? He repeated his statement and escorted me over to a dark closet then turned on a UV lamp. Then I then could see the error in the glowing number. They were using invisible ink. The ribbon in the machine looked like a strip of oily white cloth. By the time I finished the repair my hands were glowing under the lamp as much as the printing.

They had started this system because tires were turning up missing somewhere in the plant. At each stage an inspector should count the number of tires in a batch and write it on the card under the printed numbers. He could see the original number printed on the card and he got to estimating the count instead of actually counting. Because there were certain defects that would cause tires to be rejected the number of tires in each batch would often decrease.

The day when the invisible numbers started coming out there was flurry of calls wanting to know how many tires should be in each batch. They were told to ?just count them.? They then asked ?how will we know how many there should be, and how many were they were to count, and how will we know if we are right?? The reply was ?Just count them all and we will tell you if they are correct or not.?

Shortly there was noted of occasion a sharp drop in the number of tires in one general area. A lookout room was built in the rafters over that department to watch them. From the high perch they saw a trash truck stopping out or normal sight of the floor level people. They layered the bottom of bed with tires and filled the top with trash. All this with a camera rolling featuring them. A undercover police car followed the truck to a warehouse with many stolen tires in it. The system of invisible numbers worked so well that they continued using it. I remember innocently saying once to another C.E. they used invisible ink to print on their 519. I had to explain the process and reason to him.


How the IBM S/360 Green Card Came About - by Milton Thrasher June 2006, June 2011
I find that many remember the "Green Card" from the 1960s. It is the pocket reference card for the S/360 instruction set and the many other things that programmers needed to know. It was perhaps the most significant thing I did at IBM in my 35.5 years considering its overall effect It was the most heavily used publication in the 60?s and 70?s. It was later changed to a buff color but continued to be referred to as the "Green Card".

In 1964, I was the Manager of Systems Engineering Techniques Development in the Eastern Region in NYC. The goal was to reduce the number of systems engineers needed by providing tools and techniques to make them more efficient and effective. The newly formed DPD HG SETD Department was headed by Alvin Gayle. He was under Jerry Haddad with 6 to 8 people in White Plains, about 15 people in Kingston and probably 8 or 10 people in each of 3 Regions. They had a long list of proposed products. I did not see many of them as very helpful in reducing the need for Systems Engineers. Most called for programs to be ordered from PID ? the IBM Program Information Department. My theory was that if it was not in the pocket/purse or attach case of the System Engineer, it probably was not going to be very helpful to many.

I was in the Eastern Region with access to the IBM Time Life Data Center. I proposed and got funding for the development of PAT/360, the S/360 reprogramming of a Procedure for Automatic Testing that was available for the 1401/1405/1410 family. It allowed customers to put a series of S/360 Assembler Language Programs on magnetic tape to be tested remotely. A tape could be sent to the data center for hands-off remote operation. The application programs would be compiled and data tapes generated from the control cards. An attempt to execute the application programs would be made after test data tapes were generated from control cards. When the program failed, an automatic memory dump would be written back on the original tape along with the collection from the output tapes if any. The resultant tape would be returned to the customer who could then find the errors and resubmit.

The importance was that System Engineers could stay with their customers and not spend the time to travel to NYC or other data centers to test programs which is very time consuming if done manually. The Automatic remote testing could be done by mail or by messenger overnight! The savings in travel costs were significant for IBM and its customers.

Because the people I had been assigned to work in SETD had no similar programming experiences, I got permission from Jerald Haddad's staff to use some money saved by not hiring for my staff so that I could hire an outside consultant/programmer.

To do the PAT/360 project, I hired David Goldstein, a former IBM systems programmer who had worked for the Poughkeepsie Programming Center Manager but based at Time Life. He was a very bright and competent programmer who saw a bigger future in contract programming.

Dave and I planned how to convert the PAT/360 System from the PAT/1401 which was the simplest of those available. We took our scheme to the Endicott Programming Center when Earl Wheeler was the Director. He assigned some of his people including Charles Schultz, the S/360 Assembler Development manager to work along with us. Schultz provided a collection of programming aids used to develop the S/360 Basic Tape and Basic Disk Operating Systems which were steps for building Disk Operating System/360.

We were surprised how cooperative this group was because they had a planned comparable but more complex system called AutoTest/360 for DOS/360 users. That system was top-heavy with many more control cards and set up procedures. We perceived that it was doomed to failure if it ever got delivered. That created a political problem that was destined to work against PAT/360 later.

Our new found collection of aids included an early version standalone compiler, disk dumps, tape dumps and a set of diagnostic programs. They came with minimal documentation along with a very early version of the Basic Tape Operating System. Dave Goldstein and I took them to the Time/Life Data Center and we became a small sensation of the time. We got their first System/360 to actually do productive work in S/360 mode! Until then, they operated strictly in 1401/1410 or 7070 compatibility mode.

I adopted the role of a customer developing and testing S/360 DOS programs. I had done some sample assembly language programs for the IBM/1401. I had to relearn how to program in S/360 Assembler Programming Language due to the very complex instruction set with many options. Some programs had to be written in a lower level machine language for performance. So the ?bits and the bytes? were very important. The SRLs, System Reference Library manuals, were very large and not easy to work with. I had a stack of manuals about 24 inches high. We needed a handy reference card so I built it from these appendices and added some tables I created to manipulate EBCDIC.

I knew that the card could not be finalized until a lot of people proofed it by using used it heavily and pointed out more things needed. I printed five versions with ever increasing content on light weight paper that would self-destruct. That way they would eventually disappear. They were printed in larger size fonts than the final card so that they could be read more easily during development. Dave and I worked many days and nights at the T/L Data Center to get the first TOS/360 to assemble the converted IBM 1401 BAL to S/360 Assembler routines. Dave got excellent cooperation from the Endicott Center because he found and fixed a lot of bugs for them. He also had many good suggestions on how to solve some of their most difficult problems. Soon, the Endicott Programmers realized that they could get a lot of machine time at the T/L Data Center. They sent a small group of programmers to NYC to work along with us. Having close proximity to the developers, Dave and I were able to get PAT/360 running as soon as the Endicott Programming Center made their first release of TOS/360. We were well ahead of their first release of BOS/360.

But, almost as soon as we finished the first PAT/360 Type I program release, we were shot down by the DPD HQ Software Product Marketing Administrators. They thought their job was to only support Type I Programs developed by the Product Divisions. They had a dim view of Type III Programs that were available from PID but unsupported. I was never able to get resources to maintain PAT/360 even though it was up and running and saving people tremendous time in developing Assembly Language Programs. That was because they thought that DOS/360 AutoTest which was only planned, not announced, had specified functions that included ours. It was to be a fully supported program while ours was in the Type III unsupported library. That was very unfortunate because when it was finally released a year later, AutoTest was scarcely used due to its cumbersome control cards and obscure instructions. It introduced more problems than the customers' own programs! It was like a very complicated Job Control Language. Our PAT/360 required a minimum of 3 control cards for each program. It was very stable and did not require much maintenance. The SETD Headquarters group would not allow us to spend any resources or publicize it in their brochures once it was released!

I challenged the DPD Headquarters product administrators to try using AutoTest documents and PAT/360 for tests of actual programs. That was for them to decide which they would use if they were the Systems Engineers on a customer account. They refused to try either system. This was a very disappointing encounter with the headquarters bureaucracy which shaded my thinking and approach to handling future encounters.

A number of S/360 early customers took PAT/360 as their main tool for program development. Time Magazine, housed in the same building as the Time/Life Data Center, was one of our first users. They claimed that even with their close proximity, they were able to get more programs tested and running sooner than they would have otherwise. They gave us a strong testimonial. This gained PAT/360 a lot of new users very quickly that were testing at the Time Life Data Center. Word of mouth and recommendations by the Time Life Data Center Reps was very positive. That was important to me later in my career. Several of the Data Center Reps went on to be my higher level management! They remembered what a strong technical program I had created.

I watched the customer programmers work with their memory dumps to find out what features they needed in addition to what was on the preliminary reference cards. Then, I would talk to the Poughkeepsie publication manager who would consider adding something more to the SRLs or clarify what was written. We had a very symbiotic relationship, particularly with David Ulrich. He was a competent programmer and took a big interest in helping with the pocket reference card development.

After releasing the five iterations of the reference card to customers and documenting their comments, I took it to the DPD Headquarters Technical Publications Department to have it numbered, type set and printed. Alice Gnad, a first level manager, assigned Al Reynolds to work with me to finalize it and select the color. We picked the green for being easier on the eyes for the fine print. The first printing was done in about 10 panels, 5 per side. Not long after we were up to the final 16 panel card which was about as large as could be handled easily.

We found that most programmers had glass desk top covers and put the two sides of the card under glass. That helped account for the huge volume of cards that were needed very quickly. The card was very useful to other than Assembler Language Program. That was because it showed how to calculate with EBCDIC, the base 14 numbering system of the S/360. Each S/360 class was started by handing out the "Green Card" with my phone number on it. This produced a lot of good suggestions.

Knowing that no good deed goes unpunished, I expected things to start happening badly. And they did. First, Al Gayle's headquarters group objected because the Green Card was not on their sanctioned project list. That was even though I did it as an aside to the PAT/360 project with out any additional funding.

Next, Roger Bury, the head of DPD Publications sent a complaint letter to Y. P. Dawkins, Eastern Region Manager stating that a person in his region was producing "bum publications". He meant that they were not authorized and did not go through his product test cycle like other publications from DPD Hdqtrs. This resulted in the Eastern Region?s number two man, the former Western Region manager, coming to visit me to learn about my "bum publication". I showed him the reference card and the steps I had gone through to produce it. I also showed him the list of esoteric projects that I was being asked to staff and fund from my budget which I had refused. After listening to my story, that manager said, "Keep up what you are doing. You are on the right track!"

Very soon thereafter, I got a better job in DPD HQ Software Marketing due to my hands-on work with S/360 software!

About this time, OS/360 was being tried out in the T/L Data Center and found to have significant operating problems. One thing led to another and I was assigned to work on ?usability problems? for OS/360. They were known as Human Factor problems. I was assigned to work with Ted Plaut, Manager of Product Test. He had programmers that identified many user problems before the releases could be approved. They needed fixes as quickly as possible to meet the ever shortening release dates for versions with new peripheral product support.

I went out to the Regional Software Marketing Representatives to solicit fixes from SEs and customers who were able to solve problems locally. We called the project Operational Characteristics Improvement Program ? OCIP. It soon became the banner for getting things fixed. We even dabbled in getting some hardware changes. For instance, the first console was an IBM 1040 typewriter type terminal, not a display unit. Later, we were one the first to support the color displays. That became a great show piece.

Very soon thereafter, Buck Rodgers, Western Region Manager and later IBM DPD President, took notice of some of the things I was doing. He came to White Plains with the Bank of America account salesman, Hal Durett, and their list of usability problems. They had documented 19 things that they must have fixed in OS/360 to allow them to process their "messengers" from their outlying branches by 11:00 a.m. everyday without fail. When Buck Rodgers became DPD President, he remembered OCIP fondly. He gave me a book titled ?The Entrepreneur? as a memento which I still have.

Chuck Ruby, who became a very well known SE Manager, was assigned to follow through with me when dealing with the Poughkeepsie Programming Center to get the fixes they needed done expeditiously. Chuck had a better overall view of OS/360 than most of the Poughkeepsie Programming Center architects and managers. That was because he had to make many local innovative fixes to keep their many S/360 Model 65s running with Reader/Sorters for their check processing. They had the Reader/Sorters on one floor and the computers on the floor above. That was because the dust from the chad of the checks would fill the air and cause the filters to clog if on the same floor. He had a lot of suggestions and some code that could be used by others.

Very soon thereafter, I was given the clout needed to get things moving. Bill Viteck was assigned by Ted Climis as the management link I was to work through. There was a systems planning department with a long list of add-on functions. And, there was my separate list of problem areas. I was eventually given a budget of as much as 5% of the lines of code and 10% of the cost of each module throughout the OS/360 as needed to get the problems fixed. This gave OCIP the authority and creditability that it needed.

Before that happened, George Widding hit upon the idea of putting out match books with the words: ?OS/360 - Performance, Function and Usability? on one side and ?Human Factors Will Be Fixed? on the other side. He came to me with this idea. I immediately took a mocked up sample match book to a neighbor, Terry O'Connell of Westfield, NJ. He had just become an area manager for the Diamond Match Company. He took my order for a case of match books with about twenty to a box. They were delivered in about 2 weeks.

When I got them, I took them directly to Poughkeepsie and had the cigarette vending machines stocked with them and told Don Gavis about them. He said, "That's a great idea!" But, before I got back to White Plains that day, I had a call from the Poughkeepsie Plant Facilities Security Manager. He demanded to know whom I worked for and who paid for the matches. He was convinced that they were very damaging publicity for the Poughkeepsie Programming Center's product. I could not convince him that they would be helpful in getting the programmers to focus on fixing the problems. Very soon, my manger, George Widding was called on the carpet for these matches. He called me at home and told me to confess that he had authorized them. He later told me that the match books were just the last straw. He had been very demanding that Poughkeepsie fix a number of other problem areas beside usability and they were gunning for him.

That one case of match books had a life of its own. Some Poughkeepsie OS/360 programmers reported they found a box of them in Hong Kong. Those who wanted to be in the ?know? carried them in their pockets. Don Gavis claimed that they created a ?state of mind? throughout the development centers which were spread throughout the manufacturing division. IBM Palo Alto, Boulder, Kingston, and Hursley England had large roles to play in OS/360 Development. We had OCIP Meetings at most of the locations to get their managers directly involved. I remember Tom Apple in San Jose Data Management being initially suspicious of our authority but he later became a great proponent.

Glenn Morgan had a Western Region bright young man in mind to replace him. That was Ivan Bowman. He was a very detail man and knew a lot about how the Operating System was designed and how it was supposed to evolve. About a month later, Ivan replaced George Widding who took a job as the Systems Engineering Manager for the Western Region. This was very good for OCIP in that he would call in from cities like Boise, Utah with direct input on how the OS/360 problems were impacting sales.

Soon, each Region was asked to appoint an OCIP representative to work with me in establishing what problems should be addressed. These were OS/360 program administrators only. DOS/360 program administrators were never given such an opportunity because the direction was to try to move all customers to OS/360. That was because, to the very end, Larry Foster and other OS/360 architects claimed that they could produce an OS/360 subset that would satisfy even the small customers. Of course, that never happened because OS/360, like government, never shrinks. It grew by leaps and bounds and the lower model hardware did not provide the memory or performance required by the huge number lines of OS/360 code.

Once large customers found out about the Bank of America getting special treatment, the user groups - GUIDE and SHARE put OCIP on there meeting agendas and demanded to know more about the program. They both met twice per year with working committees meeting between major meetings. So, four times per year, I made presentations of what was being done to solve their problems. We established the discipline to have them vote on the severity and importance of each problem with an estimate of how many customers of which types would be affected.

I quickly gained the reputation as the man to talk to if you wanted to get your problems fixed. I had the problem that IBM was very conscientious about not pre-announcing products. It was the time of the Consent Decree. Our competition could promise the moon but we could only announce things that were eminently deliverable. I had to have all of my presentations scrubbed by the legal and customer relations departments. The Industry Marketing Sector that dealt with consultants was especially sensitive to what I would say. The consultants needed to be in a position to provide the best advice as to what to spend their resources on. The Industry Marketing Director for Consultants took a big interest in OCIP. He was able to bring a lot of IBM management attention and resources to OCIP.

OCIP continued until Release 20 when OS/360 became fairly stable and the need for usability fixes became much less. I made a final presentation to management that we had solved 240 specific problems and had expended over $10,000,000 additional resources over 5 years. They included Checkpoint/Restart, System Management Accounting, remote console support, and improved Job Control Language and ?lost device end interrupt?, a particularly troublesome problem. We gave test code to those accounts that had severe problems so that the fixes came back to us with assurance that they solved the known problems.

The way we wound down the program was typical of IBM. They simply found new jobs for the people involved and terminated the program unceremoniously. Milton Thrasher mthrasher@verizon.net 941 966-9172 Sarasota, FL

Milton Thrasher
mthrasher@verizon.net
941 966-9172 Sarasota, FL


Please send Assembler Coding Sheet

from Milcia Cruz

----- Original Message -----
From: Milciacruz@aol.com

hi i am student, and i am taking assembler language. I will like to know if you can send me a copy assembler coding sheet.

MILCIA CRUZ


Reply by Ed Thelen
I'm sorry - It just is not practical for me to do that.

Actually I rarely used the official coding forms of the different manufacturers that I worked for -

  1. usually poorly printed with smudgy ink, (IBM was OK)
    - after a few hours, part of your writing hand would be blue, black, or green- depending
  2. - printed character boxes too small
    They typically put rows of 80 little boxes on the page, landscape mode (sideways)
    Allowing for borders, this made very small boxes and confusion if your hand written characters touched the edges of the little boxes
  3. some other form to have to keep around

So - I typically keypunched/data-entered my own stuff
This saved

  • wandering about, dealing with keypunch,
  • being told that they couldn't get to it for several hours,
  • use ink instead of pencil - or the opposite depending,
  • slash the zero, or don't, depending
  • slash the seven or don't, depending
  • general screwups, ...
  • and I could proof the written code as I keypunched/typed
  • and I can keypunch/type about as fast as most folks
  • and I can be more careful than most
  • and I know that smudge should be an "m" not an "n"
  • and I can resolve that usual ambiguity between 1, lower case l, 7, vertical slash, i, I and other problems with vertical marks
  • and I can resolve upper case O, lower case o, zero, upper case Q
  • etc., etc. and so on :-))

I normally took a normal writing tablet with horizontal lines, drew three quick lines vertically, and went to work.
Column Column Column Column
1 2 3 4
Symbol
or blank
Op Code Operand Remarks, lots of remarks
( need lots of remarks because my memory is very bad.)
. ...
. ...
. ...
. ...
. ...

Have Fun :-))

Ed Thelen

IBM 101 - "and counting"

from Alfred Hexter
You asked me to tell you about my experience with the IBM 101. Here it is, at length.

I entered graduate school at UC-Berkeley in 1956, working for an MA in Statistics. A week after I enered, my advisor reviewed my program with me. He noted that I had a background in biology and asked if I would be interested in biostatistics instead of statistics. I had never heard of biostatistics, but I went to the School of Public Health and talked to Dr. Jacob Yerushalmy. He told me if I changed to biostatistics, I would take the same courses in statistics plus additional courses in public health. That interested me, and I changed. So the day I learned of the existence of biostatistics was the day I changed my major to it.

I got my MA in 1958, and got a job with the Contra Costa county health department. The health officer was on the advisory committee for a research project in tuberculosis. They had given tuberculin tests to school kids in ten California counties and now had data for two years, with repeat tests on 55,000 kids. This was an important study. They needed someone to help analyze the data.

I was interviewed by the research director, Dr. Escholzia Lucia. She knew some statistics but she was primarily an administrator. If I would analyze the data, I would be a co-author of the paper. That was a big deal for me, I had never written anything for publication. I would also learn how to operate the equipment. So in November 1958 I joined the project. Shortly after that I went to IBM school in San Francisco, where I learned how to operate a keypunch, how to use the sorter, and how to wire the boards for various machines, including the IBM 101. When I got back to the office I designed the tabulations, and made wiring diagrams for these tabulations. Eventually, the cards arrived, behind schedule, and then they wheeled into my office a machine that was paid more than I was, an IBM 101 statistical counter-sorter.

The 101 was a remarkable gadget. It had 60 counters (60 separate registers in which you could accumulate counts) and 13 pockets for sorting, corresponding to the 12 rows on an IBM card plus a reject. (The sorter had the same 13 pockets, but the sorter read a single column and sorted whatever was punched.) There was a smaller version of the 101, which looked the same but was called a smaller version because it had only 15 counters. The 101 would do complicated sorts and complicated counts. For example, you could wire it so if there was a 5 in column 3 and an 8 in column 7 it would sort in pocket 1, and so forth, and similarly for the counters. Control cards were cards with a 9 in a particular column. When the machine reached this card, it would stop and print out the totals in the counters. The counters would then reset to zero (you selected which counters would reset). For this study, the counters going across might be the induration (the swelling on the skin at the site of the test) and the sorting might be age of the child. I would put a 9 card on top of each batch of cards in the pockets, pull them out in order, and run them again. The output would then show induration by age, with the totals on the top.

The machine was a pleasure to work with, except for a few not-so-minor problems. The worst problem was my feet. I have flat feet, which kept me out of the army, and also means I can't stand for very long. The machine read 450 cards a minute, the hopper held about 500 cards, and each pocket held about 500 cards. When the machine was running, it was impossible to sit, I was busy all the time. A single pass for 55,000 cards took more than two hours, and a box of 2000 cards weighed ten pounds, so I was working hard. One pass would almost finish me for the day. As we ran the cards, they got worn, and occasionally they would jam. There might be 2 or 3 cards that were bent or torn, and had to be repunched. The study used about 30 or 40 columns in each card, not all of them adjacent. They did not budget for a real keypunch, so we had an IBM 10. That is a little desktop that takes one card and had 12 keys (one key for each position in the column) plus a spacebar. To repunch, we would put in a card, space to the first column used (bang, bang, bang on the spacebar), punch the number, space to the next column, etc. It didn't print, so we would pencil in the numbers above the punches. An office a couple of blocks away would let us use their keypunch, and sometimes I would go there clutching a handful of cards.

When the study was finished, the paper was written by the physician heading the tuberculosis control program for the state health department, which had put up the money. The co-authors were a county health department physician and the head of the California tuberculosis association on whose premises the work was done. None of the four people who did the analysis were even mentioned, not even Dr. Lucia. You would have thought, from the paper, that the three co-authors personally tested each of the 55,000 kids, and they took turns feeding cards through the 101. The paper was not well written and it ignored what I thought were important findings of the study, but that is a different story.


Pioneer Business Programming from Gerry Jean
In January, 1956, I was one of 15 or so people selected by my employer, Pepperell Mfg. Co., headquarted in Boston (I was then working at the Lewiston, Maine finishing plant) and sent to NYC for two weeks of indoctrination/training on the Datatron 205. Our instructors were Paul King and Gordon Lovelace. With Electrodata/Burroughs input, Pepperell selected the four least confused attendees, I being one of the four. We started to design and code a basic order/invoicing system, taking all of 1956 and 1957. One of the four selected was already a New Yorker; the other three of us moved our families (Long Island) in the spring/summer of 1957. The 205 was installed in 1958 in the Wurlitzer Bldg. on 42nd Street (at Times Square). Alas, it was uninstalled in 1960 because of (1) inordinate machine downtime, and (2) poor system support systems at the various company branches.

I'd like to know if you could direct me in finding any text/photos of the Pepperell installation. I've tried the Pepperell web sites but the company has gone through at least two acquisitions that I'm aware of and I haven't any luck trying that route.

>   a) do you still have documentation on the Datatron 205?
Unfortunately, no. I'm always on the lookout for some whenever I browse through old computer stuff in a dusty old bookstore.
>   b) what language were you using to code the
>           order/invoicing system
Machine language. (64 = clear & add; 04 = change on non-zero; etc.) I think that Burroughs' first assembly language was STAR, which was initially available on the B220.
>   c) could you amplify on

>            (1) inordinate machine downtime,

It seemed that the maintenance engineers had more time with the B205 than we users did. In order to run our production programs, Pepperell had an agreement with Atlantic Mutual Co. (marine/hull insurance), also in NYC, to use each other's B205 off-hours to keep our production systems from falling too far behind. The order processing was never able to catch up to the backlog.
>          (2) poor system support systems at
>                  the various company branches.
In 1956-57 I don't believe there was even the position/function known as system analyst ...... certainly not any text books available. Burroughs had assigned a "tech rep" to work with us ..... Ira Rubin (who went on to be a fulltime professional bridge player). Ira was a mathematician by training and he tutored us as though we were all well-versed in that discipline. For example, instead of the flow-charts checking "new order # GEQ previous order#", we were taught to use "n sub-prime 1 GEQ n sub-prime2". The point is that even our system designs were tough to follow & required constant referencing of a legend to decipher n, a, x, tt, etc. Don't forget that we were extreme babes-in-the-woods ...... just like youngsters, we looked to our tech. rep. as our guru and believed that this was the way to do things.

The technical people that Pepperell had at various branches still had IBM tab equipment and, naturally, only could think along that technology. Again, the tech staff at the B205 NYC site consisted of, besides the keypunchers, we four programmers. We had no expertise (nor the staff) to properly coordinate systems at the computer site and the branch tab shops. Burroughs didn't/couldn't provide any meaningful assistance in the design area ... in fact, our tech rep support only lasted through the summer of 1956 ... we went it alone after that.

We were truly all pioneers!

Gerry Jean - Pacifica, CA

Stretch crew car thieves ?? from Jack Worlton Nov 2015
I was reading your notes on the Stretch machine when I came to the part where it noted that the core memory was immersed in oil. The following anecdote came to mind.

We were having trouble with random memory errors that drove us all nuts for a long time. Finally someone (I don't remember who) suggested changing the oil in the memory, which we did and it worked! The problem turned out to be a bit of solder that was circulating in the oil, and the oil change cured the problem. We always like to point out that it was the only time a computer problem was solved by giving the machine an oil change,

I don't remember exactly when, but it happened in Poughkeepsie while Stretch was still in the late checkout stage. It would have been in the winter/spring of 1960/1961.

We did no classified work on Stretch in Poughkeepsie, at least that I was aware of.

Another odd story concerns the time we were accused of being auto thieves. We were working in the wee hours of the night, and when our time was interrupted by the engineers for their work, we decided to go get something to eat. Problem was we didn't have a car, so one of the engineers offered his keys so we could drive to a restaurant. We went out and found a car meeting the description we were given, the key fit, and off we drove. When we got back, there was a Sheriff looking into a stolen car incident. It turned out that there were two nearly identical cars in the lot and we picked the wrong one, and the key fit both cars. So at one time the Los Alamos Stretch crew were accused of auto theft!

Jack Worlton
PO Box 171236, Salt Lake City, UT 84117
Jack's cell: 801-608-2727

Telephone 411 support, with IBM 360 Mod 50 - from Hal Murray July 2016
Computer Corporation of America had a data base package. In 1969, we got a contract with Bell Labs to build a prototype directory assistance system. It was run at PacBell in Oakland. 4 of us (half the company) moved out here for 6 weeks or so. We rented a big house in the edge of the hills. I walked it occasionally but it was a long walk.

PacBell didn't have room for us in the main building so they rented space a few blocks away. The CPU was a 360/50. It had 3 2314s with the dual channel option and 3 data channels. (The 2314 was the big brother of the 2311. It had twice as many platters, probably more bits per platter. It came in a big package with 9 drives, 0-7 with a spare.)

The machine room was spacious. So was the coffee area.

I got there a few days before the CPU arrived. The tapes and disks had been there for a while. The controllers were smart enough to exercise the read/write and mechanical parts. The CEs had that stuff all sorted out.

I wasn't there when the CPU came down the freight elevator. (We were a half floor below ground level.) The CEs had it mostly together when I arrived.

I saw a big hammer on the top of a tool box. It seemed a bit strange so I asked the guy. "That's our door fitting tool."

After a while, they turned power on and some breaker blew. This machine had 384K. (128K wasn't enough. 512K was too expensive.) This was one of the first ones shipped. These guys had never seen one before. The documentation hadn't been debugged yet. They scratched their heads for a while and rewired something in the power area and then power stayed up.

They pushed the boot button and nothing happened. Then one of them said "Did we reseat all the loose cards yet?" They turned power off. There were 3 or 4 CEs. They opened up the CPU logic wings. The cards were behind air-flow covers about 8x10 inches with plastic plungers in the corners. They would open up a cover and tap each card with the back of a screwdriver. If it didn't sound solid they would reseat it. There were occasional shouts of "got one" and occasional rattles as a card fell out when they opened a cover. After that, they tried booting again. It worked. I did the sysgen that evening.

I got to know most of the CEs reasonably well. There were 4-5 of them at the local office. It turns out that most of the 360/50s in the area were at banks. Banks wouldn't give them the time of day. If the machine was idle we would let them play. I enjoyed working with them. They spent a lot of time at our place. Sometimes just drinking coffee and BSing. Our system worked well.

Several years ago, I found a blog by the woman who was the chief operator. PacBell obviously wanted this to work. They picked good people.

There were 2 56 Kb lines from their main building to our place. One went out the back door and the other went out the front door so a backhoe couldn't get them both unless it was right next to our building.

Back then there were 1.5 million phones in 415. It was something like 3/4 million residential, 1/2 million business, and 1/4 million government. Part of our job was to write hack code to extract what we needed from the tapes used to print the phone books. We had one guy working full time on that.

We got a tour of the directory assistance work area. There were rows of booths. When you called 411, and the operator asked "What city please?", she really meant "Which phone book?" There were 6 or 8 books on a rack in front of the operator. They were reprinted every week or so on a staggered cycle. The new listings had a big black dot next to them. There were a few sheets updated daily with the changes since the books were printed and a few more listings in large print on a chalk board at the end of the room for panic cases, like a new restaurant that got screwed up. The walls of each booth had the most-frequent requests.

Our promise was that if you gave us 3 characters of the last name and 3 of the first name or street name, we would return a page of answers in a second. That was based on their statistics and simulations by a guy at Bell Labs. It turned out to be slightly optimistic. After a short preliminary test, we reloaded things with another character.

Odd CRT Terminal - from Michael Albaugh July 2016
1) When I worked at the instrument shop at U.C. Berkeley (E.E. department, Cory Hall), we got in some very odd CRT terminals. This would have been about 1971 or 72.

They used "Transformer" memory for the read-only character generator, and MOS shift-registers for the display buffer (characters, not bitmap. memory of any kind was pretty expensive). The CRT was oriented "portrait", rather than "landscape", and had _four_ yoke drivers (and four sets of yoke windings, of course) the "main" yokes swept the beam in a course raster that covered every character position, while the "tweeter" yokes swept the beam within a character position. Pixels for any given character were painted top to bottom, left to right.

The "left to right" of course was partially due to the "main" yoke deflection, but the tweeter horizontal would normally counteract it to make the columns of pixels vertical. You could set a bit in a character to alter that tweak, to make oblique characters. The keyboard was also, "interesting". Neither QWERTY nor DVORAK, but somewhat phonetic. I once knew the name, but "senior moment" sigh.

Anyway, think along the lines of Soundex coding. For example, there was a "SH/SCH" key. We were told they had been part of an experimental "Directory Assistance" project, and had come from Oakland. I don't know whether I had correctly guessed that they were more likely for intercept operators. We were never able to actually put them to use, because the interface was some sort of serial line _to_ the computer they had been connected to, but the _from_ side was a couple fairly fat parallel connectors, with what appeared to be the sort of 91 ohm skinny coax I had seen in some IBM equipment. We had good docs for some of the analog stuff, but none at all for the interfaces, so we gave up.

2) The reason I mention intercept operators is that's what it appears Hal's group was doing, (see story from Hal Murray above) and that a friend of mine (sometime about 1977 to 1981) was working for George Litho in SF. They were one of the first big printers to do computer typesetting, and got the contract to print the intercept books Hal mentions. They would get (weekly?) tapes from PacBell, then typeset and print them on the graveyard shift.

My friend had written the custom code for this, and being a diligent programmer (and having had some odd gaps in the output, missing records, etc.) put in code to log when the input validity checks had skipped a record to the console terminal.

The next production run, he got an urgent phone call from the graveyard operator. The console printer was "going nuts" and the job was stalled. He talked the operator into disabling error logging (patch on the running program?) so the job could complete. next day he changed it to only log the first n errors of any tape. The sales guys had talked the customer into paying extra to get those logs, and I think it was quite some time, if ever, before they ever got one with less than n errors logged.

Of course, this was all around the time when both normal directory assistance and intercept were being consolidated into a few regional offices, so it was no longer possible to dial 411 and ask for "that hardware store down the street from the H-street C.O." and get the answer.


Other sites with Stories

The end -