Accessing IMS data using the TIBCO Object Service Broker rules language is similar to accessing TIBCO Object Service Broker data. The main difference is in the way IMS uses your selection criteria in conjunction with the IMS table definition to interpret the request.
The following sections outline any differences encountered while using rules, point out normal rules behavior that must be considered when building applications, and explain how your rules selection criteria translates into DL/I calls.
If you issue a rule language EXECUTE statement within a main (parent) transaction, it creates another transaction stream (child transaction), to a maximum of ten streams. The number of streams allowed in a TIBCO Object Service Broker transaction depends on the TRANMAXNUM Execution Environment parameter, which has a default of nine streams. Each transaction stream in TIBCO Object Service Broker accessing IMS data requires its own TIBCO Service Gateway for IMS/DB or TIBCO Service Gateway for IMS/DB under CICS DL/I task.
The number of IMS tables you can access per transaction depends on the POOLSIZE gateway parameter, and the CTABLESIZE Data Object Broker parameter. If the default parameter sizes are used, you can access at least 16 IMS tables per transaction; more, depending on the size of the IMS table definitions. Refer to
Estimating the CTABLESIZE Parameter for more information. Refer to
TIBCO Object Service Broker Parameters for more information about parameters.
Using TRANSFERCALL or DISPLAY & TRANSFERCALL statements in a rule minimizes the number of Gateways and reduces the possibility of IMS locking contention.
If your TIBCO Service Gateway for IMS/DB is executing in a CICS Execution Environment, when the THREADUSAGE gateway startup parameter is set to TRANSACTION or TABLE, the PSB specified by the first IMS table accessed in a TIBCO Object Service Broker transaction is scheduled for the duration of that transaction.
The Gateway uses PATH calls to access IMS data. Only one PATH call is required for each GET or FORALL in your rule that is retrieving a sequence of segments in a hierarchical path. An occurrence is returned only if data is available for all segments defined in the path.
The Gateway includes all parameter values and access values in the SSA with an equality qualification. Additionally, the Gateway uses the selection criteria specified for primary keys and for IMS fields that are defined in the DBD, providing the selection criteria meets all the following conditions:
When a TIBCO Object Service Broker transaction runs in browse mode, locks are not taken on the TIBCO Object Service Broker data. Locking of IMS data is determined by the PROCOPT parameter for the database PCB in the Gateway PSB. Refer to
Defining Gateway Program Specification Blocks for more information.
A GET…ORDERED statement retrieves all IMS data satisfying the selection criteria, and sorts it in the Execution Environment before returning the first occurrence.
A FORALL statement is a looping construct that processes a set of occurrences. The body of the loop consists of the statements to be executed for each occurrence satisfying the selection criteria. FORALL statements can be nested provided they refer to different table names.
A FORALL returns occurrences to TIBCO Object Service Broker in the order in which IMS passes them. To get the data in a different order, include an ORDERED clause in the FORALL. TIBCO Object Service Broker orders only occurrences specified in the selection criteria.
IMS tables containing non-unique segments (no key, or a multiple sequence key) require their own database PCB. This enables the Gateway to maintain its position in the IMS database when accessing non-unique IMS data.
A REPLACE request against an IMS table modifies the last TIBCO Object Service Broker IMS occurrence retrieved. All segments defined in the access path are replaced, starting with the segment where the primary key is defined. Parameterized segments are used for positioning only.
You can modify all fields selected from each segment defined in the access path, starting with the segment where the primary key is defined. Consider the following when modifying fields:
An INSERT request to an IMS table inserts all segments defined in the access path, starting with the segment where the primary key is defined. Parameterized segments are used for positioning only.
A DELETE request against an IMS table deletes either the last TIBCO Object Service Broker IMS occurrence retrieved or the occurrence that contains the primary key value specified in the DELETE request.
The segment the primary key is defined at and all child segments associated with that parent are deleted. Parameterized segments are used for positioning only.
TIBCO Object Service Broker Parameters about the TRANMAXNUM Execution Environment parameter.
