return to main page
return to 1950s Team Bios page

1401 Stories and e-mails

Purpose of this page - provide stories of the unit record world and the 1401.

Links to more stories.
   - IBM 1401 1950s Team Bios, including goals, architecture, design, software, production, marketing teams, stories, ...
   - 1401 Stories
   - Stories about People and Machines
   - IBM Stories from John Van Gardner
   - Many about Lawrence Livermore

Contents: (newest near the top (here))

More Vietnam - posted February 2024
From John Lawrence

A little more on my experience. I was assigned to the Army's 519th Military Intelligence Unit as a prisoner Interrogator. Once in Saigon they discovered I had a computer background, the 1401 was stored in vans on the air base/airport. With the help of IBM we were able to get the system up and running.

The Rand Corp was in the process of supplying data on North and South Vietnamese individuals on punch cards. Once up and running the Rand Corp with IBM had created a autocoder program to process the data and create print outs for use in the war effort. Later other applications were added along with the 729 Tape Drives.

The picture I supplied showed a Vietnamese army person standing by the 1402 was part of the plan to turn over all functions to the Vietnamese Army and let them be responsible for the 1401 System, so there was a lot of training in order to make this happen. It never really happened.

The command later build a facility data and all hardware was moved from the vans into that building. We actually had Army soldiers sitting at key punches with their rifles by them doing the key punching, the facility was not totally secure. I never thought I would see a 1401 in Vietnam!

About half way through my deployment I started working on a new computer, IBM 1131, it was used to drive a plotter that produced map overlays for the B52 strikes, also known as Rolling Thunder. I returned to the US in September of 1967

a Vietnam vet describes their 1401 system ‘in country.’ - posted August 2021
via Dag Spicer
from John Rausch (Facebook)

In 1968 I received orders to the Naval Supply Depot in DaNang, Vietnam. At the time, it was the largest military supply depot in the world. The Data Processing Branch was operating with only unit record equipment. It was one of, if not the, top unit record *rental* site for IBM at that time. Two 407s fed by lots of other machines could not process one day’s transactions. Reordering was done manually.

The lieutenant in charge found a surplus 1401 tape system in Guam he could have. There were only two enlisted data processing technicians in the entire Navy with a proficiency code as a 1401 programmer. Inventory control is a fairly simple application. I had it completed in less that a month. The other programmer worked on engineering work orders.

I wrote a reorder program, even though it was not requested, and, a report generator specifically for Federal Stock Records because the supply officers were asking for simple, but different, reports all the time.

Several months after I arrived, an ARVN ammo dump right across the road from us (duh) was hit with a satchel charge that set off everything. It was late and I was not there. The next morning I arrived to see our building pretty much destroyed. Warehouses and Quonset hut offices were wrinkled up like tin foil, all from shock, not impact.

The 1401 was on its face and covered with dust and debris. The CEs, who lived in a villa in downtown DaNang were on site. They stood up the 1401 and moved it and the peripherals to a plywood air conditioned room built inside one warehouse that was not severely damaged. One of the address dials on the face was broken and replaced. They vacuumed it out, gave it a good look over, and powered it up. It worked just fine.

Some of the DaNang IBM activity is written about in:
“When Big Blue Went to War: The History of the IBM Corporation's Mission in Southeast Asia During the Vietnam War (1965-1975).”

In DaNang, the Marines had two 360s. For what? Beats me.

The photo is when equipment was being moved out the back door.
John Rausch

1401 Code Lives Forever, and ever and ... - posted June 2017
from Robert Garner:
Peter Capek's < peter.capek@gmail.com > The most outrageous case of nesting Operating Systems" anecdote (and subsequent items on H-200?).
Thank you Robert for the H-200 info, and especially for the link to the 2010 IEEE Solid State Circuits article that you and Rick Dill wrote about the 1401. I learned a lot from it (the origins of Rent's rule, among other things) and really enjoyed reading it.

I think I met Maurice Papo when I visited La Gaude ca. 1972-3 when John Cocke had dispatched me there to help Gerry Lebizay think about software for a small PBX called, I think, Snowflake. Glad to hear he's still involved.

The IEEE article included this sentence: There is a reasonable chance that an IBM mainframe somewhere is still running a 1401 application from decades ago.

I must respond to that by giving you the following, which was included in around 1993 in an early e-mail based discussion about the "History of Cyberspace"; I think you'll get a chuckle out of it. I don't think the FARGO description is accurate, and it probably wasn't "bought", but don't let those details detract from the story:

----------------------------------------------------------------
The most outrageous case of nesting Operating Systems:

I had a customer who had a payroll system setup in the 1950's using 407 punch card accounting machines. There was a problem (labor dispute, I think) that led to a permanent injunction that forbade the customer from changing the system.

When they acquired a 1401 system in the early 1960's, the method had to be brought over, intact, from the 407 to the 1401. They bought a program, called FARGO. Each wire on the 407 plug board was coded into a punch card, and the deck of cards was feed to FARGO as input. FARGO's output was 1401 source code that emulated the original 407 function. This was found satisfactory to the court, and became the way of doing business.

In 1967, the customer acquired a System/360 model 30, and migrated the FARGO generated code to the 360/30 - 1401 Emulator. When the 360/30 was running in 1401 mode, it was using different microcode and WAS a 1401 for all practical purposes.

Later a software emulator was installed that allowed the 1401 code to be run as a 360 DOS application in one of the three partitions that DOS/360 then supported.

As time went along, the company was bought by a larger firm, who moved its system to a 360 model 65 using OS/360. The application was now run under a DOS emulator within OS/360.

Finally, the parent company moved the entire DP operation of the smaller company to a VM/370 system. It's OS applications were run in a VM guest machine. Thus the stack of systems emulated became something like this:

VM/370 <- OS/360 <- DOS/360 <- 1401 Emulator <- 1401 407/Emulator <- 407

Each of the transistions had to be blessed by the court. It has been twenty years since I had contact with that customer, and I have often wondered if that 407 function was now being emulated a few layers deeper.

Probably, the principals are now all dead or retired, but if not, someone may still be sitting at a (virtual) keypunch to prepare a (virtual) card to be read into a (virtual ** 5) 407 accounting machine to write a real paycheck.

Jim Ayres
jayres@vnet.ibm.com

More on the Honeywell Threat - posted June 2017
On Fri, Feb 27, 2015 at 10:22 PM, Robert B Garner wrote:
Peter,

fyi, below are some excerpts from an H-200 planning memo that was forwarded to us by Rob Sanders... (I can forward the entire memo if you're interested - or I think Ed may have posted it on our web site...)

Illustrates that Honeywellers were a bit mixed up...

- Robert

----- Forwarded by Robert B Garner/Almaden/IBM on 02/27/2015 07:19 PM -----

From: Rob S < robonsite@honeypi.org.uk >
To: Robert Garner
Date: 05/13/2014 05:46 AM
Subject: Re: The Honeywell 200

I think the apparent lack of confidence may stem from doubts about the resources available to the enterprise within Honeywell. Computers weren't its primary product, so competing with IBM for just a small share of that market wasn't a big deal in the eyes of the board apparently. I don't have permission to pass on all the documents that Gay has shared with me, so I won't be backing up that remark with any evidence.

Regarding the delay line memory, Gordon wrote an earlier paper on the subject in September 1961, one of the three that I made available on my webspace. Presumably as a consequence of that, there were actually twofeasibility studies done according to the memo from December 1961 attached here, and Gordon was specifically tasked with examining the delay line approach. He mentions glass delay line technology developed by Corning, but I don't know what its capabilities were. Regarding the H400 and H800, he seems to have been concerned only with providing interfaces with them rather than direct compatibility.

The point that IBM hadn't intended the 360 to be able to emulate the 1401 is interesting as it implies that they must have intended to run the two product lines in parallel. I read somewhere the view that IBM were actually more concerned about the incompatibilities between the H200 and 1401 than the similarities as any customers who bought H200s would eventually end up running software that couldn't be run on any IBM machine and they would never return to the fold. In my article for the CCS journal I made the point that the H200 was similar enough to the 1401 to attract IBM customers but different enough to keep them. In the case of my own employers, they were a green field site using punched cards and tabulator equipment, so could pick any make of computer as a relatively cheap starter machine and in 1965 the choice was obvious. The baseline H200 was only a small part of a highly modular series of machines under development and in the smaller UK market machines tended to be bought outright rather than rented, so longevity was a factor. Once we started developing our own software to take full advantage of the series 200's features we were bound to stay with Honeywell for decades, exactly the scenario that concerned IBM. Therefore the idea that the H200 was a failure by not being entirely compatible with the 1401 isn't actually the whole picture. My demonstration programme on the HoneyPi Project website was written as an example of code that was totally incompatible with the 1401 and also to prove that the H200 designers had come up with a machine that even in its most basic form was very economical in its use of memory, the component that had given them the serious cost problems.

Rob Sanders

----- Forwarded by Robert B Garner/Almaden/IBM on 02/27/2015 07:18 PM -----

From: Robert Garner
To: Rob S
Date: 05/12/2014 11:02 PM
Subject: Re: The Honeywell 200

Rob,

Thanks so much for scanning/forwarding Honeywell/Gordon's 1962 design study!

It's intriguing, particularly these comments about the 1401, which hint at a certain lack of confidence/resignation, and perhaps even insinuate that, in the end, the H-200 may not be effective against the 1401: "It also means that IBM can counter (if pressed) by endowing the 1401 with input buffer storage. Surely some time has been found to lay down the order books to design such an addendum."
....
Re this excerpt: the 1401 clock rate was/is 11.5 microseconds, not 11.2, and the original 1403 speed goal had always been 600 lpm, so I wonder how their "conjecture was directly substantiated."??
I'm not sure how 11.2 implies 900 lpm.
1401 users who cared about print performance likely ordered the 1403 print buffer option:

And what was Honeywell/Gordon thinking by proposing slow/unreliable acoustic delay line memory (with a 20-MHz central clock)!!?

I can see how S/360 in 1964 might have shocked Honeywell/the "seven dwarfs." Here, in 1962, it looks like Honeywell was proposing more of the same/cost-reduction; while not preserving compatibility with their existing H400/H800 ISAs (?).

However, little could Honeywell have imagined at the time that IBM was nearly inflicting marketing suicide since they had no plans to emulate the 1401 on the S/360! (until the H-200 was announced in Nov 1963, shocking IBM management/designers.)

Cheers,

- Robert

p.s. You might be interested in my detailed article about the 1401, here:
http://ibm-1401.info/IBM1401_IEEE_SSCS_Mag_Jan2010-100DPI.pdf

On May 9, 2014, at 12:45 PM, Robert Garner wrote:

Rob,

Thx for sharing this document! I look forward to reviewing it.

IBM used I/O DMA in their 700 series and 650. The 1401 intentionally did not in order to achieve their extremely aggressive cost target, monthly entry rental of $2500/month in 1956 dollars. (Btw, its data paths were designed in Paris, in the WWAM prototype.)

Sort7 - Feb 2017
> p.s. You�ll want to start asking Bill how magnetic-tape-based SORT7 worked to replace the unit record sort/merge routine�

Just trying to be a spoil sport ;-))
There was a whole cottage industry that flourished
     writing and selling sorts that beat the IBM sorts.

However, Sort 7 is a very generalized sort, with lots of options and parameters -
Including lots of parameters for the tape label record - the first record on many business tapes.
(It is a good idea to verify that the operator mounted the correct tape reel ;-))
    (Regardless of the label stuck on the reel.)
Possibly the competitive sort vendors were tailoring
     their sorts for particular customer needs ???

Sorting (using either cards or magnetic tape) was a very big deal
    - much of the billed machine time was spent sorting

I'm not exactly sure how to research and back-up the above folk-lore and claim. Suggestions cheerfully accepted ;-))

-Ed Thelen

PS Also technology played a part in the sorting game, and sorting bench marks -
     The IBM 729 tape drives (controller) could not read backward -
     so the famous IBM high speed mag tape rewind was vital.
    
     Other vendors (including General Electric) could read backward -
     so their slower rewind speed was no penalty in a "properly written" sort. :-))
     (In general, you want to read the sort file you have just written, for merging,
     for the next sort pass, for the next merge pass, for the ... ;-)
     (Slower rewind speed was a penalty at the end of some processing,
     taking extra time to get the processed tapes off the few drives
     and mounting tapes for the next function.)
    
     More than you ever wanted, or needed, to know
     http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/1401/C24-3317-1_sort7spec.pdf
     http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/1401/C24-1456-1_1401_sort7.pdf

Alan Kay's 1401 emails - V3

> From: Alan Kay
> Subject: Re: [1401_software] First section features an IBM 402
> Date: February 21, 2012 6:12:07 AM PST
> To: Gary Mokotoff , 'Keith Falkner' , "ed@ed-thelen.org"
> Cc: '1401 Software Team' <1401_software@computerhistory.org>, 'Bill Worthington' , '1401 Hardware Team' <1401_team@computerhistory.org>
> Reply-To: Alan Kay
>
> As far as I can recall, Air Training Command (at Randolf AFB) did not use FARGO or CARGO, in 62-63 when I was there.
>
> But we did have RPG, which I tried several times -- and for a few things it worked well. It was not quite the 4th Gen it needed to be, so it was only useful for some types of problems, and was real quicksand if requirements changed in a way that it couldn't handle. (It was a tribute to IBM's programmers that it would work at all on an 8K 1401.)
>
> By the time I arrived there as an enlisted man programmer, they had evolved a pretty good theory of how to survive using both of their machines -- the other one was a Burroughs 220, a larger more mainframe like computer that was also odd by today's standards (Knuth's experience with a 205 and the 220 led to the MIX machine in his early books).
>
> This solution was essentially trying to create higher-level languages using the macro-generators supplied with each machine. (There has been much discussion of AutoCoder on this thread, and it was quite impressive, especially for conditionally tailoring code sequences during assembly.)
>
> Some of these -- e.g. on the 220 -- would be called "quasi-object oriented" today.
>
> I found out later that -- in the field as a whole -- there was just enough knowledge in 62-63 about how to more easily make real higher level languages to allow us to go beyond macro systems. IBM was terrible at this and it seemed to require enormous numbers of people to do it. We had no contact of any kind with the real research in computer science that was just starting up. And ATC was not set up to have the smart youngsters it used as programmers try to go beyond what the Air Force considered their brief.
>
> When I went to grad school just a few years later I was shocked at what we could have tried to do. And I was especially taken with Val Shorre's Meta II system (done on an 8K 1401 at UCLA in 1963) that would have been a great route to start making higher levels of expression than you could get from macro generators.
>
> Cheers,
>
> Alan
>
> From: Gary Mokotoff
> To: 'Keith Falkner' ; ed@ed-thelen.org
> Cc: '1401 Software Team' <1401_software@computerhistory.org>; 'Bill Worthington' ; '1401 Hardware Team' <1401_team@computerhistory.org>
> Sent: Tuesday, February 21, 2012 5:05 AM
> Subject: RE: [1401_software] First section features an IBM 402
>
> I vaguely recall FARGO . Actually RPG (Report Program Generator) was created to ease the effort of EAM users into using computers. Turning an indicator on in RPG was equivalent to co-selector pickup on a 407.
>
> Gary Mokotoff
>
> From: Keith Falkner [mailto:keithfalkner@gmail.com]
> Sent: Tuesday, February 21, 2012 12:04 AM
> To: ed@ed-thelen.org
> Cc: Gary Mokotoff; Bill Worthington; 1401 Hardware Team; 1401 Software Team
> Subject: Re: [1401_software] First section features an IBM 402
>
> Just for the heck of it, I wonder if your 1401 installation is equipped with FARGO software. The acronym stands for Fourteen-oh-one Automatic Report Generation Operation, and the program is a five-part deck of cards, maybe 700 in all, that effectively functioned as a 407 Emulator. 407 is the "modern" upgrade from the 402 and 403 Electric Accounting Machines. The FARGO programmer would code up cards defining headings, control breaks, calculations to be done, and reports to be printed, and summary cards to be punched. Then the 1401 would simulate the accounting machine and its attached 514 Summary Punch to provide the required reports and punched output. No compilation, just shove in the intermixed FARGO +specifications deck and the data, and stand back.
>
> I think that an experienced 402 programmer and FARGO programmer could study the wiring panel and produce the corresponding FARGO decks with no trouble at all.
>
> I recall that a user contributed a program called CARGO, standing for Condensing After Report Generation Operation, which served as a patch to the final piece of the FARGO deck, and caused a condensed object deck to be punched out. This condensed deck, much less bulky than the combination of FARGO software + specifications, was a convenience for shops that used FARGO a lot.
>
> Finally, I recall someone musing about the System/360 Model 407.
> This mythical machine could be achieved if a System/360 emulated
> a 1401 running a FARGO job! Of course, all this is possible today.
>
> Keith Falkner
> EAM trainee in 1963
> 1401 programmer 1963-????
>
> _______________________________________________
> 1401_software mailing list
> 1401_software@computerhistory.org
> http://mail.computerhistory.org/mailman/listinfo/1401_software
>
>
> _______________________________________________ Begin forwarded message:
> From: Alan Kay
> Subject: Re: [1401_software] Bill Worthington is giving a chalk talk on 1401 AutoCoder Macros
> Date: September 8, 2009 3:47:27 AM PDT
> To: Robert B Garner
> Cc: Robert B Garner , robgarn@mac.com
>
> Sure, why not?
>
> Well, the 1401 was what the Air Force ATC had at Randolph Field in 1962 (along with another pretty idiosyncratic computer, the Burroughs 220). There was an aptitude test "which no one passed" (except a few) and one learned to program the 1401 in a one week intensive course that IBM and a few sergeants conducted. But there was also still a huge PCAM "floor" the size of a football field where most of the accounting and other computational work was done. Both machines had been acquired to gradually replace the PCAM machinery. That is what we did.
>
> The 1401 we had was an 8K one with 6 tape drives, and considerably ingenuity was required to get it to be more automatic. One of the triumphs of Autocoder programming was done by the best guy there - Rachon Andre Douglas - with a little help here and there by the fledgling me: a real batch OS that would fit into the top 1K of the machine. I gained more appreciation for the 1401 as I learned more machines over the next few years (all of which were pretty idiosyncratic, as were most of the hardware organizations back then), particularly the the ability to "craft memory with word marks", and of course the marvelous Autocoder macros.
>
> And I think everyone has fond memories of their first real computer, particularly the first one you got to program in direct machine code (which was the general case back then). FORTRAN was both slow and ugly (in the sense that its lack of meta-features on a small slow machine made it much more difficult to accomplish many tasks than good Autocoder design and programming). Balgol (which ran on the 220) was pretty, but again was not well set up for systems programming on a small machine. And though we learned the B5000 from afar (everything was more than pretty on this machine, and the deep high level language ESPOL was both elegant and powerful) I left active duty to go back to university before the machine actually arrived.
>
> My next machines at the National Center For Atmospheric Research in Boulder (where I worked my way through U of Colo) were the IBM 7090 and a much nicer example of a similar architecture, the Control Data 3600. Then the CDC 160A and finally for that phase, the first version of the CDC 6600 -- which had what we would call today an advanced RISC architecture with fine grained parallelism (multiple execution units for storage, fetching, and arithmetic) and multiple processor organization (1 central CPU and 10 satellite CPUs) far earlier than the term or general notion.
>
> However, the B5000 was (and still is in my opinion) the greatest single hardware design ever done, and today's organizations are quite silly when compared with the B5000. We used a "meta-version" of the B5000 architecture at Xerox PARC on the Alto and subsequent machines, and it was one of the big factors in PARC's success.
>
> Cheers,
>
> Alan
>
> From: Robert B Garner
> To: Alan Kay
> Cc: Robert B Garner ; robgarn@mac.com
> Sent: Monday, September 7, 2009 11:22:40 PM
> Subject: Re: [1401_software] Bill Worthington is giving a chalk talk on 1401 AutoCoder Macros
>
>
> Alan,
>
> I was thinking that given your interest and clear attachment to the 1401 (something I would never had expected in a million years!*), that you would enjoy having your name listed with the other donors who have supported the project from a monetary perspective (including Steve Wozniak, who was excited about the 1401 project when he visited a couple years ago, esp with opportunity of kids learning the basics of computers by working on/using it.) It's also inspiring to some of the (software) folks on the restoration team that you're so enthusiastic about it.
>
> Would you consider an exception to your anonymous donor rule?
>
> - Robert
>
> * I had fallen out of my chair when I saw in the Dealers of Lightening book that your first computer was a 1401. I think a 1401 as it was dealt to you back then would have stopped me in my tracks! As a grade school kid, we had access to a GE time-sharing system, then a Sigma-7, PDP-10, etc.. But we were just young users having fun! ;-)
>
>
> IBM Almaden Research Center, San Jose, CA
> Office: 408-927-1739
> Mobile: 408-679-0976
> robgarn@us.ibm.com
>
>
>
>
> Alan Kay
>
> 09/06/2009 02:29 PM
>
> To
> Robert Garner
> cc
> Robert Garner , Robert B Garner/Almaden/IBM@IBMUS
> Subject
> Re: [1401_software] Bill Worthington is giving a chalk talk on 1401 AutoCoder Macros
>
>
>
>
>
>
>
> I'm happy to kick in $100. But I always donate anonymously. So tell me where to send the check and to whom.
>
> Cheers,
>
> Alan
>
> From: Robert Garner
> To: Alan Kay
> Cc: Robert Garner ; Robert B Garner
> Sent: Sunday, September 6, 2009 2:22:47 PM
> Subject: Re: [1401_software] Bill Worthington is giving a chalk talk on 1401 AutoCoder Macros
>
> Alan,
>
> Did you see my email asking if you might be able to contribute to the 1401 restoration fund? I'm creating the donor sign now. Say $100 ?
>
> Thanks!
>
> Robert
>
> Sent from my iPhone
>
> On Sep 5, 2009, at 10:44 AM, Alan Kay wrote:
>
> Oh boy, I wish I could go to this. AutoCoder was my favorite "thing" in good old 1962.
>
> Cheers,
>
> Alan
>
> From: Ed Thelen
> To: 1401 Software Team <1401_software@computerhistory.org>
> Cc: 1401 Restoration Team <1401_team@computerhistory.org>
> Sent: Saturday, September 5, 2009 10:19:03 AM
> Subject: [1401_software] Bill Worthington is giving a chalk talk on 1401 AutoCoder Macros
>
> Bill Worthington is giving a chalk talk on 1401 AutoCoder Macros
> this coming Wednesday, after lunch (1:00),
> meet in the 1401 room for class room assignment.
>
> I am CCing the "Restoration Team" incase we can get anyone
> to "defect", or increase their pay by going, to software ;-))
>
> A donation of your first born is requested at the door.
>
>

---------------------------

Alan Kay's 1401 emails - V5
Begin forwarded message:
> From: Alan Kay
> Subject: Re: Fortran II, Fortran IV, or COBOL? RE: Rope > Date: February 10, 2014 7:53:08 PM PST
> To: "ed@ed-thelen.org" , Ronald Mak
> Cc: "'Stan Paddock, '" , 'Robert Garner' , 'Fausto Saporito' , 'Van'
> Reply-To: Alan Kay
>
> PL/1 requires quite a lot of careful words to criticize it as deeply as the effort deserved. Maybe on another day.
>
> However, it is easy to praise the B5000 (I'll leave out quite a bit here).
>
> The first public paper about this architecture was written by Bob Barton in 1961 "A new approach to the functional design of a digital computer" for the Western Joint Computer Conference.
>
> What today is sometimes called a "byte-coded virtual machine" for a higher level language (such as the ones we did at PARC, how Java was first implemented, and many other dynamic and semidynamic languages) was directly executed by the hardware of the B5000. There was nothing like "assembly code" and all programming was done in one of several higher level languages, especially Algol, and for systems programmers, an extension of Algol called ESPOL.
>
> Code was made of 12 bit bytes, contained no addresses, and was reentrant. The "environment" was "granted" to code but could not be seen by code unless the environment contained that access route. This was the first computer to have the ideas of "capabilities". The words of the machine were contained in swappable segments that were controlled by "descriptors" which were extended protected pointers that contained base bounds and swapping information. It was not possible for user programming to forge one of these descriptors.
>
> The environments were essentially the instance variables and properties of objects, and so the machine was ideally suited for Simula when it came along ca 1965-66. The main improvement we made was to factor out the shared methods so that most objects could be small.
>
> The machine had processes made of stacks and had automatic stack frames for procedures with automatic subroutine calling and process switching. (Even the 1st B5000s had multiple processors, etc., so real multiple threads were running o)
>
> The architecture had a very long life because it was virtually uncrashable and was very easy to program.
>
> We emulated a very similar architecture for our languages at PARC using microcode on the many different computers we designed and built there. We had the honor to fix the only drawback in the original design (which was that it really needed microcode to help deal with learning curves. Barton had realized that before PARC and was already working on a microcoded emulation machine (the B1800) when I was in grad school.
>
> It's worth comparing the original genius designs with the more parsimonious adaptations we did (because we wanted to do all of this stuff on a personal computer rather than a mainframe).
>
> My summing up of the B5000 was "7 out of the 10 best software ideas implemented and some invented in hardware".
>
> Bob Barton did get the first Eckert-Mauchly award from the ACM, but they went through almost 4 decades without giving a Turing to a hardware designer and Bob was allowed to die without getting one (which was completely ridiculous).
>
> Cheers,
> Alan

Begin forwarded message:


> From: Alan Kay
> Subject: Re: Fortran II, Fortran IV, or COBOL? RE: Rope
> Date: February 10, 2014 3:50:27 PM PST
> To: "ed@ed-thelen.org" , Ronald Mak
> Cc: "'Stan Paddock, '" , 'Robert Garner' , 'Fausto Saporito' , 'Van'
> Reply-To: Alan Kay
>
> COBOL was a great idea ... and had some excellent people working on it ... it just needed to be allowed to evolve as they learned more about programming and programmers -- instead its very popularity made it difficult to bring forward, and like many languages it failed to keep up in power of expression, but was kept alive anyway.
>
> I have occasionally gotten students to go back to COBOL and think about what it should have turned into ...
>
> (A logical next step would be to incorporate various kinds of problem solving engines, etc. And another would be to shield data both from formats and from what was wrong about relational data bases. One could imagine a much more comprehensive set of descriptions and namings in the declarative divisions ...)
>
> Cheers,
>
> Alan

Begin forwarded message:


> From: Alan Kay
> Subject: Re: [1401_software] Fwd: Fortran II, Fortran IV, or COBOL? RE: Rope
> Date: February 9, 2014 7:14:01 PM PST
> To: Robert Garner
> Cc: Ron Mak , Ed Thelen , "Van.Snyder@jpl.nasa.gov" , Robert B Garner
> Reply-To: Alan Kay
>
> Hi Robert
>
> I don't think so.
>
> I did my Air Force stint between my second and third year of college, had been doing a lot of science and math from a young age, and was a double major in math and biology when the "junior birdman" interlude happened starting in 1961.
>
> Looking back -- and I'm sure most of the people who worked on computers back then will agree -- it was the variety of approaches that was striking. Part of this was from general experimentation in both hardware and software, and part was that one generally learned to program in machine code for most of the machines one worked with back then, and this required understanding their architectural approachs.
>
> The first programming I did was PCAM machine boards (mostly 407 and 101, etc.), and that was interesting. The first three programmable computers I learned -- 1401, Burroughs 220, and Burroughs B5000 -- were all quite different. The next two were somewhat similar and more orthodox -- IBM 7094 and CDC 3600 -- but the next one -- CDC 6600 -- was quite unusual again.
>
> I stated in the "Early History of Smalltalk" that I didn't understand or appreciate the really deep features of the B5000 when I learned it in the AF, I was taken with the byte codes and the stack, etc. It wasn't until I went to grad school in 66 after seeing Sketchpad and Simula that I realized just how radical and amazing the B5000 was.
>
> Bob Barton happened to be at Utah when I was in grad school but he didn't like to talk about the past. However one could get him to talk about "possibilities for the future" and that would reveal a bit about the past. (I actually found out more by talking with his wife Wanda ...)
>
> I was in pure math -- algebras -- and the idea of generic operations over abstract types is central to why algebras were invented. This idea was present in a file system written for the B220 that was there when I arrived, it was inherent in the B5000 (but I didn't see it used), and it was a direct principle in Sketchpad (also ca 1962).
>
> One of the most interesting -- to me anyway -- juxtapositions is to compare the B5000 against any HW or SW of the early 60s -- the distance in concept and power is vast and breathtaking.
>
> Cheers,
>
> Alan
>
>
> From: Robert Garner
> To: Alan Kay
> Cc: Ron Mak ; Ed Thelen ; Robert Garner ; Van.Snyder@jpl.nasa.gov; Robert B Garner
> Sent: Sunday, February 9, 2014 12:59 PM
> Subject: Re: [1401_software] Fwd: Fortran II, Fortran IV, or COBOL? RE: Rope
>
> Alan,
>
> Unfortunately, I don't believe anyone has found the 1401 RPG code.* :-(
>
> A question I've been meaning to ask: Given that your first programming experience (the 1401) exposed you to opcodes (functions ;-) that accepted operands of arbitrary length ("types" ;-) , was this an early nudge towards polymorphic thinking (albeit extremely limited)?
>
> Of course, the B5000 was remarkably elegant in this regard, and there were many other variable length computers around at that time, 705, etc.
>
> Cheers,
>
> - Robert
>
> p.s. Here's the main software that Paul Pierce kindly read from our tapes stored in the basement with the Connecticut 1401: http://ibm-1401.info/CT-TapeInventory.html
>
>> Anyone come across the IBM RPG for the 1401? This was used for a small percentage of programming tasks at USAF ATG in 1962-63 .... I wrote several of them ...
>>
>> Cheers,
>>
>> Alan
>>
>> From: Robert Garner
>> To: 1401_software@computerhistory.org
>> Sent: Sunday, February 9, 2014 12:16 PM
>> Subject: [1401_software] Fwd: Fortran II, Fortran IV, or COBOL? RE: Rope
>>
>> fyi - Sharing this thread on writing new 1401 software with our 1401 software alias, <1401_software@computerhistory.org>
>>
>> With two working 1401s, there's been more interest in new program development, first on ROPE, then the 1401s.
>> (We also need more demo program developed for the 3-4pm live demo sessions every Wednesday... :-)
>>
>> Begin forwarded message:
>>
>>> From: Ronald Mak
>>> Subject: RE: Fortran II, Fortran IV, or COBOL? RE: Rope
>>> Date: February 9, 2014 11:54:34 AM PST
>>> To: ed@ed-thelen.org, 'Van' , 'Bob Feretich'
>>> Cc: "'Stan Paddock, '" , 'Robert Garner' , 'Fausto Saporito'
>>>
>>> I still have the punched cards of a COBOL program that I wrote for the 1401 back when I was still in high school. I recall that it took over 40 minutes to compile! (I don't even remember if the program worked. I was only able to compile it once.)
>>>
>>> I actually taught a class on COBOL to other high school students. I taught FORTRAN classes at Stanford back in the 70s.
>>>
>>> I'm currently teaching a class called Programming Language Paradigms at SJSU (http://www.cs.sjsu.edu/~mak/). To give my students a better appreciation for today's languages, I wanted their first assignment to be to write a COBOL program. Alas, I couldn't find a free compiler that was easy to download, configure, and configure that worked on Windows, Linux, and the Mac. (The GNU COBOL compiler was not so easy to compile, especially on Windows). So their first assignment was to write a FORTRAN IV program instead using either the WATCOM or GNU FORTRAN 77 compilers.
>>>
>>> -- Ron
>>>
>> Begin forwarded message:
>>
>>> From: Van Snyder
>>> Subject: Re: Fortran II, Fortran IV, or COBOL? RE: Rope
>>> Date: February 9, 2014 11:32:26 AM PST
>>> To: ed@ed-thelen.org
>>> Cc: Bob Feretich , "Stan Paddock," , "Ron Mak," , Robert Garner , Fausto Saporito
>>>
>>> On Sun, 2014-02-09 at 02:00 -0700, ed@ed-thelen.org wrote:
>>>>>
>>>> also, at the time there was a 2,000 character
>>>> tape record limitation in the 729 Emulator -
>>>> Bob Feretich - is that still a limitation?
>>>
>>> I wrote a program that splits long tape records, and another one that
>>> recombines them. The one that splits writes the one that recombines on
>>> the tape first. So you can boot from the tape with the split records,
>>> and it writes a tape with original-length records.
>>>
>>> The intent was that you would split records in SimH, then boot the
>>> split-record tape through the emulator, and write a real tape with
>>> original-length records. Then you could boot from the real tape. I
>>> tried this out, but on that day the TAU and real tape drives didn't
>>> cooperate.
>>>
>>>> Is it practical to rectify the limitation?
>>>> Port to a machine with more memory ??
>>>
>>> I was recently given five Rabbit computers. They're about the size of
>>> two postage stamps. They have prototyping boards about the size of a
>>> postcard, including ethernet. The guy who gave them to me says there is
>>> an excellent software-development environment to program them in C,
>>> including complete network stacks. I don't know whether they have
>>> adequate I/O. Maybe some of the parallel stuff that's done in the
>>> emulator could be converted to serial with shift registers and
>>> jam-transfer buffers. The Rabbit is plenty fast to handle that. I can
>>> send one to Bob, along with a copy of the software development CD, if
>>> he's interested.
>>>
>>> The guy who gave them to me is enthusiastic about XMOS computers, which
>>> have much more I/O capability than Rabbits. IIRC, XMOS was offering
>>> development kits for about $49. Maybe they still are. XMOS also offers
>>> excellent software development support. I can ask about them, if Bob is
>>> interested.
>>>
>>> Van
>>>
>>> From: ed@ed-thelen.org [mailto:ed@ed-thelen.org]
>>> Sent: Sunday, February 09, 2014 1:00 AM
>>> To: Van; Bob Feretich
>>> Cc: Stan Paddock, ; Ron Mak, ; Robert Garner; Fausto Saporito
>>> Subject: Fortran II, Fortran IV, or COBOL? RE: Rope
>>>
>>> > Would you do this using Autocoder, Fortran II, Fortran IV, or COBOL?
>>>
>>> OH !!!
>>> Now that the two 1401s are restored
>>> and being legally shown to museum visitors,
>>> "we" might re-expand our horizons -
>>>
>>> In 2009, Van Snyder mentioned that
>>> FORTRAN IV and COBOL might be available -
>>> http://ibm-1401.info/LangProcTape.html
>>>
>>> also, at the time there was a 2,000 character
>>> tape record limitation in the 729 Emulator -
>>> Bob Feretich - is that still a limitation?
>>> Is it practical to rectify the limitation?
>>> Port to a machine with more memory ??
>>>
>>> Googling the 1401 web site brought up some applications
>>> http://www.ibm-1401.info/K-Falkner-MCDI02.html
>>>
>>> Just thinking out-loud ;-))
>>>
>>> Ed Thelen
>>>
>>> -------- Original Message --------
>>> Subject: Re: Rope
>>> From: Van
>>> Date: Sat, February 08, 2014 2:40 pm
>>> To: Fausto Saporito
>>> Cc: Ed Thelen , "Stan Paddock,"
>>> , "Ron Mak," , Robert
>>> Garner
>>>
>>> Fausto Saporito wrote:
>>>> Hello all,
>>>>
>>>> thanks a lot!
>>>> I would rewrite a program I found to do some matrix calculation to approximate a given matrix using a specific set of "basic" matrices. (it refers to the Solovay-Kitaev theorem).
>>>> Now because there're a lot of matrices to use, I want to store them on a tape, and I need four big arrays, so it means four tapes.
>>>>
>>>> Oh yes... they are complex matrices :)
>>>>
>>>> So let's see if I can do that... it should be quite amazing :)
>>>
>>> Would you do this using Autocoder, Fortran II, Fortran IV, or COBOL?
>>>
>>> Regards,
>>> Van
>>>
>>>>
>>>> regards,
>>>> Fausto
>>>>
>>>>
>>>>
>>>> 2014-02-08 9:04 GMT+01:00 :
>>>>
>>>> Fausto,
>>>>
>>>> I have added text about adding peripherals to a ROPE simulation.
>>>>
>>>> http://ibm-1401.info/1401SoftwDevel.html#Peripherals
>>>>
>>>> The code in the background is a tape sort program
>>>> that I wrote and lost for a while -
>>>> note the tape rewind and I/O instruction formats ;-))
>>>>
>>>> (This code looks like a mess because I am changing the
>>>> instructions in memory at run-time so that one tape subroutine
>>>> can write to all tape units - idea stolen from SORT7 listing ;-))
>>>>
>>>> Good luck, let us know how you are doing :-))
>>>>
>>>> Ed Thelen
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: Rope
>>>> From: Fausto Saporito
>>>> Date: Fri, February 07, 2014 4:36 pm
>>>> To: Stan Paddock
>>>> Cc: Ed Thelen
>>>>
>>>> Hello all,
>>>>
>>>> thanks a lot for your replies!
>>>> I'm looking forward for the new release.
>>>>
>>>> thanks,
>>>> Fausto
>>>>
>>>>
>>>>
>>>> 2014-02-08 0:45 GMT+01:00 Stan Paddock :
>>>>
>>>> There was a way to do that.
>>>> I just checked and it is not there in my current copy.
>>>> I am not sure why.
>>>> But I am planning on getting back to ROPE later this Spring.
>>>> I will let you know when the new edition comes out.
>>>>
>>>> Stan Paddock
>>>>
>>>>
>>>>

---------------------------

Alan Kay's 1401 emails - V7
Begin forwarded message:
> From: Alan Kay
> Subject: Re: Vienna's Meta-IV (was Fw: Crossing paths?? Konrad Zuse
> Date: August 27, 2014 10:20:30 AM PDT
> To: Robert B Garner
> Cc: Ed Thelen , Marc Verdiell , Robert Garner , "carl.claunch@gartner.com"
> Reply-To: Alan Kay
>
> It's a tough problem, and -- with a number of brave attempts, etc. -- I don't know of anyone/group that has been able to find a great balance between the three pillars of computing (engineering, math, and science) to do justice to what is needed.
>
> This leaves prejudice -- or at least mine -- and I've tended to like what McCarthy did in the 50s (pretty much before anyone) when he was thinking out Lisp and wanted to define it in itself. He did use a few ideas from mathematicians, but the cool thing about Lisp was that it was both a practical programming language of considerable power made from a few basic powerful ideas *and* a very compact metalanguage for thinking about and defining semantics of computations. For example the "table" construct that VDL used as an abstraction for storage was definable in a few lines of the basic five function Lisp and then used to define its own interpreter. The Lisp version was still a kind of abstraction, but it was also formally defined and used from the even simpler kernel of Lisp. (I think John was "smarter than most people", as Dave Evans used to say.)
>
> Cheers,
>
> Alan

Begin forwarded message:


> From: Alan Kay
> Subject: Re: Vienna's Meta-IV (was Fw: Crossing paths?? Konrad Zuse
> Date: August 27, 2014 7:25:59 AM PDT
> To: Robert B Garner
> Cc: Ed Thelen , Marc Verdiell , Robert Garner
> Reply-To: Alan Kay
>
> Hi Robert
>
> I have very vague memories of VDL and Meta-IV.
>
> The problem -- as we saw it back then -- was that the the VDL approach pretty much brought nothing worthwhile to the table (though it did generate many papers). It was basically just way too complicated -- hugely feature laden and much of it ad hoc -- to bring any theoretical or pragmatic clarity to the problems of designing, defining and explaining programming languages.
>
> In the end one would like something that helps humans to reason and make, and for computers to run - and VDL (again in our opinion) did not deliver. There were wry observations about how much VDL abstractly resembled another IBM "concoctive concatenation" -- PL/1 -- in so many ways.
>
> However, I don't think there is yet a really good solution today for what VDL was trying to do, though what does exist is better and simpler in many respects. There are certainly much better (and much neater and smaller) approaches today for making programming languages (for example Alex Warth's OMeta and Ohm). And many of these have more clarity in many areas. Still, I think a really good approach to understandable semantics that allows reasoning to be straightforward is yet to happen.
>
> Cheers,
>
> Alan

Begin forwarded message:


> From: Alan Kay
> Subject: Re: A Burroughs story (Re: [1401_software] Fwd: Alan Kay on Early Computers, B5000, PL/1, and COBOL)
> Date: February 11, 2014 7:45:08 AM PST
> To: Jay Jaeger , "1401_software@computerhistory.org" <1401_software@computerhistory.org>
> Reply-To: Alan Kay
>
> Lots of different dates (even "eras" and "different species") here.
>
> The B5500 was ca 1964, the 6500 ca 1970, the 8500 (as I recall) was from the military part of Burroughs in Paoli, Pa and was an attempt to hybridize their military B825 with some of the "California ideas" of the B5500 along with some thin-film in various parts of the memory for speed. Did they ever deliver even one of these?
>
> Cheers,
>
> Alan
>
>
> From: Jay Jaeger
> To: 1401_software@computerhistory.org
> Sent: Tuesday, February 11, 2014 6:19 AM
> Subject: A Burroughs story (Re: [1401_software] Fwd: Alan Kay on Early Computers, B5000, PL/1, and COBOL)
>
> I took one of my earliest CS classes on a B5500 at U. Wisconsin. In a
> class normally taught in FORTRAN and with pretty simplistic assignments,
> our final two assignments were a very simple stack machine emulator with
> an assembler, and then a recursive descent compiler for a tiny subset of
> ALGOL.
>
> The professor I took an advanced systems programming class from in grad
> school (Fitzwater) told the following story wherein Burroughs tried to
> cover up the problems they had with the development of the B8500. After
> months and months of delay, U. Wisconsin demanded some visible sign of
> progress, and Burroughs invited them to a demonstration. During the
> apparently successful demonstration, one of the attendees reportedly saw
> an unexplained cable going somewhere. It turned out that the somewhere
> was a B6500 (if I remember the story correctly) that was providing some
> some sort of computational assist to the B8500. That ended things, with
> Burroughs instead loaning (I think) UW a second B5500 which UW used
> until it upgraded its Univac 1108 to an 1110. Fitzwater said that some
> in the CS department felt like they should acquire the B8500 anyway,
> owing to its advanced architecture, though I expect such a move would
> have been untenable from a State procurement perspective. The Univac
> 1110 was probably computationally speaking the fastest machine in the
> state until Wisconsin DOT acquired an Amdahl 470 a few years later.

---------------------------

Alan Kay's 1401 emails - V8

on the c compiler project...

Begin forwarded message:


> From: Alan Kay
> Subject: Re: [1401_software] Storing I-Address register
> Date: December 3, 2014 4:29:27 AM PST
> To: Luca Severini
> Cc: "1401_software@computerhistory.org" <1401_software@computerhistory.org>
> Reply-To: Alan Kay
>
> Hi Luca
>
> As I mentioned, BCPL has an interesting history because of its ease of portability and its approach to allowing high-level systems programming to be done in it. It was a mainstay at Lincoln Labs during the mid to late 60s, was used by Strachey and Stoy to write the OS 6 tiny operating system (would be interesting on a 1401), and was used by the Computer Science Lab at Parc for many of their projects (e.g. the first version of Microsoft Word was done at Parc in BCPL). A language derived from BCPL which was used for small machines at CMU in the 60s was called Bliss (Bill Wulf and Chuck Geschke).
>
> I would urge anyone working on a 1401 to bootstrap Meta II and its VM, and then use it to make something like VALGOL or BCPL.
>
> The OS 6 papers are worth reading (they are online).
>
> The 1401 was my first machine (I had spent a little time wiring plugboards before this), and I didn't have any perspective to see how idiosyncratic it was (even in an era where there was a much wider variety of computer architectures one had to learn). It just was what it was, and one had to make things work on it.
>
> At that time, I didn't appreciate "meta-thinking" -- on the contrary, almost everything about writing 1401 programs at Randolph AFB in the early 60s was about optimizations, some of them really fragile and dangerous, to deal with the rather large problems that were to be solved on an 8K machine (that was thought of as "small and slow" even by the standards of 1961). The larger B220 was also slow, especially its tape drives, and again it had an architecture that by today's standards was "unusual".
>
> I should mention that the "meta" that *did* exist -- which was quite interesting and powerful -- was the Autocoder macro system, and we spent quite a bit of effort writing "tailored macros" that would optimize functions upon expansion in the assembly process. This was good, and did help level of expression, but it missed the deeper meta-game.
>
> However, a few years later in grad school (with a few more kinds of computers in between), I started seeing what could be accomplished by "meta" and especially having a relatively simple and powerful tool -- like a Meta II, or the "Tree Meta" that the Engelbart folks used -- to deal with form. I could see that many parts of past struggles with "hardware that had little to do with software or programming" (which was most hardware of the day) would have been much easier to deal with if I had BCPL or Meta II, etc. in my utility belt. The heuristic of quickly writing an intermediate system to escape gratuitous complexities came late to me.
>
> Cheers
>
> Alan
>
> From: Luca Severini
> To: Alan Kay
> Cc: Jay Jaeger ; "1401_software@computerhistory.org" <1401_software@computerhistory.org>
> Sent: Wednesday, December 3, 2014 3:51 AM
> Subject: Re: [1401_software] Storing I-Address register
>
> I found the article "BCPL: a tool for compiler writing and system programming" on the ACM digital library.
> Do you know any other book that could be useful for this or similar projects on the 1401?
> Thank you!
>
> Luca
>
>
>
>
> On Dec 3, 2014, at 3:38 AM, Alan Kay wrote:
>
>> Oh, I know Ron, he's a good guy. A good way to "establish a beachhead" for a higher level language on the 1401 is to first write an interpreter for a byte coded virtual machine. This can be used as a target for a variety of projects -- compilers, and meta-compilers (like Meta II) -- and lots of things can be accomplished before worrying about the tricky problems of generating efficient native code for the 1401.
>>
>> It's a good approach for a compiler *on* the 1401 itself or a cross-compiler to the 1401 (and take a look at the VALGOL example in the Meta II paper, to see how much can be accomplished how quickly via this route). The wikipedia article on Meta II has a link to an online implementation you can try things on ...
>>
>> This follows a long useful tradition going back to at least the beginning of the sixties, and the wrestling with not just FORTRAN and COBOL on small machines, but especially Algol 58, and Algol 60. (Another basic point is that many of the apparent speed losses one incurs from interpretation can be made up many times over if you don't have to overlay -- Engelbart *speeded up* their system on the SDS-940 when they moved from a compiler to an interpreter because so much more would fit into a working set, and swapping to the drum was minimized ....)
>>
>> And, of course, the B5000 very early did one of the first (maybe the first) byte-code VMs except it was a RM (it *was* the machine's instruction set).
>>
>> A classic book is by Randall & Russell that chronicles an early successful implementation of Algol-60 (on the KDF9 actually) via a parallel implementation of interpreter and compiler. As I mentioned, this was the route that BCPL took, that Meta II took, the classic Euler implementation by Wirth and Weber, etc.
>>
>> Cheers
>>
>> Alan
>>
>> From: Luca Severini
>> To: Alan Kay
>> Cc: Jay Jaeger ; "1401_software@computerhistory.org" <1401_software@computerhistory.org>
>> Sent: Wednesday, December 3, 2014 3:19 AM
>> Subject: Re: [1401_software] Storing I-Address register
>>
>> Hi Alan,
>>
>> My prof is Ron Mak who originally wrote the ROPE developer environment (Autocoder assembly) for the 1401.
>> The idea was mine. Instead to create an useless compiler nobody will never use I asked to wrote the small-c compiler for the 1401.
>> Sure is not an easy task but is very interesting and I'm having fun.
>> Moreover I got a chance to get comments and suggestions from expert people like you, Van Snyder, Stan Paddock, Jaeger , Albaugh,and
>> some more I don't write down just to stay brief...
>> In any case now is too late to switch on something else. Perhaps next semester but only after this compiler is completed.
>> Thanks for your suggestion anyway.
>>
>> Luca
>>
>>
>>
>>
>> On Dec 3, 2014, at 2:53 AM, Alan Kay wrote:
>>
>>> Hi Luca
>>>
>>> As your prof about doing BCPL instead ... it's a nice compromise language, and could be a very good fit to the 1401 (and especially for your class project).
>>>
>>> Cheers
>>>
>>> Alan
>>>
>>> From: Luca Severini
>>> To: Alan Kay
>>> Cc: Jay Jaeger ; "1401_software@computerhistory.org" <1401_software@computerhistory.org>
>>> Sent: Wednesday, December 3, 2014 2:32 AM
>>> Subject: Re: [1401_software] Storing I-Address register
>>>
>>> Hi Alan,
>>>
>>> It's the final project for my Compiler Design class and must be C or, more precisely, Small-C.
>>> However I will give a look to it. Everything suggestion that can help is welcome. Thanks!
>>>
>>> Luca
>>>
>>>
>>>
>>>
>>> On Dec 3, 2014, at 2:26 AM, Alan Kay wrote:
>>>
>>>> Just a suggestion: before trying C, I'd suggest you look at its ancestor BCPL by Martin Richards. It is set up to bootstrap from one computer to another, and was made to have an Algolic language that could be used to write systems. The bootstrap is done via a simple byte-code interpreter (that you write), it has its own compiler written in itself, and you can modify the code generators -- etc.
>>>>
>>>> Cheers,
>>>>
>>>> Alan
>>>>
>>>> From: Luca Severini
>>>> To: Jay Jaeger
>>>> Cc: 1401_software@computerhistory.org
>>>> Sent: Tuesday, December 2, 2014 8:34 PM
>>>> Subject: Re: [1401_software] Storing I-Address register
>>>>
>>>> I'd like to keep the decimal characteristic of the 1401 and make my life easier
>>>> not having any real programming experience on 1401.
>>>>
>>>> For the data types I imagined something like this:
>>>>
>>>> BOOL DCW 0 * 0-1 0-1
>>>> CHAR DCW 000 * 0-255 00-FF
>>>> SHORT DCW 00000 * 0-65535 0000-FFFF
>>>> INT DCW 00000 * 0-65535 0000-FFFF
>>>> LONG DCW 0000000000 * 0-4294967295 00000000-FFFFFFFF (later)
>>>>
>>>> Luca
>>>>
>>>> On Dec 2, 2014, at 8:30 PM, Jay Jaeger wrote:
>>>>
>>>> > An alternative you could consider is actually using the ASCII collating
>>>> > sequence for strings, and writing your own compare routines, and using
>>>> > binary for for end of string.
>>>> >
>>>> > Similarly, you could consider having 12 bit short numbers, binary
>>>> > encoded in two characters, and 18 or 24 bit longs. Of course, you would
>>>> > not be able to use the 1401 to actually add or compare or anything like
>>>> > that.
>>>> >
>>>> > The result would be pretty close to threaded code, as others have
>>>> > described - everything would turn into subroutine calls.
>>>> >
>>>> > On 12/2/2014 6:18 PM, Luca Severini wrote:
>>>> >>
>>>> >> On Dec 2, 2014, at 4:16 PM, Michael Albaugh wrote:
>>>> >>
>>>> >>>
>>>> >>> On Dec 2, 2014, at 4:10 PM, Luca Severini wrote:
>>>> >>>
>>>> >>>> I'm using in part that approach.
>>>> >>>> For example for the bitwise operations.
>>>> >>>> I created some routines and, or, xor, shl (shift left), shr (shift right).
>>>> >>>
>>>> >>> _technically_ you will not need separate right-shifts for signed and
>>>> >>> unsigned. In practice, your users will tar and feather you for using
>>>> >>> a non-sign-extending right-shift for signed ints. One compiler for the
>>>> >>> x86 did that (it is/was legal, as right-shifting a negative value is/was
>>>> >>> undefined behavior). You should have heard the swearing!.
>>>> >>>
>>>> >>>> Same for some comparison like >= and <=
>>>> >>>> Probably I need to do something also for strings like C intend them...
>>>> >>>
>>>> >>> Like I said, you are going to run into the issue of '\0' being either
>>>> >>> a blank (space) or flame-bait.
>>>> >>
>>>> >> I was thinking to use the unused bitzone as '\0'...
>>>> >> What do you think?
>>>> >>
>>>> >>>
>>>> >>> -Mike
>>>> >>>
>>>> >>

---------------------------

Braille from a 1403 ?? - from Jim Strickland July 28, 2014
as seen in "Volunteer Information Exchange"
Volume 4 Number 8 July 28, 2014
From a Bell Labs visitor:
The 1403 print hammers strike with a roughly equal pressure, so when the character is a �W�, the pressure is spread over a large area but when the character is a period, the pressure is much higher causing the period to create a little dimple in the paper.

A blind programmer at Bell Labs wrote a program to translate his compiler output into multi-line Braille characters and reversing the output from left-to-right to right-to-left. Then he would turn the paper over and read the dimples.

A Haanstra story - from Charles Branscomb, July 25, 2014
Robert

I assume you recall my story about John from the "1401 story". In early 1961 when I had moved to division HQS, John was division VP of Development. He asked me to go with him on a Friday visit to the Kingston, NY Lab (about 2 hour drive) and all the way up and back he probed me on how the 1401 handled Input/Output. Monday AM his secretary called me what I did to her boss on Friday. After the weekend John had showed up with some 14 to 18 Executary "belts" (The IBM OPD recorder used belts instead of tapes giving random access to recordings) to be transcribed. They represented the design of a multiplexor front end for the 1401.

John was not only a powerhouse intellectually but he was powerful physically as well. I still vividly remember being in a meeting with John and the VP of Manufacturing for the division (Bud Thue) where John was demanding that 1401 production for the first year be doubled. He had a habit of cupping his hand and pounding on the conference table - I believe the room actually shook when he did that. John won and production was doubled.

You have got some good insights into the Development area activity after Honeywell announced the H200. It is unfortunate That Jim Desell is no longer living. Jim was Systems Engineering Manager in the Eastern Region when H200 was announced and he could have personally provided the Marketing division activity. When he found out that Endicott engineers were skeptical that Liberator would work, Jim found a way to get into a Honeywell customer demonstration and saw that he did in fact work. He then went to Endicott to make sure there was no misunderstanding and demand that development respond. I was on Vin Learson's staff while this was going on and remember interacting with Jim about H200 and Liberator but I do not remember the specifics.

About a dozen years later Jim and I became very good friends in the General Systems Division where he was head of Marketing and I was head of Development and Manufacturing. As I think you know GSD re-established IBM leadership in the middle to low end of the product line. I read recently that IBM world wide sold over 250,000 System 32/34/36/38s.

I did not mean for this to get so lengthy - I hope some of it is of interest to you.

Chuck

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

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

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

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

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

Frank

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

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

This 2 hour presentation was done at the IBM Computer Museum where they rehabed two IBM 1401s and told that story as part of the presentation. See it at http://www.youtube.com/watch?v=FVsX7aHNENo. See the photo attached.

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

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

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

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

Milton

Milton Thrasher
941 966-9172

Early ?1st? 1401 Application - from Milton Thrasher June 20, 2011
Best of all was my week or 10 days with the IBM 1401 Development team under Fran Underwood. I was able in a matter of a few days program a Telephone Directory Billing application that with the same deck of card produced print slips for the typesetters in the 22 yellow page directories of NJ Bell Telephone.

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

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

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

You probably know that Fran Underwood recently had another birthday.

Milton Thrasher

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

Good Day, Gentlemen

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

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

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

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

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

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

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

Regards

Simon Barratt

-------------------------

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

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

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

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

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

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

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

Cheers,

Alan

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

1401 software folks,

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

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

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

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

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

On Feb 14, 2008 at 12:01 AM, Robert Garner wrote:
I found the 1964 ACM paper "META II a syntax-oriented compiler writing language" by D V Schorre here: http://portal.acm.org/citation.cfm?id=808896

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



NOPUN DCW @0@
Usually, during initialization, we had
MCW @2@,NOPUN
but in October, we had instead
MCW @4@,NOPUN
The above code was executed once.

Then, when some cards were needed, we had
(logic to create the card)
HITIT P
   S    @1@,NOPUN
   MZ  @0@,NOPUN
   C    @0@,NOPUN
   BU HITIT
So how did we get two cards in, for example March? NOPUN counted from 2 to 1 to 0, giving us two cards. Next time through, NOPUN counted to -1 and had its zone stripped, and then it counted back to zero, again giving us two cards.

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

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

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

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

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

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

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

Keith

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Story:

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

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

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

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

"Slight of hand ;-))" from Jud McCarthy May 1, 2005
Here is an interesting 1401 Development story from Byron Rucker (1401 Development Engineer) that involves B.O.Evens and Chuck Branscomb. Regards ----- Jud

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

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

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

We got two very early 729 tape drives (Serial No.'s 2 and 7) off the 729 tape line. Apparently they were delivered to the dock in the upper building, but Branscomb decided they must be for the 1401 so they got moved (late at night) to the lower building.

I understand B. O. Evans was on the line with Poughkeepsie trying to determine when he was going to get his tape drives for the 7070 program. We had tapes up and running very early. I do not remember the A, B, C model designation.

Byron

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

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

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

Cheers,

Alan

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

My Early Days With IBM and Sorbus - by Howard Oels

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

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

Robert Garner asked about running the Mod 40 in emulation mode

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

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

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

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

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

Interesting items:

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

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

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

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

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

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

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

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

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

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

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

Regards, Bill


Robert B Garner wrote:

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

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

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

Thanks!

- Robert


IBM Almaden Research Center, San Jose, CA
Office:  408-927-1739
Mobile: 408-679-0976
robgarn@us.ibm.com
----- Forwarded by Robert B Garner/Almaden/IBM on 08/13/2007 04:08 PM -----
Karl.Ganzhorn@t-online.de (Karl Ganzhorn)

08/07/2007 05:18 AM

To
 Robert B Garner/Almaden/IBM@IBMUS
cc
Subject
 1401 History_3







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

------------------------------------------------------------------------------------------------------------------

                                                                                August 6, 2007.

Subject: 1401 History_3.

Dear Robert,

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

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

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

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

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

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

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

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

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

...

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

from Gary Mokotoff 1/17/2007 

Gentlemen:

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

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

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

Are you interested?

Gary Mokotoff

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

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

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

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

David Macklin


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


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

Predict Home Run Race from Jim Foley Sept 15, 2006
1961

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UpdatingPunchedCards provided by Stan Paddock

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

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

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

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

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

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

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

Ok, Another true story.

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

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

the Computer Wanted It

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

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

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

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

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

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

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

Simon Wheaton-Smith MBCS, CITP

return to main page