Date: 2-January 1997
From: Glenn C. Everhart,PhD
OpenVMS Engineering, I/O group
110 Spit Brook Rd
Nashua, NH 03062
Everhart@star.enet.dec.com

To Whom It May Concern:

About two weeks ago, in conjunction with an investigation which I agreed
to do for Bob Nolan of Raxco (we have known one another for several
years) which involved checking whether the ASCI WATCH product uses a
software driver to intercept terminal I/O, I received an evaluation copy
of this product on a CD labelled "Advanced System Concepts Software
Distribution, Disc 1 of 1, September 1996". (A photocopy of the front of
the CD is enclosed.) This package had the ASCI WATCH product and came
with a PAK which expired on 31 December 1996. I ran the test for Mr.
Nolan (and found that ASCI WATCH does use this technique, on which Raxco
holds a patent, incidentally.)

However, the CD also contains copies of various other ASCI packages.
Since I had been asked previously by some Digital legal folks what
evidence might exist that a part of the Deviceshare package contains
Digital code, I generated a disassembly of the TMSCPDRIVER.EXE image
which was located on the CD for purposes of checking to see whether this
image contained Digital copyrighted code. I had previously done this with
an image linked on 10-MAR-1994, a date prior to Brian Schenkenberger's
arrival at ASCI (as I am informed), and found clear evidence that the
image did indeed contain long sequences of instructions identical with
those in the Digital TMSCP code. These sequences are far too long to have
been a result of anything but copying of the code.

The image I examined yesterday was linked on 15-AUG-1996, and is most
similar to the earlier version, showing only minor differences apparently
to fix a couple of bugs. Both images contain Digital code, and it is
evident that no effort whatever has been expended to remove any of the
Digital code.

The disassembly was produced with the public domain DISM32 tool which can
be obtained via DECUS sources, or at a number of ftp sites on the
Internet; it is distributed in source form.

I can furnish the disassembly output should it be necessary, though
anyone can run the disassembly from any copy of this CD. The disassembler
generates a header which decodes the link date of an executable image,
which is generated by any VMS linker automatically.

While an electronic copy of an image can (with considerable difficulty)
be completely faked, a CD is not subject to this. Nevertheless, the
nearly identical results of the disassembly of this code from the current
CD and from the image whose internal date in early 1994 predates Mr.
Schenkenberger's employ at ASCI suggests that this code has been stable
for a fairly long time and that the Digital code has been there since not
long after it appeared on the VMS listing CDs.

I will add one additional bit of information. Looking over the
documentation of the ASCI packages, I see they are selling a device
shadowing package which claims not to require using a different device
name for the shadow set. This implies that it operates by intercepting
I/O from pre-existing devices, a touchy area. In fact, this cannot be
done safely with all current VMS device drivers; SCSI disks in particular
will be corrupted in many cases by programs which attempt to do this,
unless a different I/O subsystem is also supplied, which I do not believe
ASCI does. Quite apart from other reports of their shadowing package
corrupting data on other types of disks, ASCI's continued distribution of
these packages does harm both to Digital and to their own customers by
introducing disk corruption where otherwise there would be none. Nobody
else, to the best of my knowledge, has made this mistake in the design of
a shadowing system for OpenVMS.



Glenn C. Everhart