Re: outq order of spooled files-result

Jim Franz wrote on 08/18/2005 05:16:55 PM:

> Solution was to close print1 then close print2, not letting the
> ending of the program handle the close.
>
> I still think it is wrong for the outq to not process in the order
> of the file number (which is the order they are opened in).

I think you may be confused by the meaning of SEQ(*FIFO) on an output
queue. Here is some of the help text for the SEQ parameter of the CHGOUTQ
command.

*FIFO
    The queue is first-in first-out within priority for each file.  That
    means, new spooled files are placed on the queue after all other
    entries of the same priority.  The following changes place a queue
    entry after all others of equal priority on the queue.

     o  A change of output priority with the Change Job (CHGJOB) command

     o  A change in status from held (HLD), saved (SAV), closed (CLO),
        or open (OPN) to available (RDY)

     o  A change in status from available (RDY) to not available (HLD,
        SAV, CLO, OPN)

     o  A spooled file added to the queue if the file is opened

     o  Using the Change Spooled File Attributes (CHGSPLFA) command to
        move a spooled file to an output queue which has SEQ(*FIFO)
        specified

>From earlier discussion I thought I saw a hint that these spooled files
must always be produced together and in the correct order. If that is the
case, and if the printer writer is active for this output queue, and if
other jobs are also placing their spooled files on the output queue, then
timing situations can occur that may cause other spooled files to be
printed between these two. This is true for both SEQ(*JOBNBR) and
SEQ(*FIFO) output queues. If this is a problem, then one solution would be
to combine the two files into one.

Ed Fishel,
edfishel@xxxxxxxxxx