|
Robert [ Garner ]: Thanks for the email to the [ CHM IBM 1401 ] gang. In answer to your question about the 305, and more than you probably wanted to know, I offer the following:
The program for the 305 was a version of a game I knew of at the time as “21”. One player picks a number (from 1 to 5? I don’t remember the limit) then the other player picks a number which is added to the first, and so on, until the total is 21. The player forced to add up to 21 loses. The first player can always win. Nothing to brag about, but I think the IBM guys were mistakenly impressed because “21” to them meant “blackjack”. This long story leads to an episode with an 1130. As I mentioned to you, during my junior and senior years of high school I was in an Explorer post sponsored by the Omaha IBM office where I got to “play” with a 1401, the 305, and a 1440. In the spring of my senior year of high school (1965), I got a job programming a 1620 at the University of Nebraska Medical Center. I worked there summers of 1965, 1966, 1967 and 1968, while attending Caltech. In the summer of 1967, the Medical Center installed an 1800, which I programmed. Returning to Caltech in the fall of 1967, I learned the Computing Center there had installed an 1800. (pictured) I inquired and was hired part-time to program the 1800, given my previous experience. The 1800’s job was to collect data from labs around campus via long serial lines. (The principal computer was a 7094/7040 system). The first data source for the 1800 was a mass spectrometer called the “Lunatic”, since it was destined to analyze moon rocks. The lab belonged to Dr. Gerald Wasserburg, who was the chairman of the committee that would determine the distribution of moon rock samples. I wrote the first software to collect data from the “Lunatic”. A picture I took is attached, as well as the Smithsonian article about their acquisition of the Lunatic. The manager of the Caltech computer center wanted me to stay for the summer of 1968 and continue work on the 1800, but I needed to return to Omaha because I intended to return to school in the fall with a car, the better to facilitate visits to my wife-to-be at Scripps in Pomona. When I returned to Caltech in the fall of 68, the computer center manager said he had nothing for me. A grad student had taken over the 1800 project, so, alas, when the moon rocks were finally analyzed the following summer, it was NOT my software that collected the data. Another grad student heard I was looking for work, and he referred me to a small company, Western Telematic, Inc (WTI), in El Monte. They were designing a multi-terminal serial interface for the 1130 attached via the SAC (Storage Access Channel) which IBM made available for customer-attached devices. WTI had engaged a contractor to create an interpreted interactive Fortran to sell with their hardware. It was single-user, and I was hired to help the contractor convert it to multi-user. My 1800 experience was essential, the 1130 and 1800 being close in architecture. I wrote code to do what we called then “core swapping” – swapping a user’s image on and off disk. But we found that the disk driver provided by IBM couldn’t keep up with the disk rotation. (This was before someone thought of interleaving non-consecutive sectors, as was commonly done with early PC drives) To verify the disk problem, one evening the contractor and I had the 1130 open and were probing its innards with a scope when the boss walked in. It took a while to justify our audacity, but we demonstrated the problem to the boss and were able to write a much faster disk driver that made the whole multi-user system possible. I don’t remember if we told IBM about the problem, or published our work. It was probably best left as a trade secret for WTI. WTI wanted me to work for them after graduation, but with the draft hanging over my head, I had to return to Omaha and the Medical Center, and an occupational deferment. The Smithsonian article: https://americanhistory.si.edu/collections/search/object/nmah_1405004 Bob
|
4 Ton Beast - Daystrom 046 Computer - by Bill Richter (Ham Radio call W5YAR)- sent May 29, 2020
|
4 Ton Beast - Daystrom 046 Computer My first computer maintenance job (1961) at Union Carbide was on the "Daystrom 046", at the Olefins-2 plant. It weighed 4 tons, had 4k of main memory (magnetic core), and 100k of rotating magnetic drum memory (about the size of a 55gal barrel, driven by a 480 volt, 3 phase, 3hp motor), and about 5,000 transistors. Yet we made some of the purest (99.9%) ethylene gas in world. Direct Memory Access: The VFA analyzers and other instruments automatically went (wrote) directly into dedicated memory locations in the high end of the 4K, therefore no software programming was required to access analog signals, they just appeared in main memory (at rate of 5,000 samples per second). Similarly, control outputs came from unique dedicated memory locations and directly adjusted set-points on the panel-board instruments. This was the first DDC (direct digital control computer in the world). Programming code had to be very tight back then due to limited main memory. Furnace control programs were only a few dozen words long; they simply read a few hard memory locations, did some simple math, and output directly to a unique hard memory locations, which controlled set-points. The math was done by calling pre-loaded math sub-routines. These math sub-routines came from the Daystrom factory, on a roll of punched paper tape, and when loaded, took up almost all of the 4k memory. Hardware maintenance (my job) was another amazing aspect of this 4 ton beast. There were no circuit or wiring diagrams, only several volumes of Boolean logic equations, in Sheffer Stroke notation. Every transistor and diode had a unique logical value in the Boolean equations. Knowing how to read the equations, and how to use of an oscilloscope, along with a few replacement transistors, and a good soldering gun was all that was needed to fix the thing. Here is a link to the specs on the "Daystrom 046" http://ed-thelen.org/comp-hist/BRL64-d.html Union Carbide is listed as one of their customers.... about 9 were built.
Late one night, one of our chemical plant operators called me and yelled "the 046 is on fire, what should we do". Being half asleep at the time, I said the obvious.... "Put it out.... I'll be out there as soon as possible"..... and then hung up. On the 30 mile drive to our plant, I began to worry about my choice of words, as I could only imagine a fire water hose being applied without shutting off power. Luckily, they killed the power and then applied a hand held Halon fire extinguisher. Upon entering the computer room, I saw the magnetic core memory rack, open and slid out on it's rails, with some pretty heavily carbonized circuit boards visible.. There were 22 circuit boards involved, and all looking pretty much destroyed. Why 22 boards? Because Daystrom designed their instruction word with a whopping 21 bits and one parity bit; this seemed like a good choice, I guess, because the 8 bit byte had not been invented yet. Without diving too deep into how magnetic core memory works..... each memory bit is composed of a magnetizable iron core toroid (do-nut), the size of a pin head with 3 wires passing through it, 2 for addressing and one as an inhibit wire. The inhibit wire supplies opposing current (when needed) to prevents a 1 from being written. Anyway.... what happened here was that the master inhibit driver, which normally applied a short write pulse, failed in the ON state, causing the core stack to heat up like a big toaster. What saved the core stack was that the 22 inhibit driver transistors and related circuitry competently burned off the circuit board, destroying the top quadrant, and thankfully caused the current to stop. Fast forward.....Two days latter, working round-the-clock, we rebuilt the 22 inhibit drivers and replaced the errant master inhibit driver. The repair consisted of taking the burnt boards to our machine shop, and with a band saw, cut off the charred top quarter. We then took perforated vector board, epoxyed it to the missing section, and hand (hay stack) wired the replacement circuitry. After that, the "046" ran fine for another 20 years.
Bill Richter ( Union Carbide Corp - Retired) bill333@suddenlink.net |
The IBM 650 & early transistors, by Rick Dill Rick Dill - sent September 2019
|
I was at CMU when they got their first computer, an IBM 650. I'd worked for IBM the summer of 1954 and at RCA Labs the summer
of 1955. At IBM as a summer student, they put me in a "new employee" three week class about IBM while the rest of the
company went on their "scheduled" two week vacation. It was like drinking out of a firehose, starting with punch cards,
meat scales at the beginning, with the details of the evolution of punch cards (aka 1954) and the technologies that followed.
I have the hand-out notes and think that someone in CHM has them. I would like the notes back, but CHM needs to understand
them. It shows well IBM's path from unit record to computers.
1954, I got to look at the functional layout drawings of the 604. It was a "plug programmed" calculator, but 3 years later when I got introduced to the 650, that very simply was a 604 with I-box (instruction handling set for programming). I saw lots of other stuff as well. At IBM, I was encouraged to "invent" functional electronic devices that did higher level logic than individual transistors. I left with a decimal counter based upon unijunction transistor concepts. IBM never did anything with it but Ian Ross (later head of BTL) built the same thing at Bell Labs and published it at a conference I attended while at RCA. That helped give me confidence that I could play with the "big boys" in the field I had chosen with the Shockley, Bardeen and Brattain announcement of the point contact transistor while I was in high school. NO, I didn't want to start a company, I wanted to invent things like Edison did. As background for this, as a "poor" student needing all the income I could find, I had already been in a part time job for a Physics grad student. My job was to enter numbers from Hall Effect measurements into a Freiden calculator and get him the results he needed. I'd also played in my "kid" life with adding machines and the Freiden. OK, fast forward a little. I abandoned my physics major undergrad and walked across campus to EE, under Rod Williams an incredible communications engineering professor. I got bored because they thought I needed to take undergraduate "Electronics" . Facing a boring and trivial lab report, I just submitted an idea I had for building a degenerate form of parametric amplifier using semiconductor diodes as the non-linear capacitors. Well my office was where some more senior grad students were building these with barium titanate capacitors which had to be in a water bath because their capacitance depended on both temperature and voltage. OK, I build my circuit and published it with my electronics professor, first publications for both of us. The next year I used the same tech and some fun with circuits to build the replica of the classic HP audio oscillator which did a decade of frequency with the turn of a single knob. Published that and was bored, but needed a thesis topic. Well I also needed a thesis adviser because no one in the department was in the field I wanted I went to Williams with three topics ranging from deep physics (which I was poorly prepared for) to understanding the unijunction transistor which had only a primitive explanation of why it worked, to doing more with semiconductor capacitance which I was bored with. He agreed to serve as adviser and turned me loose. I had to make the devices and then figure out how they worked. Shortly afterwards Dale Critchlow who was young faculty at CMU went to IBM for a summer. He is in NAE for his work in DRAM and things like trench capacitor. He talked IBM into supporting three of us. Me, Bob Dennard who you know as the inventor of DRAM but who was just starting with a thesis in magnetism. The third was me already working on theory of unijunction transistors OK, as expected, I had some troubles. I needed some help with getting the physics right. An hour at RCA with Herb Kroemer (nominal inventor of the drift transistor ++++ much more) got me past that. Then I was into non-linear differential equations to follow the electrons and holes and simply didn't have the math tools. Well, CMU (really Carnegie Institute of Technology) got their first computer. A few students got head starts by going tot their local Mellon Bank and programming for their theses on an IBM 659. I had a close friend (that extended through much of my career) who ran over to the new 650 and started programming, first in assembler and then in SOAP which assigned memory locations for memory so that they would come up just after being needed. Karl knew me well. I wanted answers, not adventure with new computer. He directed me to the Wolontis simulator which ran on the 650 (also called BLISS at Bell Labs) It took the 650 and used half the memory to provide a three address computer image. Well with half the memory gone you had 1000 ten bit floating point words. That let me program without all the details like memory management or where the decimal point was. IT WORKED! I later gained a good friend at Bell Labs who had, with a help of a math guy, created the same programs for solving Poisson's Equation, which is core (in three dimensions) in all device simulations today. OK it was NOT EFFICIENT. I used a lot of computer time. I found that midnight to six was easy to get, so at one point Perlis, the guru owning the computer and creating a compiler, "IT". more or less with IBM's FORTRAN. It eventually got folded in by IBM into FORTRANSIT. I didn't use IT because it was in early development and I wanted something stable enough to get me out of school. When I got the IBM support, they wanted me to come to Poughkeepsie monthly to report on my progress. I did that most months and it at least got some people listening to me even they had little deep knowledge to help with. While at IBM, computer time was easy. I just had to find a 650, often with covers off. I could run it until I ran our of personal energy. At CMU the 650 eventually got some core memory, but that was well after I left in Feb 2018. I would love to see the 650 and even better would like to see one run at CHM. It was one of the very first computers to be made in relatively large numbers.
Rick Dill
|
IBM 2321 Data Cell from Ignacio Menendez added March 2018
|
This was a rather unusual random access data storage machine.
See
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_2321.html
and
https://en.wikipedia.org/wiki/IBM_2321_Data_Cell
I had these interesting experiences with the first 15 IBM 2321 Data Cell Drives, manufactured by SMD, and still on B test in San Jose, circa 1962. We had been working on pickability and strip wear problems for over two weeks on the the final test floor, I happen to run into an old gentleman, by the name of Ollie (?), from manufacturing Engineering, who had been very helpful before, and I related the current problem to him..... I almost got fired for telling this gentleman about it, without permission of the dept. Mgr, or the lead tech.... but the results cleared me, he found that the settings that we were using for the strip housing rotational adjustment, and the cell air adjustments were not the optimal, so he changed the spec.... he also did something for the stripwear, don’t remember exactly what, perhaps allowing the use of the GREEN lapping strips flying for a few seconds, to better burnish the housing. My other experience was with a 2321 that had finished the final test, but when run on the mod30 System, diagnostic routine F650, random seek, it failed with a permanent seek error. I was able to retrieve from the 2841 sense data, the from and to addresses for the servo, and sure enough, it would fail from the CE panel as well, but not anywhere that we would do our seek alternate testing on the final test line.... I wrote a small program on the ‘robot tester’ (modified 1620’s, I think), and ran 4 and 5 subcell moves all around the bin.... This 2321 would fail like crazy at some addresses 90 degrees apart, on these small bin moves.... I took my program and ran it on all the 2321s on the floor, and you guessed it, ALL of the 2321’s failed.... I showed this to QA and they Red tagged all the machines, for which I also almost lost my job, until.... Luckily, Ed Shaules (?) from development Engineering came in, and determined that we needed a more precise Pegasus red tag servo valve, for the blue one that we were using, could not handle with precision these moves on the four roll vane areas of the Hartman hydraulic motor. Anyhow, I hope this was not too boring an old story. Iggy |
a COBOL joke - from Keith Falkner - Feb 11, 2014
|
COBOL joke
In 1996, we COBOL programmers were all looking over our shoulders and cringing under the pressure to update masses and heaps of programs that had been handling the calendar year with two digits. As 2000 approached inexorably, we were busily adapting these programs to use four digits instead, and devising algorithms that would reliably infer the first two digits by considering the current year and the given last two digits. Let me tell you, it was dull stuff. But we did it. There was a programmer who rebelled. He was so bloody tired of dealing with trite and sloppy code that he decided to take refuge … in the future! He figured that by 2004, all programs would routinely use four digits for the year, and any bugs left over from the conversion effort would be long since eradicated. He built a suspended-animation chamber, and programmed it to keep him alive, but unconscious for eight years. Unfortunately, his programming skills did not match his engineering skills, and his program was, as we said, not Y-2-K compatible. The result was that he stayed in suspended animation, not for the intended 8 years, but for 8000 years. He emerged in the year 9996! He found a civilization that was still running COBOL programs, but had nobody to maintain or upgrade them, until his reawakening. So he was welcomed most earnestly, and had no choice but to earn his living by converting all the COBOL programs in the world to handle the five-digit year that would soon be upon them. None of the existing COBOL programs was Y-10-K compatible! |
Monrobot - one of many "lost" in history - from Donald Caselli - July 6, 2013
|
Reference -
MONROBOT-III,
MONROBOT-V,
MONROBOT-VI,
MONROBOT-IX,
MONROBOT-XI,
MONROBOT-MU
I recently discovered your website was able to find some word references to Monrobot but nothing of any historical significance. You may know that Monroe Calculator Co. of Orange, NJ was the designer and manufacturer of the Monrobot XI computer in 1959. I was introduced to the Monrobot XI in 1965 by way of Peter George Petropolis in NJ who had founded a software company known as Systems Design, Inc. His focus was on programming the Monrobot XI to process back office work for the stocks & bonds industry as well as other financial institutions. One major accomplishment was programming the Monrobot XI to calculate a basis price extending out beyond 40 years. I worked at Monroe in Orange for one year and then joined up with Peter Petropolis and others who were forming Computer Property Corp in Hanover, NJ. Computer Property Corp acquired the entire Monrobot XI line with spare parts, etc. There were 350 installations of the Monrobot XI at the time they took over. ... I would travel to some of the installations over the few years that we operated. I improved the assembler so that source programs could be kept and processed with the 8 channel paper tape and produce object 8 channel paper tape output that would be executable programs. I also developed a dis-assembler that was able to accept an 8 channel object paper tape as input and produce an 8 channel source paper tape that could then be input to the assembler. This was done so that modifications could easily be made to programs that were being sent to Systems Design, Inc. from installations around the USA, and there was one in Toronto, Canada, and I spent a little time with that installation. Two IBM Model B typewriters could be connected. Two IBM 026 keypunch machines could be connected. There was a magnetic card, the size of an 80 column Hollerith Card, that held 96 32-bit words, known as the Monro-Card. I do not know of a physical Monrobot XI in existence. I have some original documents and manuals from Systems, Design, Inc. and some photos, which I posted on flickr.com These photos should be able to be found by using the search keyword monrobot ... There is a computer museum at Camp Evans in Wall Township, NJ which is part of infoage found on the Internet as infoage.org The museum is M.A.R.C.H. known as mid-atlantic retro computer hobbyists. There are other museums at Camp Evans and can be visited at times shown on their website infoage.org In May, 2011 I gave a short presentation regarding the Monrobot XI and distributed a small booklet that I printed regarding a little history of the Monrobot XI. - Cover of a presentation The purpose was to explain that the Monrobot XI computer was able to be installed at a particular place or office and be used to process various data and produce printed reports, checks, etc. instead of sending the data to a data center which would take a few days whereas the Monrobot XI would produce results immediately in an office. British Overseas Airways in New York City and the American Stock Exchange were good examples of successful Monrobot XI operations regarding payroll processing. Of course there were 90 stocks and bonds installations, 35 installations for fuel oil delivery companies and many others. So this was the type of history that I was interested in presenting. ...
Donald O. Caselli
|
Magnetic tape media problems - from Dana Roth - July 5, 2013
|
A little background from Ed Thelen:
When I was fixing computers for General Electric in the early 1960s, one of our plagues to smooth running computer sites were the crappy tape drives and the crappy magnetic tape media. See my tale here.
Introducing Dana:
The tape certifier had a microscope. New tapes had excess oxide (and other oddities) and needed to be cleaned before certifying. As the tape was being tested, a bad area (from many sources like contamination, bad mylar, etc.) would position below the microscope and could be usually repaired. There was a counter on the tape certifying machine which counted errors. Too many and the tape was sent back for replacement. The issue, of course, was why so many bad tapes. The government site had about 800 tape mounts a day and 25,000 volumes on-site and were serious about data. I understand it to be a lot of remote sensing from satellites keeping track of minerals etc. The 66X tape drives were flying at 200 inches per second, so I became an expert on tape subsystems pretty quickly. I suspect that manufacturing companies sampled tapes to reduce overhead costs. The GOC had a good tape librarian to ensure quality (and beat up on the vendors)! One day CDC flew me down to Dallas TX (on the hottest day in May), Mobile Oil site to work on tapes. They had a quarter million tapes on-site, which looked like a gymnasium filled from floor to ceiling, all seismic data, from all over the world. The tapes were in rough shape (peanut butter on them and the like) and a single process job would run for three days, processing seismic data. A tape would break into the second day and they would have to restart the job. They had three CDC 6000’s in one room, with some special “stunt boxes” that allow for some serious number crunching. We helped develop an algorithm to uniquely address each block on tape (similar to disk) and take checkpoints in case a tape or drive would break. They could then repair a tape and move it to another drive, seek to the broken spot and continue in mid-job, saving days of processing. Tapes had to work, even if bad. In hindsight, maybe that’s why oil is so expensive (a 72 hour job @ $30,000/hr.)! Tape abrasion was a problem and CDC went to glass heads that were pre-grooved so as not to distort the tape passing over the head. On the GE front, one day a computer operator miscued a tape (the system was actually self loading but operators threw the tape on the drive) on a 667 tape drive. He opened the door to check how the tape loading was stuck. A General Electric AC motor capacitor exploded and coated him with PCB oil. In those days, the oil wasn’t well known to be a carcinogen, as it is today. CDC bought him a set of new clothes. I got to change out all the remaining capacitors and had them properly disposed of. What a mess! —- dana |
7094 II Move and CoreMemory problem - from John Van Gardner - Mar 17, 2013
|
When Lockheed won the contract to build the C-5 in October 1965, they knew
they were going to need more computing power. At the time Math Analysis had
a 7094 they owned and one they were leasing from Greyhound Leasing. The
California division had a directly coupled 7094 II that they were replacing
with something else. On September 25, 1966 they decided to bring it to the Georgia Division.
At this time there was no computer room to put it in and we did not have anyone trained on the Mod. II. Lockheed began building a computer room in an old cafeteria down in tunnel 2 of the plant. I ordered a set of manuals for the Mod. II and spent a whole Labor Day weekend reading them. On Monday we found out there were no 7607 data channels coming with the machine as it had been directly coupled to a 7044. IBM found 2 channels in a warehouse in St. Louis, MO, but they did not have the feature that allowed attachment to a Mod. II. I called Poughkeepsie and had someone read me the wiring list and SMS card list for the change. I recorded the phone conversation on an IBM Executary dictation machine our salesman, Bill Bull, had given me when it broke (just a bad relay). Poughkeepsie shipped me the SMS cards by air. Lockheed put the 7094 II and all the tape drives on their L-100 (Civilian version of the C-130) and flew them to us. By the time the machine arrived Lockheed had built a small section of the raised floor with a temporary ramp in the middle of the old cafeteria in tunnel 2. We positioned the frames and began wiring the channels. It was freezing cold as none of the equipment was powered up so I worked with my coat on. The painters were painting the ceiling with a roller and when I got home I had paint all up my backside. It ruined a good suit. After we got all the construction out of the way everything went as a normal installation. I was able to trouble shoot all the bugs we had and from the day Lockheed decided to bring the machine from California to the day we turned it over to them it was 18 days. I had one interesting bug on this machine about 3 months before it left. They had a program that was a matrix inversion problem. It gave different answers every time they ran it. I found out that if you turned off the overlap switch it would run correctly but slower. Lockheed had a young blond mathematician named Stuart Austin who worked with me on the problem and she found out that one of the instructions in an index loop, that added up a column of numbers, was picking up a bit in the decrement field of the instruction. The 7094 II used an air-cooled split array memory with a cycle time of 1.4 microseconds. I scoped the memory and found that the location of the instruction was being half selected many consecutive cycles during the loop. I talked to Poughkeepsie and they said, that was sometimes caused by a core that had a chip out of it, and it would flip with half current. They said the only way to fix it was to replace the core plane in the array and it would cost $35,000.00 for them to send someone to do it. We knew the machine was due to go out in 3 months and that the program would run if you turned off interleave so I decided to try and fix it. I took a current probe and looked at the current pulse on the half selected driveline and decided to add a resistor in series with the terminator for that line. If I remember correctly I think the terminator was a 250 ohm Non-inductive resistor so I added a 25 ohm in series and looked at the scope. I could not tell the difference in the current pulse. I tried the program and it failed. I had already replaced the 250 ohm resistor just in case so I took the original 250 ohm and added it in series and the current pulse dropped about 10%. The program worked fine. I ran all the diagnostics and bias test and it worked. Well, so much for ohms law. I had forgotten I was trying to send a square wave pulse down a long wire with lots of inductive kickback. The machine ran fine until it left and a 250 ohm resistor saved $35.000.00. Stuart Austin went on to program the CDC computer at the wind tunnel where she met and married Johnny Johnson. They both later went to work for IBM as System Engineers.. |
IBM - Customer Choice of Colors - from John Van Gardner - Mar 02, 2013
|
Here is some tourist information about the colors. It all started when
IBM offered the customer a choice of color on typewriters. There was
set of standard colors some of which I remember: Classic Blue, Flame
Red, Garnet Rose, Light Gray, Pearl White , Raven Black, Sky Blue,
Sunrise Yellow, Willow Green. In 1971 orders for new typewiters was
down and IBM started taking trade-in IBM machines on new orders. These
machines were sent to the plant and completely dissassembled and
cleaned. All worn parts were replaced and these machines run down the
assembly line and adjusted to meet new machine specs. All of these
machines were painted Charcoal Brown and sold to employees only at a
large discount. I bought an Executive with a wide carriage and carbon
ribbon for $220.00 plus $6.60 GA sales tax. IBM deducted $9.44 from
each pay check untill it was paid for with no interest charged. A new
Executive like mine would have cost $525.00. I still have it somewhere
in my attic.
In 1955/56 when I was in 704 school in Poughkeepsie they had a computer room on the back of the plant with a 702 that they actually did the plant's payroll and other data processing. It was a nice looking room that they showed potential customers on tour. The whole front was plate glass windows they could look through. There was a desk for a receptionist with a yellow typewriter and yellow telephone. The receptionist had long blond hair like Betty Grable and always wore a yellow sweater. Every day at lunch I would go by there to see if she ever wore anything but a yellow sweater. I never saw her in anything but yellow if she was there. I wondered if that had been written into her job description. When Lockheed at Marietta, GA got their 705 Model 3 they paid $3,000.00 for an RPQ to get their's painted Garnet Rose. That was the first colored system I ever saw. Later on Martin Aircraft in Orlando, FL got a 704 system with each box a different color. When the 7000 series machines came along I was working on a 7094 in a test cell at the Poughkeepsie plant and the next cell had a 7074 that was going to the U.S. Justice Dept. and it's main frame was blue and it had 7340 Hypertape Drives with red and white vertical panels. You could not look over to that test cell without thinking about the American flag. When Customers began to get multiple systems they would get different colors and refer to them as Old Red or Old Blue. Van Gardner
from Stan Paddock, March 4, 2013
Back in the late 1960's, I worked for an IBM refurbishment center.
I thought it was a bit strange when a
complete 1401 system came in covered with wood grained contact paper.
A savings and loan company in Los Angeles
wanted to spruce up the system as it was visible from the lobby.
IBM gave them the ok to adorned the system
if they paid to have the contact paper taken off the machine.
I pulled my share of the paper off
before the machine was sent to be destroyed.
|
Doing computers in the State of Washington - from Jordan Stedman - Feb 17, 2013
|
I'm a bit of a dark horse here: I got my start in computing by pinning plug-boards for a still-functional Burroughs E-101 in the fall of 1966 – then writing ML (no SOAP) for an imaginary IBM-650 – all at Lincoln H.S. in Seattle. Then I had a brief chance to write some assembler code for an IBM-1620 at WWSU where my uncle taught. Finding a keypunch brought me into contact with Herb Burke, who then owned the IBM-709 from Lockheed Sunnyvale via the Univ. of Wash., operating it as a small service bureau in Seattle – "Puget Sound Computer Service" – where I worked from age 17 to 25. That machine and its sister from WSU – plus a 7094 that I personally reinstalled back in the '70's – are now part of Paul Pierce's collection. (That's "my" 709 in the top photo on his home page.)
We did a few interesting things at PSCS: extended the OpSys and Fortran IV compiler, plotted/drafted maps of defoliant ("rainbow agent") spray missions over Vietnam under contract to the National Academy of Sciences – and resold some used "DecTapes" acquired in a bankruptcy sale (and useless to our purposes) to a couple of young high school students for "a project": the late Kent Larson and a fellow named Bill Gates. From there I went on to an IBM-360 shop (Prodata Systems, Inc) where I wheedled my way into system admin and datacenter manager, piloting upgrades through a National Semi ECL chip-level knockoff of a 3158-3, an IBM-4341/12, 4381/12 and 9221-191, dozens of OpSys upgrades, and build-out of 500-device network using CICS and 3270 terminal technology in both BiSync and SNA/SDLC. We were one of the first implementers of IBM-3380E DASD in Seattle (Wow! 5GB in a large 'refrigerator"!) and an early adopter of 3480s. It was all ultimately ported to a Flex ES emulator running on a Dell server with 120 GB of RAID under UnixWare. I have some interesting stories from my interactions with IBM FEs from that time. – one in particular (Glenn "Jake" Jacobson) actually gave me a "key" to the boxes [key-ring Allen wrench] in testimony of his trust that I knew how to open them up and put my fingers in without breaking anything. He also taught me how to secure and move a string of 3380 DASD and then unlock and restart them without assistance: I paid him back by getting him some interesting employee file commendations and a Christmas bonus. [Interesting story here: one year the company offered this FE a Christmas fruit basket, and he refused it based on strict IBM policy that forbade gratuities. Cup of coffee was okay – but not a fruit basket. So I dug out the name of his manager and I think his manager’s manager, and sent a letter expressing that in lieu of the refused fruit basket we were sending a check in Jake’s name to the local food bank org, Northwest Harvest. About a week or two later, Glenn caught me and said “wow – that letter was WAY better than any chintzy little fruit basket!” I never did learn precisely what he got out of it, but I gather is was manifestly spendable!]
I also did some interesting development projects, creating an application infrastructure under DOS/VSE-->VSE/ESA that would now be recognizable as a rudimentary O-O "com-layer" [~20k lines of COBOL and several thousand in HL-Assembler.] Then I took ownership of first a NetWare infrastructure and then Windows NT at 3.5.1-->4.0-->2000-->2003. I was the primary contact and one of the certified employees for Prodata's MCSP agreement with Microsoft for several years. Prodata (f. 1958) was sold in 1997 and subsequently downsized pretty literally into a garage – and I was forced to look for other work in 2010 so I have been taking vendor contracts at Microsoft since. Currently I am working under contract as a member of the MSIT Identity and Access Management – Domain Controllers team – an admin in all AD domains in MS Corp and providing specific support to Microsoft Retail Store. Well, I can't really say much more about that – except hundreds of domain controllers scattered around the world, running on G8 servers each with 2x8 hyper-threaded cores (32 LProcs) 128 GB of DRAM and about net 1.2 TB of RAID-1+0+S storage. This industry has changed a lot in 45 years, but I am still kicking! (and still broke... sigh)
Jordan Stedman, Shoreline, WA
|
Coding for a new computer, with no other computer for cross-assembler - from LaFarr Stuart - January 9, 2013
|
by LaFarr Stuart When I got to Iowa State (a graduate student in statistics), the Cyclone had been running for a year. It was a duplicate of the ILLIAC, using 5-level paper tape, and its' memory was Williams Tubes (41 of them for 1024 40-bit words of memory and one as a monitor that could be dialed to display any bit position of the 1024 words). There was no parity or error checking in the hardware. During the summer, (before I arrived) they replaced the memory with 4 banks of 4096 words of core memory; and 8-bit paper tape I/O. This caused a major change in the address decoding in the hardware, (2 instructions per 40 bit word, each instruction was 8-bit op code and 12-bit address.) The older memory only used 10-bit address, and much of the software used the 2 high order bits, which were ignored by the hardware, as flags or whatever. After the changes the "New Cyclone" had zero software, and the instructions were being being upgraded when I arrived. But three new Flexowriters were working, and the 8-bit paper tape reader and punch were being connected. Getting a computer going, without another computer to make a cross-assembler, run a simulator, and develop software on, was an interesting experience few have had; and nobody will have in the future. Our input/output was Friden Flexowriters that had no electrical link to the Cyclone whose only input/output was paper tape. We did not use Octal on the Cyclone. We used a form of hexadecimal, that did not use letters of the alphabet for digits greater than 9. It used characters like: , . ; for them. Our Flexowriters were slightly customized to have on one key we called "subten" it was a little "10" lower than most letters; and its hex value was 15. The intended output use of that key was to print large decimal values using a power of ten notation. |
Young, frisky, and learned to fix the IBM-650 from the manual
- from John Falk - July 4, 2012
OK - I was well trained on every system that I was sent out to repair -
But train yourself to understand and maintain a whole vacuum tube based computer system ???
from John Falk - July 4, 2012
My first assignment as a new IBM Customer Engineer was MGM Studios which ran 24/7.
Yep. and they gave me a parking place in the Exec lot where I could park my plymouth next to Rolls and other cars I didn't recognize.
One day I stepped out of the building where Data Processing was and into the little street and Debbie Reynolds almost ran over me in her station wagon. Was all apologetic and dressed in her grundgie clothes.
The guards name at the gate was Ken Hollywood and I learned years later that he was brother of girl I went to high school with in Venice.
I was 21 and lived 2 miles from MGM and took all night and weekend calls at home directly from MGM.
Upgraded the 650 to 4K drum and replaced the 533 with rare 543 reader and 544 punch units. Those were the predecessors of the 1402 read and punch feeds.
When I went to 1301 school in San Jose I ended up teaching the 1402 Punch feed part because of the many hours I spent with the 544.
Short Stories I Can Tell -
from Jay Jaeger - March 25, 2012
That same 1410 had an annoying trait: when it first powered on, the 1403 printer would show a sync check for nigh unto 10 minutes until it "warmed up". Well "formed up" would be more to the point. One day our CE and the crack CE that knew the 1410 inside and out decided to try and figure out what the heck was wrong. They were at it with their scope on the 1414 I/O Synchronizer that the printer was attached to for hours. Finally they kind of shook their heads and laughed a bit. The 1414 had a bunch of electrolytics with leads that fit over wire wrap pins -- probably several per row of cards (presumably bypass capacitors as a guess). It turned out they had all been installed BACKWARDS -- either on "day one" or as part of some CE change earlier in its lifetime. Oops.
That same 1410 had a special interface built for it so that we could communicate with the UNIVAC 1108 main academic computer on campus. The special interface was hooked into the 1410 as though it were a telegraph. 8^) It used balanced line drivers to get the half-mile to the main computer science building. Bruce Orchard (who passed away a year or so ago) wrote a program to make the 1410 look to the UNIVAC 1108 as though it were a UNIVAC 1004 RJE station. We had far and away the best 1108 printouts in town (the normal UNIVAC printers were drum printers -- wavy lines like you wouldn't believe).
Another related story. Our 1410 CE also did 360/370 work. One day another programmer from our 1410 shop that I was working with to do a student records system on a 370 at the Wisconsin Alumni Research Foundation (WARF) entered the WARF building where we did our work on second shift. The scene was of the CE working hard under a 3330 drive (one of the ones that you thru a switch and the drive slid out like a shelf). Turned out one of the day shift 370 operators (or maybe a programmer -- who knows) and put a TAPE LABEL on a 3330 disk pack, and spun it up. Well, of course that label soon separated itself from the pack -- and took out most of the heads.
(The other 1410 story I already told. The UW Computer Sciences department received a donated IBM 1410 from Oscar Mayer here in Madison. I set the thing up using the CE instructions, and it pretty much ran right off the bat. One of the CEs got the Selectric console working, pro bono. The machine was later stored, and over the winter the temperature in the building dropped due to some HVAC / construction work. I set up the 1410 again in another room the next summer. The machine worked, but some of the wires in the core had apparently snapped, and some storage locations no longer functioned properly.)
The Flash that Snapped the Tapes - from Keith Falkner
Mar 24, 2012
The strong flash of light confused the tape drives: they interpreted the light pulse as evidence that the beginning-of-tape marker had passed, and immediately put on the brakes that are meant to stop a low-speed rewind quickly. The four tapes snapped, and the photographer was politely ushered out of the room while the operators commenced recovering from the accident.
Printer Tales
Extra Circuits - from Hans Franke
Oct 14, 2011
Back then (at least for Siemens) banks where the largest customers for
/360ish machines (even before government). Of course they had a need to
make sure that every number send out would also end up on paper. So every
hammer had not only a coil pushing it, but also a secondary coil where the
moving rod created a little blip as feedback. A rather delicate circuit
(*1) now compared the timing, signal strength and form to what was
expected for a working hammer hitting a typeface thru paper and ribbon. It
was a little masterpiece of analog technology.
Anyway, long story short, we got the printer in 1979, after years of
service at the Munich Tax Office, for free. It's been a great improvement
from the 1960s drum printer we used before. We even accepted the 2-5 false
alarms per month we got, no matter how careful the printer was adjusted.
Hans
*1 - you got to keep in mind that 95% of all circuitry in such a printer
was analog and you got literally hundreds of pots to fiddle with timing
parameters - in fact, it was impossible to adjust it right, since most
values influenced each other - I once spend almost a day to adjust one ...
Well, OK, to be honest, I wasn't inclined to do any other work waiting for
me, but that's a different story
Hans' comment about Ed's ribbon story (above) - "Oh, and an addition, the Printer also
had a sensor to determine if the ribbon is
still centered (otherwise printer got stopped) and a sensor to make sure
it's wet (resistance thru the ribbon)"
an IBM 1403 OOPS - from Van Gardner
Oct 13, 2011
It was a very detailed report that listed each empolyee and the hours spent at each cost center by shift worked.
The report was printed on full width paper with Shift number printed in the last 7 print postitions at the top of each page.
One night after the job had been run and printed one of the operators came screaming into the CE room shouting,
"Come look what that 1403 had done to our report". When I looked at it I saw that the F had been left out of each shift number.
The
hammer bar that fires against the back of the paper to print the letter in front of the paper was broken. This hammer bar
was supported by two vertical flat leaf springs and the front one was broken . The 1401 checked that the hammer fire pulse
was sent but had no way of knowing the hammer did not move.
It was an easy fix to replace the hammer but the whole job had to be reprinted.. Ever since then when I see one of those
bumper stickers that says "IT HAPPENS" I think, "It really does".
Van Gardner
an IBM 1403 OOPS - from Keith Falkner
Sept 25, 2011
Here's a simple anecdote that concerns a 1403, which was being driven by a System/360, not a 1401. A man whom I considered clever and insightful was idly looking at a thick report, which consisted of many columns of large numbers. He seemed a bit puzzled, and I asked what concerned him about the printout. He said, "There don't seem to be a lot of sixes in this report."
Well, the pages of the report were numbered, so I turned to pages 16, 26, 36, etc. Sure enough, a substantial number of those sixes were incorrect, all the same digit (but I forget what that digit was). As I knew which 1403 had recently been serviced, I went to that machine and stopped it, then tried to corral all the printouts that it had produced since the Customer Engineers had turned it back to us for use. Then I requested the assistance of a Customer Engineer, who studied the print train and reported that it had been incorrectly assembled.
I think that we (which means IBM's Toronto Downtown Datacentre) were particularly lucky to catch that error before any erroneous reports reached our customers. My colleagues and I tipped our hats to our perspicacious colleague for a long time thereafter.
Techie tip - The printer was a chain printer, with the individual characters as individual
slugs of metal. An option for speeding printing highly numeric data was to place multiple
series of numbers along with a single alphabet on one chain. This almost doubled
the speed of the printer when successive lines were all numeric.
The NUMBERS Report - from Stan Paddock - Sept 25, 2011
In a large shop there was a COBOL program that did not terminate correctly.
The customer did not complain that there was a memory dump at the end of his report.
While the printouts were ok and also the files, the programmers left the program to be fixed at a later date.
When they did fix the program, the customer called and wanted to know "Where is my NUMBERS report?"
Reduce the printer load - from Ed thelen - Sept 25, 2011
The mother of my children began programming at Fairchild. Her introduction
was to ask internal users if they needed all the copies of the reports they were getting.
The universal answer was "YES" even though she could see stacks of computer printed
reports gathering dust in corners of offices - seemingly never opened.
After rounds of attempts to reduce the huge printer work load for internal reports,
management decided to charge the receiving departments by the page for reports delived to them.
She was asked to modify some report, and she made and verified the mods.
The Programming Standards Committee
found that the text of her COBOL comments field in the program started in a non-standard column.
She had to wait another two weeks for the program to be re-examined by the Committee. -
You might imagine that internal users complained a lot about slow responses to requests
for report changes.
1401 and on
- from Lee (& Carol) Veal
Feb 19, 2011
Fascinating stuff.
I learned to program using Disk Autocoder on a 12K 1401 with 2 1311 disk drives, a 1403 (600lpm) and 1402 card reader/punch. I had enrolled at Tyler Jr. College in the fall of '66; in the first semester, our class worked through wiring tab equipment boards (548 Interpreter, 512 Reproducing Card Punch, 085 Collator, 402 Accounting Machine, we had an 082 Card Sorter but no board wiring was required for it) , but then in the 2nd semester we started programming the 1401.
Unfortunately, I never programmed a 1401 in a commercial environment. Because of my detailed levels of study of the 1401, I was fairly easily able to teach myself the S/360's Assemble Language. In 1968, I was drafted into the Army. I started out operating a UNIVAC 1005 4K Card-based (non-disk, non-tape) which had an assembly language called SAAL (Single Address Assembly). There was no facility in the computer for a memory to memory move. Everything was loaded to a register, then operated on memory to register then stored back in memory. The longest data move was 132 characters to the print buffer. Unlike the good ol' MLC and MRCM instructions in the 1401 which were limited only by the placement of word marks or record marks and the amount of memory installed. Every instruction in the 1005 was exactly the same length, unlike the 1401's various instruction lengths which helped to conserve the core memory.
In the 1980s my wife was working for a trucking company in Mesquite, Tx, which was using an NCR Criterion system, the next generation after NCR's Century 100 system. Because of my experience with 1401 architecture and Autocoder, I was able to help her debug a few Neat/3 programs that no one on the trucking company for which she worked had been able to figure out. She was a newbie on the programming staff, so they dumped the program on her. Every time they ran the errant program, it would go into an idiot loop and never come out of it. By studying the program listing she'd brought home, I was able with help from her to get a grasp of the instruction set of the Criterion. She was clueless about the use of index registers, since she'd never programmed a 1401 or any other system that used them the way the 1401 and Criterion did. So, we had what's now called a teaching moment so that she'd know why the changes would work and why the original code was going into an 'idiot loop'.
The Centurion it turned out had several 5-character index registers similar to the three 3-character index registers in the 1401 (as I recall, I think the 1401's were in the memory locations from 81 thru 100 above the end of the card read area (1-80) and below the card punch area (101-180). Anyway, one of the NCR index register was being initialized to point to a table, but it was never being incremented in the table look-up routine to point to the next entry in the table. Ergo, the 'idiot loop'. The first time a 'look-up' was needed, the program would go into an endless loop. The table was hard coded into the program with an argument and several other elements that could be used in various parts of the program.
My wife took the corrected Neat/3 program back to work, made the changes that I'd helped her with. My wife fixed a program that much more experienced programmers had failed to debug and fix. Several other 'unfixable' programs were brought to (dumped on) her. She fixed 'em all. She was a smart cookie and a quick study. I don't remember if she ever told them what she did to fix them, but the other programmers should have been able to see the corrections. For that matter, they should have been able to see what was wrong with the coding in the first place. I mean a student of the 1401 figured it out, and I'd never actually seen a Neat/3 program before my wife brought one home for me to look at.
Good job...
Lee Veal
I remember the 1311 disk drives and how they amazed me. I was blown away by the disk packs having a whopping capacity of 2M characters, 6 platters, 10 surfaces, 20 100-byte fixed-length sectors on each of 10 tracks in a cylinder and 100 cylinders on the removable pack. The ones we used at Tyler Junior College did not have the 'direct seek' feature installed on them, so if a seek from cylinder 10 to cylinder 11 was commanded, then the 1311 had to reset to cylinder 0 and then count out to cylinder 11. Runs of Disk Autocoder for assembling our class assignments really worked the 0 drive. I ran across a manual of RPQ features for the 1401, 1311 and other gear. The programming, as I recall, for the direct seek feature, was not supported in the stock IOCS within Disk Autocoder and there were special disk commands that the programmer had to hard-code in the program in order to take advantage the direct seek feature.
I also loved the macro facility of Disk Autocoder, I even wrote a couple of rudimentary macros. They were far beyond the class-assigned programs, but the prof for the class knew that I was completing my assignments way ahead of my classmates, so, I think he was the one who gave me the 'macro-language' manuals. The only macro-language command I can remember now is 'BOOL', I hope you can cut me some slack, that was back in the late 1960s.
Lest we forget - Analog Computers - and EAI - from George Shrier
Jan 17, 2011
If you look at computer books from the 50s, you'll see introductory fluff about how there are two kinds, analog and digital, but THIS book will discuss digital, etc. In fact, analog computers retained a hardcore following for quite some time, especially among oldtimers who were familiar with the tricks of that particular trade.
"General purpose" analog computers focused on the solution of simultaneous ordinary differential equations, i.e. problems in which a finite number of mutually interacting variables had to be tracked through time. "Programming" a machine meant repatching a plugboard. Programs were saved by physically removing the plugboard and putting it on a shelf.
The big player in this business was EAI, Electronic Associates. After a long delay, EAI realized in the early 80s that the business would keep shrinking if they didn't reinvest in it. They then constructed "SIMSTAR", the last and greatest of all analog computers and the first and only one programmed in software. A compiler would process the user's CSSL program (these languages for specifying differential equations are still in use - for digital computers) and "autopatch" the computer, without any physical movement of wires being necessary.
SIMSTAR sold for several million dollars(!), was the size of two very large refrigerators, and was bought by about fifty customers over the years. I arrived in late 1991 or early 1992, at which time two machines were on premises: The first was an early prototype that was not quite compatible with later machines. The second was the final machine ever built, which was purchased by the U.S. Army in 1990, but which they hadn't yet taken delivery of.
In appearance, the circuit boards were quite dissimilar from those of digital computers. By the time I came, one of the oldtimers told me that the internal expertise was already gone, and that the company would probably have been unable to build another one if an order came in. He himself was keeping very busy scrounging spare parts for old products that were still in use on every continent.
Every obscure corner of digital computer history has been thoroughly fussed over, so it astonished me how little knowledge or interest there was in SIMSTAR. Maybe ten years ago, I wtote Emails to so-called "curators" of computer museums warning of the danger that all these machines would be scrapped; they merely volunteeered to take a SIMSTAR off my hands if I sent them one!!!
All I ever had was contact info. I knew someone familiar with the entire customer list, because he was the salesman and oversaw maintenance of all machines in the field.
Footnote: I came to EAI as a contractor writing a(n optimizing) compiler for the "Digitally Implemented Analog Computer", later called "Starlight". This was meant to be the successor to SIMSTAR. It was a 20MHZ machine that was abandoned right after it had been successfully completed. It also ran a CSSL. Do you remember that ENIAC had 20 registers, but no memory, except for read-only constants that could be set on switches? What kind of problems need a KFLOP of horsepower but no memory? The answer of course, is systems of ordinary differential equations, e.g. trajectory computations.
Likewise, Starlight had no RAM, but rather 2048 registers plus ROMs for storing the program and lookup tables of function values for doing interpolations. Physically, of course, this was all RAM, but it was not writable at execution time. User programs were branch-free, basically giant basic blocks of arithmetic for updating each time step. Ah, what enjoyable stuff!
Alas, Starlight is extinct too. Five copies were sold to a Japanese distributor, but then EAI decided to become a service company doing contract circuit board manufacturing. It abandoned computers altogether.
If you find someone interested in SIMSTAR, I can try to help you find G.V. Aryama, who was the salesman I referred to.
Ed Thelen commenting - Ah - you have reached a sympathetic ear ;-))
The first computer I got my hands on was a military analog computer
which provided computing services
for the Nike AntiAircraft Missile System. (about 1954).
Twelve years later, working for Control Data Corporation (CDC) - Special Systems Division - among other
interesting work, we interfaced with EAI and other analog computers making "hybrid" systems.
But the hand writing was on the wall - digital computers were getting fast enough and less expensive.
And you could change problems in seconds rather than hours, and had outstanding accuracy and stability
and ... CDC also offered a program called "MIMIC" which permitted an analog oriented person
to write in that mind set and do "analog computing" on the CDC 6xxx series. For instance,
you didn't worry about finding a
Runge-Kutta integration routine - you merely gave the integration inputs and initial conditions -
... and magic happened - at good speed too ;-))
"Signs of the times" - the Nike systems (above) were retrofitted in the mid 1970s to all digital - using a
militarized DEC PDP-11 - which, including peripherals, took up 1/2 of one of the 4 cabinets of the
analog computer. The other three cabinets were used for hanging coats ...
A view of the ENIAC and UNIVAC story
LaFarr Stuart and I (Ed Thelen) went to
this conference
and met "Kay" - a very interesting and fun person.
I asked Kay how she felt about John Atanasoff.
Harry Huskey on "You Bet Your Life"
Huskey starts at about 15:00 in...
Wow!
http://gizmo.org/crypt/chm/youbetyourlife500510no4932door_otrcat.com_.mp3
dag
--
Macro Assemblers - on-line telemetry analysis
From a slightly broader perspective -
It was a little like "monitor" for your computer now -
you now (since about say 1990) ASSUME it has color capability. ;-))
The only assembler, released by a manufacturer that I
ever worked with that I am not SURE had macro capability
was the assembler for the LGP-30 in 1958.
Ed Thelen
P.S. a little tale -
(This way, different flight tests could be requested or
delayed during flight depending on what the engineers saw.
More testing could be done more safely per day.
Like crash your prototype, and you have a huge costly delay.
And killing your test pilot isn't so cool either.)
(We heard this system was for the E-14, later the F-14 "Tom Cat".)
A friend who was interfacing with the 1700s decided
to write a cross assembler for the 1700s that ran on
a 6xxx computer. It was, of course, written in FORTRAN
and of course had "macro capability"
because the existing 1700 assembler had "macro capability".
The 1700 group, a contentious competitive group,
said the macro capability didn't work.
"Show me" - well, they had taken an entire 1700 tape
diagnostic program, framed it as a macro,
and the 6xxx based 1700 cross assembler has run out of
macro memory - (FORTRAN at the time did not
have a UNIX malloc command ;-)) and my friend
had assumed "reasonable" macro size and usage.
The 1700 group kept POO-POOing the offered
cross assembler so my friend trash canned it.
Of course, no good deed goes unpunished ;-))
An IBM Career - design of 1401, work on floppy disk, ...
Here are some facts that you don't know:
Ralph Mork was Director or V. P. of IBM's Military division at that time
In Owego NY. When the WWAM program was in dire need for some serious
attention from USA, Ralph was relieved of his job and given the task
of directing an Endicott effort. I never understood why this happened,
because Ralph had no relevant experience and no personnel was assigned
to him.
This turned out to be very fortunate for both me and IBM.
He looked around for help and found only me. I proceeded to do my thing [designing a processor which became the 1401]
with no management from Ralph. I was completely on my own, and I think
Ralph had no idea what I was doing, but he was very adept at shielding me
from distracting
interference. Thus, I was free to get the job done.
I also give a lot of credit to Jim Troy, Manager of the Endicott Lab. When
it
was time to compare different approaches from France, Germany and San Jose,
Jim was always there for me. He really understood what I was doing.
When my [1401] design was finally accepted, a management team was assembled,
Jim Ingram was my manager, then came Chuck Branscomb and the Bob Evans,
all great people and very good at their jobs.
At some point, the 1401 project had grown and I was given a group of 100 or
so
to manage without any management training what so ever!!!
Sheesh! So as you might imagine, I made a couple of management errors.
For instance, I was given a Secretary with a poor attendance record: 600
hours of sick leave per year. She persisted in this behavior so I fired
her, The firing was quickly nullified and I was chastised. A couple of
years later I discovered that she was
promoted to manager of her own department. No explanation given.
After the 1401 was announced and selling like chocolate chip cookies , five
of the
most deserving members of the effort were given first class trips with
their spouses to anywhere they wished to go, for up to three weeks, first
class all the way, all expenses paid, no questions asked!.
I had previously let IBM know that I wanted to work in CA, so when the 1401
was well on its way Chuck Branscomb was transferred to San Jose to head up
a new development of Education Systems. He had me transferred to work on
Process Control. (eventually, the 1800). Then I moved to Education Systems.
Meanwhile, back at Endicott, people working on early 360 systems needed an
IPL device (Initial Program Load) in place of what we now call BIOS.
Somehow, I got the job, along with a bright Engineer named Bob Treseder.
We came up with the first (in IBM) idea of a floppy disk We conceived of
cutting disks
from tape stock and stretching it over a plastic substrate. I designed the
mechanism.
That was the start of the IBM floppy disk. I went on to design a prototype
of IBMs first PC as a component of the Secondary Education system. The
floppy disk was a part of it. Integrated circuits hadn't been invented yet
so the system was slow and expensive. I had some ideas for great
improvements and tried to convince management to create a subsidiary to
pursue the development of Intelligent Terminals
and to use a different pricing formula.
The pricing formula at that time
was outrageous and certain death for small, high volume systems. This idea
went all the ay to the top and was violently rejected. "IBM doesn't do
things that way and never will". Ha.
The floppy disk idea was eventually rejected by the 360 development people
because of the availability of improved circuitry. The development was
transferred to another department where the idea of enclosing the disk in a
paper envelope was created.
This was a good one. Too good in fact because it could replace card as I/O
devices.
This was a serious threat to IBM's multi-billion dollar card business. IBM
issued a clear directive to all development that no system was ever to
include floppy disks, either as I/O devices or storage. Unbelievable, huh?
Alan Shugart was my direct manager while all this was happening. He was no
dummy, so he left IBM (presumably with all the documentation) and started
Shugart Associates!! The rest is history as they say.
IBM didn't get serious about PCs until all this happened and I had retired.
When I retired, I had my own Engineering Consulting business. for eight
years.
During that time I designed about 15 Scrap-metal recovery plant installed
around the world. I also designed disk drive testers and wrote some two
million lines of code to run them.
You mentioned that you went cross-country skiing. Ever do downhill skiing?
I spent the next 15 years designing ski lifts for CTEC. Finally retiring
for the forth
time in 2003.
Well, looking back on all I have written today, I suppose I have told you
more than you wanted to know. =-)
Fran,
Programmer "English" from Dick Weaver March 2008
English instructor?
When he was finished, the now very colorful manual was put on
the shelf in his office. One day his manager noticed the manual, saw
what he had done, and asked for permission to send it to the language
development group. So the manual arrived at our publications
department, who brought it to me saying they could not possibly process
about a thousand comments as a "Reader's Comment Form" and what should
they do.
We had a quick conversation: me "This is the answer!", pubs
"But what's the question?", me "Why is our manual so hard to use". We
launched a rewrite. The exact details are vague now, but over about a
year (there was other work going on) the 300 page language manual was
rewritten to about 200 pages. I did the rough markup and a cut and
paste (at a time when real scissors and real glue were used) on the
floor at home (some text may have been deleted by our cat); a writer did
the rest.
I became a lot more careful about manual wording (and still
made errors) and the writer, in an environment where pages produced was
one measure of his productivity, had a productivity of minus 100.
My English remains bad, but I'm now a nut about not saying things more
than once and always using the identical terminology and phrases
(exactly what we were taught NOT to do in high school English).
dick w
Invisible Ink has its uses
- by Stan Paddock September 2007
They had started this system because tires were turning up missing somewhere in the plant. At each stage an inspector should count the number of tires in a batch and write it on the card under the printed numbers. He could see the original number printed on the card and he got to estimating the count instead of actually counting. Because there were certain defects that would cause tires to be rejected the number of tires in each batch would often decrease.
The day when the invisible numbers started coming out there was flurry of calls wanting to know how many tires should be in each batch. They were told to ?just count them.? They then asked ?how will we know how many there should be, and how many were they were to count, and how will we know if we are right?? The reply was ?Just count them all and we will tell you if they are correct or not.?
Shortly there was noted of occasion a sharp drop in the number of tires in one general area. A lookout room was built in the rafters over that department to watch them. From the high perch they saw a trash truck stopping out or normal sight of the floor level people. They layered the bottom of bed with tires and filled the top with trash. All this with a camera rolling featuring them. A undercover police car followed the truck to a warehouse with many stolen tires in it. The system of invisible numbers worked so well that they continued using it. I remember innocently saying once to another C.E. they used invisible ink to print on their 519. I had to explain the process and reason to him.
How the IBM S/360 Green Card Came About
- by Milton Thrasher June 2006, June 2011
In 1964, I was the Manager of Systems Engineering Techniques Development in the Eastern Region in NYC. The goal was to reduce the number of systems engineers needed by providing tools and techniques to make them more efficient and effective. The newly formed DPD HG SETD Department was headed by Alvin Gayle. He was under Jerry Haddad with 6 to 8 people in White Plains, about 15 people in Kingston and probably 8 or 10 people in each of 3 Regions. They had a long list of proposed products. I did not see many of them as very helpful in reducing the need for Systems Engineers. Most called for programs to be ordered from PID ? the IBM Program Information Department. My theory was that if it was not in the pocket/purse or attach case of the System Engineer, it probably was not going to be very helpful to many.
I was in the Eastern Region with access to the IBM Time Life Data Center. I proposed and got funding for the development of PAT/360, the S/360 reprogramming of a Procedure for Automatic Testing that was available for the 1401/1405/1410 family. It allowed customers to put a series of S/360 Assembler Language Programs on magnetic tape to be tested remotely. A tape could be sent to the data center for hands-off remote operation. The application programs would be compiled and data tapes generated from the control cards. An attempt to execute the application programs would be made after test data tapes were generated from control cards. When the program failed, an automatic memory dump would be written back on the original tape along with the collection from the output tapes if any. The resultant tape would be returned to the customer who could then find the errors and resubmit.
The importance was that System Engineers could stay with their customers and not spend the time to travel to NYC or other data centers to test programs which is very time consuming if done manually. The
Automatic remote testing could be done by mail or by messenger overnight! The savings in travel costs were significant for IBM and its customers.
Because the people I had been assigned to work in SETD had no similar programming experiences, I got permission from Jerald Haddad's staff to use some money saved by not hiring for my staff so that I could hire an outside consultant/programmer.
To do the PAT/360 project, I hired David Goldstein, a former IBM systems programmer who had worked for the Poughkeepsie Programming Center Manager but based at Time Life. He was a very bright and competent programmer who saw a bigger future in contract programming.
Dave and I planned how to convert the PAT/360 System from the PAT/1401 which was the simplest of those available. We took our scheme to the Endicott Programming Center when Earl Wheeler was the Director. He assigned some of his people including Charles Schultz, the S/360 Assembler Development manager to work along with us. Schultz provided a collection of programming aids used to develop the S/360 Basic Tape and Basic Disk Operating Systems which were steps for building Disk Operating System/360.
We were surprised how cooperative this group was because they had a planned comparable but more complex system called AutoTest/360 for DOS/360 users. That system was top-heavy with many more control cards and set up procedures. We perceived that it was doomed to failure if it ever got delivered. That created a political problem that was destined to work against PAT/360 later.
Our new found collection of aids included an early version standalone compiler, disk dumps, tape dumps and a set of diagnostic programs. They came with minimal documentation along with a very early version of the Basic Tape Operating System. Dave Goldstein and I took them to the Time/Life Data Center and we became a small sensation of the time. We got their first System/360 to actually do productive work in S/360 mode! Until then, they operated strictly in 1401/1410 or 7070 compatibility mode.
I adopted the role of a customer developing and testing S/360 DOS programs. I had done some sample assembly language programs for the IBM/1401. I had to relearn how to program in S/360 Assembler Programming Language due to the very complex instruction set with many options. Some programs had to be written in a lower level machine language for performance. So the ?bits and the bytes? were very important. The SRLs, System Reference Library manuals, were very large and not easy to work with. I had a stack of manuals about 24 inches high. We needed a handy reference card so I built it from these appendices and added some tables I created to manipulate EBCDIC.
I knew that the card could not be finalized until a lot of people proofed it by using used it heavily and pointed out more things needed. I printed five versions with ever increasing content on light weight paper that would self-destruct. That way they would eventually disappear. They were printed in larger size fonts than the final card so that they could be read more easily during development.
Dave and I worked many days and nights at the T/L Data Center to get the first TOS/360 to assemble the converted IBM 1401 BAL to S/360 Assembler routines. Dave got excellent cooperation from the Endicott Center because he found and fixed a lot of bugs for them. He also had many good suggestions on how to solve some of their most difficult problems. Soon, the Endicott Programmers realized that they could get a lot of machine time at the T/L Data Center. They sent a small group of programmers to NYC to work along with us. Having close proximity to the developers, Dave and I were able to get PAT/360 running as soon as the Endicott Programming Center made their first release of TOS/360. We were well ahead of their first release of BOS/360.
But, almost as soon as we finished the first PAT/360 Type I program release, we were shot down by the DPD HQ Software Product Marketing Administrators. They thought their job was to only support Type I Programs developed by the Product Divisions. They had a dim view of Type III Programs that were available from PID but unsupported. I was never able to get resources to maintain PAT/360 even though it was up and running and saving people tremendous time in developing Assembly Language Programs. That was because they thought that DOS/360 AutoTest which was only planned, not announced, had specified functions that included ours. It was to be a fully supported program while ours was in the Type III unsupported library. That was very unfortunate because when it was finally released a year later, AutoTest was scarcely used due to its cumbersome control cards and obscure instructions. It introduced more problems than the customers' own programs! It was like a very complicated Job Control Language. Our PAT/360 required a minimum of 3 control cards for each program. It was very stable and did not require much maintenance. The SETD Headquarters group would not allow us to spend any resources or publicize it in their brochures once it was released!
I challenged the DPD Headquarters product administrators to try using AutoTest documents and PAT/360 for tests of actual programs. That was for them to decide which they would use if they were the Systems Engineers on a customer account. They refused to try either system. This was a very disappointing encounter with the headquarters bureaucracy which shaded my thinking and approach to handling future encounters.
A number of S/360 early customers took PAT/360 as their main tool for program development. Time Magazine, housed in the same building as the Time/Life Data Center, was one of our first users. They claimed that even with their close proximity, they were able to get more programs tested and running sooner than they would have otherwise. They gave us a strong testimonial. This gained PAT/360 a lot of new users very quickly that were testing at the Time Life Data Center. Word of mouth and recommendations by the Time Life Data Center Reps was very positive. That was important to me later in my career. Several of the Data Center Reps went on to be my higher level management! They remembered what a strong technical program I had created.
I watched the customer programmers work with their memory dumps to find out what features they needed in addition to what was on the preliminary reference cards. Then, I would talk to the Poughkeepsie publication manager who would consider adding something more to the SRLs or clarify what was written. We had a very symbiotic relationship, particularly with David Ulrich. He was a competent programmer and took a big interest in helping with the pocket reference card development.
After releasing the five iterations of the reference card to customers and documenting their comments, I took it to the DPD Headquarters Technical Publications Department to have it numbered, type set and printed. Alice Gnad, a first level manager, assigned Al Reynolds to work with me to finalize it and select the color. We picked the green for being easier on the eyes for the fine print. The first printing was done in about 10 panels, 5 per side. Not long after we were up to the final 16 panel card which was about as large as could be handled easily.
We found that most programmers had glass desk top covers and put the two sides of the card under glass. That helped account for the huge volume of cards that were needed very quickly. The card was very useful to other than Assembler Language Program. That was because it showed how to calculate with EBCDIC, the base 14 numbering system of the S/360. Each S/360 class was started by handing out the "Green Card" with my phone number on it. This produced a lot of good suggestions.
Knowing that no good deed goes unpunished, I expected things to start happening badly. And they did. First, Al Gayle's headquarters group objected because the Green Card was not on their sanctioned project list. That was even though I did it as an aside to the PAT/360 project with out any additional funding.
Next, Roger Bury, the head of DPD Publications sent a complaint letter to Y. P. Dawkins, Eastern Region Manager stating that a person in his region was producing "bum publications". He meant that they were not authorized and did not go through his product test cycle like other publications from DPD Hdqtrs. This resulted in the Eastern Region?s number two man, the former Western Region manager, coming to visit me to learn about my "bum publication". I showed him the reference card and the steps I had gone through to produce it. I also showed him the list of esoteric projects that I was being asked to staff and fund from my budget which I had refused. After listening to my story, that manager said, "Keep up what you are doing. You are on the right track!"
Very soon thereafter, I got a better job in DPD HQ Software Marketing due to my hands-on work with S/360 software!
About this time, OS/360 was being tried out in the T/L Data Center and found to have significant operating problems. One thing led to another and I was assigned to work on ?usability problems? for OS/360. They were known as Human Factor problems. I was assigned to work with Ted Plaut, Manager of Product Test. He had programmers that identified many user problems before the releases could be approved. They needed fixes as quickly as possible to meet the ever shortening release dates for versions with new peripheral product support.
I went out to the Regional Software Marketing Representatives to solicit fixes from SEs and customers who were able to solve problems locally. We called the project Operational Characteristics Improvement Program ? OCIP. It soon became the banner for getting things fixed. We even dabbled in getting some hardware changes. For instance, the first console was an IBM 1040 typewriter type terminal, not a display unit. Later, we were one the first to support the color displays. That became a great show piece.
Very soon thereafter, Buck Rodgers, Western Region Manager and later IBM DPD President, took notice of some of the things I was doing. He came to White Plains with the Bank of America account salesman, Hal Durett, and their list of usability problems. They had documented 19 things that they must have fixed in OS/360 to allow them to process their "messengers" from their outlying branches by 11:00 a.m. everyday without fail. When Buck Rodgers became DPD President, he remembered OCIP fondly. He gave me a book titled ?The Entrepreneur? as a memento which I still have.
Chuck Ruby, who became a very well known SE Manager, was assigned to follow through with me when dealing with the Poughkeepsie Programming Center to get the fixes they needed done expeditiously. Chuck had a better overall view of OS/360 than most of the Poughkeepsie Programming Center architects and managers. That was because he had to make many local innovative fixes to keep their many S/360 Model 65s running with Reader/Sorters for their check processing. They had the Reader/Sorters on one floor and the computers on the floor above. That was because the dust from the chad of the checks would fill the air and cause the filters to clog if on the same floor. He had a lot of suggestions and some code that could be used by others.
Very soon thereafter, I was given the clout needed to get things moving. Bill Viteck was assigned by Ted Climis as the management link I was to work through. There was a systems planning department with a long list of add-on functions. And, there was my separate list of problem areas. I was eventually given a budget of as much as 5% of the lines of code and 10% of the cost of each module throughout the OS/360 as needed to get the problems fixed. This gave OCIP the authority and creditability that it needed.
Before that happened, George Widding hit upon the idea of putting out match books with the words: ?OS/360 - Performance, Function and Usability? on one side and ?Human Factors Will Be Fixed? on the other side. He came to me with this idea. I immediately took a mocked up sample match book to a neighbor, Terry O'Connell of Westfield, NJ. He had just become an area manager for the Diamond Match Company. He took my order for a case of match books with about twenty to a box. They were delivered in about 2 weeks.
When I got them, I took them directly to Poughkeepsie and had the cigarette vending machines stocked with them and told Don Gavis about them. He said, "That's a great idea!" But, before I got back to White Plains that day, I had a call from the Poughkeepsie Plant Facilities Security Manager. He demanded to know whom I worked for and who paid for the matches. He was convinced that they were very damaging publicity for the Poughkeepsie Programming Center's product. I could not convince him that they would be helpful in getting the programmers to focus on fixing the problems. Very soon, my manger, George Widding was called on the carpet for these matches. He called me at home and told me to confess that he had authorized them. He later told me that the match books were just the last straw. He had been very demanding that Poughkeepsie fix a number of other problem areas beside usability and they were gunning for him.
That one case of match books had a life of its own. Some Poughkeepsie OS/360 programmers reported they found a box of them in Hong Kong. Those who wanted to be in the ?know? carried them in their pockets. Don Gavis claimed that they created a ?state of mind? throughout the development centers which were spread throughout the manufacturing division. IBM Palo Alto, Boulder, Kingston, and Hursley England had large roles to play in OS/360 Development. We had OCIP Meetings at most of the locations to get their managers directly involved. I remember Tom Apple in San Jose Data Management being initially suspicious of our authority but he later became a great proponent.
Glenn Morgan had a Western Region bright young man in mind to replace him. That was Ivan Bowman. He was a very detail man and knew a lot about how the Operating System was designed and how it was supposed to evolve. About a month later, Ivan replaced George Widding who took a job as the Systems Engineering Manager for the Western Region. This was very good for OCIP in that he would call in from cities like Boise, Utah with direct input on how the OS/360 problems were impacting sales.
Soon, each Region was asked to appoint an OCIP representative to work with me in establishing what problems should be addressed. These were OS/360 program administrators only. DOS/360 program administrators were never given such an opportunity because the direction was to try to move all customers to OS/360. That was because, to the very end, Larry Foster and other OS/360 architects claimed that they could produce an OS/360 subset that would satisfy even the small customers. Of course, that never happened because OS/360, like government, never shrinks. It grew by leaps and bounds and the lower model hardware did not provide the memory or performance required by the huge number lines of OS/360 code.
Once large customers found out about the Bank of America getting special treatment, the user groups - GUIDE and SHARE put OCIP on there meeting agendas and demanded to know more about the program. They both met twice per year with working committees meeting between major meetings. So, four times per year, I made presentations of what was being done to solve their problems. We established the discipline to have them vote on the severity and importance of each problem with an estimate of how many customers of which types would be affected.
I quickly gained the reputation as the man to talk to if you wanted to get your problems fixed. I had the problem that IBM was very conscientious about not pre-announcing products. It was the time of the Consent Decree. Our competition could promise the moon but we could only announce things that were eminently deliverable. I had to have all of my presentations scrubbed by the legal and customer relations departments. The Industry Marketing Sector that dealt with consultants was especially sensitive to what I would say. The consultants needed to be in a position to provide the best advice as to what to spend their resources on. The Industry Marketing Director for Consultants took a big interest in OCIP. He was able to bring a lot of IBM management attention and resources to OCIP.
OCIP continued until Release 20 when OS/360 became fairly stable and the need for usability fixes became much less. I made a final presentation to management that we had solved 240 specific problems and had expended over $10,000,000 additional resources over 5 years. They included Checkpoint/Restart, System Management Accounting, remote console support, and improved Job Control Language and ?lost device end interrupt?, a particularly troublesome problem. We gave test code to those accounts that had severe problems so that the fixes came back to us with assurance that they solved the known problems.
The way we wound down the program was typical of IBM. They simply found new jobs for the people involved and terminated the program unceremoniously.
Milton Thrasher
mthrasher@verizon.net
941 966-9172 Sarasota, FL
Milton Thrasher
Please send Assembler Coding Sheet
hi i am student, and i am taking assembler language. I will like to know if you can send me a copy assembler coding sheet.
Reply by Ed Thelen
Actually I rarely used the official coding forms of the
different manufacturers that I worked for -
So -
I typically keypunched/data-entered my own stuff
I normally took a normal writing tablet
with horizontal lines, drew three quick lines vertically,
and went to work.
Have Fun :-))
I entered graduate school at UC-Berkeley in 1956, working for an MA in Statistics. A week after I enered, my advisor reviewed my program with me. He noted that I had a background in biology and asked if I would be interested in biostatistics instead of statistics. I had never heard of biostatistics, but I went to the School of Public Health and talked to Dr. Jacob Yerushalmy. He told me if I changed to biostatistics, I would take the same courses in statistics plus additional courses in public health. That interested me, and I changed. So the day I learned of the existence of biostatistics was the day I changed my major to it.
I got my MA in 1958, and got a job with the Contra Costa county health department. The health officer was on the advisory committee for a research project in tuberculosis. They had given tuberculin tests to school kids in ten California counties and now had data for two years, with repeat tests on 55,000 kids. This was an important study. They needed someone to help analyze the data.
I was interviewed by the research director, Dr. Escholzia Lucia. She knew some statistics but she was primarily an administrator. If I would analyze the data, I would be a co-author of the paper. That was a big deal for me, I had never written anything for publication. I would also learn how to operate the equipment. So in November 1958 I joined the project. Shortly after that I went to IBM school in San Francisco, where I learned how to operate a keypunch, how to use the sorter, and how to wire the boards for various machines, including the IBM 101. When I got back to the office I designed the tabulations, and made wiring diagrams for these tabulations. Eventually, the cards arrived, behind schedule, and then they wheeled into my office a machine that was paid more than I was, an IBM 101 statistical counter-sorter.
The 101 was a remarkable gadget. It had 60 counters (60 separate registers in which you could accumulate counts) and 13 pockets for sorting, corresponding to the 12 rows on an IBM card plus a reject. (The sorter had the same 13 pockets, but the sorter read a single column and sorted whatever was punched.) There was a smaller version of the 101, which looked the same but was called a smaller version because it had only 15 counters. The 101 would do complicated sorts and complicated counts. For example, you could wire it so if there was a 5 in column 3 and an 8 in column 7 it would sort in pocket 1, and so forth, and similarly for the counters. Control cards were cards with a 9 in a particular column. When the machine reached this card, it would stop and print out the totals in the counters. The counters would then reset to zero (you selected which counters would reset). For this study, the counters going across might be the induration (the swelling on the skin at the site of the test) and the sorting might be age of the child. I would put a 9 card on top of each batch of cards in the pockets, pull them out in order, and run them again. The output would then show induration by age, with the totals on the top.
The machine was a pleasure to work with, except for a few not-so-minor problems. The worst problem was my feet. I have flat feet, which kept me out of the army, and also means I can't stand for very long. The machine read 450 cards a minute, the hopper held about 500 cards, and each pocket held about 500 cards. When the machine was running, it was impossible to sit, I was busy all the time. A single pass for 55,000 cards took more than two hours, and a box of 2000 cards weighed ten pounds, so I was working hard. One pass would almost finish me for the day. As we ran the cards, they got worn, and occasionally they would jam. There might be 2 or 3 cards that were bent or torn, and had to be repunched. The study used about 30 or 40 columns in each card, not all of them adjacent. They did not budget for a real keypunch, so we had an IBM 10. That is a little desktop that takes one card and had 12 keys (one key for each position in the column) plus a spacebar. To repunch, we would put in a card, space to the first column used (bang, bang, bang on the spacebar), punch the number, space to the next column, etc. It didn't print, so we would pencil in the numbers above the punches. An office a couple of blocks away would let us use their keypunch, and sometimes I would go there clutching a handful of cards.
When the study was finished, the paper was written by the physician heading the tuberculosis control program for the state health department, which had put up the money. The co-authors were a county health department physician and the head of the California tuberculosis association on whose premises the work was done. None of the four people who did the analysis were even mentioned, not even Dr. Lucia. You would have thought, from the paper, that the three co-authors personally tested each of the 55,000 kids, and they took turns feeding cards through the 101. The paper was not well written and it ignored what I thought were important findings of the study, but that is a different story.
Pioneer Business Programming from
Gerry Jean
I'd like to know if you could direct me in finding any text/photos of
the Pepperell installation. I've tried the Pepperell web sites but the
company has gone through at least two acquisitions that I'm aware of and
I haven't any luck trying that route.
The technical people that Pepperell had at various branches still had IBM tab
equipment and, naturally, only could think along that technology. Again, the
tech staff at the B205 NYC site consisted of, besides the keypunchers, we four
programmers. We had no expertise (nor the staff) to properly coordinate
systems at the computer site and the branch tab shops. Burroughs
didn't/couldn't provide any meaningful assistance in the design area ... in
fact, our tech rep support only lasted through the summer of 1956 ... we went
it alone after that.
We were truly all pioneers!
Stretch crew car thieves ??
from Jack Worlton Nov 2015
We were having trouble with random memory errors that drove us all nuts for a long time.
Finally someone (I don't remember who) suggested changing the oil in the memory,
which we did and it worked! The problem turned out to be a bit of solder that was
circulating in the oil, and the oil change cured the problem. We always like to point
out that it was the only time a computer problem was solved by giving the machine an oil change,
I don't remember exactly when, but it happened in Poughkeepsie while Stretch was
still in the late checkout stage. It would have been in the winter/spring of 1960/1961.
We did no classified work on Stretch in Poughkeepsie, at least that I was aware of.
Another odd story concerns the time we were accused of being auto thieves. We were
working in the wee hours of the night, and when our time was interrupted by the
engineers for their work, we decided to go get something to eat. Problem was we
didn't have a car, so one of the engineers offered his keys so we could drive to
a restaurant. We went out and found a car meeting the description we were given,
the key fit, and off we drove. When we got back, there was a Sheriff looking into
a stolen car incident. It turned out that there were two nearly identical cars
in the lot and we picked the wrong one, and the key fit both cars. So at one time
the Los Alamos Stretch crew were accused of auto theft!
Jack Worlton
Telephone 411 support, with IBM 360 Mod 50
- from Hal Murray July 2016
PacBell didn't have room for us in the main building so they rented space a
few blocks away. The CPU was a 360/50. It had 3 2314s with the dual channel
option and 3 data channels. (The 2314 was the big brother of the 2311. It
had twice as many platters, probably more bits per platter. It came in a big
package with 9 drives, 0-7 with a spare.)
The machine room was spacious. So was the coffee area.
I got there a few days before the CPU arrived. The tapes and disks had been
there for a while. The controllers were smart enough to exercise the
read/write and mechanical parts. The CEs had that stuff all sorted out.
I wasn't there when the CPU came down the freight elevator. (We were a half
floor below ground level.) The CEs had it mostly together when I arrived.
I saw a big hammer on the top of a tool box. It seemed a bit strange so I
asked the guy. "That's our door fitting tool."
After a while, they turned power on and some breaker blew. This machine had
384K. (128K wasn't enough. 512K was too expensive.) This was one of the
first ones shipped. These guys had never seen one before. The documentation
hadn't been debugged yet. They scratched their heads for a while and
rewired something in the power area and then power stayed up.
They pushed the boot button and nothing happened. Then one of them said "Did
we reseat all the loose cards yet?" They turned power off. There were 3 or
4 CEs. They opened up the CPU logic wings. The cards were behind air-flow
covers about 8x10 inches with plastic plungers in the corners. They would
open up a cover and tap each card with the back of a screwdriver. If it
didn't sound solid they would reseat it. There were occasional shouts of
"got one" and occasional rattles as a card fell out when they opened a cover.
After that, they tried booting again. It worked. I did the sysgen that
evening.
I got to know most of the CEs reasonably well. There were 4-5 of them at the
local office. It turns out that most of the 360/50s in the area were at
banks. Banks wouldn't give them the time of day. If the machine was idle we
would let them play. I enjoyed working with them. They spent a lot of time
at our place. Sometimes just drinking coffee and BSing. Our system worked
well.
Several years ago, I found a blog by the woman who was the chief operator.
PacBell obviously wanted this to work. They picked good people.
There were 2 56 Kb lines from their main building to our place. One went out
the back door and the other went out the front door so a backhoe couldn't get
them both unless it was right next to our building.
Back then there were 1.5 million phones in 415. It was something like 3/4
million residential, 1/2 million business, and 1/4 million government. Part
of our job was to write hack code to extract what we needed from the tapes
used to print the phone books. We had one guy working full time on that.
We got a tour of the directory assistance work area. There were rows of
booths. When you called 411, and the operator asked "What city please?", she
really meant "Which phone book?" There were 6 or 8 books on a rack in front
of the operator. They were reprinted every week or so on a staggered cycle.
The new listings had a big black dot next to them. There were a few sheets
updated daily with the changes since the books were printed and a few more
listings in large print on a chalk board at the end of the room for panic
cases, like a new restaurant that got screwed up. The walls of each booth
had the most-frequent requests.
Our promise was that if you gave us 3 characters of the last name and 3 of
the first name or street name, we would return a page of answers in a second.
That was based on their statistics and simulations by a guy at Bell Labs.
It turned out to be slightly optimistic. After a short preliminary test, we
reloaded things with another character.
Odd CRT Terminal - from Michael Albaugh
July 2016
They used "Transformer" memory for the read-only
character generator, and MOS shift-registers for
the display buffer (characters, not bitmap. memory
of any kind was pretty expensive). The CRT was
oriented "portrait", rather than "landscape", and had
_four_ yoke drivers (and four sets of yoke windings, of
course) the "main" yokes swept the beam in a course raster
that covered every character position, while the "tweeter"
yokes swept the beam within a character position. Pixels
for any given character were painted top to bottom, left
to right.
The "left to right" of course was partially
due to the "main" yoke deflection, but the tweeter horizontal
would normally counteract it to make the columns of pixels
vertical. You could set a bit in a character to alter
that tweak, to make oblique characters. The keyboard
was also, "interesting". Neither QWERTY nor DVORAK,
but somewhat phonetic. I once knew the name, but "senior
moment" sigh.
Anyway, think along the lines of Soundex
coding. For example, there was a "SH/SCH" key. We were
told they had been part of an experimental "Directory
Assistance" project, and had come from Oakland.
I don't know whether I had correctly guessed that
they were more likely for intercept operators.
We were never able to actually put them to use,
because the interface was some sort of serial line
_to_ the computer they had been connected to, but
the _from_ side was a couple fairly fat parallel
connectors, with what appeared to be the sort
of 91 ohm skinny coax I had seen in some IBM equipment.
We had good docs for some of the analog stuff, but
none at all for the interfaces, so we gave up.
2) The reason I mention intercept operators is
that's what it appears Hal's group was doing, (see story from Hal Murray above)
and that a friend of mine (sometime about 1977
to 1981) was working for George Litho in SF.
They were one of the first big printers to do
computer typesetting, and got the contract to
print the intercept books Hal mentions. They
would get (weekly?) tapes from PacBell, then
typeset and print them on the graveyard shift.
My friend had written the custom code for this,
and being a diligent programmer (and having had
some odd gaps in the output, missing records, etc.)
put in code to log when the input validity checks
had skipped a record to the console terminal.
The next production run, he got an urgent phone
call from the graveyard operator. The console printer
was "going nuts" and the job was stalled. He talked
the operator into disabling error logging (patch on
the running program?) so the job could complete.
next day he changed it to only log the first n
errors of any tape. The sales guys had talked
the customer into paying extra to get those logs,
and I think it was quite some time, if ever, before
they ever got one with less than n errors logged.
Of course, this was all around the time when both
normal directory assistance and intercept were
being consolidated into a few regional offices,
so it was no longer possible to dial 411 and
ask for "that hardware store down the street
from the H-street C.O." and get the answer.
The end -
I, Ed Thelen, paint the environment of the
mid 1950s through early 1960s computer era - and maybe sales/service life in general -
Sometimes
He is told to fly to Chicago to teach a class on
XXYYZZ the following Monday morning.
Victim - "But I know nothing about XXYYZZ !?!"
Boss - "Are you going to waste this weekend ??"
The local FE is told to install and maintain it best he can.
I had that happen several times with G.E. - long nights -
Nike Fire Control system,
General Electric 225 computer system.
But not everyone was so lucky -
I used this manual [see below] to teach myself how the 650 worked.
IBM form 22-6284-1 - IBM 650 Data Processing System - Customer Engineering Manual of Instruction
- 5.2 MB .pdf file .
A plus about having MGM for an account was eating in the Commissary with the stars
and going out in the back lot to watch filming of Ben Hur
For example, the weekend after I was hired at the University of Wisconsin School of Business as an operator on their IBM 1410 (which they had acquired after the UW Registrar upgraded to a 360), I went in to practice a little. Machine just would not cooperate. Red lights and error printouts on the 1415 Selectric console like crazy. I assumed I was doing something terribly wrong, but I left a note, and headed off to my girlfriend's apartment. I got a call that afternoon -- in fact the machine was really broken, and the errors were all real.
Not every photograph of a running computer system is a success. In the mid-1950s, Confederation Life had a fine 704 system on Bloor Street in Toronto Ontario Canada. A professional photographer, using a press camera with an immense flash bulb, took a picture of that system at the end of a long sort run, while four tape drives were doing a high-speed rewind.
worn ribbons - from Ed Thelen
Oct 18, 2011
Trying to assure that the correct marks
actually get printed on the paper is always a serious problem.
One day ( in 1962 ) I got an irate call -
The dollar amounts on a long billing run were mostly invisible !!!
The printer ribbon on the G.E. printer had gotten worn on one side.
(Typically the left side)
The worn ribbon had pulled/drifted to the left,
leaving the right hand side print hammers with no ribbon.
The billed dollar amounts were on the far right of the forms, invisible.
There wasn't a thing I could do other than recommend:
- more frequent ribbon changes, - expensive to the customer -
- manually rewinding the ribbon "left to right" to balance wear -
( a messy tedious process
I demoed how to do it - once !! )
- more operator care and observation
( The IBM 1403 printer downstairs had the
printer ribbon automatic lateral reposition system
and likely would have printed completely across the forms.
- another black eye for G.E. )
Reminds me of a printer we got around 1979. The incident Van [ next letter below ]
notes might not have been so rare at all. Otherwise the HFÜ or
Hammerflugüberwachung (literally Hammer Flight Control) wouldn't have been
invented in the mid 60s.
( the 1403 was probably the world's best "line" printer, BUT ;-))
In the late 1960s when Lockheed was building the C-5 there were over 30,000 people working there.
The second most important computer program that had to be run each week was the one that printed the pay checks.
The most important job was the report sent to the Air Force to justify each man hour spent on each project .
The Air Force had to accept this report before they would deposit the money in the bank to make Lockheed's checks good.
Some day I want to ride my motorcycle from Florida to [Computer History Museum, Mountain View]
California to see those
wonderful 1401 computers in operation. I have greatly enjoyed the simulators
I have downloaded and programmed since joining this forum.
A real case from way back when.
Long ago - in Silicon Valley - when Fairchild Semiconductor was a big player
The printer work load for internal reports was quickly cut in half. ;-))
re: 1401 Restoration
I saw your antique computer web site, so I thought I'd pass on a bit of frustration, even though it's doubtful you can do anything about it. Maybe you have more contacts than I do, but it's probably already too late.
"The Kathleen McNulty Mauchly Antonelli Story"
including a view of ENIAC and UNIVAC. A short autobiography by the wife of
John Mauchly, a co-developer of ENIAC and UNIVAC
a bio on wikipedia
(The court found that John Mauchly had gotten ideas from John Atanasoff but had not mentioned that
in the patent. This was one of the reasons for
invalidating the Eckert-Mauchly patent.)
Kay stated that " no one mentioned that name in her house."
This is absolutely brilliant: Harry Huskey on "You Bet Your Life" (host:
Groucho Marx!), ca. 1950.
There was quite a discussion as to whether an assembler with macro capability was a "compilier" in the IBM 1401 world. Some folks
figuring an assembler was a "one line, one machine instruction" language.
In response to questions by Robert Garner.
Robert B Garner wrote:
> Dick,
>
> Thanks for your great feedback (as always).
>
> Were you an English instructor?
> Don't you know that programmers can't write and shouldn't even try!? ;-)
>
> I'll incorporate your feedback this evening and resend.
>
> - Robert
All IBM 519's had a device that could print on one end of a card up to nine numbers on one line or the other. What printed was under the control of the wiring of the control panel. One day one of the operators handed me a card and said that the end-printer was printing incorrectly. I could see nothing there and I said ?don*t you mean not printing at all.? He repeated his statement and escorted me over to a dark closet then turned on a UV lamp. Then I then could see the error in the glowing number. They were using invisible ink. The ribbon in the machine looked like a strip of oily white cloth. By the time I finished the repair my hands were glowing under the lamp as much as the printing.
I find that many remember the "Green Card" from the 1960s. It is the pocket reference card for the S/360 instruction set and the many other things that programmers needed to know. It was perhaps the most significant thing I did at IBM in my 35.5 years considering its overall effect It was the most heavily used publication in the 60?s and 70?s. It was later changed to a buff color but continued to be referred to as the "Green Card".
mthrasher@verizon.net
941 966-9172 Sarasota, FL
----- Original Message -----
From: Milciacruz@aol.com
I'm sorry -
It just is not practical for me to do that.
- after a few hours, part of your writing hand
would be blue, black, or green- depending
They typically put rows of 80 little boxes
on the page, landscape mode (sideways)
Allowing for borders, this made very small boxes
and confusion if your hand written characters
touched the edges of the little boxes
This saved
Column
Column
Column
Column
1
2
3
4
Symbol
or blank
Op Code
Operand
Remarks, lots of remarks
( need lots of remarks because
my memory is very bad.)
. . . .
. . . .
. . . .
. . . .
. . . .
You asked me to tell you about my experience with the IBM 101. Here it is, at length.
In January, 1956, I was one of 15 or so people selected by my employer,
Pepperell Mfg. Co., headquarted in Boston (I was then working at the
Lewiston, Maine finishing plant) and sent to NYC for two weeks of
indoctrination/training on the Datatron 205. Our instructors were Paul
King and Gordon Lovelace. With Electrodata/Burroughs input, Pepperell
selected the four least confused attendees, I being one of the four. We
started to design and code a basic order/invoicing system, taking all of
1956 and 1957. One of the four selected was already a New Yorker; the
other three of us moved our families (Long Island) in the spring/summer
of 1957. The 205 was installed in 1958 in the Wurlitzer Bldg. on 42nd
Street (at Times Square). Alas, it was uninstalled in 1960 because of
(1) inordinate machine downtime, and (2) poor system support systems at
the various company branches.
> a) do you still have documentation on the Datatron 205?
Unfortunately, no. I'm always on the lookout for some whenever I browse
through old computer stuff in a dusty old bookstore.
> b) what language were you using to code the
> order/invoicing system
Machine language. (64 = clear & add; 04 = change on non-zero; etc.) I think
that Burroughs' first assembly language was STAR, which was initially
available on the B220.
> c) could you amplify on
> (1) inordinate machine downtime,
It seemed that the maintenance engineers had more time with the B205 than we
users did. In order to run our production programs, Pepperell had an
agreement with Atlantic Mutual Co. (marine/hull insurance), also in NYC, to
use each other's B205 off-hours to keep our production systems from falling
too far behind. The order processing was never able to catch up to the
backlog.
> (2) poor system support systems at
> the various company branches.
In 1956-57 I don't believe there was even the position/function known as
system analyst ...... certainly not any text books available. Burroughs had
assigned a "tech rep" to work with us ..... Ira Rubin (who went on to be a
fulltime professional bridge player). Ira was a mathematician by training and
he tutored us as though we were all well-versed in that discipline. For
example, instead of the flow-charts checking "new order # GEQ previous
order#", we were taught to use "n sub-prime 1 GEQ n sub-prime2". The point is
that even our system designs were tough to follow & required constant
referencing of a legend to decipher n, a, x, tt, etc. Don't forget that we
were extreme babes-in-the-woods ...... just like youngsters, we looked to our
tech. rep. as our guru and believed that this was the way to do things.
I was reading your notes on the Stretch machine when I came to the part where it noted
that the core memory was immersed in oil. The following anecdote came to mind.
PO Box 171236, Salt Lake City, UT 84117
Jack's cell: 801-608-2727
Computer Corporation of America had a data base package.
In 1969, we got a contract with Bell Labs to
build a prototype directory assistance system. It was run at PacBell in
Oakland. 4 of us (half the company) moved out here for 6 weeks or so. We
rented a big house in the edge of the hills. I walked it occasionally but it
was a long walk.
1) When I worked at the instrument shop at U.C. Berkeley
(E.E. department, Cory Hall), we got in some very odd CRT
terminals. This would have been about 1971 or 72.