AS/400-iSeries Starter Kit

Printing. It's one of the most common things any computer does, and it's relatively easy with the AS/400. What complicates this basic task is that the AS/400 provides many functions you can tailor for your printing needs. For example, you can use multiple printers to handle various types of forms. You can use printers that exist anywhere in your configuration -- whether the printers are attached to local or remote machines or even to PCs on a LAN. You can let users view, hold, release, or cancel their own output; or you can design your system so their output simply prints on a printer in their area without any operator intervention except to change and align the forms.

The cornerstone for all this capability is the AS/400 output queue. Understanding how to create and use output queues can help you master AS/400 print operations.

What Is an Output Queue?

An output queue is an object containing a list of spooled files that you can display on a workstation or write to a printer device. (You can also use output queues to write spooled output to a diskette device, but this chapter does not cover that function.) The AS/400 object type identifier for the output queue is *OUTQ.

Figure 10.1a shows the AS/400 display you get on a workstation when you enter the WRKOUTQ (Work with Output Queue) command for the output queue QPRINT

WRKOUTQ QPRINT

As the figure shows, the Work with Output Queue display lists each spooled file that exists on the queue you specify. For each spooled file, the display also shows the spooled file name, the user of the job that created the spooled file, the user data identifier, the status of that spooled file on the queue, the number of pages in the spooled file, the number of copies requested, the form type, and that spooled file's output priority (which is defined in the job that generates the spooled file). You can use function key F11=View 2 to view additional information (e.g., job name and number) about each spooled file entry.

The status of a spooled file can be any of the following:

OPN

CLO

HLD

RDY

SAV

WTR

I have mentioned two options for spooled files -- option 3, which holds spooled files, and option 6, which releases them. The panel in Figure 10.1a shows all available options. Figure 10.1b explains each option.

How To Create Output Queues

Now that we've seen that output queues contain spooled files and let you perform actions on those spooled files, we can focus on creating output queues. The most common way output queues are created is through a printer device description. Yes, you read correctly! When you create a printer device description using the CRTDEVPTR (Create Device Description (Printer)) command or through autoconfiguration, the system automatically creates an output queue in library QUSRSYS by the same name as that assigned to that printer. This output queue is the default for that printer. In fact, the system places "Default output queue for PRINTER_NAME" in the output queue's TEXT attribute.

An alternative method is to use the CRTOUTQ (Create Output Queue) command. The parameter values for this command determine attributes for the output queue. When you use the CRTOUTQ command, after entering the name of the output queue and of the library in which you want that queue to exist, you are presented with two categories of parameters -- the procedural ones (i.e., SEQ, JOBSEP, and TEXT) and those with security implications (i.e., DSPDTA, OPRCTL, AUTCHK, and AUT). For a look at some of the parameters you can use, see the CRTOUTQ panel in Figure 10.2.

The first of the procedural parameters, SEQ, controls the order of the spooled files on the output queue. You can choose values of either *FIFO (first in, first out) or *JOBNBR. If you select *FIFO, the system places new spooled files on the queue following all other entries already on the queue that have the same output priority as the new spooled files (the job description you use during job execution determines the output priority).

Using *FIFO can be tricky because the following changes to an output queue entry cause the system to reshuffle the queue's contents and place the spooled file behind all others of equal priority:

• A change of output priority when you use the CHGJOB (Change Job) or CHGSPLFA (Change Spooled File Attributes) command;

• A change in status from HLD, CLO, or OPN to RDY;

• A change in status from RDY back to HLD, CLO, or OPN.

The other possible value for the SEQ parameter -- *JOBNBR -- specifies that the system sort queue entries according to their priorities, using the date and time the job that created the spooled file entered the system. I recommend using *JOBNBR instead of *FIFO, because with *JOBNBR you don't have to worry about changes to an output queue entry affecting the order of the queue's contents.

The next procedural parameter is JOBSEP (job separator). You can specify a value from 0 through 9 to indicate the number of job separators (i.e., pages) the system should place at the beginning of each job's output. The job separator contains the job name, the job user's name, the job number, and the date and time the job is run. This information can help in identifying jobs. If you'd rather not use a lot of paper, you can lose the job separator by selecting a value of 0. Or you can enter *MSG for this value, and each time the end of a print job is reached, the system will send a message to the message queue for the writer.

Don't confuse the JOBSEP parameter with the FILESEP (file separator) parameter, which is an attribute of print files. When creating or changing print files, you can specify a value for the FILESEP parameter to control the number of file separators at the beginning of each spooled file. The information on the file separators is similar to that printed on the job separator but includes information about the particular spooled file.

When do you need the file separator, the job separator, or both? You need file separators to help operators separate the various printed reports within a single job. You need job separators to help separate the printed output of various jobs and to quickly identify the end of one report and the beginning of the next. However, if you program a header page for all your reports, job separators are probably wasteful. Another concern is that for output queues that handle only a specific type of form, such as invoices, a separator wastes an expensive form.

In reality, a person looking for a printed report usually pays no attention to separator pages but looks at the first page of the report to identify the contents and destination of the report. And as you can imagine, a combination of file separators and job separators could quickly launch a major paper recycling campaign. Understand, I am not saying these separators have no function. I am saying you should think about how helpful the separators are and explicitly choose the number you need.

The security-related CRTOUTQ command parameters help control user access to particular output queues and particular spooled data. To appreciate the importance of controlling access, remember that you can use output queues not only for printing spooled files but also for displaying them. What good is it to prevent people from watching as payroll checks are printed, if they can simply display the spooled file in the output queue?

The DSPDTA (display data) parameter specifies what kind of access to the output queue is allowed for users who have *READ authority. A value of *YES says that any user with *READ access to the output queue can display, copy, or send the data of any file on the queue. A value of *NO specifies that users with *READ authority to the output queue can display, copy, or send the output data only of their own spooled files unless they have some other special authority. (Special authorities that provide additional function are *SPLCTL and *JOBCTL.)

The OPRCTL (operator control) parameter specifies whether or not a user who has *JOBCTL special authority can manage or control the files on an output queue. The values are *YES, which allows control of the queue and provides the ability to change queue entries, or *NO, which blocks this control for users with the *JOBCTL special authority.

One problem you might face relating to security is how to allow users to start, change, and end writers without having to grant them *JOBCTL special authority, which also grants a user additional job-related authorities that might not be desirable (e.g, the ability to control any job on the system). An alternative is to write a program to perform such writer functions. You can specify that the program adopt the authority of its owner, and you would make sure that the owner has *JOBCTL special authority. During program execution, the current user adopts the special and object-specific authorities of the owner. When the program ends, the user has not adopted *JOBCTL authority and thus cannot take advantage of a security hole.

If the user does not have *JOBCTL special authority or does not adopt this special authority, (s)he must have a minimum of *CHANGE authority to the output queue and *USE authority to the printer device.

The AUTCHK (authority check) parameter specifies whether the commands that check the requester's authority to the output queue should check for ownership authority (*OWNER) or for just data authority (*DTAAUT). When the value is *OWNER, the requester must have ownership authority to the output queue to pass the output queue authorization test. When the value is *DTAAUT, the requester must have *READ, *ADD, and *DELETE authority to the output queue.

Finally, the AUT parameter specifies the initial level of authority allowed for *PUBLIC users. You can modify this level of authority by using the EDTOBJAUT (Edit Object Authority), GRTOBJAUT (Grant Object Authority), or RVKOBJAUT (Revoke Object Authority) command.

As you can see, creating output queues requires more than just selecting a name and pressing Enter. Given some appropriate attention, output queues can provide a proper level of procedural (e.g., finding print files and establishing the order of print files) and security (e.g., who can see what data) support.

Who Should Create Output Queues?

Who should create output queues? Although this seems like a simple question, it is important for two reasons: First, the owner can modify the output queue attributes as well as grant/revoke authorities to the output queue, which means the owner controls who can view or work with spooled files on that queue. Second, the AUTCHK parameter checks the ownership of the output queue as part of the authorization test when the output queue is accessed. So ownership is a key to your ability to secure output queues.

Here are a few suggestions. The system operator should be responsible for creating and controlling output queues that hold data considered public or nonsecure. With this ownership and the various authority parameters on the CRTOUTQ command, you can create an environment that lets users control their own print files and print on various printers in their area of work. For secure data (e.g., payroll, human resources, financial statements), the department supervisor profile (or a similar one) should own the output queue. The person who owns the output queue is responsible for maintaining the security of the output queue and can even explicitly deny access to DP personnel.

How Spooled Files Get on the Queue

It is very important to understand that all spooled output generated on the AS/400 uses a print file. Whether you enter the DSPLIB (Display Library) command using the OUTPUT(*PRINT) parameter to direct your output to a report, create and execute an AS/400 query, or write a report-generating program, you are going to use a print file to generate that output. A print file is the means to spool output to a file that can be stored on a queue and printed as needed. Also, a print file determines the attributes printed output will have. This means you can create a variety of print files on the system to accommodate various form requirements.

Another essential fact to understand about spooling on the AS/400 is that normally all printed output is placed on an output queue to be printed. As mentioned in the previous chapter, the AS/400 is capable of bypassing the spool process to perform direct printing; but this is normally avoided because of performance and work management problems when implementing direct printing. With that said, we can examine the spooling process more closely.

When a job generates a spooled file, that file is placed on an output queue. The output queue is determined by one of two methods -- if the print file has a specifically defined output queue or is overridden to a specific output queue, the output from that print file is placed on that specific queue; if the print file does not specifically direct the spool file, it is placed on the output queue currently defined as the output queue for that particular job.

Figure 10.3 illustrates how one job can place spooled files on different output queues. The job first spools the nightly corporate A/R report to an output queue at the corporate office. Then the program creates a separate A/R report for each branch office and places the report on the appropriate output queue.

How Spooled Files Are Printed from the Queue

So how do the spooled files get printed from the queue? The answer is no secret. You must start (assign) a writer to an output queue. You make spooled files available to the writer by releasing the spooled file, using option 6. You then use the STRPRTWTR (Start Printer Writer) command. The OUTQ parameter on that command determines the output queue to be read by that printer.

When the writer is started to a specific output queue and you use the WRKOUTQ command for that specific output queue, the letters WTR appear in the Status field at the top of the Work with Output Queue display to indicate that a writer is assigned to print available entries in that queue.

You can start a writer for any output queue (only one writer per output queue and only one output queue per writer). You don't have to worry about the name of the writer matching the name of the queue. For instance, to start printing the spooled files in output queue QPRINT, you can execute the STRPRTWTR command

STRPRTWTR WRITER(writer_name) OUTQ(QPRINT)

(Messages for file control are sent to the message queue defined in the printer's device description unless you also specify the MSGQ parameter.)

When you IPL your system, the program QSTRUP controls whether or not the writers on the system are started. When QSTRUP starts the writers, each printer's device description determines both its output queue and message queue. You can modify QSTRUP to start all writers, to start specific writers, or to control the output queues by using the STRPRTWTR command. After a writer is started, you can redirect the writer to another output queue by using the CHGWTR (Change Writer) command or by ending the writer and restarting it for a different output queue.

To list the writers on your system and the output queues they are started to, type the WRKOUTQ command and press Enter. You will see a display similar to the one in Figure 10.4. You can also use the WRKWTR (Work with Writer) command by typing WRKWTR and pressing Enter to get a display like the one in Figure 10.5.

It is important to understand that the output queue and the printer are independent objects, so output queues can exist with no printer assigned and can have entries. The Operational Assistant (OA) product illustrates some implications of this fact. OA lets you create two output queues (i.e., QUSRSYS/QEZJOBLOG and QUSRSYS/QEZDEBUG) to store job logs and problem-related output, respectively. These output queues are not default queues for any printers. Entries are stored in these queues, and the people who manage the system can decide to print, view, move, or delete them.

A Different View of Spooled Files

The WRKOUTQ command allows you to work with all spooled files on a particular output queue. Another helpful command is the WRKSPLF (Work with Spooled Files) command. This command allows you to work with all spooled files generated by your job, even if those spooled files are on multiple output queues. Figure 10.6 represents the WRKSPLF command output for someone who works at the "basic" OS/400 assistance level (one's assistance level is determined first at the user profile level by the ASTLVL parameter, then at the command level based on the last use of the command or what the user enters when prompting the ASTLVL parameter on the command). Notice that one spooled file is assigned to the printer "CONTES3" while the other spooled files are "unassigned." They are definitely on an output queue; but since no printer is currently started for any of those output queues, the files are listed as "unassigned." This basic assistance level hides some of the technical details of spooled files and output queues unless you request more information by selecting option 8 "attributes" to display the spooled file detail information.

Figure 10.7 represents the WRKSPLF command output for someone who works at the "intermediate" level (there is no "advanced" assistance level for this command, so those at the advanced assistance level will also see this same panel). Now you can clearly see which output queue each spool file is assigned to, the number of pages, the status, and the user who created the spooled file. You cannot see other spooled files on those same output queues since this WRKSPLF command works only with the current user's spooled files.

You then have two methods for working with spooled files. You will find that you use both in your daily operations, but that using the WRKOUTQ command is the most useful of the two for system operations, since you can see more than one job's spooled files.

How Output Queues Should Be Organized

The organization of your output queues should be as simple as possible. To start, you can let the system create the default output queues for each printer you create. Of course, you may want to modify ownership and some output queue attributes. At this point, you can send output to an output queue and there will be a printer assigned to print from that queue.

How can you use output queues effectively? Each installation must discover its own answer, but I can give you a few ideas. If your installation generates relatively few reports, having one output queue per available printer is the most efficient way to use output queues.

Installations that generate large volumes of printed output need to control when and where these reports might be printed. For example, a staff of programmers might share a single printer. If you spool all compiled programs to the same queue and make them available to the writer, things could jam up fast; and important reports might get delayed behind compile listings being printed just because they were spooled to a queue with a writer. A better solution is to create an output queue for each programmer. Each programmer can then use a job description to route printed output to his or her own queue. When a programmer decides to print a spooled file, he or she moves that file to the output queue with the shared writer active. This means that the only reports printed are those specifically wanted. Also, you can better schedule printing of a large number of reports.

What about the operations department? Is it wise to have one output queue (e.g., QPRINT or PRT01) to hold all the spooled files that nightly, daily, and monthly jobs generate? You should probably spend a few minutes planning for a better implementation.

I recommend you do not assign any specific output to PRT01. You should create specific output queues to hold specific types of spooled files. For instance, if you have a nightly job that generates sales, billing, and posting reports, you might consider having either one or three output queues to hold those specific files. When the operations staff is ready to print the spooled files in an output queue, they can use the CHGWTR command to make the writer available to that output queue. Another method is to move the spooled files into an output queue with a printer already available. This method lets you browse the queue to determine whether or not the reports were generated and lets you print these files at your convenience.

For some end users, you may want to make the output queue invisible. You can direct requested printed output to an output queue with an available writer in the work area of the end user who made the request. Long reports should be generated and printed only at night. The only things the user should have to do are change or add paper and answer a few messages.

What a moutain of information! And I've only discussed a few concepts for managing output queues. But this information should be enough to get you started and on your way to mastering output queues.