I learned yesterday that one of my mentors has passed.

Jack Schwartz was a professor of mathematics at NYU’s Courant Institute when I was there in the mid 1960’s. He founded the Computer Science department at NYU.

Jack also devised one of the first time-sharing systems, SHARER, to which he invited some brilliant NYC high school students to develop. Many of those students went on to important careers in the field.

But what I remember most about Jack was how warm and generous he was, even tho his reputation as a mathematician, as John Markoff  puts it in his obituary in today’s New York Times, was fearsome.

The three years I spent working in the computer center at the Courant Institute of Mathematical Sciences (CIMS), from 1965-1968, were the most important three years in my life (so far). It started my career in computer programming for science and engineering. We were all quite young, and Jack, and the director of the CIMS Computer Center, Max Goldstein, were our “father figures”.  And as such, we mark his passing.

I was searching for some photographs to put up on my photo blog when I came across a couple of pictures that I took in my office a the Lawrence Berkeley Lab computer center (room 1127/50A) in February, 1975. I have an earlier photo of me in my office from 1971 in a blog post I did a while back, and it's interesting to compare the difference.

First, note the CRT terminal. No, this is not a computer. It's a video equivalent of the teletypewriter, connected by a fairly slow line to the CDC 6400/6600/7600 complex down the hall in building 50B. I was one of the first people in the LBL computer center to do away with punched cards and work exclusively interactively. Also note the microfiche reader next to it. At this time LBL produced most of its output on microfiche. I was maintaining all the compilers and libraries on the CDC system, which of course meant lots of big code listings. You can see them on the shelf in the previous image from 1971. On the wall the calendar would seem to indicate that it was the last week of February 1975. Some of the pictures on the wall you may find on my photo blog now (this one, and this one). And two portaits of my wife at the time, Anita. On the far right is part of a brochure from Davos, Switzerland, where we were the previous year. The framed print was a gift from local artist Carol Law. I still have it somewhere.

On the bookshelf I can see the Webster's Collegiate dictionary that I still have in my office at Sun. Note the rotary phone. Next to it on the desk is a stack of CDC manuals (the red front page indicates update pages)

Here's a closeup of what's on the screen:

What's being displayed is some job control language for the BKY system, a homegrown version of CDC's own Chippewa OS that ran as a front-end to the 7600 back-end. Looks like the JCL is compiling a listing of the CDC FORTRAN 77 compiler FTN, and staging the listing to the microfiche writer.  You can see that even in 1975 I was using RCHRD as my job login name. The history of RCHRD is in an earlier post. 

Note there's no "scroll bar" on the display, and it's all UPPER CASE. It was primitive, but quite a change from 1971 when everything was done on cards. COPYPSS  was an intermediate storage device where you could store data or output for later retrieval. Remember, this was a few years before UNIX, and there was no central permanent data store on the computer itself... data had to be staged into and out from the program running on the 7600 to external mass storage devices, like tape.

Never thought I'd become nostalgic about that old ADM display. I can almost recall the bakelite smell when it got hot.

The Computer Museum Muenchen is proud to announce that we now have a Sun Enterprise 10000 ready for you. This Saturday, March 3rd 2007, the machine will be online for the first time and be happy to serve your user requests. The publicly accessible domain of our Enterprise 10000 consists of 56 Sun UltraSparc II CPUs and 56 GB main memory. More details about our Enterprise 10000 can be found here:
Some details about the history of that machine:
The Enterprise 10000, or Starfire (a development codename also used for marketing purposes) was a high-end multiprocessor datacenter server capable of up to 64 UltraSPARC-II processors. This was largely designed by Cray Research's Business Systems Division as a successor to the Cray Superserver 6400. After Cray was acquired by Silicon Graphics in 1996, this division was sold on to Sun and the Starfire launched (as the Ultra Enterprise 10000) in 1997. The Starfire has an impressively long pedigree; the CS6400 itself was the follow-on to the Cray S-MP, which was in turn developed from the FPS Computing Model 500 minisupercomputer and its ancestor, the Celerity 6000.

The Starfire was based around the fault-tolerant Gigaplane-XB processor/memory interconnect. Like the X000 and X500 series servers, the Starfire incorporated many high-availability features, including the ability to be partitioned into multiple virtual machines or "domains", each running its own instance of Solaris. The Starfire was the first server from any vendor to exceed 2000 on the TPC-D 300 GB benchmark. Starfire systems were used by a number of high-profile customers during the "dot-com" boom, including eBay, and typically sold for well over $1 million for a fully-configured system. [ Source: http://en.wikipedia.org/wiki/Sun_Enterprise ]

If you have any additional questions about this machine, direct them to
mail-AT-cray-cyber.org, we will be happy to answer you.

If you open an account (free), they'll even let you play around with a Cray-X/MP

There's more to go. There are 8000 slides sitting in boxes under my desk. All numbered, cataloged, and waiting to be scanned.

I started the photo blog last September. I even collected 80 of the images and put them into a book on blurb.com.

Take a look. Let me know what you see.

Also, the Gates Foundation just gave $15M to the Computer History Museum! Read the press release.

Its all here: early FORTRAN manuals, Algol60, Simula 67, the first real C manual from 1976, PL/I from 1969... Great stuff.

I found this site a few months ago while looking for a copy of the IBM 704 FORTRAN manual and had bookmarked it for further digging. I rediscovered it today.

He also has a JPG scan of a FORTRAN Coding Sheet from Ruhr-University Bochum, along with an article on flowcharting techniques from 1969 and pictures of flowchart drawing templates.

Reading thru these old manuals, you realize the distance travelled in these 40+ years.

The other great storehouse of computer documentation is bitsavers.org. They report: As of Jan, 2005 there are over 5450 documents containing over 559,000 pages in the archive. The even have a copy of the CDC 6600 RUN Fortran compiler manual from 1966 that I had, at one time, committed to memory.

Further digging gets you to the Retrocomputing Pages, with lots of links original source information about early hardware, like the PDP-8.

Of course if any of this sort of thing interests you, I should mention the Computer History Museum in our own back yard.
( Jul 01 2005, 10:07:30 PM PDT ) [History] Permalink

So there's a story in how I became known as rchrd. First, we have to go back to around 1970.

In 1970 I was working as a systems programmer at the Lawrence Berkeley Lab (then the "Rad Lab") computer center on the CDC 6600. (See Welcome to Berkeley.)

Here's how you used a big scientific mainframe like the Control Data 6600 in 1970:
First you punched your program and data on cards, or prepared a data tape offline, but there was no way to avoid actually punching the program statements into cards. And the card decks had to have a specific structure. The first group of cards were the job control statements, and these could be followed by source code or data. The sections of cards were separated by a special end-of-record card with 7-8-9 punched in the first column. The last card in the deck, the end-of-file card, had a 6-7-8-9. So the first "record" group of cards spelled out the commands, similar to the commands we use today at a terminal prompt.
But the first card in the deck was special. It was the 'Job Card", and it specified the accounting information for the job: chargeback account number, time limit, memory limit, priority.

After the job was run, the printed output for the job was filed by the operators on shelves in the reception room. (Programmers almost never got near the machines, unless you were one of the elite systems programmers; most programmers only got close to the keypunches and the printers.)

Sometime around 1970, the LBL computer center decided to improve the way jobs and accounts were identified. The systems staff redesigned the format of the job card to look something like:

jobname,priority,timelimit,memorylimit.account comments

You could now assign an arbitrary "jobname" to a job deck, and it was under this jobname that your output would be sorted, and the particular job identified. You could now assign more than one job to an account, and if you used the same jobname for multiple jobs, the system would append a two digit sequence number. And, the rule about job names was that they had to be 1-5 letters.

When this new job card and job name came into effect, everyone using the LBL computer center was informed that they should start using unique jobname identifiers. A suggestion was made that the job name could be the programmer's name, or project name.

Being clever at that time (I was 26), I wrote a Fortran program to print out random groupings of five letters and stared at the output for days. I had to choose a clever jobname to use so that everyone would know my jobs. But I couldn't find anything in those lists of random characters anything that said "use me". Others were using their names, but mine was 7 letters. In a flash of inspiration, I discovered that if I removed the vowels, RICHARD becomes RCHRD. That was PERFECT!

So I started using RCHRD as my job name from that point onward. And it even got worse. I wrote articles for the center's newsletter, and started signing my name Rchrd. To get back at me, people would address me as "Rchrd", trying to pronounce Richard without the intervening vowels. The sound that made was something close to a growl with your teeth clenched. Very strange.

When LBL introduced its UNIX servers, this whole new paradigm introduced the concept of a login name and password. Naturally, my login was rchrd. And so it has been since. (I was rchrd@well.com, rchrd@emf.net, rchrd@mindspring.com, rchrd@earthlink.com, rchrd@pacbell.net, and now rchrd@sun.com. The great day came around 1999 when I claimed rchrd.com as my own domain.)

We reached even new heights around 1980 when I bought a new car (Honda Accord) and treated myself to personalized RCHRD plates (which I still have, the plates - not the Honda - but now on my VW Eurovan Camper). Which reminds me that one day I was driving across the Bay Bridge behind a pickup truck filled with plants and small potted trees. The license plate: ORCHRD.

This is probably more than anyone wants to know. But we live by the abbreviations we make.
( Jun 30 2005, 10:50:12 PM PDT ) [History] Permalink

    ' beer1;count;fc;s;s2
[1]   :for count :in ²¼99
[2]       fc".count ª s"(count¬1)/'s' ª s2"(count¬2)/'s'
[3]       fc,' bottle',s,' of beer on the wall, ',fc,' bottle',s,' of beer; take 1 down, pass it
around, ',(.count-1),' bottle',s2,' of beer on the wall.'
[4]   :endfor
    '

So where am I in this story now? Let's see... 1968, June 5, and I'm flying into San Francisco Airport with 60 boxes of books and everything I own, to take a job at the University of California Lawrence Radiation Lab (now Lawrence Berkeley Lab) computer center. But if you want to read this in the right order, you need to scroll down to part 1.

I started working at the LRL Computer Center, up on the hills above the Berkeley campus in July, 1968. I stayed there 13 years. And for most of that time I was responsible for maintaining the compiler (FORTRAN), assembler (COMPASS), linker/loader, I/O libraries, and related stuff. I also served as user support and wrote a lot of the user documentation.

By '68, CDC had given up on its futuristic SIPROS operating system and was forced to adopt the system developed by the engineers in Chippewa Falls (Wisconsin) under Seymour Cray. It was known simply as COS and was a productized version of the raw system we started using at NYU in '65. Still, input into the system was cards, output on paper or tape or punched cards. It would be another 5 years before display terminals appeared.

The picture above was taken in 1971 (by my Dad on a visit from NY, which may explain the sunglasses.) But note the typewriter. I was the only one on the staff with a typewriter, on which I wrote articles for the center newsletter and printed (xeroxed) documentation. Note also the bound listings on the desk and shelf. The shelf has the listing of the CDC 6600 assembler, COMPASS, and the RUN compiler.

What you can't see is the card file to my left. It held trays of cards. But by '71 source code management had progressed from decks of cards to source files on tapes and a program called UPDATE from CDC. UPDATE was an ancestor of SCCS on Unix. Now the update instructions ("replace card 248 in deck XYZ with the following cards") were punched on cards and fed into the card reader with the job control cards that read the source tape and generated a new version of the source program. This is how we maintained the thousands of lines of the compiler, assembler, etc.

What I enjoyed the most of my years at LBL was the community of scientists, engineers, mathematicians, and programmers. You never knew who you would meet in the cafeteria, including Nobel prize winners. The systems group was quite small, maybe 5 full-time programmers (one of them is also now at Sun, Marty Itzkowitz , and ironically just like at LBL, his office in Menlo Park is still next to mine).

In March of 1971, I and a small team of programmers and computer operators went to Chippewa Falls to run acceptance tests on the CDC 7600 that was installed at LBL later in the year. The 7600 was a big improvement on the 6600, running 4 times faster at 27.5 nanoseconds, and featured multiple pipelined functional units, which meant that you didn't have to wait for one multipy to end before you started another.

Also, by this time CDC had developed its SCOPE operating system, based on limited time sharing and remote job entry (satellite card reader and printer stations linked over phone lines). But after careful review, the LBL systems group decided to further develop the COS system for its own needs, and called the derived operating system BKY. And my job was to keep the compilers and tools that CDC made available under SCOPE running under BKY.

One great advance was CDC's FTN compiler, which replaced RUN. FTN did some amazing scalar optimizations. It knew a lot about instruction timing and scheduling. Finally we had a compiler that would produce code that ran as fast or faster than equivalent code written by hand in assembler. But maintaining FTN was a lot different than maintaining RUN. It was no longer possible to call up the compiler programmer and report a problem, and then get a patch in the mail in a few days. Things had gotten very corporate. Filing a bug against FTN required filling out a form, include test source code and listings, and mailing it to CDC Sunnyvale. Eventually a distribution tape with a new compiler would be issued with a list of fixed bugs. Hopefully, your bug would be on that list. For me the interesting part was creating a software environment in which the compilers and tools could live that interfaced the BKY system. Altho at the programming level BKY and SCOPE were not that far apart, there were always problems as SCOPE got more mature. And, keep in mind that all systems programming on these systems was done in assembly language.

...to be continued