Remote print spooling from RSX to VMS


This UIC contains the sources for a specially modified version of
the VP: virtual device and an associated special copy of the VDV$$$
task called VPVDV.

Since it looks like a regular printer, this virtual driver allows
completely transparent use of the standard RSX print spooling
from the queue manager.

A remote system with a printer and the appropriate DECnet task 
will receive print records exactly as they would be sent to 
an RSX printer, including header and file break pages.

To allow sharing the printer on the remote system, the remote object 
opens a temporary file when the VP: driver receives a IO.ATT QIO.
Records are then copied across the network till the task driving the 
VP: device issues an IO.DET. The remote temporary file is then 
closed and sent to the real printer on that system.

To cause attach and detach QIO's to be sent to the printer, the 
print que must be initialized as shared. (see the /SH switch).

Our high speed printer is on a VMS system. The only code required in 
the VMS system is a short DCL file called RPRINT.COM, supplied in 
this uic. RPRINT.COM just copies SYS$NET to a temporary file, then 
prints the file with no VMS header or trailer and deletes it after 
printing.

Implementation notes:

	1. The only change to the stock VP: driver is turning on the 
	U?.ATT notifcation bit in the UCB.

	2. VPVDV must be installed by name and should be started 
	of the clock queue with a:

		run vpvdv 1S

	This makes it's owner CO:.

	3. VPVDV brings the VP: driver online explicitly. BE CAREFUL 
	to make sure you have the modified VP: driver. The original 
	one will hang.

	4. VPVDV tries to connect to node RPRINT, task RPRINT. We 
	assign the appropriate aliases.


Excerpts from the startup command file for out systems are in 
VPSTART.CMD. This can be used as a starting point.



THIS IS A VERY PRELIMINARY VERSION OF THIS CODE AND STILL HAS BUGS.

VPVDV IS A PRIVILEGED TASK AND CAN EASILY CRASH A SYSTEM. USE WITH CARE.

Some of the known problems are:

	1. The remote side should be defined as a multicopy DECnet 
	object. Currently it is openned by task name. This means if
	one RSX system is transfering a print file, another RSX system 
	will fail to connect.

	2. The code for VPVDV.MAC was hacked out of VDV.MAC. It 
	should really be cleaned up and commented. Some debugging 
	messages print on the console.

	3. Some kinds of carriage control don't print properly.
	This is a side effect of the implied carriage control in the 
	VMS temporary file. VPVDV tries to remove excess CR/LF's.

	4. VPVDV can hog the system badly. We normally run it at 
	priority 45.

Questions, complaints, praise (I rather like the last) can be 
addressed to:

	Hans J. Jung
	Assistant Manager of Research and Development
	The Associated Press
	50 Rockerfeller Plaza
	New York, NY 10020
	(212) 621-1568

I will take calls, but am notoriously hard to reach by phone. I also 
can't guarantee you much phone time.