Greetings

[Greg Stark]

I'm just guessing here but I would suspect this had more to do with the
hardware capabilities of the tape system.

Not all tape drives could just pause to wait for more data then resume. If
the data wasn't being steamed fast enough the tape would have to resync
somehow which could even require rewinding and it's possible that was
either unsupported or just unreliable

On Thu., May 2, 2019, 12:41 p.m. Paul Koning via cctalk, <
cctalk at classiccmp.org> wrote:

>
>
> > 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
>
>