Resolution:
When a table T is defined with a primary concatenated key structure such as:

Table: T
Field Name Typ Syn Len Dec Key Ord Rqd
---------------- - – ----- – - - -
P1 S C 20 0 P
P2 Q B 2 0 P
P3 D B 4 0 Q
P4 Q B 2 0 P
. . .
F1 S C 4 0
F2 S C 3 0
. . .

A selection such as:

1) FORALL T WHERE P1= 'SDC69668V0036331T1' | P1 = 'SDC69668V003633138' & F2='XYZ' & F1 = 'ABCD'
or
2) FORALL T WHERE P1= 'SDC69668V0036331T1' & F2='XYZ' & F1 = 'ABCD' | P1 = 'SDC69668V003633138' & F2='XYZ' & F1 = 'ABCD'

results in a table sweep being performed on z/OS. This is because an index access request structure is not generated, resulting in a table sweep with post-application of the selection criteria.

Since the partial key supplied is the high-order portion of the table's primary key, the access should be optimized to take advantage of this. Performance on very large tables is otherwise compromised.

Environment:
============
* z/OS

Symptoms:
=========
On tables containing large numbers of rows, time to return the result set may be very long appearing almost as a hung condition.

Cause:
======
The index is not utilitized efficiently to satisfy the selection provided.

Resolution:
===========
Customer's experiencing this problem should open a service request and ask to be put on the interested parties list for resolution of incident OSBZ-1379.


References:
===========
TIBCO® Object Service Broker Programming in Rules
TIBCO® Object Service Broker Managing Data