BSD DSS
You should use the BSD DSS only when there is either no other way to communicate with a device (for example, it is connected to a non-Linux processor) or you require:
- A terminating actual destination for the configurable transform subsystem
- An exit for your own use
The BSD DSS is capable of mapping InfoPrint Manager job and document attributes to options for your destination command. InfoPrint Manager uses the values in the attribute-map attribute to map InfoPrint Manager job and document attributes to options that append the destination-command value. This provides a means to customize the options passed from InfoPrint Manager to your destination command. Each value of the attribute map consists of an InfoPrint Manager attribute name, a colon, and a string containing the option flag to which the attribute maps. InfoPrint Manager appends the value of the attribute after the option flag in the generated command.
For example, if you set your attribute-map attribute to this:
copy-count:-N job-name:-T job-owner:-Dand your destination command is
lprafp -p mpcl -s ip_address, the BSD actual destination would generate this command:
lprafp -p mpcl -s ip_address -N copy_count_value \ -T job_name_value -D job_owner_value filename
The attribute-map attribute defaults to destination-pass-through:-o. Set your attribute-map attribute appropriately for your destination command.
If the destination-pass-through attribute is not mapped on the attribute-map attribute, the contents of this attribute are inserted into the command that the BSD actual destination generates after the job and the document mappings, but before the filename.
For example, if attribute-map=copy-count:-N and the destination command is
lprafp -p mpcl -s ip_addressyou can submit the command:
pdpr -P LogPrt1 -x "copy-count=2" -x "dest-pass-through=-p15" /etc/motdand expect this result:
| From dest-command attribute: | From job/document attribute: | From document's destination-pass-through attribute: | From document file names: |
|---|---|---|---|
lprafp -p mpcl -s ip_address |
-N 2 |
-p15 |
/etc/motd |
If possible, you should avoid using the BSD DSS to send jobs to printers for these reasons:
- Because InfoPrint Manager does not directly control the printer device, printer status information and error detection are limited. For example, if the remote queue is up, but the printer device cannot print because of a hardware problem, the BSD actual destination remains in a normal state.
- For the same reason, job status information is limited. For example, InfoPrint reports jobs as complete when they have been sent to the remote queue even though the printer device might be down. This means that you should not include BSD actual destinations in a pool. Jobs can be requeued on the remote queue and never actually printed, although other printers in the pool might be capable of printing them.
- Because most remote queues support only one data stream, BSD actual destinations usually accept only a single document format.
- BSD physical printers do not generate auxiliary sheets. The system where the printer device is attached might create auxiliary sheets, but you cannot control them using InfoPrint Manager attributes.
- If a job sent to a BSD actual destination includes multiple data sets, the output might be interleaved with the output from other jobs. For example, if you request two copies of a job, the printer device might print one copy, then another job, then the second copy.