Greetings

[Paul Koning]

> On May 2, 2019, at 10:49 AM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
> 
> On Thu, May 2, 2019 at 8:13 AM Paul Koning <paulkoning at comcast.net> wrote:
>>> On May 1, 2019, at 10:58 PM, Ethan Dicks <ethan.dicks at 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

More in particular, it is a design failure, relying on timing hacks rather than explicitly and correctly passing ownership of data from producer to consumer.

	paul