These two pieces of code are the fundamental necessary software
to build a directory service as an addon for VMS. They implement the
kernel mode parts of services which gain control when XQP / ACP requests
are made and allow alteration.

My notion was that file operations can be captured so that file
create in fact first is set to create a null file in a spiralog
volume, and another file on another disk, with the spiralog file
header pointing to the real file. The underlying file can be
created with or without a pathname; that's a matter of taste. The
underlying file structure for ODS2, ODS5, or even ODS1 is valid
in any case.

Opens would use the softlink structures in the code to open
a file on the real disk, and the close (deaccess) monitor
would clean up the user channel when done.

I could perhaps share some of the ACE creation code with you if
you like, to save time. Note that the daemon calls some code
which is used to read an entire ACL in case the ACL is too long to
be read initially in the kernel thread.

The io$_access filter routine (accfilt:) saves the original access
and issues its own read-acl for the file, and checks for its own
format ACE in the ACL,interpreting the contents. I use one (large)
(potentially) ACE instead of a bunch of them, and just encode things.

Thus the softlink part has a flag, the device name, and the file ID
on the device. The $QIO runs from kernel mode, delivers a normal
kernel AST which simply fires up a special kernel AST, and the
special kernel AST restores context and restarts the original user
IRP. If the ACE has a "talk to the daemon" flag, the driver sends
a message to the daemon input mailbox with info including where the
daemon should fire up a special kernel AST. The daemon does its thing,
fills in status and starts a special kernel AST where told to which
merges in to the line of code that restarts the original I/O (which
has to restore the previous mode bits of the PSL as well as other
context).

Create filtering as in the current driver will just send a message
to the daemon regardless and await a status, then turn the create
to an open existing. (Notion is that the daemon creates both files
and returns FID info of the real file so that can be soft linked to
the way Safety does conditional softlinks.). It could instead run
a thread of kernel control to create the files instead. This would need
to

1. Create the null sized file in the directory structure of the spiralog
disk
2. create the real file on some other volume
3. Add an ACE to the null sized file on the spiralog device with the
device and FID of the created file (which info is presumably not available
until the create is done on the subordinate disk)
4. Return with the in memory structures set up to have an ACE with a
softlink to the file on the secondary device.

5. Then run the original open with user channel munged and keeping
an LDT structure around so the channel can be put back on close.

It is of course possible to do a version that uses the daemon to do
the creation for you first, then later build a kernel thread of
execution. This would prove the concept and be usable, and maybe even
fast enough...

The Spiralog disk and the underlying disks would remain valid VMS
file structures, stand alone, at all times here.


If later you want to generalize and replace the spiralog directory
structure with a RDBMS (and add read/write directory monitoring)
the extenstion of the same methods should work...

Glenn Everhart
(You can forward this to EDO when it becomes possible...)