Frequently, the location of the application generating data to be printed and the printer itself are in two different locations. This topic describes how to set up one system to send print requests to a remote site and another system to receive the requests and print them.
The receiving system may be either another system running TSG software or a PAD which has a serial printer connected to one of its asynchronous ports.
When one system sends information to another that is to be printed, the receiving system needs to know why the call request is being made. That is, the receiving system needs to know that the data corresponding to a new call request should go to a printer, rather than to login for example. There are a number of ways to do this and the one you choose will be determined by the abilities of the system receiving the call:
You may decide to configure the receiving system to send all calls to the printer. If this is the case, you can use any type of call request from the sending system.
If you are using a PAD to receive the call, you may decide to use a subnet Address (SNA). An SNA is basically extra digits added on to the real address provided by your network. So for example, if your network address is 999999, you may set up the sending machine to call address 9999993 and attach the printer to asynchronous port 3 on the PAD. Your PAD may need to be configured to send calls to SNA 3 to port 3. Your PAD vendor should be able to tell you how to do this.
Another common method of determining the reason for a call request is to use call user data (CUD). These are just extra characters (numbers or letters) appended to the call request. So for example, you may set up the calling system to use a CUD of "PRINT" and have the receiving system direct all calls with this CUD to the printer. This is the recommended method if the receiving system also has TSG software installed. This method can also be used for PADs if they are correctly configured.
As long as the sending machine and the receiving machine agree to send or receive a certain type of call request for printing purposes, any method can be used.
The receiving system may be anything that can connect to both an X.25 line and a printer. If this is a PAD, check with your vender and configure it to pass print requests to the printer. This will involve configuring the call request type described in the previous section (the SNA or CUD) and may involve some configuration of the asynchronous port.
If the receiving system is running TSG software, it is recommended that you use the printx25 utility supplied with the software. To the file /etc/x25tab, add the following line:
CUD=\1\0\0\0PRINT:PASS:API:YES:/usr/lib/x25/utils/printx25 $dev -dhp_printer
Replace hp_printer with the name of the printer to be used. The names of your printers can be displayed by running:
lpstat -t
Note that this assumes you have previously set up a print spooler on the system that is to receive the print request. That is, you should be able to type:
cat /etc/x25tab | lpr -dhp_printer
(or whatever printer name you have chosen) and have a copy of the file /etc/x25tab printed out.
In the above example, a call user data with the binary digits "1000" and the ASCII characters "PRINT" were used. The CUD "1000" is used for all X.29 over X.25 calls and "PRINT" distinguishes this as a print request.
The xprint utility is used to perform the sending of a print request. It uses the X.25 API, so any problems introduced by tty line disciplines and interaction with the X.25 network (like flow control) will not occur.
xprint uses much the same command line syntax as xpad. However, once it has connected a call, it simply sends everything it receives as stdin down the X.25 link to the remote system.
To test xprint, enter the following on the UNIX command line:
cd /usr/lib/x25/utils
ls -l | ./xprint -d 9999999 -uPRINT
As described in the "Overall Considerations" section, you will need to adjust the address (999999) and/or call user data (PRINT) for your system. A complete list of call request options can be displayed by running xprint -h.
Once you have been able to print a listing of the contents of your directory on the remote printer, you can integrate xprint with the UNIX printer spooling system on the sending system. To do this, run lpadmin to make your new printer:
/usr/lib/lpadmin -premoteprint -i/usr/spool/lp/model/network -v/dev/null
enable remoteprint
accept remoteprint
If you are running Netcom on an SCO system, /usr/spool/lp/model will have a script called network. After installing the printer, edit /usr/spool/lp/remote to contain the following line:
remoteprint: /usr/lib/x25/utils/xprint -d 999999 -uPRINT
As described previously, you will need to adjust the address (999999) and/or call user data (PRINT) for your system.
Again on SCO, you must also edit the file /usr/spool/lp/admins/lp/interfaces/remoteprint. Edit the last line of this file to read:
) | $network
That is, delete the arguments you see following the $network command.
If you are not running Netcom on an SCO system, it is a bit more complex. Do not use the -i network option. When you omit this, lpadmin uses the default interface script. After lpadmin finishes, you must manually change the interface script for the printer you installed by editing /usr/spool/lp/admins/lp/interfaces/remoteprint to use xprint instead of cat or lpcat to print the file.
Copyright © 1997-2003 The Software Group
Limited. All Rights Reserved.
® Netcom is a registered trademark of The Software
Group Limited.