Resolution:
If the IMS key for a segment is not completely defined in the TIBCO Object Service Broker table for an IMS database, then a retrieval request such as:
   FORALL imstable WHERE partial_key1 = value and partial_key2 = value:
     . . . .
   END;
may return the same data in a never-ending loop.

Environment:
============
IBM IMS™
IBM z/OS
TIBCO® Object Service Broker
TIBCO® Service Gateway™ for IMS/DB

Symptoms:
=========
Forall enters logical loop returning the same data repeatedly. If the data is being stored in a memory table such as TEM or SES within the Execution Environment (EE), the user's session may fail with an error such as:
   S6BST001E STORAGE MANAGER ERROR: GETMAIN REQUEST FAILED; SPID=34,LENGTH=00040000,RETCODE=00000004
Additional symptoms might include but are not limited to: ABENDS322 (CPU time exceeded), session hung or no response returned to client.

Cause:
======
When a rule issues a FORALL against an IMS database, the request is passed to the Data Object Broker (DOB) and then to a database gateway capable of processing the request. If the amount of data exceeds the communications buffer size, data may be returned to the EE in multiple transmissions, allowing the FORALL to process each chunk before requesting the next buffer of data. The last row received is returned to the gateway in order to allow correct positioning within the data for the next series of rows. If the OSB table definition does not include the full key structure for the segment, then incorrect positioning may result causing looping or incorrect data to be returned to the end user.

In mapping IMS fields to Object Service Broker fields, be sure to use the appropriate external and internal syntaxes as incorrect definitions may also cause the access request to misbehave. Do not assume that IMS and OSB syntaxes have the same characteristics.

In particular, be extremely careful when using syntax "C" for external (XSYN) or internal (SYN) Object Service Broker as this syntax has an implicit upper case translation feature implemented in the syntax. If the data being mapped contains underlying lower case text or binary/packed data, the translation may result in incorrect positioning or corrupted data. Use XSYN "V" to resolve this problem.

If using packed decimal data, be careful to choose the external syntax that is capable of supporting the sign stored in your IMS data. External Syntaxes may generate different sign nybbles:

"G" -generates sign "F" for positive values and "D" for negative
"L" -generates sign "F" for positive values and "D" for negative
"O" -no sign stored
"P" -generates sign "C" for positive values and "D" for negative
"U" -generates sign "F" for positive values. Negative values are not supported.

If a field F1 is defined in an IMS DBD as TYPE=P with data stored with a sign of "F", then defining the external syntax XSYN as "P" in the OSB/IMS table definition and executing rule statements such as:
  GET imstable WHERE F1=12345;
may return no result even though a segment with field F1=12345 exists. The reason for this failure is that the Object Service Broker Segment Search Argument (SSA) request passed to IMS will contain the wrong sign value because XSYN syntax "P" was used, generating a packed number of the form x'12345C' but the IMS data actually is stored as x'12345F'. For some types of databases, IMS will perform a character rather than an arithmetic comparison, resulting in no matching values. Using XSYN of "G" will resolve this problem.


Resolution:
===========
Define the complete key field structure in your OSB/IMS table definition and use the correct syntaxes.


References:
===========
IBM IMS Application Programming
TIBCO® Object Service Broker Programming in Rules
TIBCO® Service Gateway™ for IMS/DB Installing and Operating