Planning your Printer Configuration

The Line Printer Spooling System (LP spooler) is a set of programs, shell scripts, and directories that control your printers and the flow of data going to them.

	NOTE: Use the LP spooler if your system has more than one user at any given time. Otherwise, listings sent to the printer while another listing is printing will be intermixed, thus scrambling both listings. Even if you have a single-user system, you may want to add your printer(s) to the LP spooler so you can queue print requests. This way, you do not have to wait for one request to complete before sending another.

To understand the LP spooler, think of it as a plumbing system, as shown in Figure 2-2 “Line Printer Spooler “Plumbing” Diagram ”. The data to be printed enters the system like “water”. Request directories (printer queues) serve as temporary holding tanks for print requests until they are sent to a printer to be printed. The request directory and printer control the flow of print requests.

Accepting, rejecting, enabling, and disabling print requests control the data through the LP spooler as valves would control the flow of water in a real plumbing system.

Interface scripts (written as shell scripts) near the end of the data flow serve as pumps which “pump” an orderly flow of data to the printers.

The line printer scheduler (called lpsched) controls the routing of print requests to the printers. It functions as an automated flow controller in the “plumbing” system by routing print requests to the physical printers on a FIFO or priority basis. lpsched enables files to be printed on a specific printer or printer class. It prevents intermixed listings (that is, the interspersing of printed pages from different print requests). lpsched also monitors printer/printout priorities, adjusts printer status, and logs LP spooler activities.

If one printer’s “drain gets clogged”, you can reroute a print request from that printer to another by using the lpmove command.Unwanted data can be “flushed” from the spooling system with the cancel command.

Figure 2-2 Line Printer Spooler “Plumbing” Diagram

Printer model files are required in the following procedures:

When you configure your printer into the LP spooler, you must identify the printer interface script to be used. The /usr/lib/lp/model directory lists printer interface scripts from which to choose. This directory contains files corresponding to the models and names of all HP printers and plotters (plus some generic model files). Table 2-5 “Model Files and Corresponding Printers and Plotters ” lists the names of the basic model files, the additional models to which they are linked, and the HP product numbers they support.

If you are configuring a non-HP printer to HP-UX, read the ASCII model files to identify the essential printer characteristics — such as whether your printer uses Printer Command Language (PCL) or PostScript. Also see the manual that came with your printer for more information on PCL language levels. For third-party printers that are not PostScript printers, use the model dumb; for non-PostScript plotters, use dumbplot.

The /usr/sbin/lpadmin command copies the identified model script to /etc/lp/interface/printername. See lpadmin(1M) for information on the command options.

A local printer is physically connected to your system. To configure a local printer, see “Adding a Local Printer to the LP Spooler ”.

A remote printer may be physically connected or simply configured to a computer and accessed over a network via rlp(1M). To access the remote printer, your system sends requests through the local area network (LAN) to the other system. To configure a remote printer into your local LP spooler, you must be able to access the remote system via the LAN. To configure a remote printer, see “Adding a Remote Printer to the LP Spooler ”.

A network-based printer differs from a remote printer in that it is connected directly to the LAN; it is not physically connected to a specific system. Network printers do not use device special files, but have their own IP address and LANIC identification. See “Adding a Network-Based Printer”.

When you configure a printer into the LP spooler, you assign it a printer name, to which you direct print requests. A printer name may have up to 14 alphanumeric characters and may include underscores. The following are sample valid printer names: laser1, letterhead, invoices, check_printer. The printer names you assign are listed in the directory /usr/spool/lp/interface. Each file in that directory is a copy of the model file (printer interface script) that enables you to print to the named printer.

You can make efficient use of multiple printers by grouping them as though logically they were a single printer. To do so, you create a printer class. A printer class is a collective name for a group of printers. The printer class is retained in the directory /usr/spool/lp/class. For example, our sample printers named laser1 and letterhead might be assigned a printer class called VIP, while printers named invoices and check_printer might be assigned a printer class called Accounts. A printer can belong to more than one class, however remote printers cannot belong to a printer class.

To use a printer class, you direct print requests to it, rather than to a specific printer. The print request is spooled to a single print queue and printed by the first available printer in the class. Thus, printer usage can be balanced and reliance on a particular printer can be minimized.

To create a printer class, see “Creating a Printer Class ”. Also see “Removing a Printer from a Printer Class” and “Removing a Printer Class”.

The print destination is the printer or printer class where a file will be queued. Several commands for the LP spooler require you to specify a print destination. You can appoint one print destination in your LP spooler to the system default printer. Alternatively, you can assign each user a default printer by setting a user’s shell environment called LPDEST.

Each printer has two priority attributes:

Typically, print requests are handled by a printer in the order they are received. By default, print requests have the printer’s default request priority and are FIFO (first-in-first-out). However, print jobs can be assigned priority values to raise or lower their priority, using the -p option of the lp command. Priority values range from 0 to 7, with 7 being the highest priority. See lp(1) for details.

A print request priority can be altered by using the lpalt command. A printer’s default request priority can be set using the lpadmin command (SAM allows a default request priority other than zero to be set when a printer is added, but cannot change a printer’s default request priority). See lpadmin(1M) and lpalt(1) for details.

If multiple print requests are waiting to be printed on a specific printer and all have priorities high enough to print, the printer will print the next print request with the highest priority. If more than one print request has the same priority, print requests with that priority will print in the order they were received by the LP spooler.

Similarly, a priority fence value can be assigned to each printer to set the minimum priority that a print request must have to print on that printer. A printer’s fence priority is used to determine which print requests get printed; only requests with priorities equal to or greater than the printer’s fence priority get printed. See lpadmin(1M) and lpfence(1M) for details.

Every LP spooler system request is logged in a log file located in /usr/spool/lp/log. The file contains a record of each LP spooler system request, including request ID, user name, printer name, time, error messages, and reprints due to failure.

The LP spooler system serves routine print management quite adequately. However, as technology needs have grown, the issue of scalability has proven an obstacle for the LP spooler.

If you are administering a large-scale printing environment, the HP Distributed Print Service (HPDPS) might be a preferable tool-set (see “HP Distributed Print Service (HPDPS)”).

HPDPS (also referred to as DPS) allows users to use familiar LP spooler commands, while giving you greater flexibility managing a complex print environment. Conversely, HPDPS commands allow far greater specificity in your print requests.

The HP Distributed Print Service (HPDPS) is a print administration and management product that represents an advancement beyond the LP spooler system. HPDPS handles large-scale and distributed print environments to a degree impossible using the LP spooler alone.

Both LP spooler and HPDPS may coexist in the same environment; code compatibility enables you to make a gradual migration to HPDPS. Though HPDPS is managed differently from the LP spooler, end users can continue to use familiar LP spooler commands in a HPDPS environment.

HPDPS provides a complete set of

To use the full capabilities of HPDPS requires using the HP9000 Distributed Computing Environment (DCE), a separately purchased product. If your host system is configured as a DCE cell, you can implement the HPDPS Extended Environment, which features a multiplatform client/server infrastructure, single-point administration, client authentication, and object authorization.

HPDPS can also be configured without DCE. Using the HPDPS Basic Environment, HPDPS still provides more functionality and scalability than the LP spooler, but some configuration must be managed locally, instead of from a single point of administration.

Simply stated, HPDPS consists of three kinds of printer management objects:

Depending on implementation, these objects may be configured on a single system or distributed on several computer systems.

HPDPS also uses a Gateway Printer, a logical printer similar to a “remote printer” provided by the LP spooler. A Gateway Printer allows you to direct a print request between the Basic Environment and the DCE Extended Environment and between hosts within the Basic Environment.

Using HPDPS, the administrator can manage the following kinds of settings from a single location:

HPDPS provides the following features:

If you decide to implement HPDPS, take the time to read the first five chapters of the HP Distributed Print Service Administration Guide before proceeding any further. This will give you an overall understanding of the design, capabilities, and strategies used when installing, implementing, and administering HPDPS.

For procedures, see “Implementing HPDPS” or the online help in SAM.

Plan your HPDPS Logical and Physical Configurations

Familiarize yourself with the HPDPS Objects

Before you can design your HPDPS-managed print environment, familiarize yourself with the interrelated components of HPDPS. Read the following sections in Chapter 1, “Introducing HP Distributed Print Service” of the HP Distributed Print Service Administration Guide:

• “HPDPS Architecture” defines basic HPDPS terminology and shows the objects in relation to one another.

• “How HPDPS Processes Jobs” explains how HPDPS components work together.

Additionally, “Planning your Logical Configuration” in Chapter 3 enumerates considerations relevant to the basic HPDPS objects.

Consider your Users

To figure out how you want your HPDPS system to manage the printers, ask yourself about the needs of your user population:

• What patterns do you observe among your users in the way they access the printers? Do they print continually throughout the day or in spurts? Are they printing from forms or onto letterhead? Is much time expended waiting for printouts at certain times of day or from certain printers but not others?

• Can your users be grouped according to their needs?

• What kinds of defaults do each group of users need?

• How should the flow of print requests be distributed to your printers?

To formulate a plan of how to apply the HPDPS objects to the needs of your users, review the following sections of the HP Distributed Print Service Administration Guide:

• The Minimum HPDPS Configuration, in Chapter One.

• Configuring HPDPS to Meet the Needs of Your Users, in Chapter One. This section introduces a variety of arrangements of HPDPS objects.

• Selecting Logical Configuration Models, in Chapter Three. This section assesses the advantages and disadvantages of various configurations of HPDPS objects.

Design Your Physical Configuration

Determine how many clients, spoolers, and supervisors to install.

For example, you can configure a Basic Environment, which will have all objects installed on a single host system. You will need to configure one client, one spooler, and one supervisor.

Figure 2-3 Sample HPDPS Basic Environment

In Figure 2-3 “Sample HPDPS Basic Environment”, fancy is a single host system, on which are installed the HPDPS client, spooler, and supervisor. Attached to fancy is one locally configured printer. However, any other printer accessible via the LAN may be configured to be used and managed by HPDPS. Also, any DPS-managed printers on another Basic or Extended system can be made available locally via Gateway Printers.

A sample HPDPS configuration with an Extended Environment might have one or more clients, one or more spoolers, and one or more supervisors, distributed among several host systems.

Figure 2-4 Sample HPDPS Extended Environment

In Figure 2-4 “Sample HPDPS Extended Environment”, fancy, tango, and kenya are host computer systems, on which are configured HPDPS objects that are distributed in an Extended Environment. The entire environment may be managed (using SAM) from any system on which a client is configured. Thus, fancy and tango may be used to manage all HPDPS objects, including those configured on kenya. Attached to kenya is a locally configured printer, which necessitates that an HPDPS supervisor reside there. Users of fancy and kenya may send HPDPS print requests to any HPDPS printer because clients are configured on their systems. The user attached to tango may not submit HPDPS print requests, even though the HPDPS spooler is configured there. However, by using the lp spooler, tango’s user may send print requests to any HPDPS-configured printer. The lp spooler is able to handle the print requests and forward them to HPDPS printers.

For further information, read the section, “Planning your Physical Configuration, in Chapter Three of the HP Distributed Print Service Administration Guide.

Determining Filesets to Install and Where to Install Them

HPDPS software is bundled under the CDE Run-Time Environment (or under Instant Ignition under the Run-Time Environment) in the product DistributedPrint.

You can install the entire product or selected filesets, depending on the role your system plays in the distributed print environment.

These are the filesets:

PD-CLIENT

Mandatory. Select this fileset to use the HPDPS commands. You must also have this fileset if you plan to manage the print environment with SAM.

PD-SPOOLER

Select this fileset to run an HPDPS spooler on the system.

PD-SUPERVISOR

Select this fileset to run an HPDPS supervisor on the system.

PD-COMMON

A backend-dependency fileset used by all components.

PD-SERVCOMMON

A backend-dependency fileset used by spooler and supervisor code.

When using swinstall to select HPDPS filesets for client, spooler, and/or supervisor, the appropriate backend-dependency fileset(s) will be pulled in automatically.

You will use this information in “Implementing HPDPS”.

Familiarize yourself with the HPDPS Environment Variables

Table 2-7 “Values stored in the /etc/rc.config.d/pd file” shows the values set in /etc/rc.config.d/pd. Once your HPDPS configuration is stable, you may want to edit this file to set the values, so that when HP-UX boots, it activates the configuration automatically.

Table 2-7 Values stored in the /etc/rc.config.d/pd file

Value	Definition
PD_ENV	Defines the HPDPS environment. Set to basic by default; set to extended to execute as an HPDPS Extended Environment.
PDPRNPATH	Defines the paths where HPDPS finds printer model files. (For information on the contents of a model file directory, see the HP Distributed Print Service Administration Guide.)
PD_CLIENT	Specifies whether the host system starts a client daemon. Set by default to PD_CLIENT=0, meaning the host does not start a client. (Set PD_CLIENT=1 to start a client daemon automatically during reboot.)
PD_SPOOLERS	Defines the spooler names to start and execute on this host. No spoolers are started by default; follow the instructions given in the file to start spoolers.
PD_SUPERVISORS	Defines the supervisor names to start and execute on this host. No supervisors are started by default; follow the instructions given in the file to start supervisors
PD_MEMLIMIT	Defines the maximum amount of memory (in kilobytes) the spooler or supervisor can use on the host system

 

	NOTE: For further information about these values, consult the section, “Automatically Starting HPDPS,” in Chapter 4, “Getting Started with HPDPS”. You can read /etc/rc.config.d/pd to familiarize yourself with the values you need to set.

DCE and HPDPS Extended Environment

If you intend to take fuller advantage of HPDPS functionality and configure an HPDPS Extended Environment, you must also install DCE filesets. Note, the DCE filesets required to run an HPDPS Extended Environment are not those that are bundled with the HP-UX core filesets. They are part of an optional HP product.

• To implement HPDPS Basic Environment, load the 10.x default DCE core services bundled with HP-UX for distributed computing environment functionality.

• To implement HPDPS Extended Environment, load the DCE servers, a separately purchased product.

Detailed instructions for installing the HPDPS components using swinstall are found in Chapter 2, “Installing HP Distributed Print Service,” of the HP Distributed Print Service Administration Guide. Pointers to DCE documentation are found in the same chapter.