Design best practices for ODBA Db2 for z/OS stored procedures
If you follow certain recommendations when you design Db2 for z/OS stored procedures that use ODBA, the stored procedures are less likely to encounter problems.
Use the Open Database Manager (ODBM) to protect IMS from unexpected termination of Db2 for z/OS stored procedures
ODBM uses the ODBA interface to communicate with IMS. Many of the parameters in the ODBM CSLDCxxx configuration PROCLIB member are the same as those used by ODBA in the DFSxxxx0 startup table that is built from the DFSPRP macro parameters.
Because ODBM uses ODBA, ODBA application servers, such as Db2 for z/OS or WebSphere® Application Server for z/OS can be configured to connect to IMS through ODBM instead of through ODBA. Connecting through ODBM prevents a U0113 abend from occurring if a DB2® stored procedure or WebSphere Application Server application program terminates unexpectedly during DL/I processing.
Configuring an ODBA application server to use ODBM does not require any changes to existing application programs that run under the ODBA application server.
To use ODBM, you must also enable the Structured Call Interface (SCI) and Operations Manager (OM) components of CSL. For more information, see Configuring ODBA application servers to use ODBM.
Design short-running stored procedures
When you write a stored procedure for ODBA, design it so that the total running time between each APSB call and DPSB call is relatively short – approximately one second or less. This recommendation is similar to the recommendation for MPP stored procedures.
An ODBA stored procedure holds database locks while it is running. Until the stored procedure ends and releases the locks, IMS /DBR commands for the database cannot complete and other IMS functionality can also be lost as a consequence. By minimizing the running time between APSB and DPSB calls, you also minimize the possibility of delaying a /DBR command and losing IMS function.
Another way to prevent this problem is to stop all ODBA stored procedures before you issue the /DBR command.
Do not use the ASUTIME statement in Db2 for z/OS stored procedures that interact with ODBA
The Db2 for z/OS ASUTIME parameter defines a limit on the amount of processor time that a Db2 for z/OS stored procedure is allowed to run before Db2 for z/OS cancels the procedure.
When the ASUTIME limit is reached, Db2 for z/OS issues a CIMS FTHD call to ODBA, giving ODBA six seconds before Db2 for z/OS ends the TCB. Depending on the environment, if ODBA is unable to complete preparations before the TCB to goes away, threads can hang or other problems can occur.
Use only one APSB call at a time per Db2 for z/OS thread
Use only one APSB at a time per Db2 for z/OS thread. If you have more than one APSB active at a time, various timing problems can occur if the application abends.
You can avoid the timing problems if, after every APSB call, you make a DPSB call before the next APSB call, as shown in the following example:
APSB
(Other application calls)
DPSB
APSBUse the same value on the IMS MINTHRD= and MAXTHRD= parameters in the DRA startup table
Frequently creating and tearing down threads while your application program is running can cause timing-related errors.
When the MINTHRD= and MAXTHRD= parameters are equal, ODBA creates the requested number of threads during initialization and does not tear them down until termination. In between, threads are not created or destroyed.