Q: Print: Share an output queue between AFC and a printer

Question:
How can Auto Forms Control share an output queue with a printer?

Answer:
Sharing one output queue between Auto Forms Control and a printer.

In version 2000M53 a new function was added in InterForm400.

When you choose 80. Administering InterForm 400, and then select option 2, and press Enter several times you will get this screen:

Do you want to use the APF3812/STRWTRCHK program as validity checking program
for the STRPRTWTR and STRRMTWTR commands, to avoid a writer to be started with
FORMTYPE(*ALL) on one of the output queues defined in Auto-Forms-Control, and
if yes, what formtype has to replace *ALL when a writer is started on one of
these output queues.



Use APF3812/STRWTRCHK as a validity checker N (Y N)

Formtype to replace *ALL . . . . . . . . . .

This option is especially useful, if you are using the same output queue
for both input to AFC-functions and for output to a printer, as a writer
never should be started with FORMTYPE(*ALL) on such an output queue.

Here you can add a validity checking program to the OS/400 commands: STRPRTWTR and STRRMTWTR. If you state Yes, then the validity program, APF3812/STRWTRCHK is added to the commands.

You can change it back (or just see it), if you prompt these commands with F4:

CHGCMD CMD(STRPRTWTR)
CHGCMD CMD(STRRMTWTR)

This parameter is changed:
Validity checking program . . . STRWTRCHK Name, *SAME, *NONE
Library . . . . . . . . . . . APF3812 Name, *LIBL, *CURLIB

If you regret the change, you can either state N to use a validity checker on the screen above or change this parameter back to *NONE. (This is necessary, if you decide to uninstall InterForm400 and remove the apf3812 library (but why should you do that?!?) ).

OK, what does it really do?
When a writer job is started the STRWTRCHK program will check if this output queue is monitored by AFC. If so the writer job will only print out the form type above - and ignore all others. (This does the same as the command, 'STRPRTWTR DEV(printer) FORMTYPE(xxx *NOMSG)' - where the form type 'xxx' is the only one printed out ).

Remember, that you have to stop and start the relevant writer jobs before the change takes effect.

OK, so what is it good for?
Well, there are some customers, that do not want the usual setup where Auto Forms Control is monitoring one output queue and sending the result to another output queue with a printer attached. They want only one output queue shared between Auto Forms Control and the printer.

Can't I just use the option F=Change writer in AFC?
That might not work if the printer is too fast. If the printer is very fast, then it will grab all spool files and print them out before InterForm400 can react and change the writer. So the advise is: Use the new function, it is much safer.

OK, so what form type should I specify to replace *ALL on the command?
It depends. It is not possible to say what is the best of the 3 solutions below. Read them and take the decision depending on your setup and preferences.
(The solutions are listed in rating after my personal opinion)

1. Using a common form type like e.g. *STD:
You could e.g. specify *STD. The form type of the spool files created by the customer is probably *STD initially. If you choose this, then all spool files will be printed. If you want to have AFC to handle spool files, then the form type of those spool files must be changed to something different than *STD. All merges should result in the form type *STD. If the you are not able to change the form type of the spool files, then this form type can not be used - use another special form type e.g. PRINT as below.
Advantages: Easy to set up and InterForm400 can work like 'the old days' steering the spool files depending on the form type. When you start up all spool files will be printed out until you specify otherwise in Auto Forms Control, and spool files not used by InterForm400 will be printed out even if the subsystem, AUTO_FORM is not running.
Disadvantages: You have to change the form type of the original SCS spool files (e.g. in the printer files), when Auto Forms Control is going to handle them.


You could specify a special form type e.g. PRINT instead of *STD. If you choose this, then
you have the choice between these two setups:

2. First setup using a special form type e.g 'PRINT':
Auto Forms Control will have to change the form type of all spool files, that are not to be merged to PRINT.
Here Auto Forms Control merges will be depending not (only) on the form type but (also) on the other spool file attributtes like e.g. program name, device file or..

Here the form types *STD and A4 are changed to 'PRINT' - inserted as the very last lines in AFC. You could also change these 2 lines to merge with a empty dummy overlay, that has *INPUT in all fields possible.

Update AFC-functions attached to output queues

Queue: AFC_INPUT4 Library: APF3812

Seqnbr Funct Form type Save Jobname Filename Device file Pr
0001 1 *STD INVOICE
Merge, Overlay: IF400DEMO Fileset: SAMPLE
0002 6 *STD INVOICE
Hold Spooled File
0003 9 *STD INVOICE
Exit
0004 *                                  
9998 A *STD
Change attributes, Form type: PRINT User data: *SAME
9999 A A4
Change attributes, Form type: PRINT User data: *SAME

Here all merges has to result in the form type PRINT (naturally).
All lines e.g. specifying a merge should finish with an Exit line (option 9), so that the last 2 lines are not executed for this spool file.
Advantages: You do not have to change form type of any of the original spool files.
Disadvantages: You have to insert and keep some lines to take care of the spool files left as the final lines in the definition. These lines could however be inserted in another template definition, and be refered to by this AFC-outq. Another disadvantage is, that you have to specify 9=Exit for each type of spool file, that is not to be printed this way.

3. Second setup using a special form type e.g 'PRINT':
Instead of the setup where you change spool file attributtes like above, you could use one large overlay selector to merge with instead. The overlay selector should select 'real' overlays when needed, and an empty 'dummy' overlay for spool files, that should not be merged e.g. *SCS spool files.
Advantage: The setup in AFC is very easy for a normal setup. You simply insert one line in AFC doing the merge with the overlay selector. *SCS spool files are merged to ascii spool files. *SCS spool files merged with empty dummy overlays will normally print faster, than spool files printed with Host Print Transform.
Disadvantages: Since each page is considered when selecting overlays, it is necessary that enough information is available on every page to select an overlay. There is also a very small overhead because the contents of each page is 'looked at' to deside an overlay to merge with.