Navigation: [Next Page] [Previous Page] [Contents] [My Writing Page] [My home page]

Copyright © 2004, Glenn Story

The Army

It was shortly thereafter that my friend Dave told me he had heard about an opportunity to let the U.S. Army pay for one’s college education.  He and I decided to go check up on it.  Here is a document I wrote a few years later describing what happened.




For some reason, I stopped writing at that point.  To continue the story:  I passed the pre-induction tests and planned to enlist with a guaranteed slot in an Army computer-programming school.  However, whenever the recruiter tried to get us slots he always got back the response, “no quota available.” 


In those days, which were during the Vietnam War, there was a military draft in the U.S.  I was deferred from the draft because I was a college student.  However, I didn’t enroll for the spring semester in anticipation of my coming enlistment.  When the draft board found out about that, they pulled my deferral.  This meant I had better enlist soon or I would be drafted.  If drafted, I would have no guarantees about the kind of job I would get.


The local recruiter suggested that Dave and I go talk to the Army Security Agency recruiter.  Because of their classified mission, they had their own training schools, their own recruiters, their own everything.    When we went to see the ASA recruiter he wouldn’t tell us much about what they do.  Nor would he guarantee that we would get computer training, “but we always try to give people what they want.”  While this may be true, the fact is that the ASA would never have accepted either Dave or me into their computer-programming school because it had entrance requirements (previous computer-operations experience) that we didn’t have.  But, of course we didn’t know that at the time.  And since we were getting desperate to avoid the draft, we decided to sign up.


The army also had a “buddy enlistment” program that guaranteed that Dave and I would attend basic training together.  So Dave and I ended up at Fort Ord, just outside of Monterey, for our Basic Combat Training.  


After basic training comes advanced training in the specialty to which one has been assigned.  “Buddy enlistment” didn’t guarantee that we would end up in the same place for advanced training, but in fact we did:  Fort Devins in Massachusetts.   Dave was assigned to “Electronic Warfare Equipment Repair School,” and I to “Morse Code Intercept School.”  Neither of us, you will note, got computer training.


While I was at Fort Devins I decided I would start learning about the IBM System/360, so I ordered some documentation from IBM.  In those days IBM often gave away documentation and even software, although technically there was supposed to be a charge for it.  I didn’t care either way. 


The documentation for the IBM 1620, the computer I had been using in college, consisted of two manuals:  one for the hardware and one for the software.  And, one could get by without the hardware manual.  The chapter on SPS (the assembly language) described the 1620 machine language as well.


I wanted to learn the System/360 machine and assembly languages.  I noticed there was an assembly-language manual so I ordered that.  But when it came, I found out that it didn’t describe the machine language at all.  For that I would need to order another manual, the “Principles of Operation.”   And to figure out how to do input/output I would need several other manuals.  And to figure out how to operate the computer several more.


I ordered a second batch of manuals, and from that I determined I needed a third batch.  I was sending these orders to the IBM office in Boston.  It turns out that IBM had a field representative on assignment to Fort Devins because the ASA programming school was located there.  So when my third round of orders arrived at the IBM office in Boston, instead of mailing me the requested manuals, they sent them to their representative along with a note to find out why I was ordering them instead of going through him. 


So the IBM representative called me.  His office was in the building where the programming school was held.  One needed a top-secret clearance just to get in that building, and my clearance hadn’t been processed yet.  So he had to come outside.  This building had all its windows painted black.  Around the building was a tall fence with barbed wire at the top.  And around the fence, was another fence, also topped by barbed wire.  Between the fences were guard dogs.  And the entrance was guarded by a young marine.  When the IBM guy came out of this building with a pile of papers (the manuals I had ordered), the guard was pretty nervous.  For all he knew, this guy was handing me a pile of secrets.  But of course he wasn’t, and I guess the guard realized it from overhearing our conversation, because he let me have the manuals. 


The IBM representative tried to talk me into enrolling in the programming class.  I went back and talked to my company clerk with that thought in mind.  But my company clerk talked me out of it, saying not only would I be turned down, but it would look bad to the instructors for the morse-code class I was already enrolled in.  I suspected he was just too lazy to type up the request, but I nevertheless took his advice. 


When I completed the morse-code school, I was assigned to the 4th U.S. Army Security Agency Field Station (“Kagnew Station”) in Asmara, Ethiopia.  (“Kagnew” is the Ethiopian word for “gazelle”.) 


There were no computers in Ethiopia.  When I mentioned computers to an Ethiopian friend, he said, “I was once one.”  To him it was a job, not a machine.  As a matter of fact I believe we had, in the enlisted-men’s club the only juke box in east Africa.  Nevertheless I spent some of my spare time studying the assembly language for System/360.  I had a book on the subject, plus a training manual from IBM. 


After I had been in Asmara for a while I heard an advertisement on Armed Forces Radio:  re-enlist for the school of your choice.  Of course, I had tried that route without success when I originally enlisted, but this time, I was in no hurry, so I went to see the re-enlistment officer for our post.  He explained that since I had originally enlisted for four years, I would have to re-enlist for four years.  But the new four-year period would start as soon as I signed the papers, so it would really only add about a year to my total enlistment commitment (since I was by then about a year into my first enlistment). 


My company clerk filed the necessary request for the school and I waited.  The request got lost.  It was submitted again.  The Army Security Agency thought I was enlisting in the ASA programming school and they turned down my request on the grounds that I didn’t have the required background—proving that the company clerk at Ft. Devins had been right.  So I filed a third request explaining that I wanted the regular army programming school, which didn’t have the same prerequisites.  This final request was approved and I re-enlisted.


So in August 1968 I came home from Ethiopia, spent a month of leave in L.A. and then went off to the army programming school at Ft. Harrison , Indiana.  There I learned assembly language for the IBM 1401.



The 1401 was a contemporary of the 1620.  Whereas the 1620 was oriented toward scientific and engineering problems, the 1401 was a business computer.  Like the 1620 it used decimal addressing and arithmetic, but it did not use in-memory addition tables.  (In fact, I’m not sure how it carried out its decimal arithmetic.  It had six data bits per memory location plus a word-mark bit (similar to the flag bit on the 1620) and a parity bit.  With six data bits you could store an alphabetic character in one memory location.  There were actually two assemblers:  SPS and Autocoder.  The latter was more flexible and was what most people, including the army training school, used.  Disk drives were not standard on the 1401, and we mostly used tape drives instead.


Here is a sample autocoder program from the army class:




I guess the army didn’t teach us to put comments in our code, so I have no idea what this program did.  Just printed a report basically.  In fact we were under time pressure to get the project done.  Moreover, the army announced that whoever got the highest marks in the class would be given their first choice of duty assignments after class.  Since I had a girlfriend in L.A. I was hoping to land an assignment there.  In fact I was faster than my classmates in finishing the assembler assignments because I knew how to patch machine-language code and could thus avoid the 20-minute assemblies every time I found a mistake in my code. 


In addition to assembly language, the 1401 supported FORTRAN, and COBOL.  We learned the latter in the programming class. 


We also learned the assembly language for an obscure semi-computer known as a Univac 1005 accounting machine.


At the end of the training, I did end up being number one in my class.  But there were no assignments in L.A.  The closest to home was at the Presidio of San Francisco. 


At the Presidio I worked on computers from RCA, the 301 and the 501.  All our programs for the 301 were written in assembly language, while 501 programs were in COBOL. 


In some ways the 301 was an analog of the IBM 1620:  It had in-memory arithmetic tables in order to do decimal arithmetic.  It also had an in-memory print table to tell it where the letters were on the printer.  The printer was a chain printer:  all the characters were on a loop that ran around two gears at either end of the paper, like a bicycle chain.  As the correct character would move past a print position where it was supposed to be printed a hammer would fire to press the character against an inked ribbon and then against the paper.  If a program cleared the print table, it would cause the computer to fire the hammers for every print position at every position of the chain.  Every hammer had a fuse and this rapid firing of the hammers would blow the fuses.  There were 132 print positions.  So the simple mistake of clearing the print table and then printing would blow 132 fuses.  This did not make the operators who had to change all those fuses happy.


The 301 ran one program at a time, and the program was loaded from magnetic tape.  In order to start a new program the operator would mount the tape and then perform these steps from the system console:  (1)  Turn on “single-instruction” mode so that the computer would stop after each instruction.  (2)  Key in (one bit at time) a tape “read forward normal” instruction to read the first block of the tape into memory.  (3)  Press “Run” which would execute that single instruction and then stop.  (4)  Turn off “single-instruction” mode.  (5)  Key in (again one bit at a time) a transfer instruction to branch to the memory location just loaded from tape.  (6).  Press “Run” which would execute the transfer instruction and then execute the code that had been loaded from the tape.  That code would then load the rest of the program. 


Another strange feature of both the 301 and 501 is that they used ľ-inch magnetic tape whereas the industry standard was ˝-inch tape. Moreover, while standard tape drives used “vacuum columns” to handle the sudden starts and stops that the tape drive would make, the RCA drives just piled a bunch of tape into two bins:  one for the feed reel and one for the take-up reel.  It was very time consuming to thread the tape through these bins and so, instead a long piece of tape was left threaded from just before the bin for the feed reel, through that bin, past the read/write heads, through the bin for the take-up reel and onto the take-up reel itself.  Then when the operator wanted to mount a tape, he would splice the end of the tape onto the aforementioned section of tape that was already in place.


At the Presidio I worked with a mixture of other soldiers (most of whom were draftees) as well as government civilian workers.  Most of the soldiers were draftees who had had some programming experience in Civilian life.  Most people in the army (increasingly including myself) just wanted to do their time and get out.  As for the civilian workers, they were career civil servants.  A lot of them were lazy or under qualified.  Once you got a government job it was almost impossible to be fired.  I remember one of them telling me how hard she thought programming in the private sector must be—you had to worry about things like how well your program performed.  There were a few civil servants who worked hard;  they carried the load for the rest of them.


Our main application at the Presidio was personnel accounting.  Every day in every company in the army, a company clerk would fill out a form called the “morning report” which could include a list of everyone in the company who had changed status in any way:  joined the unit, departed, went on leave, came back, got a promotion, etc.  These morning reports all came to us where they were translated into a computer-input format by “coding clerks” who were all soldiers.  We kept a master file of the status of all soldiers stationed in the 6th Army on tape. 


One of the things we frequently had to do was match a set of punched cards to our master file.  These punched cards represented a list of soldiers, sent from the Pentagon, which had somehow gotten “lost”.  The army had lost track of their whereabouts.  These requests were always ad hoc and so we didn’t have a program available to run the match.  It required custom programming each time.  These requests were, however, all similar so I designed a program that could take selection and reporting parameters, similar to the IBM language, RPG.  I called this program, “Tecgen”—“Tape Extraction c--- Generator.”  I even put on a PR campaign:  “Tecgen is the wave of the future.”


These were the days of batch processing.  We would submit our programs on “coding sheets” to a key-punch operator who would punch them into cards.  (I want to call them “IBM cards” but this was an RCA computer;  the card format was, however, the same.)  We would then submit these decks of cards to be processed later.  When they had been run, the deck and associated printout were returned to us.  If there were errors, we would submit it again.  Typically we would submit source programs to be compiled which would create an object tape.  Then we would submit a request to run the test program.  We generally got one, maybe two, “turnarounds” a day.


While I was at the Presidio the Army decided to convert to using “third-generation computers.”  (“Third generation” was a term that I believe IBM invented.  The first generation was vacuum-tube computers; the second was discrete-component solid-state computers, and the third generation used integrated circuits—where one “chip” contains multiple electronic components.) 


The model the army chose was the Burroughs B3500.  I was chosen to be the one to learn about the new machine;  I was sent (along with a civilian, named Ed, to a Burroughs school in Atlanta, Georgia.  The main thing I remember about that school was that it was unbearably hot and humid and so we spent all of our time either in our motel room or the classroom or in the motel restaurant, all of which were air-conditioned. 


The B3500, like the System/360 had what we today would call an operating system, although at that time, the term was specific to the IBM software, OS/360, previously mentioned.  The corresponding Burroughs software was called the MCP which stood for “Master Control Program.”  (Ironically, Walt Disney later came out with a movie (“TRON”)  about computers wherein the Master Control Program was the bad guy.) 


The MCP was what we would further describe as a batch operating system.  It read “jobs” from the card reader.  These jobs consisted of control cards, each of which contained some kind of command, and data cards.  The data cards could include a source program to be compiled.  Object programs were stored on the disk.  The B3500 also had a Teletype machine for a console device, used by the computer operator to control the machine.  The “language” used for entering operator commands to the console was separate from the command set used for control cards. 


I believe all the operator commands were 2 characters.  This foreshadows the terseness of Unix commands, and for similar reasons:  a teletype (also the original Unix input device) was not easy to type on:  it had a very stiff action and long keystrokes.  Moreover, its mechanical nature made it slow.  I could probably type in excess of 50 words per minute in those days and the teletype couldn’t go that fast.  Thus it was very desirable to keep typing to a minimum and so short commands were invented.


The main language used by the B3500 was COBOL.  In fact the machine-language was optimized to support COBOL.  There were no registers and instructions could contain one, two, or three operands;  it was the only machine I’ve ever worked on that had three-operand instructions.  Thus one could translate a COBOL statement like:




using one machine instruction.


Fortunately for me, unfortunately for the Army, not long after I finished my training on the B3500, I received orders to transfer from the 6th Army Data Processing Center at the Presidio of San Francisco, to the 2nd Logistical Command in Okinawa.  (I say “fortunate for me” because it forced my hand to marry the woman I was seeing at the time, Dixie Chow.  “Unfortunate for the Army” since their Burroughs training was largely wasted on me.)


The U.S. Government, including the Army went out of their way not to buy IBM equipment, since IBM held a virtual monopoly on computers at that time, and the government (which the Burroughs teacher had told me was Burroughs’s largest customer) wanted to share business to other companies.  (The computer industry at that time was known as “IBM and the seven dwarfs” with Burroughs being one of the “dwarfs”.)


Apparently, the general who ran the 2nd Log Command had considerable power since he was able to buy IBM computers despite the government policy.  Thus it was that I at last was able to work on the IBM System/360.  Although I came to feel that the Burroughs MCP was more elegant in many ways, I thought it was important to get IBM experience since I realized that it was better for my post-army career.  I knew that Okinawa would be my last military assignment and I would thereafter re-enter civilian life.


Like the Burroughs MCP, OS/360 had separate operator-command languages and languages for use in punched cards.  The System/360 used “Selectric” typewriters, made by the typewriter division of IBM, as the console device.  This was easier and faster to type on.  Nonetheless, the operator commands were still terse:  most of them were single characters.  For example to find out the status of a job the operator would type “q” followed by the job name.  The operators in Okinawa liked to amuse themselves by typing “q blow” which would elicit the computer response, “BLOW JOB NOT FOUND”. 


The command set used in punched cards was called “Job Control Language” or JCL for short.  It consisted of only three statements:  JOB which defined the beginning of a job, EXEC which defined the beginning of a job step and told which program to run, and DD (meaning Data Definition) which connected a logical filename used in a program to an actual file.  EXEC could also be used to invoke a “stored procedure” which was a primitive scripting capability.


As had been true in San Francisco, I worked for a government civilian manager.  In Okinawa his name was Howard Bushnell.  He took good care of me.  When the army threatened to make me a platoon sergeant which I didn’t want to do, he put me on a funny shift that made it so I never had to attend morning formation, which was the only time a platoon sergeant was needed. 


All of my official work in Okinawa was in COBOL.  But in my spare time I tried some programs in assembler language to, at last, make use of what I had studied on my own when I had been in Ethiopia.


There wasn’t a lot to do in Okinawa so I also spent time writing a kind of operating system for the RCA 301, the machine I had used in San Francisco.  Since I didn’t have a 301 in Okinawa or any software for it, I wrote a cross-assembler that ran on the System/360.  Strangely, I wrote the cross-assembler in COBOL.


In the summer of 1971, I heard somehow that the Army’s program, called “early out for school” had been extended from three months to six months.  This meant that if I agreed to go back to school, I could get out of the army six months early, so instead of getting out in March of 1972, I could get out in September of 1971.  I was sick of the Army by then, so I applied.  My first sergeant was shocked:  since I had re-enlisted once (to get into programming school) he assumed I was a “lifer,” a career soldier.  But what I was asking for was standard policy; he had no choice but to approve.  (At that time the Vietnam War was winding down and the Army had too many soldiers, which was part of their motivation for extending the “early out” program. 


When I had been at Glendale College prior to joining the army, they had had virtually no computer classes.  To plan for my return to school, I wrote for their catalog; now they had a good selection of classes.


The Army transferred me from Okinawa to the Oakland Army Base to be discharged.  I was processed out and headed, with my wife, for L.A. to go back to school.


Navigation: [Next Page] [Previous Page] [Contents] [My Writing Page] [My home page]