The RSX Stories

On the Bus to Mandalay

n the mornings it was customary to assign educational tasks to one's trainee. Simple tasks such as writing KMC11 microcode, debugging device drivers and second-guessing project estimates were popular. I checked my trusty rubber-band Rigby and trekked down the hall to the computer room to find the boy Justin L. Hewser and see how he was doing.

Justin sat cross-legged on the floor next to the open 11/70 processor. I watched. He looked into the processor and wiggled cards. He booted. The console printed. He typed on it. The console printed again. He turned off the second CPU and swapped two cards. Then he restarted both systems and repeated the process from the start. This went on a long and tedious time.

I pried open the heavy steel security door with my trusty frequent flyer card. "What," I asked, "in the wide, wide world of sports is up? At 9 you went off to install a new DMR and it is now 11:30. The door log says that you have not left the room, and it is impossible for you to loaf while being watched through these big windows. Could it be that you are having trouble of some sort?"

"Indeed, it is so," he replied. "Something strange is going on. I do not understand this at all. The new DMR works fine in the data logging system, but does not work at all over here. I have swapped the DMRs back and forth several times. They behave exactly the same in both CPUs. So it is not a DMR problem."

"Very good," I said. "That implies that you have isolated a problem in the central processor itself."

"I agree," he said. "But I have swapped all the CPU boards now and the problem has not moved. I do not understand."

"That," I said, "is most interesting. Let us short-bus the processor and run XXDP." This took a few minutes. Then we brought up XXDP and ran the system diagnostics. The CPU and options passed. The memory passed also.

"The system appears to be fine," I said. "So let us check the DMR." This we did. The DMR passed some tests but inconsistently failed diagnostics requiring any actual I/O.

"Very interesting," I said. "The DMR works in the other system, but does not work here. The problem must be in the bus itself then, since it is not in the DMR, memory or the CPU."

"How can that be a problem?" cried the boy. "It is just pins and sockets and wire. Nothing can go wrong with that."

"You," I said, "should take up stand-up comedy. An 11/70 backplane barely clears the power supplies. When working on a 70 it is critical that the CPU box come out straight. Otherwise the supplies rake across the backplane and rip wires off pins."

"And that," I continued, "is only one thing that can go wrong. Wires can work loose and short across pins. Things can fall into a backplane slot. Cut NPR jumpers can touch. It is very important to remove cut NPR jumpers completely. You did remove the NPR jumper completely, did you not?" I inquired.

"Ah," said the boy.

"Completely," I said, "not just cut?"

"Um," said Justin.

"I think I know what the problem is," I said. I cut and unwrapped the NPR jumper from the DMR processor's backplane slot. After doing this all the DMR diagnostics ran perfectly.

I bopped him on the head with the wirewrap tool. Bop, bop. "You must read," bop, "the hardware documentation," bop, "more carefully," I said. Bop, bop. "It should state to remove the NPR jumper from backplane pins CA1 to CB1. This is necessary for all UNIBUS DMA devices. If this is not done, the device cannot intercept the non-processor grant signal, NPG as it is called, and strange things happen on the bus."

"But," said the boy, "I installed the TU58 last week and it ran just fine. And I did not have to remove any jumper."

"The TU58 DL11 board," I replied, "is not a DMA device. Only for DMA devices must the NPR jumper be out. But I shall excuse you this time because NPR jumpers are very troublesome. On some backplanes they are all in and must be removed as required. That is the customary case for the very common DD11-DK 9 slot backplane."

"But," I said, "other backplanes such as the 11/24 short box are different. On these backplanes all the NPR jumpers are always out. Then double-wide grant continuity cards are required, since backplane pins are inaccessible or nonexistent."

"Today," I concluded, "many UNIBUS cards have NPR grant built in. Jumpers need not be wired for such cards. But many older cards do not have it. And even on newer cards, and especially non-DEC cards, this may vary. The only way to be sure is to check both the card and the backplane."

"I will remember that," he said. "Pins CA1 to CB1 for UNIBUS DMA devices. I will not forget again. I am most heartily sorry for having offended the CPU."

"Go," I said. "Your ignorance is forgiven. Offend the CPU no more. And make a good act of contrition."

"What shall I do?" inquired the boy.

"Try saying ten Hail Kens and buying me lunch at the B.K.," I suggested.

The RSX Stories

No Bones About It

n the afternoons it was the custom to spend some time with one's trainee. I took my rubber-band Rigby and checked the magazine, left it open to the centerfold, and left the safety of my office. I trekked across the shag carpet to the humble and squalid cube where the boy Justin worked.

Justin was not there. There was a box of cookies on his desk. They were chocolate amaretto raisin mint butterscotch peanut chip cookies. Frosted pink. They were not manly cookies.

Justin's dog sat in his office. He woofed. I gave him a cookie. He ate the cookie. He woofed again. I gave him another. He woofed the cookies. It was an interesting thing to see. I gave him the entire box of cookies. He ate them all and shortly seemed ill at ease. He yawned. It was a Technicolor yawn and was very amusing. Then he looked much better. I sat down to wait for Justin's return.

"So, dog," I said. "How is it to belong to my trainee Justin?"

"Ruff," replied the dog. I took this to mean, 'He buys cheap generic dog food. It gives me gas.'

"I see," I told him. "Where is he, by the way; do you know?"

"Roof," he said. He was clearly a dog of few words. This obviously meant 'Checking out the air conditioner. It's still icing up and cycling like crazy.'

"Aha," I said. "I told him to fix that last week. I figured he was over sniffing around the secretarial pool, looking for what's-her-name ..."

"Ruth," he said. He looked at me crosswise. Plainly he did not consider me very intelligent. In this he was joined by my supervisor and many bagged managers.

"While you are here," he barked, "I have been meaning to talk to you about timesharing under RSX. I do not understand why RSX is not a timesharing system. After all, it supports multiple terminals and multiple users. That would appear to make it a timesharing system."

"This is not an uncommon perception," I replied. "Nevertheless, RSX is not a timesharing system. It is a multi-user system, which is not the same thing at all."

"Timesharing systems," I continued, "try to make sure that all users get a fairly divided shot at the CPU. All job priorities start at the same level, and as a job takes up more time, its priority falls. The converse is also true; as the job uses less time, the priority rises."

"RSX does not work like this," I explained. "In RSX, everything is assigned a fixed priority at install or run time. The highest priority task always gets the CPU, if it wants it. Task priority does not fall. Low priority tasks must wait for high priority tasks to finish or give up the CPU."

"To ensure fair sharing of the CPU," I said, "most timesharing systems employ a time unit called a quantum. After a quantum passes, the operating system takes over, readjusts priorities and checks to see if there is another job eligible for the CPU. That makes sure no job can hog the CPU. But it costs part of the available time and CPU horsepower to enter the operating system and reschedule at every quantum."

"RSX is not like that," I said. "Not at all. The RSX scheduler is started by significant events, not by time passing. The system trusts all tasks to be excellent to each other. If there is no I/O going on, and no other source of significant events, a priority 1 job can keep a priority 235 job out indefinitely."

"So one might say," he arfed, "that all timesharing systems are multi-user, but not all multi-user systems are timesharing?"

"That is a very good perception," I said, "and it cuts right to the bone of the matter." Just then Justin returned covered with grime from his expedition to the roof.

"What is all this mess here?" he cried. "It looks like someone woofed chocolate amaretto raisin mint butterscotch peanut chip cookies all over my office. Who could have done such a vile nasty awful despicable bad thing?"

"I'm sure I don't know," I replied. "There is no one here but me and your dog. And as I see you are hard at work, not loafing as you do normally, I am leaving now."

"But who will clean up this mess?" he cried.

"Ralph," said the dog. "Right," I added. "Ask the janitor. He will be here shortly." And so I left to press on with the hunt for a noisy terminal line.

The RSX Stories

Stalking the Noisy Terminal Line

t was the custom, in those days, to spend the afternoon of Friday on safari to the local bar and grill. I loaded my single-shot wallet and went to search for the boy Justin L. Hewser. I searched many places. Finally I found him underneath the cable trays in the basement.

"It is surprising but good," I addressed his feet, "to see you working at finding the noisy terminal line. I had expected to find you loafing somewhere."

He made no response, but continued to look up into the cable tray. The datascope blinked and peeped.

"It is Friday afternoon," I continued. "Let us go on safari to the Brat 'n Brau. There we may meditate on the mysteries of the operating system at two bucks a pitcher."

Again he made no response. The datascope blinked and peeped. He made snurfing and slurping noises.

"Yes," I said, "I know that you can scarf a pitcher by yourself. It is a proper reward after righteous work. The system will run much better now that the noise problem is gone."

"I am sure," I told him, "that you know why noisy terminal lines are a problem on RSX systems. But let me go over it again just to be very sure."

"The terminal driver," I said, "is a very large driver. It has many options and features. It is a large piece of code. Especially for a driver. Processing characters in the terminal driver is costly, because of all the terminal options which may be set. Each case must be checked and processed."

"Despite what is implied about the efficiency of DMA terminal interfaces," I continued, "they are not DMA input. Only on output. For almost every character received, there is an interrupt. That is a heavy interrupt load when a 9600 baud line is noisy. That is 960 interrupts per second, is it not?" I inquired.

There was no response. He was not fast at arithmetic.

"This is bad by itself," I said. "But it is worse when the line is not slaved. The terminal buffer occasionally fills up, or the noise looks like a carriage return. Then the terminal buffer is queued to the CLI, the command line interpreter as they call it, which serves that terminal."

"The CLI," I said, kicking the feet, "sees a packet of garbage and sends a message to the terminal. This means a minimum of 12 QIOs per second if the buffer is 80 characters in length. It also means that the CLI comes in 12 times per second. And if the noise is due to line crosstalk, the CLI sending many "CLI -- Syntax error" messages only makes the problem worse."

"If the problem is ongoing," I added, "it may be impossible to boot the system. The stream of unexpected interrupts may so disturb the CPU that it cannot load the system and get through the boot sequence. This is something you must check on mysterious boot failures."

"So you can see that this problem," I said. I stopped. "But the implications are of course obvious. Let us go now and taste the fruits of our labor."

The snores from under the cable tray became louder. The datascope blinked and peeped. "THE QUICK RSX GURU JUMPED ALL OVER THE LAZY SYSTEMS TRAINEE," it said. "FOXED YOU AGAIN," it said. The messages were repeated many times on the screen.

"I would not wish to disturb you when you are hard at work," I said. "I will leave you now and I will go buy the first pitcher. I will drink it all myself."

At this, he leaped up from the I-beam, banged his head against the cable tray, and fell to the floor. "I have found the problem," he said, "and I am ready to go with you."

"Fine," I said. "Give me the two bucks and I will indeed buy the first pitcher."

"It is good," he said, giving me the money, "to have a mentor who buys beers for me on Fridays."

"And it is good for me," I said, "to have a trainee who listens attentively and puts important work ahead of play. But mostly it is good that you do as you are told. Now let us go and soak our heads."

The RSX Stories

Loaded for Big Disk

peered cautiously around the corner of a long rack of 11/70s. I was stalking the boy Justin. I kept my head down. He would not see me or my powerful rubber-band Rigby. He was becoming very good at jumping and leaping away when he heard the gun go off. That was good. Soon I would be able to make him jump off chairs in important meetings by making twanging noises.

Justin sat at the console and typed incantations. Zzzt! went the console. Tap, tap, tap, RETURN, went Justin. Zzzt! went the console again. Tap, tap, tap, RETURN, and the zzzt! covered the noise of my weapon firing. Justin leaped in the air and rubbed the seat of his pants.

"That," he said, "was very clever of you. But I bet you cannot do it again."

"You are probably right," I agreed. "What is it that you are doing here?"

"I have done a partial SYSgen," he said, "to add the new 900 Mb drives. They are on the second MSCP controller. But when I reboot, they do not show up at all. I unloaded the old driver and explicitly loaded the new one. They still do not show up."

"Aha," I said. "I know what your problem is immediately. But let us explore this in some detail first to see if you can figure out where the problem lies."

"What comprises a device driver?" I asked the boy.

"It is a little piece of code that handles QIOs," said Justin, "which is mapped by the Exec as required."

"Nothing else?" I asked.

"It has a database associated with it," he replied, "which specifies the number, type, address and vector of each logical unit, and the controller associated with it."

"What does this imply?" I prompted him.

"That the database is faulty," said Justin. "But it cannot be, because I deleted the old driver and loaded the new one myself. The system must be using the new driver and database."

"Hmm," I said. "When was the original driver loaded into the system?"

"It was VMRed into the system," he responded, "at the time of the original SYSgen."

"I see that you have not made the leap," I said. "Let me be more obvious. Tell me about the driver and controller. Type CON DISPLAY ATTRIBUTE FOR DU, and tell me what it says."

"It says that there is only one MSCP controller," he replied. "And that is wrong. There should be two. The database is wrong. Round and round we go."

"Patience," I said. "Type CON OFFLINE DUA, then CON OFFLINE DU0:, and take DU1: through DU3: offline as well. Then unload the DU driver, and type CON DISPLAY ATTRIBUTE FOR DU again."

"It shows the device and controller offline," he said, "with the same vector and CSR. Wait a minute. The database is unloaded. CON cannot know the vector and CSR."

"Ah," I said. "But what makes you think the database is unloaded?"

"I unloaded the driver," he said.

"Exactly," I replied. "You unloaded the driver. But databases are never unloaded, because tasks may still have entries in their task header pointing into the database."

"And the database was VMRed into the system," said Justin. "It cannot be removed from this system at all, ever."

"Very good," I said. "So what is the next step?"

"Create a new system image," he said, "and re-VMR the system to get the new driver database into it. Then boot the new system, SAVe it, and all should be well."