On Thu, May 2, 2019 at 8:13 AM Paul Koning <paulkon...@comcast.net> wrote: > > On May 1, 2019, at 10:58 PM, Ethan Dicks <ethan.di...@gmail.com> wrote: > > I think those were still true for V3.X. I know we had a problem back > > then with our backups where someone elevated the priority of the Tape > > ACP over the Disk ACP (because it was faster) that left us with months > > of corrupt backups. > > Wow, that reflects very badly on the engineering involved. Setting > priorities wrong might cause things not to get done, or to take too long, but > it cannot ever be an excuse for data corruption.
Thinking back 35 years... it was that someone enabled the backup operator account with SETPRI, allowing the operator to elevate the priority of the script. What I think was happening was that the script was grabbing buffers from the disk before they were filled and slamming them out to tape. It definitely cut minutes off the backup time, which is why it happened. I'm sure the VMS wizards hadn't expected a user process to run at priority 31 (IIRC) because anyone with SETPRI _surely_ had the wisdom not to elevate above system processes. Definitely a failure to think of ways users could abuse the system. -ethan
