1978-01-02: GSFC – 3760/SIOC

As I dug into it, the operation of the 3760 was fairly straightforward. The machine was basically a minicomputer, internally the same as a computer Sperry made for the U.S. Navy, known as the AN-UYK-20. It was well documented, and all of the NASCOM code was documented and available for me to read. The SIOC was not well documented. The only thing resembling a program was a listing of octal numbers (hundreds of lines of 6- or 12-digit numbers using the digits 0 through 7) representing the code loaded into the SIOC processors when they were powered on. This code was stored on cassette tapes (the same as audio cassettes of the time). There was also a very brief manual that listed the instructions the processors could execute.

While waiting for an actual assignment, I took it on myself to annotate a copy of the octal listing. I used the manual to interpret the octal listing as instructions. and wrote the instruction code next to each line of octal numbers, an incredibly tedious process. Once I could read the instructions, I then identified the segments of straight line code, conditional branches, loops, subroutines, and data areas. Repeated passes over this “disassembled” listing gave me a basic outline and understanding of what the code was doing.

One of the development tools that ran on the 494 was called MASM, for Meta-Assembler. This was a program that could be configured to generate code for different kinds of computers, and was already configured to generate either 494 or 3760 code. I was able to add the ability to generate code for the SIOC, and then to write a MASM program that re-generated the octal listing for the SIOC. Of course, this wasn’t exactly the same as the original code, since I had no idea what names the original programmers had used for their data areas, branch targets, and subroutines; and it had no comments to explain it. Nonetheless, I could provide suggestive names based on what I surmised about the functioning of the program.

Eventually, I was given programming tasks for the 3760, and deepened my understanding of the programs in that computer, as well as the interaction between the 3760 and SIOC. A key aspect was the way in which buffers (temporary storage areas for messages) were obtained and returned to the memory pool of the 3760. One of the problems of this system was an occasional “crash” in which the 3760 ran out of memory, and had to reboot. Rebooting took a couple of minutes, and could cause the loss of many packets of data through the system. There were five or six 3760 programmers at this time, all more experienced than me, of course. However, none of them had ever looked into the SIOC code, and none could figure out the source of the crashes. My analysis revealed an error in the way the buffers were allocated, such that occasionally a buffer would be lost to the pool, which nowadays is called a “memory leak”. This was rare enough that the system could run for a long time before losing so many buffers that none were available when a new one was needed. The actual time between crashes depended on the amount of data being processed, but was typically several days. One work-around was to restart the computers on a regular schedule; however, this was not always convenient, especially during a mission of some sort.

I developed an approach to modifying the SIOC code to avoid the problem. However, I could not implement it because changes to that part of the system were only authorized by the original development group in Salt Lake City. My proposal was sent to them, and a trip was arranged for me to meet with them. When I explained what I had found, and how I had found it, they accepted my proposal, and updated the code. In addition, they gave me additional documentation and MASM code that would allow our group to make changes without having to make trips to Salt Lake City. This episode greatly enhanced my reputation in Sperry.

Later, I noticed a way to reduce the number of buffers that needed to be initially allocated, so that buffers could be allocated to a circuit only after data had been detected on it. This  effectively doubled the number of buffers available to the system in the same amount of memory. Unfortunately, I implemented this enhancement at the same time that Sperry’s salesmen were promoting a doubling of 3760 memory. When NASCOM management realized they didn’t need to spend money to buy more memory, they stopped that deal. This episode hurt my reputation in Sperry, at least with the salesmen.

This was my first work experience in a team of programmers working together, and I was quite pleased with myself to find my work appreciated, and to be looked to as an expert in the 3760/SIOC and related areas. It was also my first experience with the potential conflict between solving a problem with software and solving it by buying more hardware.

The SIOC was highly specialized, and not many customers used them. One group that did was a U.S. Army network technology unit located at Fort Huachuca, in Sierra Vista, Arizona. Once it was known that I had enhanced the SIOC at GSFC, it was arranged that I would go to Fort Huachuca to explain what I had learned, and to advise their programmers on techniques for programming them. Thinking back on the events, this might have stepped on the toes of the SIOC development group in Salt Lake City; however, I never heard of any complaints.

Previous: NASCOM

Next: Enhancing development tools

Print Friendly, PDF & Email