not support all the data-processing options that the printer interface does. It cannot be configured to generate a banner page, for example, or perform tab expansion. The options for the printer-interface method are not valid with the device interface method.
The setup for the two RTEL methods is similar, but not identical. Both methods take advantage of the “server_hosts” file to read configuration information. This file shows the host’s print queues and devices, and controls which service/port and server connections will map to. It is also used to specify options for processing the data sent to the EPS. For example, you can add a banner page to a particular print queue. In the case of device files, options to the rteld command line can also be specified in the “server_hosts” file.
To use the printer-backend method, you must run a shell script (mkprt) that will add a new printer queue on the host and link any executables RTEL needs to start RTEL connections. The script can also add new entries to the “server_hosts” file if you desire. For lpr-style printers, the host’s /etc/printcap file can be updated by mkprt. Mkprt will also offer to add your EPS’ IP address to the host table (/etc/hosts) if it is not there already. You can enter addresses to these files by hand instead of automatically, if desired. You need to configure the EPS separately (for service and/or port setups). After these 2 steps, you can use the EPS as a print device from the host, and it will support queued jobs, etc.
Using the device-file interface involves less initial setup, but is potentially more complicated for multiple devices. It does allow more flexibility and functionality than the printer-backend method. To setup the device interface, you must run the rteld program for each device desired. In general, the rteld program allocates a pseudo-tty device pair and attempts to connect them to the specified EPS and service. Once the program creates this pair, any user or application can use the tty device as a connection to the EPS. Applications can then print directly to the device, users can echo data to the connection, and communications programs can use the device as if it was a physical device on the host. See the rteld man page in the RTEL/source distribution directory for a detailed list of available rteld options.
There are 2 main executables that are used for the RTEL handling:
1.The lp_filter and lpr_filter programs are backend filters for your host’s lp or lpr print spooler. When using the print queue interface, the EPS calls these programs to actually connect to the EPS and output the job to a serial port. They can also be configured to do limited data processing, such as tab expansion.
2.The rteld program is run whenever a device interface to an EPS service
is created, used, or deleted. It can also be run at system startup time to establish any “permanent” pseudo-device connections.
