Earl Lakia writes:

	Anyway there are no secrets to writing an ACP other
than it is privledged, can cause system crashes,  etc.   
Each ACP must have a device driver that knows about it and
can pass packets to the ACP.  The ACP receives these
packets through its send data packet mechanism.  The ACP
changes to exec state whenever it needs to get a packet or
to do I/O done for a packet.  Othewise, it is running in
normal user mode.  Make sure that you do address relocation
for any buffers within the driver, and before you queue the
I/O packet to the ACP.   Only when the queueing task is the
current task can you be sure that the address windows of
the task are correct (the caller can do a QIO without
waiting and call the memory management routines and change
is address windows).  I once had to fix a Digital supplied
ACP that didn't follow this rule. 

	I am sending you the following as seperate letters.

	1) ZQDRV.MAC- Driver
	2) ZQTAB.MAC- Driver Tables
	3) QUEACP.CMD- Commandfile
	4) QUEACP.MAC- ACP

	This software provides store and forward queue
services similar to VMS mailboxes for tasks within a node.
This software provides a router that allows the same
functionality even if the receiver is not on the same node.
This software is available through DECUS (however, DECUS
is not very current).

	If you are familar with DEC Message Queue, this
product is almost the same, except it is public domain.  The
VMS product is implemented with VAX/VMS system services.