HP3000-L Archives

February 2000, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wayne Brown <[log in to unmask]>
Reply To:
Date:
Mon, 7 Feb 2000 12:30:53 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (73 lines)
In most of the places I've worked, operators were considered to be
programmers or system managers in training.  My first job, working with the
Air Force, was in Operations.  Loading paper (and punch cards) and changing
tapes were the MINIMUM requirements for the job; we were expected to learn
much more than that.  In my next job (an IS department at a large paper
company) I had my first exposure to the HP 3000, and as operators we were
expected to know (and do) even more than I had with the Air Force's
Burroughs, Honeywell and Sperry systems.  (Side note:  I've always thought
it was funny that we spent a year migrating from Burroughs to Sperry, only
to have the two companies merge to become Unisys a few months later.)  All
of us were sent to the HP 3000 System Manager classes as well as the
Operator classes.  When I later became an applications programmer and a
system manager myself, I often dealt with the operators in handling
after-hours problems.  When an operator called me in the middle of the
night with a problem, I could tell them to restore files, edit jobstreams
to skip certain steps, empty message files (by FCOPYing them to $NULL),
change database fields with Query, etc.  All I needed to do was to tell
them WHAT to do, not HOW to do it.  They already knew how to use the tools.
They could also swap out terminals and printers when there were problems,
and call the Response Center with intelligent descriptions of more serious
problems.  Sometimes they went a little overboard -- like the weekend an
operator decided to solve a problem by doing a full RELOAD without
notifying anyone first -- but in general they kept things running smoothly.

When that company began moving away from the HP 3000 systems (first to IBM
mainframes, then to HP 9000 systems), management decided to "dumb down" the
operator responsibilities.  Operators no longer were sent to classes, all
procedures had to be written in step-by-step no-need-to-think cookbook
fashion, and God help the operator who tried to show initiative when the
procedure book didn't have the right answer.  They soon learned to call for
help on any problem, no matter how simple, if it deviated one iota from the
documented procedures.  We ended up with more support work for the
programming staff and a group of operators who just mounted tapes, changed
paper, and answered phones -- and who resented being treated as trained
apes instead of IS professionals.

That management attitude was one of many reasons that I decided to change
jobs (after almost 12 years).  My current employer expects more of
operators, and as a programmer and DBA I enjoy working with operators who
are encouraged to learn.  Several of my fellow programmers (and some of the
PC support technicians) are former operators, and one of the current
operators is being trained for a systems programming position.  I think
it's a serious mistake to look at Operations as an unskilled or menial job.

Wayne Brown
Altec Industries





Tom Brandt <[log in to unmask]> on 02/07/2000 11:07:58 AM

Please respond to Tom Brandt <[log in to unmask]>

To:   [log in to unmask]
cc:    (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: Operations people and the agencies they deal with...





Most operations people I know do much, much more than change paper, load
tapes and answer phones.  Though it varies from company to company, most
perform similar functions to those Cynthia talked about in her message.


Tom Brandt
Northtech Systems, Inc.
http://www.northtech.com

ATOM RSS1 RSS2