UnForm includes a TCP/IP monitor program that can watch for raw print jobs arriving from network computers, similar to how a network printer would. In effect, the UnForm server can serve one or more virtual network printer ports, each with an associated UnForm client command line.
The monitor is automatically started if there are one or more port configuration lines defined in the [tcpports] section of uf100d.ini. For example:
This line would print to the server's spooler –dlaser device, processing jobs through the acme.rul file:
9100=-o ">lp –dlaser –oraw" –f acme.rul
This line would print to a Windows server shared UNC printer, processing jobs through the acme.rul file:
9101=-o \\winsrv\laser1 -f acme.rul
This line would generate pdf files to the path specified, using the date and job number to generate unique names:
9102=-o "/usr/pdfs/%d.%j.pdf" –p pdf
The following substitutions are made in the command line definition:
Characters |
Substitution |
%d |
The date in YYYYMMDD format. |
%t |
The time in HHMMSS format, using a 24 hour clock. |
%p |
The process ID (this is not necessarily unique). |
%j |
The sequential job number, which is an ever-increasing unique number. |
When jobs are submitted to the UnForm server in this manner, it is important to realize that the submission is one-way, and once printed the job resides entirely on the server. It is therefore not possible to print a job and have data returned to the client (i.e. –o client:device), or to have PDF previews generated on the submitting workstation (-p winpvw). Once the job is submitted to the TCP/IP monitor, it becomes local to the UnForm server, as if uf100c is physically run on the server (which, in fact, is what happens).
When jobs are submitted, they are dropped into the rpq/ subdirectory under the UnForm server installation. All submission files are given a unique name with a ".in" extension, and a companion file with a ".cmd" extension is also created that contains the command line options. As jobs are received, and also at least once every 5 seconds, a sweep is made of newly submitted jobs, each submitted to the server via the server's local "uf100c" program. As a byproduct, you can drop jobs into this directory independently of the server, being careful to create the ".cmd" file first, then the associated, complete ".in" file, using your own unique naming algorithm. Note that the sweep assumes that any *.in file is a complete file and will have an associated .cmd file, so it is incorrect to open a .in file and begin writing to it, as the sweep may attempt to process an incomplete file. Instead, create the file with a different extension and then rename it when it is ready for processing.
When there are launch errors processing the job, such as an invalid output device, the rpq spool files remain in the queue. Non-license errors are retried a maximum number of times (based on the tcpportretry=n setting in uf100d.ini), and then go idle to await administrator disposition. Job license count exceeded errors are retried indefinitely, until the queue files are purged via normal aging cycles. There is a .rty file for each job that counts the retries, so if a problem is transient, an administrator can remove *.rty files from rpq and the jobs will start processing again. The *.cmd files can also be edited, if needed, to fix a command line option that is causing an error, before removing the *.rty files. Note that errors that occur after a job is started, such as subjob errors or syntax errors, do not trigger retry processing.
To configure Windows printers to submit jobs to this monitor, you can use the built-in Windows support for TCP/IP printers. When configuring a printer, you can choose to Add a Port, selecting Standard TCP/IP Port. The Printer name or IP address of the "printer" will be the UnForm server, the Protocol is "Raw", and the Port Number is the number of the configured port line defined in uf100d.ini. UnForm can accept two types of input: plain text and PostScript, so you can choose either the Generic / Text Only print driver, or a PostScript driver, such as the Generic MS Publisher Imagesetter or one of the many printer vendor PostScript drivers. Note there are significant differences in the way UnForm handles the two different types of input. See the UnForm AFO chapter for more information.
The picture below shows a Windows XP example of the configuration screen:
Note that other operating systems also support methods of printing to raw TCP/IP printers. For example, Linux CUPS supports the socket://address:port device setting, The configuration is identical to that of configuring a network printer, except the "printer's" IP address and port are the UnForm server and raw port number.