Somewhere between 1995 and 2000, I was sent to teach a pSOS+ class to Westinghouse engineers in Savannah, Georgia.
At the time, the debate between Assembler-language versus C for application programming was still hot and heavy. Programs written in Assembler took longer to develop and had more bugs to detect, ferret out, and correct, but once the code was correct, it ran with record speed. C language programs, on the other hand, were quicker to write and debug, but inherently slower. The pSOS+ RTOS was written in Assembler and intended for application programs written in that language. As such, it was faster than any of its competitors, most notably Wind River’s VxWorks.
The name, VxWorks, is a contraction of VRTX and “with the works” alluding to both its original core, VRTX, and a wrapper there-around which added functionality and, more importantly, a C language interface. With VxWorks, customers could write the application programs in C and have them working sooner than those working in Assembler with pSOS+.
As processor speeds increased, it had become apparent by then that the old Assembler language advocates were losing out to the C upstarts. And to keep its customers, Integrated Systems–the company selling pSOS+–made the critical decision to add a C language interface to pSOS+.
Consequently, the training department’s focus became programming for the pSOS+ operating system in the C language. Development systems shifted from the old, Motorola Exormacs (MC68000-based) systems running VERSAdos to the use of newer Unix-based systems from any of several vendors and cross-compilers that produced code to execute on the Motorola 68000 or Intel 8086 target systems.
At Integrated Systems, the old assembler-language training materials for pSOS+ were retired.
The Westinghouse class in Savannah, Georgia was to be on Unix development systems, and students were to use the C language interfaces. It took place at a hotel in Savannah, and we (ISI) provided a catered lunch as part of the training. (I put on several pounds with the generous midday meals, and had to learn to limit my caloric intake to keep from getting the nods during the afternoon lab sessions when I sat and waited, often for an hour or more, for help requests.)
On the first day of the class, I looked out at my students. As I recall, it was a small class, perhaps eight or so in the audience. But somewhat unusually, they were all in their late 40s and 50s. Characteristic of the time, however, there were no women, no one of foreign descent, and no one of color. (All of that would change in this segment of the market–aerospace and defense–in the next decade.)
I began the first day’s lecture which reviewed the general terms of interest, real-time principles, and the operation of various kernel primitives including scheduling and task prioritization. Hands-on labs would begin on the afternoon of the second day after an overview of the development tools and the mechanics of downloading and testing.
Before class on the second day as students were filling their souvenir ceramic coffee mugs with the ISI logo and sampling the breakfast tray of fruit and pastry, I asked about their application.
One of them said they worked at the Savannah River Nuclear Facility several miles inland and were responsible for the software running “Reactor F.”
I guess my silent ignorance prompted him to continue.
He added, “We breed Plutonium-238.”
Note: According to Wikipedia (consulted on September 2022), the Savanah River Site “stopped producing bulk” PU-238 in 1988. I can only guess that at the time of this class (1995-2000), “bulk” production was on hold, and only small-scale improvements, such as re-writing the software, were being considered. But I hasten to add, this is purely my own speculation.
I’d heard the term “breeder reactor” but didn’t understand what it meant. I asked him to explain.
“It’s quite simple, actually,” he might’ve said. “Basically you fill up the reactor with the rare but fissionable uranium, pull the control rods out to just the right degree, and in the resulting melee of bouncing particles, some of them stick to a nucleus and the uranium is transmuted into an isotope of the much rarer plutonium.”
PU-238 is used in radioisotope power systems. It gives off heat that can then be converted into electricity. Several Apollo flights left Radioisotope Thermoelectric Generators (RTGs) on the moon, and Andy Wiles’ fictional main character in “The Martian” dug up one that’d been buried on Mars for safety reasons to keep himself warm while trucking around the planet.
The Westinghouse engineer in my class said their assembler-language application read hundreds of sensors within the pile of Reactor F and tweaked control rod positions to optimize the production. The control system ran on two, identical Motorola 68000-based systems running in hardware lockstep, and if either system differed on pushing in or pulling out any control rod, the hardware would automatically “scram” the reactor.
As I mentioned, on the second day of class, the students were to begin development of C-language software on the Unix server I’d set up in the room. But when we reached that point in the morning, one of them said they didn’t know how to use the Unix system nor any of its editors. I had reserve training materials for that situation and prepared to shift gears accordingly when one of them added that they wanted to write in Assembler language, not C. Neither I nor the training materials were prepared for that.
I put the class on break and called my boss. He said that Westinghouse–the employers of these engineers–had mandated they learn C and Unix. Teaching them the assembler-language interfaces was not allowed. They were to write in C. And they were to learn how to use the Unix development environment, not the old VERSAdos.
Back in class, I relayed as nicely as possible what I’d been told.
The engineers refused.
“I beg your pardon?” I suppose I said.
They said they would not write in C, would not use the Unix development system, and that everything in class that had anything to do with either of those topics was of no interest.
I felt like I was in a bad Dr. Seuss poem.
I explained that, other than yesterday’s introduction, the C interfaces and the Unix development environment were the entirety of the training.
Five minutes later, I was alone.
I called my boss again. He instructed me to wait. The remainder of the morning passed slowly. I then ate my catered lunch and watched as theirs turned cold and dry on the other plates. I spent the afternoon looking out the window, talking to my wife on the phone, and watching the clock. Nobody returned.
The second day was the same: I was set and ready to go, but no one showed up.
When I updated my boss, he said that Westinghouse had paid for five days of training, and that the walk-out was not our fault. He said I should pack up the equipment and “indulge your whims” for the remainder of the week.
During the year that followed, I taught many classes and mostly forgot this unique experience.
Then, I received notice that I had been booked to teach the same class, at the same location, and for the same customer.
Dutifully, I showed up, prepared the classroom, and greeted the arriving students.
This time, however, they were all what I’ll call fresh-outs. That is, they all looked to be freshly-minted college graduates. They were conversant in C and Unix, and all of them stayed, did the labs, and asked the typical questions I’d learned to expect and answer for our typical customers.
At lunch on the last day, I asked the engineer sitting next to me about the previous group.
He said there was only one of them left, and that he was responsible for the old system, “the one we’re going to replace.”
I nodded, not fully comprehending what he was telling me.
“And the others? What are they doing now?”
Everyone fell silent as the student across the table from me put down his fork.
“They don’t work for Westinghouse as of about a year ago.”
I won’t express my opinion on either that first group’s refusal nor on what we might speculate was Westinghouse’s position. Most assuredly, there are other facts, memos, and meetings that preceded and likely followed that first class.
But what I learned is that the world moves on. Whether you agree or not with the direction, the bottom line is that the world is a lot bigger than you or me, and while our reasoning and opinions are important, at some point we may have to choose our battles.
Moving on is as much a part of life as sticking to your guns.
Only you can decide when to do which, and only you can decide–in hindsight–if that was a good or bad decision.
In the years that followed, if my employer asked me to go and teach a class, I always agreed before I knew where, what, or for whom it would be. My teaching took me to a lot of interesting places, some of which would change the subject if I asked what they were doing. (In time, I figured out some, but for most of them, I’m still in the dark.)
In time, Integrated Systems and pSOS+ would be acquired (and effectively shelved) by Wind River. I learned and taught VxWorks but it was an uphill battle in a training organization with too many teachers. I left and put in a couple of years with Monta Vista teaching embedded Linux. When they outsourced all their training to a different company and laid me off, I founded my own Linux training company, RyteTyme. Our money ran out in two years: I sold a single session of training to two engineers. That was it. I then spent a couple of years at Green Hills and learned their INTEGRITY operating system with the intention of developing a new course to replace their existing one (and its lack-luster training department). But that didn’t work out for what I’ll term as personal reasons even though I wasn’t one of the “persons” with the reason. I ended up back at Wind River with a newly-staffed training department and taught VxWorks and Linux through them for nine years, travelled around the world, and tallied more than 300,000 miles on their nickel.
Yeah, it was nice.
I retired from Wind River at the end of 2014. They have since been acquired, like ISI before them, and later Monta Vista in the embedded Linux arena, by other companies whose priorities and markets were different, and undoubtedly evolving as well.
That first faction of engineers at Westinghouse refused to accept the change that was taking place. Whether they resigned or were canned doesn’t matter. They refused to do what the company wanted, and they’re out.
My own experience has some of that. And I have some that says it is sometimes better to accept change, learn something new, and move with the flow.
If faced with the same kind of choice, I can’t tell you what to do.
But I do know it will happen.
And you will have to choose.