Each POD corresponds to a particular choice of COD. The relationship between CODs and PODs may be one-to-one or one-to-many. A one-to-many mapping between a COD and several PODs is achieved using COD parameters.
As part of its definition, a COD may have parameters. Each parameter has a defined range of values. When defining a POD, one value from the range for each parameter is chosen. The exact choice of parameter values allows you to diversify a single COD into multiple PODs.
For example, the DP4 Till slip and journal printers are functionally identical. Furthermore, let us assume that there is a requirement to print 10-point text on the journal but 18-point on the slip, and that these size requirements may need to be altered in the future. (Remember that the example DP4 Till is an imaginary device and the requirements and solutions have only been chosen to illustrate certain key areas in DP4 device handling.)
It might be sensible to define a generic printer COD for the Till. You can distinguish it at the POD level by defining two parameters. The first consists of a character defining the printer destination, 'S' or 'J' (for slip and journal respectively). The second takes a numeric value to define the character size, 10 or 18. Therefore there are two parameters each having two values available for use:
Parameter 2 (character size) : 0x0a (10-point) or 0x12 (18-point)
When you set up a POD derived from the printer COD, its definition will include the two parameters, and these can only take a combination of the available values above. The printer PODs are defined as:
Journal printer : parameter 1 = 'J' parameter 2 = 0x0a
The parameter string will be passed ultimately to the OSDI. The example OSDI will read the first character to decide on the destination of any printer text, and the second to set the character size.
There are a number of benefits to the COD-POD relationship. A major benefit is that a POD may be moved from one owner COD to another without re-compiling the application. This is useful when your application views the two output devices as functionally identical but when their underlying implementation differs. The OSDI may have to be enhanced and a new COD defined, but the application can continue to use the original POD. The POD layer provides a high degree of output device abstraction for the application programmer.
This abstraction also allows individual COD/POD definitions to be altered without affecting the application. For example, if the character size requirement for an existing printer changes, you only need to alter a parameter value. No re-compilation of your application or OSDI is necessary. Furthermore, the fact that PODs are grouped according to their owning COD promotes a modular structure for your OSDI, allowing it to carry out common processing for related PODs. PODs are distinguished in an OSDI by their parameter values.