Writing Db2 for z/OS stored procedures that use ODBA

When you are writing application programs to run in an ODBA environment, you can avoid errors by following a general pattern of ODBA calls.

Recommendation: Use only one APSB call at a time per Db2 for z/OS thread. If you have more than one APSB active at a time and the application abends, various timing problems can occur.

If your ODBA application includes multiple APSB calls, avoid undetectable deadlocks at the PST level by using one of the following methods:

Before issuing each subsequent APSB call, issue DPSB and SRRCMIT calls after each set of updates.
Use single threads in ODBA regions.
Impose a standard sequence for accessing and updating databases across all ODBA applications.

The call pattern you follow differs depending on when the RRS-sync call is initiated.

If the RRS-sync call is initiated from within the ODBA application, use the following call pattern:
1. Begin with an Allocate PSB (APSB) call to allocate a PSB for the ODBA application.
2. After the APSB call, write the main body of your application program, which will include statements such as DLI calls.
3. Code the RRS-sync.
4. Code the Deallocate PSB (DPSB) call. This deallocates the PSB which was allocated by the APSB call.
If the RRS-sync call is initiated from outside of the ODBA application, use the following call pattern:
1. Begin with an Allocate PSB (APSB) call to allocate a PSB for the ODBA application.
2. After the APSB call, write the main body of your application program, which will include statements such as DLI calls.
3. Code a DPSB PREP call. This action ends the ability of the application to access the ODBA thread. IMS resources, including database buffers and database locks obtained as part of the DL/I calls, are not released until RRS Sync is performed.
4. Return to the application deployer.
5. Deploy the DB2 application to update DB2 resources.
6. RRS-sync.