The IBM 1130 was a small, inexpensive computer by the standards of its day. Even so, a single IBM 1130 served both instructional and administrative needs (if I remember correctly) at Lawrence Institute of Technology (Southfield, MI) in 1974.
I never attended LIT, but they had a math club that was open to high school students from the metropolitan Detroit area. Like many others, I joined the math club solely for the fringe benefit of getting an account on their 1130.
LIT's 1130 had a computer resource accounting system that was probably pretty advanced for small, departmental-sized machines of its day (or even nowadays). To run a job on the computer, you had to have a special punched card at the beginning of your deck stating your account name. (There may have been some form of interactive access to the 1130, but if there was, I didn't have use of it.) The accounting system kept track of how many jobs you ran. I don't know whether it had the ability to lock you out after a certain number of jobs; if there was, the feature wasn't turned on for the SIPFLE account.
What was the SIPFLE account, you ask? Well, LIT was slow to issue accounts to us math clubbers. A sympathetic computer operator decided to hand out account cards for an apparently randomly-selected student with the last name of Sipfle. The number of jobs run on Sipfle's account was huge. I hope he didn't get in trouble.
My work on the 1130 was done in early 1974, when I was working on a cryptology science fair project. As described in the Honeywell 1640 and CDC 3300 articles, my interest at this stage of my career was in programming languages, mostly dialects of FORTRAN. Regretably, I made little effort to learn the features of the OS or the specifications of the hardware.
I do know that the system had an 1132 line printer. This was a very slow line printer, but its print quality was excellent. I don't believe I ever saw another model printer with output of such high quality. However, I would have traded off some quality for speed. When working on the 1130, I would drive to LIT after school and typically stay there for about five hours. As I recall, I could get about three runs in during that time. The system was heavily used, as you might well imagine for such a small system in a reasonably large institution.
The long delays between runs afforded me the opportunity to write the one published poem of my life. I'm not a poetry fan, and my handiwork of one long evening was a parody of a rather flowery poem, The Windhover: To Christ Our Lord, by G. Manly Hopkins.
The FORTRAN compiler on the 1130 was, I believe, the Central Michigan University compiler. Like the IBM compiler, it had the eccentricity of allowing no more than five characters for a variable name. I suppose that some aspect of the hardware design made it efficient to pack a five-character identifier and an index into a symbol table into one word, or some such. The CMU compiler accepted a decent dialect of FORTRAN, even allowing LOGICAL variables, as I recall. This was part of the reason I primarily used LIT's computer rather than Control Data Institute's 3300 for my science fair project. Other reasons included my limited access to the 3300 (once a week), and the fact that technically, we had to pay for use of the 3300.
Modulo the long waits between runs, I had a fun time with my science fair project done on the 1130. The project was, unlike that of several of my schoolmates, not the type that wins international competitions. However, I found that science fair projects with possible military applications are more likely to win prizes than otherwise superior projects. Somewhat to my embarrassment, I won the Army, Air Force, and Navy awards in the Detroit Metro fair, finishing ahead of others who had clearly put more effort into their projects. (In case you aren't aware, a really good high school science fair project can easily represent 1000-2000 hours of work, and can explore genuinely groundbreaking territory at a level similar to postgraduate or corporate research. I never achieved that level.)
A few years later, I learned that LIT had upgraded their 1130 with a little-known clone machine that was faster than the genuine IBM 1130. I'm sure that both those machines have bitten the dust by now.
Later in 1974, I got a summer job at Giffels Associates, an architectural and engineering firm in downtown Detroit. One of their computers was an IBM 1130. It, too, ran the CMU FORTRAN compiler.
Giffels' 1130 was batch-only, and it had a card reader/punch that struck me as odd. (LIT may have had the same model--I never saw it, because at LIT the operator fed cards into the machine. At LIT, you submitted a deck and didn't get it back until the job had run and had been printed.) If you wanted to punch some cards as part of your job, you slapped some blank cards on the back of your card deck before reading the cards through. Under program control, the reader/punch would switch from reader mode to punch mode. If something went wrong, you could wind up punching over your data cards. Or even, I suppose, over your source code. I didn't like to punch cards because I saw it as a waste of paper, but with no permanent disk file storage, sometimes it was necessary.
At Giffels, I wrote a simple project billing system in FORTRAN. But the bread-and-butter engineering computing was done mostly on the Univac 1108 and another computer I forget.
In December 2004, a viewer of this page forwarded me these remarks:
My name is Eddy Quicksall. I programmed on the 1130 from about 1966 to 1972 then on the clones until 1981. I co-authored a timesharing system at DNA Systems in Saginaw. That was DNA Systems TSO/CYTOS (CYTOS was written by Tim Mellon who now owns Pan Am Airlines).
LIT bought our system and ran it on a Digital Scientific Meta-4. My good friend Dick Sherin (in Miami) wrote the emulator for the Meta-4 that allowed it to run as an 1130 (with enhancements).
It seems to me that the operating system that LIT used around 1976 on the Meta-4 was TSO. It's hard to remember. I mostly remember because some of the guys came up to DNA in Saginaw [Michigan] (where we wrote TSO) and they gave me a silly little program that would make the panel lights dance.
I copied Don Nichols. He is the one that wrote the TSO supervisor and may be able to give you more information.
Here are some other colleges that had TSO on a Meta-4:
Later, in 1995, I ran into a guy that was still using one of the clones (the GA 18/30). I wrote him an emulator that ran on a PC. At that time, my emulator would beat the 1130 by about 6 to 1. Today, on the high speed PCs, it runs about 80 times faster than the original 1130. It is still in use today running TSO.
Now there is a guy that is building a Meta-4 in an FPGA and it will run Dick's emulator.
[end of quote from Eddy Quicksall]
In October 2014, Stan Sieler submitted these remarks:
Regarding Eddy's comments about the emulator, above: I'm
not sure what that means ... unless you're saying Dick worked
for DSC and
wrote the firmware for the Meta 4?
The reason I ask is that ... as shipped by DSC ... the Meta 4
always had
the ability to run 1130 instructions. (Although marketed as an
1130 clone,
it had the two extra instructions that the 1800 had, too.)
Thus, no end user would ever have needed to write an "emulator"
(and, by
common terminology, it wasn't an emulator, but a microded
implementation
of the 1130 instruction set).
(BTW, the Digital Scientific Corporation reference manual says
"Meta 4" (i.e., no dash between "Meta" and "4".)
I used a Meta 4 with an Evans and Sutherland vector graphics
display to
write a clone of Spacewar in 1971 :)
I really enjoyed the Meta 4 ... the firmware was implemented
as large (1/4" by 1/4") copper foil squares that were stuck (or
not) in a grid on several boards. A firmware patch
involved peeling off some squares
in some locations, and pasting new ones on in other
places. Every now and then, when the computer was "acting
strange", we'd take out the boards and firmly press down on each
copper square and then put them back in place.
Although we *all* agreed there was no sound in space, one user
added explosions to my Spacewar by attaching a Wavetek audio
generator to the Meta 4 and making the appropriate code
changes. It was kind
of neat, hearing "boom" :)
I didn't know about the third party OS (TSO?) ... we ran vanilla
IBM disk OS and the IBM APL (an OS in itself, IIRC). It
was the IBM APL that got me interested in the Meta 4. I'd
been banned from the physics
lab (where we used IBM 360 APL at Orange Coast College ... using
a Selectric and a "tie [phone] line") because I spent all my
time programming in APL instead of learning physics. A few
days after the ban, I stumbled over the lightly used Meta 4 and
fell in love with it! (This was at UC San Diego, around
December 1970 / Jan 1971.)
Digital Scientific's headquarters were a few miles from UCSD,
and the professor with the lab had some kind of connection to
them.
(Later, I graduated to using APL/700 on the Burroughs B6700.)
I never saw a real IBM 1130 until I started volunteering at the
Computer History Museum.
Stan Sieler
Cupertino, CA, USA
Lawrence Tech - Registar & DP dept - 1968-1971
I was LIT's (LTU's) programmer between summer of 1968 and summer of 1971 -- after which I "prostituted myself to industry" having received my BSEE. During that time, I called myself a Computer Operations Supervisor because I operated the IBM 1130 for most of the admin programs and supervised the student operators who ran the students' programs.
I did some operations of the computer that LIT had before the 1130: It was a Univac SS (for Solid State) 80. It had drum main memory and punched card and printer outputs. To run the student programs (written in Fortran II), I ran all of them first through the compiler phase. If the compile was successful, it would punch an object deck. Then I ran the loader and entered the stack of object decks. Once in a while, the student programs would actually successfully run and create printed output!
As the new 1130 was being installed, my boss (Bernie Lis) and I attended Fortran IV classes at the IBM building in Detroit. Bernie wrote the heavy-lifting programs, such as the Registration & Drop-&-Adds. The 1130 at LIT was one of the larger installations in the Detroit area. It had 16K of core memory (as I recall). It was truly core memory back then as semiconductor memory was not commercially available yet. One fun program that we ran occaissonally was one that played "Mary had a little lamb" when you placed a transistor radio by the core memory module and tuned it between stations.
The registration program was a batch job (the 1130 was single-tasking) but could be interrupted by flipping one or more of the console switches that the Fortran program would check from time-to-time. During registration, if a class was full and a student had special permission to attend, then we would flip switch X and we could type in the new class size on the fly. Then put his/her registration card in the card reader's hopper and it would slip the student into the class. The registration program will register students first-in/first out. When the preferred class was full, it would try to find an alternate class for that time period or perhaps a different time period -- if open on the schedule. Rather sophisticated for 16k, I must say. Another ball-buster program was the drop-and-add, which not only did a lot of the registration functions, but also calculated tuition credits or debits.
I can't remember all the projects that I had but two of the more-interesting ones were the Student Job Accounting system and the Alumni tracking system. The job accounting system was really pretty simple: We had an assembler routine that we patched into IBM's Job-card reader. It called a core-image Fortran program that read the Student number and a class number on next card after the "// Job" card which the student supplied. If the student's number was not in the registration file and/or the number of submissions reached a pre-set limit, the program would call an assembler subroutine to set the "Flush" switch and print an error message on the printer. The operating system would then ignore all input cards until it finds the next student's Job card. Although the capability was there, I don't recall any instructor who mandated a limit on how many times a student could submit job. But it kept track anyway...and printed the submission number on the printed output.
In 1968, before the keypunch machines were moved out into a small room outside of the "Computer Center", the workflow was as follows: Students submitted their program via a standard Fortran coding form. This was keypunched by the staff, then sorted -- since the student dictated the proper sequence by the last 8 columns of the 80-column card. Before the 1130 was installed, the staff kept the card decks so the student would mark corrections and so the new corrected cards were inserted (or replaced) the other cards in the deck. I believe that the keypunch/tab equipment operators also had to run the decks through a collater to drop out the old cards that are being replaced. All that changed when the students could keypunch their own programs. It gave them a LOT more submission opportunities.
The limiting factor for the 1130 was the printer. We started with the 1132 which was REAL slow...about 80 LPM as I recall. Around 1970, we got a 1403 printer (and possibly one of the first 1130s to have one, since that was a common 360 peripheral). Work was a dream with the 1403 which run about 4x (or maybe more) the speed of the 1132.
Submitted by Paul Riethmeier, BSEE '71 7/26/2009
See photos (mostly of LIT personnel) submitted by Paul R.
www.ibm1130.net has two important IBM 1130 manuals, scanned by Howard Shubs.
ibm1130.org is a more extensive site that features, among other things, an excellent IBM 1130 simulator, complete with a copy of the IBM Disk Monitor System operating system--the operating system most commonly used on the 1130. The documentation that comes with the downloadable simulator is quite good.