Chapter 29

SANDY - Monday, November 27, 1961

Miguel and I spent a few minutes studying the lights on the Stretch maintenance console and the Reaper console, and I asked Steve, "What was going on in this program?"

"Well, several things. First of all, it's all running out of the fast memory, and using it for data storage as well. Beyond that, the Stretch program is reading from the fast tape and storing that data into the fast memory. Finally, I'm using the new programming technique that Sarah showed us last month to use more parallel operations."

I thought for a minute. "Can you change some of this, preferably one thing at a time? It would be helpful to try to isolate the cause of the problem."

"Sure, if I can get a couple of files on my tape punched, make some changes to the programs, and then load the Stretch and Reaper assemblers to generate some new object decks. I need to tweak both the Stretch program and the Reaper code. Tell me what you would like to split out."

"If you can vary each of these things independently, that will save us a lot of time. First of all, let's try running the Reaper program from fast or regular memory. Second, do you need to read tape into the fast memory, or would it be good enough to have the Stretch program repeatedly writing to it while Reaper is running?"

"OK, we can start with those variations. Give me a few minutes. I'll make it another option to select whether we use the fast tape or let the Stretch program do repeated references to the fast memory. Once we have my files punched, why don't you run the last two tests from my tape while I'm working on the program changes."

He told me how to find the files he needed punched, and then how to run the last two of his test programs. I did that while he was working on his changes. The last program at least didn't hang the machine or light up anything on either maintenance console, but it ended with a message saying "Program failure 315."

I asked Steve, "Does that last program use the fast memory, either for program, data, or tape?"

"No. Is there a problem?"

"There was a 'Program failure 315" message. What does that mean?"

"It means that the computation didn't generate the right answer. I think that what we have are two probably unrelated problems. Which one do you want to work on first?"

"Let's go after the first one. If it's anything to do with the fast memory, we need to get that design group involved!"

"OK, I'll set up switches for which memory we use and what, if anything, is going on at the same time. Give me another few minutes. This would be a good time for everyone else to have some coffee. Could someone bring me a cup, black, please?"

"Of course!" as the rest of us trooped down to the coffee machine. I brought back two cups, one for me and one for Steve and surreptitiously put my hand on his shoulder for a moment, asking him, "What does it look like?"

"We may learn more about the first problem when I get these programs modified. As far as the second is concerned, I'll want to run it again with some debug switches."

Soon, Steve had his program modifications punched and merged into the decks we had punched from his tape. He tried to assemble the Stretch program, but got some error printouts. He exclaimed, "Rats! Stupid error!" and repunched a couple of cards. This time it assembled without problems, as did the Reaper program.

We ran the test, varying all the switches. Running from regular memory, it didn't fail. Running from fast memory, but with no other activity in that memory, it ran OK. The problem seemed to have something to do with both Reaper and Stretch accessing the fast memory at the same time, and it was more consistent when the Stretch program was using the memory, not the tape.

I said, "It's possible that there's a problem with the fast memory capture mechanism. What if both Reaper and the Stretch are bidding for it, and there's no clear winner? Let's do some scoping!"

Miguel and Aaron quickly had scope probes attached, and we ran the program over and over again, reviewing the logic diagrams as we thought we were getting closer. After a couple of hours, I found the problem.

Paul was still with us, fortunately, and I announced, "There is a design error in the capture mechanism for the fast memory. It's not going to be hard to fix, but we will need assistance from the memory group. Paul, can you get someone down here as soon as possible?"

Paul said, "Of course. What about the other problem?"

Steve said, "I've been looking at that one. Unfortunately, I don't think it has anything to do with the first problem. It seems to be in the Reaper logic, unless I have a bug in my program. Let me tinker with that program, to put some more debugging hooks into it, and also run it on the Reaper simulator. Why don't you guys get some lunch, and bring me back a sandwich and a coke?"

I asked, "Ham and swiss OK?"

STEVE - Monday, November 27, 1961

Absentmindedly, I answered her, "Fine, on rye would be good. Mustard and mayo, please!", and then added in a whisper, "Thanks, love!"

Her smile almost made me forget about the problem, but I went back to poring over the listing, making notes about where I wanted to add switches and hooks. I had my cards punched up by the time they got back, and ran the updated program through the Reaper assembler. We spent several hours working on the problem, and narrowed it down to one section of the code. I asked Sandy, "It's in here somewhere. Would it help if I made another modification to allow you to loop on just this section?"

"Yes, very much so. That way we'll have something that we can scope!"

"I thought that might work. I just need a few minutes to update the program, and you should be ready to go!"

I added, "Sometime before five, I'll need to call Murray and give him a report."

Paul said, "I'll arrange for you to use a phone in one of the offices. The phone in here is restricted to calls inside IBM and local calls."

I thanked him, and after punching a few cards, I assembled and then ran the program. Sandy, Miguel, and Aaron started scoping. It looked like this was going to take a fair amount of time, so I took advantage of Paul's offer to let me call Murray at the agency.

When he came on the line, I said, "Murray, this is Steve. Most of the tests have run successfully, but we've found two problems. One is going to be an easy fix, but the debugging team is still chasing down the other. I think I should stay for another two days. If it's not resolved by then, I'll come back. I'm sure that Sarah can help them with the program almost as well as I could."

"How serious do you think this is?"

"I don't know yet. I'll keep you posted on what we find out."

"OK, call me again tomorrow afternoon!" and we broke the connection.

I went back to the test cell, only to find that Paul had left. I asked Sandy, "I'd like to get Sarah over here, maybe tomorrow. If this goes on very long, she can give you the programming help that you may need to help pinpoint the problem. Can you clear it with Paul?"

She smiled at me, saying, "I've already discussed this with Paul, and he agrees. She'll be here tomorrow morning."

"Sandy, you're wonderful!"

Just then Miguel called Sandy over, saying, "Here, look at this end-op signal!" as he pointed to the scope.

Sandy stared at the trace for a couple of minutes, exclaiming, "Wow! That's strange!" She then studied the logic diagrams for a while, and said, "Just for fun, let's replace this logic card."

I asked, "What's going on?"

Sandy told me, "Look at the scope trace!" I saw a pulse that had a slow rise and short duration, unlike the normal logic pulses in the machine.

"That doesn't look right. I guess you don't think so either!"

She said, "Not at all!" and quickly powered down the system to swap the logic card. When it came up again and I reran the program, it ended with the same failure. At Sandy's request, I set it to loop on the problem section, and she glued her eyes to the scope.

"Damn!" she exclaimed. "It's still showing that same strange pulse! Let's keep this scope on that pin, and take the other scope and work backwards in the logic."

"Do we know which instruction is active when this happens?"

Sandy looked surprised, and said, "No, but let's find out. That might help us a lot!"

"Here's what's going on in the loop. There are about fifteen instructions," as I took a large sheet of paper and diagrammed the loop.

"If you can identify, for each of these instructions, something that we can use as a trigger, say a code point in any one of the fields, we can pin it down in a hurry."

"OK, give me a minute." I found easy triggers for most of the instructions, but there were several that used most of the same code points. I said, "Here's something to get started," and wrote out a list of the simple triggers that I'd identified. I added, "This instruction loops anywhere from four to sixteen times, and it uses the 'no refetch' flag."

"Now that may be significant! Let's trigger on it first, and see if we can learn anything."

SANDY -- Monday, November 27, 1961

We worked until six-thirty with no real progress. I announced, "OK, guys, let's pick up here tomorrow. I'll talk to Paul about overtime when we see him here in the morning, but I don't think we need to go back to more shifts, at least for now."

As we left, I told Steve, "Bring that copy of the loop home with you. Let's think about this a little bit tonight."

We each drove to my house and went in. Mom must have realized that it had not been a good day for us, since she said, "You two don't look very cheerful tonight. What's wrong?"

I said, "Oh, Mom, there's a pesky bug in the machine that so far we can't figure out. All but two of Steve's tests passed. One failure we figured out quickly, and the fix isn't going to be difficult, but the other still has us perplexed."

"Maybe the beef stew that's almost ready will make you feel better!"

Steve perked up, smiled, and said, "It certainly will help!"

We both were hungrier than we thought, and the stew disappeared quickly. Steve and I helped Mom with the dishes, and then spread his program listing out on the table. I said, "You told me that the number of times through the loop isn't constant. Could you change that so that we would know definitely how many times it executes before it goes on to the next instruction?"

"I had been thinking about that. It should be a fairly easy change."

He scratched his head, and wrote out several versions of the loop, finally saying, "Let's try these tomorrow. If they work, it tells us that there's something significant about what I changed. If one doesn't work, it may help you pinpoint the problem."

I got up, and pulled Steve to his feet. "Tomorrow is another day, and we have our work cut out for us. Right now," as I hugged him, "it's time for bed!"

We went upstairs, and were soon in bed. Steve put his arms around me, and we quickly fell asleep.

In the morning, after a quick breakfast, we drove directly to the test cell. Steve started punching the cards for the new program variations. I found Miguel and Aaron poring over the logic diagrams again, making notes about where they wanted to scope. I said, "Steve has some new versions of the loop, and when you don't need the machine for a few minutes, he's going to need to assemble them."