The Obviation Marshal

When I was still in high school, I got onto a sign painting binge. It
likely started with making signs to protect our woods from undesired
hunters, but rapidly branched out into a variety of messages, some of
them interesting and others just silly. One sign is painted on both
sides in white on a green ground, reminiscent of informational highway
signs. One side says:

                   -----------
                  |  FAILURE  |
		  |  MARSHAL  |
                   -----------

and the other side reads:

                  -------------
                 |  OBVIATION  |
		 |   MARSHAL   |
                  -------------

Most of the signs from those days have long since disappeared, but I
still keep that one. It is just too prescient to dismiss.

I skip over the mere use of a polysyllabic term, although that says
something true about who I was and am.

As for the term "marshal", I believe that I chose it for implications
of power, particularly the varied senses of the power to bring about
good order. Retrospectively it seems a solid choice. Whether a parade
marshal or provost marshal comes to mind, a United States Marshal or
the horse servant of a Frankish lord, there remains a sense of being
entrusted to arrange the available resources in an orderly manner.

What then would an Obviation Marshal do? Logically, one would expect
such an officer to bring available resources to bear on anticipated
difficulties so as to prevent any obstruction to achieving the goals.
Should the obviation fail, that same person would be charged with
making things right; in that case, the first step would naturally be
to flip the sign over to reflect the alternative role.

Later, while there was such an occupation as Computer Programmer and
I was one, I would have been willing to argue that the core function
of a professional computer programmer was (or should have been) to be
an Obviation Marshal. I would say that neither my colleagues generally
nor the majority of my supervisors would have grasped the point.

While everything a programmer did could be referred to this role, I
remember a number of more specific actions of mine which serve both
to elucidate the concept and to illustrate my adherence to my high
school vision of myself.

Back in 1979, while working for Wick Building Systems as the System
Programmer -- the only System Programmer in the office out of a group
of three in the organization chart -- I was responsible for operating
system upgrades. These were traditionally done early in the morning
by the System Programmer, who would give up a night of sleep, take
over the computer from the computer operator, and either install the
new version of the OS or make a hash of the whole process.

I carefully planned the steps necessary to ensure protection of the
company's data and continued functionality of the computer system.
(For example, run the backup jobs and lock the application data in
the fire safe; make certain there is a functional operating system
to which operations can revert in case of error.) Then I handed the
process to the night shift operator and went home.

I programmed the steps but turned their execution over to operational
people. Both halves of that illustrate the obviator role.

The operators were more accustomed to being awake in the middle of the
night and more attuned to watching for error conditions than a System
Programmer ever was, and far more capable of following instructions
conscientiously than I have ever been. Even if the people employed as
computer operators hadn't been far more competent as computer
operators than any programmer I've ever met, which they clearly were,
why wrest control of the computer from its natural custodian? With my
method, I got a good night's rest, the company's business was never
inconvenienced, and the operators felt empowered.

A decade later, I did essentially the same thing at St. Vincent
Hospital. Neither innovation survived my departure, I believe. That
was because no other programmer had ever made a sign designating
himself as an Obviation Marshal.

Another example from my days at Wick: I created a program which would
allow me, sitting at my desk, to read and, if necessary, to change any
data block in the system. Having discovered a mechanism which allowed
a program to function as a part of the operating system (that is,
bypassing all data protections), I wrote a program out of curiosity to
see what I could make the system do. I chose to write this particular
program because I wanted enough power at my fingertips to remedy any
kind of system failure -- if, that is, I had to turn over my sign and
become a Failure Marshal. I never used the program, but I came into
the office every morning a little more confident knowing that I had
this tool available in case of need.

Today, of course, people create such tools malevolently by hacking,
but in my day I programmed the functionality explicitly and managed
it using regular, orderly, and established program management tools.
The difference, I suspect, may be lost on those who never aspired to
be an Obviation Marshal.

Speaking of hacking, I remember reverse engineering the encryption of
passwords on the System/36 in Escanaba. My goal from the first was to
protect the system from a potential bad actor; even in 1983 there were
hackers of one kind. (See the movie WarGames of that year.) With that
concern, I wanted to be able to see and modify the user security file
if the need arose. Of course, there was also the challenge of breaking
what turned out to be a trivial level of encryption. My point in this
reflection, however, is the motivation and not the short-lived
excitement.


                                                January 2017