CICS VSAM Transparency for z/OS, Version 1.2


MULTIRD variations

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.

Insert processing

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®.

Update processing

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.

Figure 1. OCCURS field in VSAM record
+------+------+------+------+------+------+------+------+------+------+
|  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.

Testing for an update

The effects of an update call for a normalized design vary. If the OCCURS clause defines the maximum number of occurrences, an update call may mean one or more SQL INSERTS. It can also mean one or more SQL UPDATES. SQL is the most expensive part of an exit and minimizing SQL activity minimizes the overhead.

It is essential that your IRD considers the implications of an update call on the OCCURS table.

There are several different ways to approach this:
  1. You can assume that the group OCCURS fields changes on every update call. In this case, you may decide to delete all the rows in DB2 and insert new rows.
  2. You can compare the updated data in the group field against the data in DB2. If there is any difference, issue SQL delete calls and then insert new rows.
  3. You can compare each group field value and issue SQL update calls for those which have changed.

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.

Initial data migration

The significant IRD parameters for initial data migration are described in Build a load record. For a repeating group IRD, pay particular attention to IRDRPTGR and IRDB2DLN.

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.

The output data set created by the VIDLOAD utility contains records for the primary DB2 table as well as the repeating group table. You must specify a value in IRDTYPE to identify the repeating group table records. The area addressed by IRDB2DAT looks like Figure 2.
Figure 2. Repeating group record built by IRD
+-+--------+---------------+-+--------+---------------+-+--------+------\
|a|key+TS  | data          |a| key+TS | data          |a| key+TS | data  \_
+-+--------+---------------+-+--------+---------------+-+--------+---------\
In Figure 2, the boxes containing “a” correspond to the 2-byte IRDTYPE parameter. The box containing “key+TS” refers to the concatenation of the DB2 primary key plus a TIMESTAMP column to make each row in the repeating group table unique. The box containing “data” refers to each occurrence of the group field.

Calculate the length of the entire area - a+key+TS+data - and store it in IRDB2DLN.



Concept topic


Last updated: November 9, 2012 20:43:53