> On May 2, 2019, at 10:49 AM, Ethan Dicks <ethan.di...@gmail.com> wrote:
>
> 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
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
