Operating a Network Printer

This section includes information for people using a network printer that the system manager has already configured. Such users can be a member of the system administration staff (managers, operators, etc.) or a standard MPE/iX user. The topics include:

Using the ENV parameter to designate a setup file
Using special forms on a network printer
Managing perforation and page separation on network printers
Acceptable text formats for network printers

Using the ENV parameter to designate a setup file

Any user can determine how a file is printed on a network printer by including the ENV parameter in a file equation or in an (HP)FOPEN intrinsic. To do so, you create the setup file and then enter its file name in the form ENV=<filename>.

When you specify a setup file in an ENV statement, the spooler assumes that it defines the entire printing environment. As a result, it supercedes all other setup file specifications in the file NPCONFIG.PUB.SYS, which the system manager created for your network environment.

If the setup file exists and if you have read access to it, the spooler opens the print file and prepends the contents of the setup file, ahead of user data, to the spool file. The information remains there for the life of the spool file.




	NOTE: Unlike environment files for other printers, no validity checks (proper filecode, syntax, other contents, etc.) are performed for printer setup files. Be sure that you consult your printer's documentation to create a valid setup file.

Managing special forms on network printers

The spooler manages special forms requests on non-network printers as follows:

Print a header, if headers are enabled.
If dialog is required, prompt the operator to approve printing the file.
If operator approves, conduct the forms alignment dialog and print the file.
If operator does not approve, print a trailer and defer the file.

In a network printing environment, this procedure is not feasible because, once the host acquires a network printer, it should print its file without interruption and release the printer. For these reason, HP recommends that users adopt one of the two following operational strategies for handling pre-printed forms. You should either avoid the use of preprinted special forms on a network printer. Or, you should dedicate the printer to one host, so that no other host on the network can print to it.

If you do use a dedicated network printer for printing special forms, you may also want to ensure that the spooler always conducts the forms message dialog for all copies of all files that include a forms message. The spooler's default behavior is to conduct such a dialog only when the forms message of the current file is different from that of the previous file. To override the default so that the spooler conducts the dialog each time, you can use the FORMSALIGN command. For example, to control the dialog for LDEV 6, you would enter:

   :FORMSALIGN 6; EACHCOPY,NOFORMIDOVERRIDE

Refer to chapter 4 and to the MPE/iX Commands Reference Manual (Volumes I and II) (32650-60115) for a complete description of the FORMSALIGN command.

Managing perforation and page separation on network printers

"Z-fold" paper is a continuous sheet of paper whose pages are separated by perforations which allow the pages to be folded together. Later they can be separated by tearing along the perforations. Such paper typically includes pinfeed (or tractor) holes for proper positioning in printers. By contrast, "cut-sheet" paper comes in individual sheet pages with no tractor holes.

Z-fold paper printers define an area near the perforations (typically 0.5 inch on either side) as the "perforation skip" area. Users can choose to avoid this area when printing. If they do, paper motion which causes the printer to enter this area instead causes the printer to continue advancing paper until it has spaced over the area.

MPE supports this conditional avoidance with the %102 (perf-skip on) and %103 (perf-skip off) CCTL codes. But the %2xx series of CCTL codes advance paper without regard to perforation (that is, they behave as if perf-skip is off, no matter what its actual setting). And the %3xx series of CCTL codes skip to a channel, which has no relation to the perf-skip mode. As a result, there are only a few CCTL codes, such as %60 ("0", double space) and %55 ("-", triple space), for which the perf-skip mode has any meaning.

The majority of network printers are cut-sheet printers, but many of them support the concept of top and bottom margins. As a result, there is a PCL perforation skip mode command. With perf-skip mode enabled, a Line Feed which would move the logical pen into the bottom margin area instead moves it beyond the top margin area of the next logical page. With perf-skip mode disabled, such a Line Feed allows the logical pen to occupy and print in the bottom margin area, to the physical limits of the printer.

The spooler supports enabling and disabling perforation skip mode, mapping CCTL codes %102 and %103 to their appropriate PCL counterparts, and implementing the %60 and %55 CCTL codes as two or three Line Feeds, respectively.

Acceptable text formats for network printers

This section describes the two forms in which applications can generate data destined for network printers which support only PCL, or PCL and, via PJL, the PostScript language. These forms are MPE record-oriented output or bytestream files, which may be raw PCL data, PostScript data, or ASCII text.

MPE record-oriented output

MPE record-oriented output is typically one line of ASCII text per spool file record. Each record includes a carriage control (CCTL) code that specifies how paper is to be moved vertically. Examples of vertical motion are advancing N lines, starting a new page, etc. Other MPE options allow for this motion to take place either before or after the text data (prespace or postspace mode, respectively). The default mode at the start of data is postspace mode.

Users need not include an explicit CCTL specification. If they do not, MPE provides a default that results in one <CR><LF> at the end of each text record.

Bytestream ASCII text files

Bytestream ASCII text files are lines of ASCII text without a record structure imposed by a file system. In bytestream files, lines are separated by the <LF> character and pages are separated by the <FF> character. The <CR> character may precede either of these, though it is not required. Unless the bytestream file was opened explicitly as bytestream data by a POSIX-aware application, MPE/iX would open it as an emulated variable-length file. In this case, the spooler would:

treat a <LF> in the data as an end of record
terminate an FREAD if the request is longer than the data preceding the <LF> or, if the request is shorter, discard any data between the last data byte read and the <LF>
start the next FREAD at the byte following the <LF>
pass the <FF> and <CR> characters unchanged

In contrast to bytestream files, MPE spool files have a very specific record-oriented file format. Therefore, to have the MPE spooler successfully process and print bytestream ASCII files, you must first convert them.

There are two general situations in which you are likely to need to know how to convert bytestream data for printing: when you want to print an existing bytestream file on disc, and when you are using a POSIX application that writes bytestream data directly to a spoolfile.

Printing a bytestream disc file

Bytestream files can exist on disc, either written directly to the HP 3000 by a POSIX application or transferred to the HP 3000 from a backup archive or another system. What method you use to successfully print a bytestream disc file depends upon whether or not the file contains motion control sequences to manipulate the logical pen of the printer other than simple <LF> and <FF> characters.

If the bytestream file on disc has motion control sequences such as PCL escape sequences or PostScript commands, use a file copy utility that (1) copies the bytestream file byte for byte, and (2) specifies a carriage control code of octal 320, which tells the spooler not to move the printer's logical pen on its own, but rather leave all such movements to the control of the file's data itself.

If the disc file has no motion control sequences other than simple <LF> and <FF> characters, use the MPE/iX PRINT or FCOPY commands (or almost any other file copy utility) to copy it to a spool file.

Writing bytestream data directly to a spool file

A POSIX application can use POSIX bytestream procedures to write directly to a device file that has the MPE/iX spool file format. The bytestream emulator portion of the MPE/iX file system automatically translates the bytestream data into variable length records, each with a carriage-control code. If the bytestream is simple ASCII text, such automatic translation to the spool file format will probably produce an acceptable report.

If, however, the bytestream data represents a graphic image, this automatic translation to MPE spool file format is not acceptable. In this situation, you may either:

Modify the application so that it uses MPE/iX file system instrinsics, not POSIX procedures, to create the output spool file. In this case, the program must explicitly specify octal 320 as the carriage control character, which tells the spooler not to move the logical pen; the data stream itself will handle carriage control motion.
Direct the application's bytestream output directly to a disc file, then use a utility to copy the disc file to spool file and specify octal 320 as the carriage control character. Again, this tells the spooler not to move the logical pen on its own.

Examples of converting bytestream files

Consider the following example, where myfile is a bytestream file:

   :FILE FROM=myfile  

   :FILE TO;DEV=LP;CCTL

   :FCOPY FROM=*FROM; TO=*TO

FCOPY opens file *TO with CCTL, using the configured record length of a printer in class LP as a default. Since myfile does not have a carriage control attribute, FCOPY specifies a CCTL code of 0 when writing a record to *TO. This code, having no special function, results in a single <CR><LF> by default. This effectively replaces the <LF> (new line character) in the original bytestream file.

Now consider a different example, where, instead of using FCOPY to create a spool file, a POSIX-aware application creates the file. This application could open myfile as a true bytestream file, then copy substrings of any size (including any <LF>s) to *TO specifying a CCTL of %320 on each FWRITE. When the network printer processes this file, the %320s tell it to not insert any paper motion sequences of its own. The data stream sent to the printer is then an exact replica of the original bytestream file.