Migrating

The NMS is part of the fundamental operating system and is installed on the MPE/iX system with the INSTALL or UPDATE utility. The first boot after an INSTALL or an UPDATE creates the HPSPOOL account structure.

With release A.40.00, device classes are now treated solely as collections of logical devices. This means that operations applied to a device class are applied to all devices in a class. For example, if a spooler is stopped for a device class, the spooler is also stopped for all logical devices in that class.

Before release A.40.00, users could issue the following command:

   STOPSPOOL ldev

and print "hot" to the printer while spool files were being created for the device classes associated with that LDEV. This is no longer possible since device classes are collections of logical devices.

There are two workarounds shown in the examples below. If the device that you want to operate unspooled is part of a class that contains at least one other device that can remain spooled, there is no problem. The following examples assume that this other device does not presently exist.

Method 1: Configure at least two devices in a particular device class.
Suppose that LDEV 6 and nonexistent LDEV 19 are configured for device class LP. Make sure that the queue for LDEV 19 is open. One way to do this is to enter an OPENQ 19 command in your SYSSTART file. If LDEV 6 is usually spooled, you can also enter the STARTSPOOL 6 command or SPOOLER 6;START command in your SYSSTART file.
Make sure that your applications generating spooled output direct that output to class LP. Enter:
STOPSPOOL 6
or
SPOOLER 6;STOP
Start your application. When it is finished, enter:
STARTSPOOL 6
or
SPOOLER 6;START
to print the accumulated spool files.
Output directed to class LP creates spool files even while LDEV 6 is unspooled because the queue is open for at least one device (LDEV 19) in the class.
Method 2: This workaround requires no dummy device.
Enter:
STOPSPOOL 6 SPOOLER 6;STOP
Start the application requiring unspooled access to the printer. Then enter:
OPENQ 6

The first method is recommended. In the second method, there is a period of time during which any process — even one that directs its output to class LP — can acquire the printer unspooled. If it is a process other than the intended one, you must either wait for that process to close the printer, or you must abort it.

This situation does not arise with the first method because there is always at least one device in class LP with its queues open.

There are two reasons for device classes being treated as collections of logical devices:

Confusion. Many users were confused by the distinction between queues and spooler processes. More confusion arose because of the different ways some of the commands operated on a logical device and the device class to which the logical device belonged.
Simplification. Previously, managing separate queues for logical devices and their device classes was messy. You could never be sure when you would get a spool file or a hot device.

Finding SPOOK in job streams

Since the SPOOK utility is obsolete in MPE/iX, it is important to locate references to SPOOK in job streams and to replace them with the appropriate commands (or the appropriate NMS commands instead. You can use an editor to do this.

Spool File transport

You may transport output spool files between MPE/iX systems through STORE and RESTORE. Since input spool files are private files, you cannot write them to tape with STORE. Also, you cannot store private output spool files. You can find more information about STORE and RESTORE in chapter 2.

The utility SPFXFER transfers files to tape in a format that MPE V/E SPOOK and MPE V/E SPOOK5 (with the exception of MPE V/E releases prior to G.02.B0) can read. For releases prior to G.02.B0, SPOOK cannot read SPFXFER tapes. The SPFXFER utility can read tapes created by SPOOK from any release of MPE/iX, MPE XL, MPE V/E, and SPFXFER itself. The SPFXFER utility has four commands that are similar to the commands of the SPOOK utility. For more information about SPFXFER, see chapter 2.

Recovery

The NMS uses a checkpoint file, described briefly in chapter 2 and in more detail in appendix D, for recovery. The checkpoint file saves page checkpoints and other data which are used to recover printing following an interrupt such as a power failure or the execution of the SPOOLER ... ;RESUME or RESUMESPOOL commands.

Device recovery

If the device returns page checkpoints (for example, CIPER protocol devices), the spooler recovers to a specific page.
The HP 2680, HP 2688, and HP 5000 series printers do not support page checkpoints, but performs a silent run from the beginning of the spool file to the page where the interruption occurred.
For CIPER devices and for HP 2680, HP 2688, and HP 5000 series printers, the output resumes printing at the correct page.
Since serial printers cannot recover accurately to a specific page, they may not resume printing at the correct page or they may shift the page boundary from its original position.
The NMS retains output spool files until the device notifies the spooler that physical output is complete and error free.

Spool File recovery

Since spool files are permanent disk files, recovery is no more complicated than it is for other disk files.

When the system executes the INSTALL command, all files, including spool files, are purged. The system preserves all output spool files for all other startups, including UPDATE.
The system only recovers input spool files for every START with the RECOVERY option. There is a job master table (JMAT) entry for each job input spool file. The JMAT is only recovered during a START RECOVERY.
The system rebuilds the spool file directories for all such startups except INSTALL from information kept with each spool file.
Output spool files that are in the CREATE state when the system is interrupted may not be completely recovered. Any data not posted to the disk before the system interruption cannot be recovered. If no data was posted, the spool file is deleted by the recovery mechanism.
After a boot, if no output spool files are recovered, the next SPOOLID assigned is O1. If any spool files are recovered, the next SPOOLID counter is one greater than the largest SPOOLID of the recovered spool files.
If the system is booted with the NORECOVERY option of the START command, an apostrophe (') is inserted between the J or S and the number in each spool file's associated job or session number. For example J1234 becomes J'1234. This is to indicate that the job or session number was not generated from the current job or session counters.

Spool File states

Spool File states include the states ACTIVE, READY, OPEN, CREATE, PRINT, DEFER, PROBLM, XFER, DELPND, and SPSAVE. The LISTSPF command displays these states. Figure C-1 shows a one-to-one correspondence between the LISTSPF states and the SHOWIN states for input spool files. Figure C-2 shows a one to one correspondence between the LISTSPF states and the SHOWOUT states for output spool files.

Table D-1 Input Spool File States

`LISTSPF`	`SHOWIN`
`OPEN`	`OPEN`
`ACTIVE`	`ACTIVE`
`READY`	`READY`

Table D-2 Input Spool File States

`LISTSPF`	`SHOWOUT`
`READY`	`READY` or `LOCKED`
`CREATE`	`OPEN`
`DEFER`	`READY`, `D`
`DELPND`	(underlying states are `READY` or `ACTIVE`)
`SPSAVE`	`READY`, `D`
`PROBLM`	`READY`, `D`
`PRINT`	`ACTIVE`
`XFER`	`ACTIVE` or `LOCKED`

The LISTSPF command, described in chapter 4, contains information about the states.

DEFER state

DEFER is a state of an output spool file, not just the condition of a spool file at priority 0 as in the past. A deferred spool file retains its original output priority but does not print, even if the priority is above the outfence. This feature allows users to see the original output priorities of deferred spool files. The spool file keeps this priority if its state changes to READY.

If you use the commands SPOOLF ...;DEFER or SPOOLF ...;UNDEFER on a file in the CREATE or PRINT states, the state that the command LISTSPF displays does not change until the file is closed either by the user process (CREATE) or the spooler process (PRINT). At that time, the file enters the DEFER or READY state depending on which command processed last.




	NOTE: A `SPOOLF` ...`;DEFER` command issued to a file in the `PRINT` state causes the NMS to interrupt the spooler process currently printing the file. The spooler ends its print job and returns the file to NMS file management.

XFER state

The XFER state indicates that a spool file has been selected for transportation from one node of network to another. It may be displayed and used as a STATE in a selection equation. It is provided for use as desired by third-party software providers. The spooler never places a file in the XFER state nor uses the state as a basis for spooler actions.

The DFID and the SPOOLID

Before version A.40.00 of MPE XL, the spooler kept track of individual spool files by assigning a unique device file identifier (DFID) number to each file. The MPE/iX (and MPE XL) NMS assigns a unique spool file identification number (SPOOLID) to each spool file. SPOOLIDs are similar to DFID, but are not the same. The IDD and ODD (CM tables) management routines assign DFIDs to unspooled input and output device files such as terminals, tape drives, and unspooled printers. The NMS assigns SPOOLIDs only to spool files. The input and output spool file directory (SPFDIR) keeps SPOOLIDs. Since they are kept in different tables, a DFID and a SPOOLID may have the same numeric value.

Similarities between a DFID and a SPOOLID include their format (#Onnnn or #Innnn) and the replacement of a SPOOLID number for a DFID number in the ALTSPOOLFILE and DELETESPOOLFILE commands.

For the FFILEINFO intrinsic, item number 38 requests a 16-bit SPOOLID. SPOOLIDs can be up to 9,999,999 and only SPOOLIDs up to 32,767 fit in the 16-bit representation. A new FFILEINFO item number, 78, which returns the same information as item number 38 has been added to accommodate SPOOLIDs larger than 32,767. If the SPOOLID fits in the 16 bit representation (less than 32,676), it is returned; otherwise, a zero (0) is returned.

Control information display

Use the SPIFF or PRINTSPF utility to view control information such as page eject locations and double spacing. Information about SPIFF and PRINTSPF is in chapter 5.

Outfence

The system outfence default is 14.

Error handling

All non-CI error messages are in SYSCAT.PUB.SYS, the native mode message catalog. You can access them by using the MPE/iX error management procedures and intrinsics. All CI messages for MPE/iX version A.40.00 and beyond are in Set 2 of CATALOG.PUB.SYS, the compatibility mode message catalog.

The status of spooler error messages are numbered according to the information part of the error status. You can call the MPE/iX error management intrinsics either to print the error or to put it into a buffer for further manipulation.