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.