Sending Spooled-files to PDFing

The STRMTWTR command starts a remote writer on a specified output-queue. The output-queue itself must be configured as a remote output queue. A remote writer will only send a spooled-file to PDFing, when the file is at status RDY and is queued on the output queue being serviced by this remote writer. In general, a remote writer will behave in exactly the same way as any other print-writer. If you have configured OS400 correctly and started the remote-writer, you should see the status of each spooled-file change to SND as it is sent to PDFing. After each spooled-file is sent, it will be deleted or its status will change to SAV.

To start a remote writer, enter command:

 
STRRMTWTR OUTQ(PDFING)

Here the remote writer job will send any RDY spooled-files on output queue PDFING until the remote writer job is ended. The name of the batch job running the remote-writer is also PDFING.

To check the processing of spooled-files by this remote writer, enter command:

 
WRKWTR PDFING

To end this remote writer, enter command:

 
ENDWTR WTR(PDFING)

When starting a remote writer, you can specify that the remote writer ends automatically when there are no more spooled-files to write, using command:

 
STRRMTWTR OUTQ(PDFING) AUTOEND(*YES *NORDYF)

Please note that command STRRMTWTR only needs to be executed once. The writer job will continue to run until either OS400 shuts down or the ENDWTR WTR(PDFING) command is executed

If the spooled-files stay at status: SND then please see our F.A.Q.

The SNDTCPSPLF command can send one spooled-file to PDFing per command execution. Execution of this command continues until the spooled-file is received by PDFing. The spooled-file can be on any output-queue and the output-queue does not need any specific configuration. The spooled-file remains in the same state after execution of SNDTCPSPLF. When the spooled-file is sentle to PDFing, the user-defined-text is not sent. However, you may specify the same tags in the DESTOPT() parameter of the command, these "tag" strings must be URL encoded.

In the following example, we assume that you have previously executed command DSPLIBL *PRINT. To send the spooled-file to PDFing, execute:

SNDTCPSPLF RMTSYS(*INTNETADR) PRTQ('PDFING') FILE(QPRTLIBL) JOB(*) SPLNBR(*LAST) +
 DESTTYP(*AS400) TRANSFORM(*NO) +
 INTNETADR('nnn.nnn.nnn.nnn')

where nnn.nnn.nnn.nnn is the internet address of the PC running PDFing. Do not key in any leading zeros in the addresss.

If you are sending an *AFPDS spooled-file, you must transform the spooled-file, by setting the TRANSFORM(*YES) and MFRTYPMDL(*HP4) parameter values.

SNDTCPSPLF RMTSYS(*INTNETADR) PRTQ('PDFING') FILE(QPRTLIBL) JOB(*) SPLNBR(*LAST) +
 DESTTYP(*OTHER) TRANSFORM(*YES) MFRTYPMDL(*HP4) +
 INTNETADR('nnn.nnn.nnn.nnn')

This command specifies that the spooled-file data will be transformed by OS400 into PCL (Hewlett-Packard printer-control-language) before being sent to PDFing.

Please note that when TRANSFORM(*YES) is specified, the "transform" process removes all spooled-file attributes, excepting file-name and user-name. However, we supply the CL source for a special transform exit-program. If you compile this program, you can you execute SNDTCPSPLF specifying this exit-program, so that all spooled-file attributes, including user-defined-text, will be sent.

SNDTCPSPLF RMTSYS(*INTNETADR) PRTQ('PDFING') FILE(QPRTLIBL) JOB(*) SPLNBR(*LAST) +
 DESTTYP(*OTHER) TRANSFORM(*NO) MFRTYPMDL(*HP4) +
 USRDTATFM(PDFING/PDFING) INTNETADR('nnn.nnn.nnn.nnn')

This command specifies that all the spooled-file attributes will be sent to PDFing but only *AFPDS spooled-files will be transformed to PCL.

Although the SNDTCPSPLF command is very useful for testing purposes, for most applications it is better to use a "remote-writer" to send spooled-files to PDFing. This is because your OS400 program can write a spooled-file and continue without waiting for PDFing to acknowledge its receipt. Spooled-files can still be written to the output-queue even when PDFing is not running, they will remain on the queue until PDFing is re-started. Once the "remote-writer" connects to PDFing again, it will send any queued spooled-files automatically.

If the SNDTCPSPLF commadd fails with error-messaage: "Remote host system rejected the open attempt", please see our F.A.Q.

If you want to use an OS400 remote writer to send spooled-files to PDFing, you must create and configure an OS400 output-queue. You can also specify that remote writers are automatically started by specifying a positive value for the AUTOSTRWTR parameter of the CRTOUTQ and CHGOUTQ commands.

To create an output-queue named (for example) PDFING in library QGPL , you must enter the following command:

CRTOUTQ OUTQ(QGPL/PDFING) DESTTYPE(*OS400) TRANSFORM(*NO) DESTOPT(*USRDFNTXT)

Please note that *USRDFNTXT should be spelled exactly as shown here! You must then change queue PDFING so that it can supply the remote writer with the information it needs to write the spooled-files on this output-queue. In the following example we assume that the PC running PDFing is named in the Domain-Name-Server for your network. Enter command:

CHGOUTQ OUTQ(PDFING) RMTSYS('PDF.your.com') RMTPRTQ('PDFING') CNNTYPE(*IP)

Here RMTSYS(PDF.your.Com) specifies the IP host name of the Windows PC.

If you do not use a domain-name server, you must specify the IP address. Enter command:

CHGOUTQ OUTQ(PDFING) RMTSYS(*INTNETADR) RMTPRTQ('PDFING') CNNTYPE(*IP) +
 INTNETADR('172.16.100.101')

Here RMTSYS(*INTNETADR) specifies that an IP address must be supplied and INTNETADR('172.16.100.101') specifies the Internet address of the PC running the PDFing program. Please note that *INTNETADR should be spelled exactly as shown here!

PDFing can convert *AFPDS spooled-files into the equivalent PDF document. However, you must configure the output queue being written to PDFing, so that spooled-files are transformed by OS400, before being written to PDFing. To specify host print transform, use command:

CHGOUTQ OUTQ(PDFING) DESTTYPE(*OTHER) TRANSFORM(*YES) MFRTYPMDL(*HP4)

Here TRANSFORM(*YES) specifies that host print transform will be performed by OS400, before the spooled-file is sent to PDFing.

Please note that when TRANSFORM(*YES) is specified, the "transform" process removes all spooled-file attributes, excepting file-name, user-name and user-defined-text. However, we supply the CL source for a special transform exit-program. If you compile this program, you can set up output-queues referencing this program so that all spooled-file attributes will be sent when the spooled-file is sent. The following command specifies that all the spooled-file attributes will be sent to PDFing but only *AFPDS spooled-files will be transformed

CHGOUTQ OUTQ(PDFING) DESTTYPE(*OTHER) TRANSFORM(*NO) MFRTYPMDL(*HP4) +
 USRDTATFM(PDFING/PDFING)

We strongly recommend that you either use this transform exit-program or set up two output-queues, one for *AFPDS and one for normal (*SCS) spooled-files. This is because the transformation of *SCS spooled-files is not required by PDFing and uses OS400 resources unnecessarily. This program may not be able to convert "complex" *AFPDS spooled-files, in case of errors, see our F.A.Q.

You may want to control which users can send spooled-files to PDFing, by controlling access to the output-queue(s) which are being written to PDFing. Output queue objects obey the normal rules for OS400 object authority. Spooled-files do not have individual object authorities, but they are always owned by the user profile that created them. There are some additional properties of output-queues and user-profiles that can over ride the basic object authorities. This information applies when OS400 is running at security level 30 or above.

Users can only create or move spooled-files onto an output queue, provided they have *READ authority on that output queue. Therefore you can easily exclude all *PUBLIC users and permit only specified users. However users with the special authority *ALLOBJ or *JOBCTL can always create or move spooled-files onto any output queue. You should always try to limit the number of users with these special authorities. The number of users with *SPLCTL special authority should also be strictly limited.

You can change the output-queue parameters for "Display Data" DSPDTA() ,"Authority to Check" AUTCHK() and "Operator Control" OPRCTL() to override the basic object authorities. These parameters control which users can display, move or change spooled-files on the output queue.

If the output queue parameter DSPDTA(*NO) is set, then only the owner of the spooled-file can display or move the spooled-files, unless:
1) Another user has *JOBCTL special authority.
2) Another user has change authority to the output queue and the output queue parameter AUTCHK(*DTAAUT) is set.
3) Another user owns the output-queue and the output-queue parameter AUTCHK(*OWNER) is set.
If the output queue parameter DSPDTA(*YES) is set, then any user with *READ authority to the output queue can display or move the spooled-file.
If the output queue parameter DSPDTA(*OWNER) is set, then only the owner of the spooled-file can display or move the spooled-files, unless:
1) Another user has *JOBCTL special authority and the output queue parameter OPRCTL(*YES) is set.
2) Another user has *SPLCTL special authority
If the output queue parameter AUTCHK(*OWNER) is set, then only the owner of the spooled-file can change or delete the spooled-files.
If the output queue parameter AUTCHK(*DTAAUT) is set, then any user with *READ *ADD and *DLT authorities to the output queue can change or delete the spooled-files.
If the output queue parameter OPRCTL(*YES) is set, then any user with *JOBCTL special authority can perform any operation on the spooled-files, provided that the output queue parameter DSPDTA(*OWNER) is not set.

You can determine the user-profile that "owns" the spooled-file by setting the SPLFOWN() parameter when creating, changing or overriding the printer device-file that creates a spooled-file.

A "virtual" printer-device performs no processing and CANNOT be varied on, it just serves as a reference to a particular output-queue. OS400 users can select a "virtual" printer-device wherever a printer-device is required and any spooled-files will then be created onto the output-queue referenced by the device.

To create an OS400 virtual printer-device execute the following command:

CRTDEVPRT DEVD(yourname) DEVCLS(*VRT) TYPE(3812) MODEL(1) FONT(011)

As well as creating the printer-device named yourname, this command will also create a new output-queue named: yourname in library: QUSRSYS