There are no OCCURS clauses that have to be handle by the MULTIRD IRD exit. Each update call accesses a single table. When an IRD exit has to handle an OCCURS clause, insert processing, update processing, and initial load processing are all different. These are discussed in this section.
If there are a fixed number of occurrences in each group, insert processing is straightforward. Multiple rows are inserted by the IRD.
In some cases, an OCCURS clause may indicate the maximum number of items in the group. Unused array items often have predefined values based on field attributes, such as zero or low values. In this case, the exit has to determine how many array items contain valid data to be inserted to DB2®.
A key factor affecting the complexity of the IRD is the update process. For example, assume that RETL-PRICE-GROUP in the copybook extract in Figure 1 holds information for the last 10 variations in the price of an item, stored chronologically. The first array element always contains latest price information. When the price of an item changes, the oldest price information drops off, and the nine remaining array elements are moved within the array. This is illustrated in the VSAM record show in Figure 1, where 0 represents the latest price information and -9 the oldest.
+------+------+------+------+------+------+------+------+------+------+
| 0 | -1 | -2 | -3 | -4 | -5 | -6 | -7 | -8 | -9 |
+------+------+------+------+------+------+------+------+------+------+
The application program issues a PUT/REWRITE call to add new price information. The latest price information is always written to the first element, so when this update takes place the remaining elements shift to the next element along.
When you implement this as multiple rows in a DB2 table, you must ensure that the same is achieved in your CICS® VT exits. You could add a TIMESTAMP column to the DB2 table, and use it as part of the ORDER BY cursor statement in the FBE. If the column was defined as NOT NULL WITH DEFAULT, DB2 generates a value corresponding to the date and time the insert takes place. This would also ensure uniqueness of the primary key.
If a TIMESTAMP column is not desirable, the column value has to be generated by the IRD.
It is essential that your IRD considers the implications of an update call on the OCCURS table.
The greater the OCCURS number, the greater the SQL overhead to process the OCCURS table. One way to eliminate unnecessary SQL calls is described in Exit work area.
To illustrate, consider the example of a group field with OCCURS 10. When IRDFUNCT = L, the IRD must build all 10 records in a single contiguous area in working storage or in the exit work area. Set the address of this area to IRDB2DAT. You specify the number of DB2 records that you have built in this area in the parameter IRDRPTGR. In this case, the value is 10.
+-+--------+---------------+-+--------+---------------+-+--------+------\
|a|key+TS | data |a| key+TS | data |a| key+TS | data \_
+-+--------+---------------+-+--------+---------------+-+--------+---------\
Calculate the length of the entire area - a+key+TS+data - and store it in IRDB2DLN.