yes, his app is trying to use an internal interface that changed. There's
nothing wrong with the DEC code. He simply has made an assumption about
how dkdriver worked, and claimed to me he HAS HAD the dkdriver.mar from
alpha vms 6.2, so he has not, in all the time since that came out, apparently
bothered to check the code to see whether his assumption was true. As a
result his product corrupts disks and has been doing so since 6.2 came
out...what, 2 years ago?

That nobody mentioned the implications for start_io stealers till recently
when I did is not that surprising. A 3rd party who is counting on some
driver's detailed behavior has a responsibility to check that his assumptions
are true; Digital has no promises outstanding to keep this stuff constant.

Given the legal climate though, and some other stuff you may not know about
I'd strongly suggest that you run any replies by legal before talking
with Ben. This is the kind of issue where a statement by a DEC employee could
be used to try to prove that Digital has made a promise to support some
internal interface. This guy might just try such a thing if we give him
the rope to do it. Let legal check a reply, or at least someone higher
in the management chain than Tom.

Geez, I'm amazed nobody told you all this. However, I've known OF his
product for some time. 
You could perhaps tell the CSC in Canada that this is a bug in a 3rd party
product, i.e., a design assumption about some internal details of dkdriver
that hasn't been correct since 6.2 came out, and that he had the listings
to check it and didn't. Up to you. But what the CUSTOMER gets to hear
is different. I think the customers (his and ours) need to hear that
this is a problem with ASCI's code...not with DEC's. And I;'d
bet that that won't be what Ben will tell them. A blitz about the product
could even be called for if that's the way it is presented. That
decision is however not mine...
glenn