PrintKit queues configured for TCP/IP communications do not have an associated device that can be used by software that expects to be able to write output to a queue using a virtual device. However, you can create such a virtual device for a PrintKit queue.

OpenVMS allows programs to send output to a print queue as though they were writing directly to an output device. To do this, it provides a “virtual” device interface that saves the data as it is written and, when it is complete, spools it for printing. There is a considerable body of legacy code that takes advantage of this capability. (In particular, this is how MUMPS programs do printing.)

For a queue that communicates with a printer over a dedicated link, there is a device associated with the queue that can be used for the virtual device interface (the device responsible for the physical connection, or a LAT device configured for a particular network service). However, for a PrintKit queue using TCP/IP communications, the associated device is the shared network interface, which cannot be used as a virtual device.

The simplest way to get around this limitation is to use a LAT device to provide the virtual device interface and configure it to spool its output to the PrintKit queue. In this arrangement, the LAT device serves only as a “placeholder.” It is never actually used for LAT communications – so its node and port settings do not matter, and it doesn't need to be connected to anything.