4 ms·

I'm terribly curious what all these jobs are: * Computer Operator * Computer Operations Supervisor * Tape Librarian * Data Control Supervisor From the arti

I'm terribly curious what all these jobs are: * Computer Operator * Computer Operations Supervisor * Tape Librarian * Data Control Supervisor From the article text, presumably these do not involve programming? I'm old by HN standards but this predates me by a couple eras. I guess "Tape Librarian" is obvious enough, but what does the day-to-day life of a Computer Operator look like?

toast0 6y ago
> Computer Operator We had a couple computer operators (one per shift, not sure if there were just two shifts or an overnight shift too) at my first job (school district), they didn't program the mainframe, they ran and supervised jobs; for us, most of the effort was around running the print jobs for things like report cards and what not. Grab the paper from the warehouse, load the paper, collate if needed etc. Run the backups, change the tapes, etc. Yell at the student interns when they run ping of death and it borks the mainframe. etc > Computer Operations Supervisor Supervises the computer operators, basically the manager. Handle shifts when a Computer Operator is out sick, presumably. Not sure we had a dedicated computer operations supervisor because we didn't have that many operators. > Tape Librarian Organizes the tapes (reel is a lot harder than the little cartridges we had). Physically deliver tapes to computer operators, or maybe load them, based on requests, etc. > Data Control Supervisor Supervising the Data Control people --- you didn't list them, so I don't have to guess what they did. :) My guess is running reports, checking consistency, that kind of thing.
gregjor 6y ago
I worked with mainframes and superminis back in the 70s. My first job was night computer operator. Computer operator: scheduling and monitoring jobs, managing the print spool (queue) printing reports, stripping (removing carbon paper) and collating, sometimes swapping disk packs, loading/unloading tapes, running backups. And making sure the computer didn’t crash or halt. The minis and mainframes I worked on generally ran one job at a time, and the jobs might have a sequence, reading from and writing to disk or tape. We kept transistor radios on top of the computer cabinets. Each job made a distinctive sound, as did runaway programs (infinite loops, for example). A halted computer did not make a sound so the radio was an early warning that something wasn’t right. Tape librarian: magnetic tapes degrade over time from use, stretching, humidity. The tape librarian cataloged the contents and sequence of tapes, how many times they were used, their age. When a tape had too many errors or got to end of life the tape librarian would schedule a duplicate job.
- majewsky 6y ago
  > We kept transistor radios on top of the computer cabinets. Each job made a distinctive sound, as did runaway programs (infinite loops, for example). A halted computer did not make a sound so the radio was an early warning that something wasn’t right. You mean you used the radio like a baby monitor?
  - danmg 6y ago
    The different components would make different electromagnetic interference patterns. You could tell what the computer was doing (or not doing) from the static. This is also how some of the first computer generated music was produced.
    - thelazydogsback 6y ago
      I remember listening to my TRS-80 that way -- easy to monitor outer/inner loops, different sounds for Basic vs. asm code, etc. The downside was that often people had no choice -- the TRS-80 was so noisy, that nobody in the house could watch (OTA broadcast) TV if I had the computer on.
      - gregjor 6y ago
        Can confirm. I did some work on a TRS-80 in a Radio Shack store (inventory on cassette tapes!). The “trash 80” as it was called would interfere with the stereo equipment in the store, the manager would have to turn the little computer on the counter off to demo a receiver.
        thelazydogsback 6y ago
        > "trash 80" Boo! :) Still much love for it...
- gregjor 6y ago
  I remember something that happened fairly often. The nightly jobs were on a schedule with estimated run time and special instructions. The jobs came with disk files or sometimes written job control language (JCL) that specified environment variables, required disk packs, resource requirements (temp disk space, memory, tapes). The JCL language was terse and arcane and the programmers and managers who submitted jobs sometimes messed it up. I would have to correct that and sometimes write the JCL if the job didn’t come with a file, or the instructions said “Same JCL as last run.” Mostly the job was rote and I could tape boxes of paper together end to end and sleep while everything churned away. The most exciting night was a meltdown. I could do my Friday shift anytime over the weekend. I went in on Saturday afternoon and found the computer room very hot. The AC had failed and the backup AC didn’t switch on. The computer room and tape vault were climate-controlled. I could hear one of the disk drives (the size of a small refrigerator) whining. I ran around shutting everything down, but one of the GE disk drives had overheated and the disk platters had melted. Most of the drives were HP and they survived, but the cheaper GE drives were all damaged. The AC supplier’s insurance had to pay for the damage. It’s hard to imagine today how big, slow, expensive, and delicate computers were back then. Hardware failures were common. RAM was measured in kB or low mB. Disk storage was expensive and slow. The job I’m describing was for a school district. They had two HP 3000 superminis (16 bit), two HP 2000 timesharing systems, and an IBM S/370. The HPs were identical, we could use one as a hot spare if necessary, though back then HP stood for rock-solid reliability. The HP 3000 has a long history, I wouldn’t be surprised to find some still in use, and I know there are emulators for it to run old application code (COBOL, Fortran, Basic). The HP 2000 systems were common timesharing systems used in public schools for admin work and student accounts for learning programming. My first exposure to programming was HP 2000 timeshared BASIC on a teletype model 33 in my high school. After the school district I got a job as a junior programmer at Blue Ribbon Sports, now known as Nike. They had several DEC PDP-11s and two DECSystem 20 superminis, all in a secure climate-controlled rooms. The programmers did not have access to the computer room, we didn’t have admin (“wheel”) accounts. We had to ask the operators to do system admin things for us. I had an ADM-3a terminal at home with an acoustic coupler, then Nike let me take a VT-100 terminal home so I could work more. We had remote work way back then in 1979.
d2throw 6y ago
Around the turn of the millennium I worked at a major visual effects house in LA as a sysadmin - with no mainframes in sight, we still basically had all of these roles in the shop. There was an entire tape operations team whose job it was to load in tapes of assets from clients (textures, models, frames) for a project (IIRC they were staged on netapp filers for the most part) and load out tapes of final rendered frames (and new or transformed assets) for delivery to the next step of the post-production workflow. (Even if WAN links suitable for pushing many many terabytes of data were economical at the time - and they weren't - the internet wasn't really trusted for shipping around this data back then. The ludicrous powers ascribed to movie hackers in the 90s-2000s gives you a real glimpse of the paranoia in the industry at the executive level. Napster scared the SHIT out of them.) The operators/ops supervisors were basically the render management department. Their role was to ensure jobs ran (i.e. to render frames) and produced (at least superficially) valid output. "Data control supervisor" didn't exist by that name but the job of managing compute and storage capacity over time definitely did. It might even have been in my department (systems) but I was just a puppy then and really wasn't paying enough attention. Fun story, one fine spring the entire render management department was out for various reasons but an urgent job had come in - the South Park movie was (IIRC) 6 weeks from release and Cinesite (IIRC?) didn't have the capacity to render out all the final frames in time. The call went out internally for volunteers to learn how to run jobs, and I gave up a weekend to babysit renders. Every day new assets would be delivered and rendered frames picked up (on huge Ampex DST cassettes - hundreds of gigabytes each! A lot in 1999, anyway.) My task was to get shots rendered at output resolution as efficiently as possible, and to preview each shot to make sure there were no obvious errors (black frames, e.g. - software wasn't perfect.) There was a bit of an art to it, since the frames could be rendered on almost any idle CPU in the facility via our in-house distributed queuing system (race, props to erco) and capabilities of the host systems were variable. If you weren't on top of things, the shot might get hung up on some frames that ended up enqueued somewhere shitty where they'd never finish, etc. The South Park frames were pathological - out of a desire for verisimilitude, the construction paper textures were HUGE, and everything was modeled in 3D (Alias) with lighting and shadows and very small Z depths between layers. A lot of the shots I drove were from the "Blame Canada" sequence (though without sound, I didn't know it until I saw it in the theater a few weeks later) - with a huge number of characters on screen, that meant gigs of texture per frame, as every character (and usually the background) was made of polygons each mapped with a particular paper texture. No wonder Cinesite ran out of time and had to go hit up other shops at the last minute. In conclusion, batch processing: still a thing. (Epilogue: sadly, didn't make it into the credits - those were already done, I guess? - but for giving up my weekendI did score an invite with a +1 to the wrap party. Isaac Hayes rocked. Mary Kay Bergman held my +1's hair while she barfed in the ladies room. And as far as I could tell, Matt and Trey never bothered to show up. A+, would give up weekend again.)
pram 6y ago
Computer Operator is probably close to being extinct but that was actually my first IT job, in 2010! It was for a very old school credit union, and I basically managed all their AIX systems and ran the nightly batch jobs for all the daily financial transactions. They changed the title to 'UNIX Administrator' while I was there so that should give you an idea.
monocasa 6y ago
Adding to what others have said, the Computer Operator profession is dead as it was replaced by "operating systems". Responsible for loading and scheduling work on computers.

toast0 6y ago

> Computer Operator We had a couple computer operators (one per shift, not sure if there were just two shifts or an overnight shift too) at my first job (school district), they didn't program the mainframe, they ran and supervised jobs; for us, most of the effort was around running the print jobs for things like report cards and what not. Grab the paper from the warehouse, load the paper, collate if needed etc. Run the backups, change the tapes, etc. Yell at the student interns when they run ping of death and it borks the mainframe. etc > Computer Operations Supervisor Supervises the computer operators, basically the manager. Handle shifts when a Computer Operator is out sick, presumably. Not sure we had a dedicated computer operations supervisor because we didn't have that many operators. > Tape Librarian Organizes the tapes (reel is a lot harder than the little cartridges we had). Physically deliver tapes to computer operators, or maybe load them, based on requests, etc. > Data Control Supervisor Supervising the Data Control people --- you didn't list them, so I don't have to guess what they did. :) My guess is running reports, checking consistency, that kind of thing.

gregjor 6y ago

I worked with mainframes and superminis back in the 70s. My first job was night computer operator. Computer operator: scheduling and monitoring jobs, managing the print spool (queue) printing reports, stripping (removing carbon paper) and collating, sometimes swapping disk packs, loading/unloading tapes, running backups. And making sure the computer didn’t crash or halt. The minis and mainframes I worked on generally ran one job at a time, and the jobs might have a sequence, reading from and writing to disk or tape. We kept transistor radios on top of the computer cabinets. Each job made a distinctive sound, as did runaway programs (infinite loops, for example). A halted computer did not make a sound so the radio was an early warning that something wasn’t right. Tape librarian: magnetic tapes degrade over time from use, stretching, humidity. The tape librarian cataloged the contents and sequence of tapes, how many times they were used, their age. When a tape had too many errors or got to end of life the tape librarian would schedule a duplicate job.

majewsky 6y ago
> We kept transistor radios on top of the computer cabinets. Each job made a distinctive sound, as did runaway programs (infinite loops, for example). A halted computer did not make a sound so the radio was an early warning that something wasn’t right. You mean you used the radio like a baby monitor?
- danmg 6y ago
  The different components would make different electromagnetic interference patterns. You could tell what the computer was doing (or not doing) from the static. This is also how some of the first computer generated music was produced.
  - thelazydogsback 6y ago
    I remember listening to my TRS-80 that way -- easy to monitor outer/inner loops, different sounds for Basic vs. asm code, etc. The downside was that often people had no choice -- the TRS-80 was so noisy, that nobody in the house could watch (OTA broadcast) TV if I had the computer on.
    - gregjor 6y ago
      Can confirm. I did some work on a TRS-80 in a Radio Shack store (inventory on cassette tapes!). The “trash 80” as it was called would interfere with the stereo equipment in the store, the manager would have to turn the little computer on the counter off to demo a receiver.
      - thelazydogsback 6y ago
        > "trash 80" Boo! :) Still much love for it...
gregjor 6y ago
I remember something that happened fairly often. The nightly jobs were on a schedule with estimated run time and special instructions. The jobs came with disk files or sometimes written job control language (JCL) that specified environment variables, required disk packs, resource requirements (temp disk space, memory, tapes). The JCL language was terse and arcane and the programmers and managers who submitted jobs sometimes messed it up. I would have to correct that and sometimes write the JCL if the job didn’t come with a file, or the instructions said “Same JCL as last run.” Mostly the job was rote and I could tape boxes of paper together end to end and sleep while everything churned away. The most exciting night was a meltdown. I could do my Friday shift anytime over the weekend. I went in on Saturday afternoon and found the computer room very hot. The AC had failed and the backup AC didn’t switch on. The computer room and tape vault were climate-controlled. I could hear one of the disk drives (the size of a small refrigerator) whining. I ran around shutting everything down, but one of the GE disk drives had overheated and the disk platters had melted. Most of the drives were HP and they survived, but the cheaper GE drives were all damaged. The AC supplier’s insurance had to pay for the damage. It’s hard to imagine today how big, slow, expensive, and delicate computers were back then. Hardware failures were common. RAM was measured in kB or low mB. Disk storage was expensive and slow. The job I’m describing was for a school district. They had two HP 3000 superminis (16 bit), two HP 2000 timesharing systems, and an IBM S/370. The HPs were identical, we could use one as a hot spare if necessary, though back then HP stood for rock-solid reliability. The HP 3000 has a long history, I wouldn’t be surprised to find some still in use, and I know there are emulators for it to run old application code (COBOL, Fortran, Basic). The HP 2000 systems were common timesharing systems used in public schools for admin work and student accounts for learning programming. My first exposure to programming was HP 2000 timeshared BASIC on a teletype model 33 in my high school. After the school district I got a job as a junior programmer at Blue Ribbon Sports, now known as Nike. They had several DEC PDP-11s and two DECSystem 20 superminis, all in a secure climate-controlled rooms. The programmers did not have access to the computer room, we didn’t have admin (“wheel”) accounts. We had to ask the operators to do system admin things for us. I had an ADM-3a terminal at home with an acoustic coupler, then Nike let me take a VT-100 terminal home so I could work more. We had remote work way back then in 1979.

d2throw 6y ago

Around the turn of the millennium I worked at a major visual effects house in LA as a sysadmin - with no mainframes in sight, we still basically had all of these roles in the shop. There was an entire tape operations team whose job it was to load in tapes of assets from clients (textures, models, frames) for a project (IIRC they were staged on netapp filers for the most part) and load out tapes of final rendered frames (and new or transformed assets) for delivery to the next step of the post-production workflow. (Even if WAN links suitable for pushing many many terabytes of data were economical at the time - and they weren't - the internet wasn't really trusted for shipping around this data back then. The ludicrous powers ascribed to movie hackers in the 90s-2000s gives you a real glimpse of the paranoia in the industry at the executive level. Napster scared the SHIT out of them.) The operators/ops supervisors were basically the render management department. Their role was to ensure jobs ran (i.e. to render frames) and produced (at least superficially) valid output. "Data control supervisor" didn't exist by that name but the job of managing compute and storage capacity over time definitely did. It might even have been in my department (systems) but I was just a puppy then and really wasn't paying enough attention. Fun story, one fine spring the entire render management department was out for various reasons but an urgent job had come in - the South Park movie was (IIRC) 6 weeks from release and Cinesite (IIRC?) didn't have the capacity to render out all the final frames in time. The call went out internally for volunteers to learn how to run jobs, and I gave up a weekend to babysit renders. Every day new assets would be delivered and rendered frames picked up (on huge Ampex DST cassettes - hundreds of gigabytes each! A lot in 1999, anyway.) My task was to get shots rendered at output resolution as efficiently as possible, and to preview each shot to make sure there were no obvious errors (black frames, e.g. - software wasn't perfect.) There was a bit of an art to it, since the frames could be rendered on almost any idle CPU in the facility via our in-house distributed queuing system (race, props to erco) and capabilities of the host systems were variable. If you weren't on top of things, the shot might get hung up on some frames that ended up enqueued somewhere shitty where they'd never finish, etc. The South Park frames were pathological - out of a desire for verisimilitude, the construction paper textures were HUGE, and everything was modeled in 3D (Alias) with lighting and shadows and very small Z depths between layers. A lot of the shots I drove were from the "Blame Canada" sequence (though without sound, I didn't know it until I saw it in the theater a few weeks later) - with a huge number of characters on screen, that meant gigs of texture per frame, as every character (and usually the background) was made of polygons each mapped with a particular paper texture. No wonder Cinesite ran out of time and had to go hit up other shops at the last minute. In conclusion, batch processing: still a thing. (Epilogue: sadly, didn't make it into the credits - those were already done, I guess? - but for giving up my weekendI did score an invite with a +1 to the wrap party. Isaac Hayes rocked. Mary Kay Bergman held my +1's hair while she barfed in the ladies room. And as far as I could tell, Matt and Trey never bothered to show up. A+, would give up weekend again.)

pram 6y ago

Computer Operator is probably close to being extinct but that was actually my first IT job, in 2010! It was for a very old school credit union, and I basically managed all their AIX systems and ran the nightly batch jobs for all the daily financial transactions. They changed the title to 'UNIX Administrator' while I was there so that should give you an idea.

monocasa 6y ago

Adding to what others have said, the Computer Operator profession is dead as it was replaced by "operating systems". Responsible for loading and scheduling work on computers.