Print job specific data
One of the primary uses of RPM Remote Print Manager® (RPM) is to save print data to a file. This functionality is useful in a variety of situations, two of which are:
- To preserve paper and the environment.
- Integration with third-party software with a folder watcher feature.
RPM offers access to a large number of variables for naming a file. Here is a fairly comprehensive list.
- From the LPR control file: source file, job name, title, banner attribute, class, remote hostname, user, indent count, mail when printed, width, format
- Queue sequence number
- Job ID
- Queue name from RPM; either set in LPD or configured in Telnet
- Local IP address from the system
- Ten unique date and time fields from both the received and process times.
During output, if the source file, job name, or title attributes contain UNIX or Windows path data, RPM can optionally extract the filename and file extension.
Some characters we may encounter in these fields are not supported in a Windows filename. These illegal filename characters are below. These characters are intentionally converted to underscores.
\ / : * ? “ < > |
Filename collisions
Given that you can include the job ID in a filename, which is always unique; the sequence number for a queue, which is unique to that queue (within bounds); or the milliseconds part of a timestamp, it seems unlikely that RPM would have a problem creating a unique file name.
Nonetheless, some customers require specific data in the file name and this can lead to unintentionally overwriting a print job before you have a chance to use that file in your other processing.
To counter this, RPM offers an option to make the file name unique. It does this by adding the dash character and an integer count prior to the file extension. While RPM is running, it remembers the file names it modifies in this way and increments the count. However, this information is lost when RPM is restarted. In that case, RPM may need to look for each alternatively named file to exist before it can safely create a new one.
This can lead to problems when you archive your jobs to a folder and forget to check the folder. We recently helped a customer who had been using RPM for some months. They reported that jobs were processing very slowly. It turned out they had a folder with over a quarter million files, identically named, except for the integer count. Once they renamed that folder and created a new one, RPM was able to process jobs as fast as they expected.