Natural for DB2 can be run in the TP-monitor environments Com-plete, CICS, IMS TM and TSO as well as in batch mode.
Under CICS, IMS TM MPP and TSO, the Natural file server for DB2 is provided. The usage of the file server depends on the FSERV parameter in the NDBPARM parameter module as described in the relevant section.
DB2 is supported by Com-plete Version 4.5. Programs running under Com-plete 4.5 can access DB2 databases through the DB2 Call Attachment Facility (CAF). This facility, together with the Com-plete interface to DB2, allows fully conversational access to DB2 tables.
If the DB2 plan created during the installation process is not specified in your DB2 SERVER parameter list for Com-plete, you must explicitly call NATPLAN before the first SQL call to allocate this plan.
Under IMS TM, Natural uses the IMS DB2 Attachment Facility to access DB2. Therefore ensure that this attachment is started.
In IMS TM transaction processing environments, DB2 closes all cursors and thereby loses all selection results whenever the program returns to the terminal to send a reply message. This operation mode is different from the way DB2 works in CICS conversational mode or TSO environments, where cursors can remain open across terminal communication and therefore selected rows can be retained for a longer time.
The file server is required to support the Natural for DB2 cursor management, while IMS TM issues an implicit end-of-transaction to DB2 after each terminal I/O operation. With the file server, database loops can be continued across terminal I/Os, but database modifications made before a terminal I/O can no longer be backed out.
For a detailed description of the file server, refer to the section Natural File Server for DB2.
Under CICS, Natural uses the CICS/DB2 Attachment Facility to access DB2. Therefore, ensure that this attachment is started. If not, the Natural session is abnormally terminated with the CICS abend code AEY9, which leads to the Natural error message NAT0954 if the Natural profile parameter DU is set to OFF.
If your transaction ID is not assigned to any DB2 plan in the RCT, you must explicitly call NATPLAN before the first SQL call to specify the required DB2 plan. The actual plan allocation is performed by the dynamic plan selection exit.
Under CICS, a Natural program which accesses a DB2 table can also be run in pseudo-conversational mode (Natural profile parameter PSEUDO=ON). In this case, at the end of a CICS task, all DB2 cursors are closed, and there is no way to reposition a DB2 cursor when the task is resumed.
To circumvent the problem of CICS terminating a pseudo-conversational transaction during loop processing and thus causing DB2 to close all cursors and lose all selection results, NDB either uses the file server to support the Natural transaction logic or switches from pseudo-conversational mode to conversational mode for the duration of a Natural loop which accesses a DB2 table.
If the file server is not used and the NDB parameter CONVERS=ON is set, NDB switches to conversational mode whenever a terminal I/O takes place during an open database loop.
To enable multiple Natural sessions to run concurrently, all Natural areas are written to the threads just before a terminal I/O operation is executed. When the terminal input is received, storage is acquired again, and all Natural areas are read from the threads.
In order to support applications, which do not deploy the implicit commit at CICS terminal I/O and which instead code explicit ROLLBACK or COMMIT to end their database transaction, a conversational mode 2 has been introduced.
Conversational mode 2 means that a DB2 update transaction is spawned across CICS terminal I/Os until an explicit COMMIT or ROLLBACK is issued.
Conversational mode 2 could be requested by the NDB parameter CONVRS2=ON or it can dynamically set or rest by calling the CALLNAT program NDBCONV.
 |
Warning: These kinds of application tend to tie up CICS and DB2 resources, as the resources are not freed across terminal I/O! |
In a CICS environment, the file server is an optional feature to relieve the problems of switching to conversational processing. Before a screen I/O, Natural detects if there are any open cursors and if so, saves the data contained by these cursors into the file server. With the file server, database loops can be continued across terminal I/Os, but database modifications made before a terminal I/O can no longer be backed out.
For a detailed description of the file server, refer to the section Natural File Server for DB2.
Natural for DB2 can run under TSO without requiring any changes to the Natural/TSO interface.
Apart from z/OS Batch, the batch environment for Natural can also be the TSO background, which invokes the TSO terminal monitor program by an EXEC PGM=IKJEFT01 statement in a JCL stream.
Both TSO online or batch programs can be executed either under the control of the DSN command or by using the Call Attachment Facility (CAF); the CAF interface is required if plan switching is to be used.
In a TSO environment, the file server is an optional feature to be able to emulate during development status a future CICS or IMS TM production environment.
With each terminal I/O, Natural issues a COMMIT
WORK command to simulate CICS or IMS TM Syncpoints. Therefore,
database modifications made before a terminal I/O can no longer be backed
out.
For a detailed description of the file server, refer to the section Natural File Server for DB2.
If you run Natural for DB2 under TSO or in batch mode and use the CAF interface, you must explicitly call NATPLAN before the first SQL call to allocate the required DB2 plan.
NATPLAN can be edited to specify the appropriate DB2 subsystem ID.
If you want to access DB2 and DL/I in the same Natural session in batch mode (not BMP), you can use the DB2 DL/I batch support facility which allows you to coordinate recovery of both DB2 and DL/I database systems.
If you want to use this facility, you must execute the DLIBATCH procedure to run the DSNMTV01 module as the application program. DSNMTV01 in turn executes the Natural batch nucleus which must be linked with the DB2 interface DFSLI000.
Since DB2 does not allow Syncpoints when running in an DSNMTV01 environment, the Natural interface to DB2 cannot execute these Syncpoints by itself. These Syncpoints are therefore routed to the Natural interface to DL/I. Only one checkpoint is written for the corresponding END TRANSACTION statement, even if both database systems are involved.
If your PSB is generated with CMPAT=YES, all Syncpoints are executed by Natural for DL/I. Therefore, you must issue a END TRANSACTION statement before you end your Natural session; otherwise all your database modifications are lost, because Natural implicitly issues a BACKOUT TRANSACTION statement at the end of the session.
If your PSB is generated with CMPAT=NO, all Syncpoints are ignored.
