Output devices owned by a Device Group are referred to as CODs. Device Groups own CODs in a one-to-many relationship. The relationship between a Device Group and its CODs frequently matches the relationship between the physical device and its components.
In the case of our DP4 Till, it is immediately apparent that the Till itself (as the Device Group) owns a slip printer, a receipt printer and a drawer. However, other functionality is available, such as the till identification value held in firmware. A Device Group should be broken down into CODs according to the functionality you wish to access from your OSDI.
It is often useful to list the available functions for a Device Group and use this list as a guide to COD definition (described in more detail here). In terms of its functionality the DP4 Till breaks down into the following CODs:
The initialisation device is a special COD, used to initialise the Device Group as a whole (for example to initialise the whole DP4 Till). This COD must be defined (DFSETUP provides the initialisation device definition automatically when you set up a Device Group). The initialisation device is used when an application starts using a new Device Group. Once the initialisation device has been selected, all the output and input devices belonging to the Device Group become available to the application.
The application does not view the Device Group directly in terms of CODs. Instead, PODs provide a further level of abstraction.
For the DP4 Till we will assume that the two printers (slip and journal) are functionally identical. Their definition can therefore be encompassed in a single printer COD. The printers can be distinguished at the POD level using COD parameters. (This is done for the sake of example, it would not necessarily be appropriate in real life.)
As just mentioned, COD Parameters provide a mechanism for the application to send additional information to the OSDI. There are several different type of parameter possible, which are described in more detail in the section on COD Parameter Definition. The original motivation for COD Parameters was to extend the facility provided by printer initialisation strings in DP4. For example, a properly set up COD can make it easier for a relatively non-technical user to set up a POD which prints to a printer in Landscape format using Times Roman font, rather than Portrait format and Courier font. Of course setting up COD parameters to do this can be quite a time consuming task (and if you are using DP4 v4.616 or later on Windows you can achieve far greater control over any printer by simply printing to the DFPRINT device). Devices such as passbook printers often have extensive lists of parameters.
An alternative to using parameters is for the OSDI to define a format for the data the application must print, and to interpret the data directly. For example for a cash drawer you could do either of the following:
Parameters are appropriate where there are relatively few possible "control values" that the application needs to pass to the device, and where it is unlikely that an application would need to pass a calculated value for such control information. For example an application would most likely not need to know the exact dimensions of a passbook. Using parameters in this case means that the application would not need to be changed if a new passbook is adopted - only the parameter values for the POD need to be changed.
Conversely passing data directly from the application rather than using parameters is appropriate when the application does need control over the device. An obvious example here might be bar code printing based on article numbers. Although the data sent from the application is probably not printed directly, (the OSDI would almost certainly be the correct place for the extra logic that would be needed for printing the bar code in the correct dimensions and with the correct separators), using parameters would be extremely unwieldy in this case (though conceivably you might use parameters to select a bar code type).