Basic print file handling for all DSSs

When a print request is made to InfoPrint Manager, the print file is sent to the pdserver running as a command processor (which then becomes the originating pdserver); this might be the pdserver containing the logical destination.

If the link option (pdpr -l) is not specified, which is the default, a temporary copy of the incoming print job is made by the originating pdserver in its /var/pd/servername directory with a randomly generated name that begins with pdpr (for example, pdpr1pp5nV). The exception is for jobs submitted with InfoPrint Submit Express clients that use /ipdata as their work area. These jobs are treated as if the link option was specified. That temporary copy stays in /var/pd/servername on the originating pdserver until the print job completely leaves the system, including job printed or cancelled and expiration of any retention periods that have been set through InfoPrint Manager attributes. To put it another way, the temporary copy remains in /var/pd/servername on the originating pdserver until a pdls for that particular job returns with a message that InfoPrint Manager cannot find the job.

If the link option (pdpr -l) is specified, the pdprxxxxxx is a symbolic link to the original file (rather than a copy of). The link is deleted by InfoPrint Manager when the job completely leaves the system.

The job is submitted to the logical destination, and a job object is stored in the queue associated with the logical destination. There are no file transfers at this point; the Job object only contains a reference or pointer to the location of the print file. Each document in the job has a document-content attribute that contains information about the location of the document's print file. There are two pieces of information contained in this attribute:

• The actual location of the print file, for example, /var/pd/CmdProcServ/pdprxxxxxxxxxxx.
• The name of the command processor pdserver.

  This attribute will be displayed with a pdls command but only if specifically requested:

  pdls   -r document-content   jobID

When the print file is scheduled to the actual destination one of two things can happen. If the printing pdserver that contains the actual destination can directly access the copy of the print file in the originating pdserver's/var/pd/servername directory, it uses the file directly and does not make its own temporary copy. However, if the printing pdservercannot directly access the copy on the originating pdserver, the printing pdserver contacts the originating pdserver and requests a copy of the print file, which is known as a file pull or pipe pull. Files are pulled from one server to another using a socket. The originating pdserver must be running for a file to be pulled. The pulled file is stored in the printing pdserver's/var/pd/servername/pdb directory. The temporary copy on the printing pdserver only remains while the job is processing. As soon as the job leaves the actual destination object, the temporary copy on the printing pdserver is erased. Meanwhile, the first copy on the originating pdserver remains until the job completely leaves the system.

All environments must plan spooling space for one copy of each print file. The command processor's copy of the print files are not deleted until the job leaves the InfoPrint Manager system. In other words, until it is completed or canceled and the retention-period has expired. Multiple machine environments must also plan additional space for pulled files. Since these files only exist while a job is processing, less space is required.