ITEM: D3330

Printing to a printer attached to a TCP/IP-based terminal server

Question:

I have a brand x terminal server to which a printer is asynchronously
attached.  The terminal server is IP-addressable, and possesses
asynchronous ports to which printers, modems, and tty devices can be
attached.

I want to set up a queue on the RISC that can access the printer on
the terminal server.  How do I do this?

Response:

The terminal servers with which I have worked all solve this problem
the same way, as outlined below.  Apologies for the many asides in this answer.

When a user uses smit to create a virtual printer, the "mkvirprt"
command is executed.  This is not a real smit conversation; notice
that when a virtual printer is created, modified, or removed via smit,
all of the F keys at the bottom of the ASCII interface vanish or, in
the graphics interface to smit, a new window is opened to deal with
the virtual printer.  A user can accomplish the same thing by issuing
one of "mkvirprt", "lsvirprt", or "rmvirprt" from the shell prompt.

When "mkvirprt" (MaKe VIRtual PRinTer) is executed, the second
"question" the user is asked is:

   Enter device name (or, ! to exit):  ->

Above this question, the mkvirprt command will list the lp devices of
which it is aware (examples: lp0, lp1, lp2, and so on).  Normally, a
user will choose one of these devices.  However, a user can enter the
name of any file that a) exists in the /dev directory and is b) either
a block special, character special, or regular file.  The string
entered in response to this question will be used as the argument to
the "file = " line in the device half of the queue-device stanza for
this virtual printer queue in /etc/qconfig.  Example, assuming "lxx" 
was typed in response to this question:

asc:  
        device = lxx     
        up = TRUE
lxx:          
        file = /dev/lxx 
        header = never
        trailer = never
        access = both 
        backend = /usr/lib/lpd/piobe

Notice that lxx is also used as the label that connects the queue half of
the stanza to the device half of the stanza.

Any job submitted to this queue will be completely processed by the
formatter filter portion of the virtual printer subsystem and then
unceremoniously dumped into the file named /dev/lxx, escape sequences
and all.  This data is exactly what would have been sent to a printer,
had a real lp device been specified as the answer to the question
posed by mkvirprt.  (This, by the way, is a useful way to capture
formatted data and troubleshoot datastream problems).

Stop the qdaemon.

   stopsrc -cs qdaemon

Edit /etc/qconfig and, using the previous queue as an example, change the "file ="
line to FALSE.

asc:  
        device = lxx   
        up = TRUE
lxx:          
        file = FALSE
        header = never
        trailer = never
        access = both 
        backend = /usr/lib/lpd/piobe

At this point in time "asc" is a queue that isn't going to do much of anything so
some more changes have to be made.

The backend for the asc queue is piobe, which is defined as the "print job 
manager" (see piobe in info for more details).  To simplify matters, think of 
piobe as a process that passes your print job from process to process (a "pipeline
of filters"), giving each process a crack at your datastream.  The processes
invoked by piobe depend upon how the virtual printer was set up and on which (if
any) command line flags were used when the job was put into the queueing system.

The last process invoked by piobe is normally "pioout", defined as "the printer
backend's device driver interface program" (see pioout in info for more details).
pioout is just a delivery boy; after the datastream is formatted beyond all
recognition, piobe sees to it that pioout is invoked to cause the physical delivery
of the datastream to the physical device.

The asc queue was defined for a virtual printer and is therefore accessible via the
"lsvirprt" command, which is useful for modifying virtual printer definitions.
Using lsvirprt to select the (example) asc queue, examine the "mo" attribute.  The
"mo" attribute is defined as 
   
   Command String to Invoke Device Driver I/F Program
      (end of pipeline)

The "mo" attribute can be defined to be whatever it needs to be.  The vendors of
terminal servers generally (but not always) provide executables that are used in
place of pioout.  The new delivery boy just snaps into the virtual printer 
definition and, if properly written, no one will ever know the difference.

The goal here is to get AIX and the local queue to format the datastream and then
deliver it to the remote printer which is asynchronously attached to an 
IP-addressable terminal server w/ individually addressable asynchronous ports.
The executable that performs this task, and that is used in the new definition for
the "mo" attribute in the virtual printer in question, is a sockets program.  These
programs typically take at least two arguments: 1) the IP address of the terminal
server and 2) the port number on that terminal server.  The fully-qualified 
pathname of the executable and all arguments must be specified in the mo attribute.

When a job is put onto the (example) asc queue, the job will be completely 
formatted (as specified by the virtual printer setup and any command line flags)
and then passed to the executable specified by the mo attribute.  That program will
then establish a socket connection to the terminal servers and deliver data to the
terminal server, which will in turn deliver the data to the specified port on the
terminal server.

Most vendors supply the source code for this program, along with directions for
compiling and using it.  There are many ways the program can be used in
conjunction with the virtual printer, but it is **MY OPINION** (and recall that it
was free) that the method outlined above involves the fewest steps and, much more
importantly, makes as few modifications to the operation of the enq-qdaemon-piobe-
formatter filter quartet as is possible, which is a good thing.  There is a lot of
communication between these processes and it should not be disrupted for no reason.

Remember to restart the qdaemon.

   startsrc -s qdaemon




Support Line: Printing to a printer attached to a TCP/IP-based terminal server ITEM: D3330

Dated: August 1993 Category: N/A

This HTML file was generated 99/06/24~13:30:57

Comments or suggestions?
Contact us