Re: So ... I suppose you never worked in computer operations.
@jake
"And no, I'm not a "BOFH". Do any of you lot even know what an Operator is? An operator is the flunky who swaps out tapes during late night backup runs. An operator keeps the admins in coffee and the printers in paper and ink. An operator counts supplies in the stock room. Most operators are interns these days. If you're a machinist, an operator deburs and degreases parts. Operators are rarely given jobs more important than remembering "one lump or two". The whole concept of an operator having admin access to corporate equipment is laughable."
I suppose by this statement you never worked as a computer operator. There's a lot more to this than you think. Admin rights is also necessary for many tasks which would be impossible to perform otherwise.
From 1988 to 1994, I was a computer operator for two organizations. My responsibilities went well and far beyond taking inventory, and mounting tapes, and sorting the printed reports, though this was part of the job.
In the first company, I was responsible for backing up 3 VAX 11/780s, 1 VAX 8350, 2 VAX 11/750s, and 2 Sun OS systems. The 3 VAX 11/780s and the 8350 ran VMS while the two engineering lab 11/750s ran Ultrix. The two early Sun systems ran of course their Sun OS with one actually being an Interleaf publishing system and the other for R&D and CAD.
On the VMS clustered machines, I submitted batch jobs, monitored the processes, and ensured all jobs completed successfully because there were dependencies of each job, which meant if one failed, then another would not complete.
In addition to the daily operations, I had what we referred to as additional projects. These projects included repairing printers, monitors, and video terminals. This in part was due to my skills as a hardware technician initially, and having come from the company that made the video terminals originally. I went through a closet full of dead equipment and with an oscilloscope, DVM, and some schematics, I was able to repair everything but two terminals which were totally fried inside due to a lightning strike on the building.
Other projects included replacing network equipment, running cables as needed, and even rewiring the punch panel. The previous operators were careless and had wires stretch haphazardly across the panel. My job was to carefully reroute these and re-punch them down.
When I wasn't monitoring the VAX batch jobs, I was also assisting the R&D department with their own proprietary Convergent Technologies workstations. These systems had an array of plug-in modules, which also needed swapping out, replacing, and repair. I did not have schematics for these, but was able to Frankenstein a few out of the scrap units.
The various printers not only needed their paper and ribbons, but sometimes the print heads needed replacing, or sometimes other parts. Two of these printers were those huge DEC LP27 band printers which would jam up, and require parts to be replaced. This usually occurred on weekends of course and the weekend operator would page me to come in and help repair one of these beasts.
Other projects came up from time to time including writing queries and building reports in Datatrieve32 and writing the batch jobs to submit these to the queue.
So why would we need admin rights?
Well we would need to do system shutdowns, cancel submitted jobs, add users to the systems, perform standalone backups and so many other tasks, which would be impossible without having admin rights.
Like all jobs these rights were given to us with the understanding of the implementations and consequences of things going wrong. Did we ever have a rogue employee? No. Never on my watch after I was promoted to lead operator.
In my final operator's position before I was promoted to helpdesk support, I ran a MicroVAX 4000 along with a massive cluster of Novell servers, and a remote IBM mainframe.
Our job description in this company involved daily backups of course, adding and removing users from the Novell server as required, clean up files, reboot and shutting down servers, workstations, and running batch jobs. All of this and a lot more, which I'm now forgetting with time since it's been 20 or more years since I was there.
In this job we were proficient in VMS, IBM MVS/TSO, SNA network printing, and Novell administrator roles. (I know I can hear you laugh because of the kinds of systems, but remember this was late 80s and early 90s).
The MVS/TSO system ran special batch jobs which required editing of the batch files prior to submission, and adding and deleting users. Being the MVS/TSO environment, the formatting had to be 100% accurate, otherwise, the job would fail. No extra spaces, nothing out of alignment. Absolutely perfect.
Since this was a financial institution, there were very specific SLA requirements set forth by regulations. Specific reports, checks, and letters needed to be printed and mailed by specific days. With these strict requirements, we had to maintain a nearly 24/7 363 day online availability. The systems were only taken down, usually during holidays, to perform maintenance and hardware replacement as required. With this availability requirements, we monitored the systems for failures and remained on call at all times. It was our responsibility to report problems to the on-call support person as well as to hardware manufacturers to replace failed equipment such as DEC and at the time Novell.
In addition to running batch jobs and performing backups, we too had special projects or specific areas of responsibility. My so-called pet project was documentation. Our manager developed a documentation server, which was to eventually contain every job that we ran regularly. The template was further refined and shared with the DBAs who needed special jobs run during the day.
Like many projects, this lead to others including report management and printing, and overall through my guidance the department went from an error prone operation to one that had a 99% success rate. The department also became proactive as we became aware of what was needed, and aware of the inter-operations of each and every task and job that was submitted on the systems. In doing this, I earned a company award and a nice little extra sum in my pay.
Again during this time there were no rogue employees and no need to limit our access to the systems. When an employee did leave, whether to move to another company position or changed employment, their user accounts were terminated according to security protocols. This is how all user accounts should be managed.
So yeah, we only make coffee?
Biting the hand that feeds IT
