The directories /disk1/banyan/bps and /disk1/BPS contain the Banyan Print service and all of its support files. The structure of the Banyan Print service directories is shown in Figure 9-1.
The /disk1/banyan/bps directory is the service directory. This directory contains the Banyan Print Service executable and its support files. As services are established on the server through MSERVICE, data directories are created in the /disk1/BPS directory.
For example, if you establish a print service on server Finance called Printer@Finance@headquarters, a directory is established in /disk1/BPS called /disk1/BPS/Printer. If the service were called Laserprinter@Finance@headquarters, the directory established would be called /disk1/BPS/Laserprinter. This directory contains data for the print queue, logs, and other data.
You can have up to 20 print services configured on each server. While there is only one service directory for the print service, there can be many data directories under /disk1/BPS.
The files in /disk1/banyan/bps are as follows:
analyzer (Executable)
Print service analyzer program.
entity (Executable)
Handles print jobs sent to parallel, serial, and PCPRINT destinations.
killoff (Script)
Kills a Banyan Print service and all of its children. This file is not used by Banyan Print services on Revision 7.0 Banyan servers.
makestd.rsc (Script)
A Postscript program that asks a PS printer to send information back about itself. This script is used by the Postscript Print Service (PPS) to retrieve information on attached PostScript printers.
npm (Executable)
Print service database analyzer. This program analyzes the Qfile database.
nps (Executable)
Print service executable.
pps (Executable)
PAP Printer Destination executable. This executable manages the PostScript Print service.
prctrl (Executable)
Printer control utility, called from the Operator menu on the server console.
setprint (Executable)
Banyan Print Queue Manager.
setprint.msb (Database)
Message file for the setprint program.
spooler.rsc (Database)
Contains PostScript code that is used to add banners to jobs on PAP printers.
startent (Script)
Starts the Entity program.
vps.err (ASCII)
Error messages for the Banyan Print service.
amsevent.map (Database)
Standard Banyan service file, as described in Table 1-2.
cores (Directory)
Standard Banyan service directory, as described in Table 1-2.
cleanup (Script)
Standard Banyan service file, as described in Table 1-2.
create (Script)
Standard Banyan service file, as described in Table 1-2.
destroy (Script)
Standard Banyan service file, as described in Table 1-2.
dumpscript (Script)
Standard Banyan service file, as described in Table 1-2.
startup (Script)
Standard Banyan service file, as described in Table 1-2.
/disk1/bps/servicename
Each Banyan Print service data directory, /disk1/BPS/servicename, contains files as follows:
data_1 (Directory)
Contains various logs and data files. See the next section for details.
dfnnnn.0, [dfnnnn.1, dfnnnn.2...] (Database)
Files associated with a single print job. A job can consist of one or more files.
hdr.n (Database)
Contains a list of data files for a job. A job can have one or more data files. For the first part of the job, n=1. For the second part of the job, n=2, and so on.
jfilennnn (ASCII)
Contains a list of jobs in the print queue. This file has a randomly-generated four-digit suffix affixed to the filename when the service is created. (A typical Jfile has a name like Jfile1481.)
nps0.log, nps1.log (ASCII)
Log files for the Print service.
Qfile (ASCII)
Information needed by the Print service for all of its associated queues.
resnnnn.n (Database)
Information on one resource or destination. The nnnn before the period is a randomly-generated four-digit suffix affixed to the filename when the service is created.
There is one of these files for each destination configured. The trailing number after the period is incremented each time a destination is created, and each time the service is shut down and restarted. If there is more than one res file, they are both incremented.
RESFile.nnnn (Database)
List of all known filters and destinations. This file has a randomly-generated four-digit suffix that is affixed to the filename when the service is created.
The /disk1/BPS/servicename/data_1 directory contains the following files:
makestd.rsc (Script)
PostScript program that asks a PS printer to send information back about itself. This script is used by the Postscript Print Service (PPS) to retrieve information on attached PostScript printers.
MEM_MGMT (ASCII)
Used by the /disk1/bps/analyzer program.
OPEN_FILES (ASCII)
Used by the /disk1/bps/analyzer program.
TASKLOG (ASCII)
Used by the /disk1/bps/analyzer program.
PPS_stats.db (Database)
Contains data on the PPS service, such as the last start time and resources used.
PPS_stats.last (Database)
Contains old service data that is rolled from PPS_stats.db.
PPSname0.log, PPSname1.log (ASCII)
Log files for a PPS (AppleTalk PostScript) printer.
resource.db (Database)
Stores information on what resources are needed by queued jobs.
spooler.rsc (Database)
VINES dictionary file.
Structure of a Banyan Print service
The Banyan Print service consists of three UNIX processes:
NPS - Main Print service process. It handles RPC traffic to VINES clients, such as requests from SETPRINT and EMT. It also arbitrates on servers that have more than one established print queue. Figure 9-2 shows the interaction between these processes.
Entity - Handles print jobs spooled to parallel and serial ports, and to printers connected to the network through the Banyan PCPRINT program. Entity handles non-PostScript printing.
PPS - Handles jobs spooled to an AppleTalk PAP PostScript printer.
Figure 9-2 shows how these processes interact.
PPS is a UNIX process that allows Macintosh users to take advantage of the Banyan queueing services that make printing more efficient. It also allows PC users to access PostScript printers located on the network.
When a print job is spooled from a Macintosh workstation, it is received by PPS. PPS then sends the job to NPS, using the same functions that an MS-DOS® workstation would use to send a text file to NPS.
Once NPS receives the job from PPS, it analyzes the job and adds it to the appropriate print queue. This way, users can monitor the job from SETPRINT or EMT.
After NPS adds the print job to the queue, it sends the job back to PPS. PPS then sends the job to the PostScript printer.
Printing PostScript Files from a PC
When a PostScript job is spooled from a DOS or Windows workstation, the job is received by NPS. NPS then spawns a transient process called postfilt.
The postfilt process adds a PostScript header and footer to the spooled job, so that it will be interpreted as a PostScript file by the destination printer. NPS sends the job to postfilt, receives it back, and then sends it to PPS for delivery to the PostScript printer. Figure 9-3 shows these transactions.
The Lexlink Bridge service accepts data from VINES Print services and translates them into data that Lexlink printers can recognize. The Lexlink service is stored in /disk1/banyan/lex. Its data files are stored in /disk1/LEX.
The directory structure of the Lexlink service is shown in Figure 9-4.
/disk1/banyan/lex
The /disk1/banyan/lex directory contains the Lexlink service executable and all of its support files. These files are as follows:
lexsvc (Executable)
Lexlink service executable.
lbs.err (ASCII)
Contains Lexlink Bridge service error text.
cleanup (Script)
Standard Banyan service file, as described in Table 1-2.
destroy (Script)
Standard Banyan service file, as described in Table 1-2.
dumpscript (Script)
Standard Banyan service file, as described in Table 1-2.
startup (Script)
Standard Banyan service file, as described in Table 1-2.
svccdLog (ASCII)
Standard Banyan service file, as described in Table 1-2.
svclogn (ASCII)
Standard Banyan service file, as described in Table 1-2.
SvcLogs (ASCII)
Standard Banyan service file, as described in Table 1-2.
SvcTable (ASCII)
Standard Banyan service file, as described in Table 1-2.
/diskn/LEX/svcname
Lexlink bridge service data files are stored in /diskn/LEX/servicename, where servicename is the StreetTalk item name of the service. For example, if a Lexlink bridge service is named lexlink@finance@wctus, the directory is called /diskn/LEX/Lexlink.
The files in this directory are as follows:
lex0.log, lex1.log (ASCII)
Rolling log files for the Lexlink service.
lexcon.db (Database)
Contains connection data for the Lexlink service.