Version 4.2.6 for Mainframes (Update)
 —  Database Management System Interfaces  —

General Information

This section covers the following topics:


Purpose

Natural for DB2 is a Natural interface designed to access data in a DB2 database.

In general, there is no difference between using Natural with DB2 and using it with Adabas, VSAM or DL/I. The Natural interface to DB2 allows Natural programs to access DB2 data, using the same Natural native data manipulation (DML) statements that are available for Adabas, VSAM, and DL/I. Therefore, programs written for DB2 tables can also be used to access Adabas, VSAM, or DL/I databases. In addition, Natural SQL DML statements are available.

All operations requiring interaction with DB2 are performed by Natural for DB2.

Top of page

Environment-Specific Considerations

Natural for DB2 is supported in the following environments:

Natural for DB2 under Com-plete

DB2 is supported by Com-plete. Programs running under Com-plete 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.

Natural for DB2 under CICS

CICS/DB2 Attachment Facility

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.

CICS DB2 Plan Selection

If the Natural CICS transaction ID is not assigned to any DB2 plan in the RCT by DB2ENTRY and DB2TRAN definitions, you must explicitly execute NATPLAN before the first SQL call to specify the required DB2 plan and define NDBUEXT as dynamic plan selection exit (PLANExit attribute). The actual plan allocation is performed by the dynamic plan selection exit.

CICS Pseudo-Conversational Mode

Under CICS, a Natural program usually runs in pseudo-conversational mode (Natural profile parameter PSEUDO set to ON, default value). In this case, at the end of the CICS transaction, the DB2 transaction is commited and all open DB2 cursors are closed implicitly and there is usually no way to resume open Natural FIND/SELECT database access loops after the terminal I/O.

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, Natural for DB2 uses the file server to support the Natural transaction logic. If you intend to operate in CICS pseudo-conversationl mode, specify the Natural for DB2 parameter FSERV=ON and provide a file server file in the CICS region.

CICS Conversational Mode

If you do not provide a file server file in the CICS region and the Natural for DB2 parameter CONVERS is set to ON, Natural for DB2 switches to conversational mode whenever a terminal I/O takes place during an open database loop. This means the CICS transaction is spawned across terminal I/O as long as there are open database loops. This could cause DB2 deadlocks, as DB2 resources are allocated across terminal I/Os.

CICS Conversational Mode 2

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 Natural for DB2 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!

File Server under CICS

The usage of the file server depends on the FSERV parameter in the NDBPARM parameter module.

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 under IMS TM

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.

File Server under IMS TM MPP

The usage of the file server depends on the FSERV parameter in the NDBPARM parameter module.

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.

Natural for DB2 under TSO

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.

File Server under TSO

The usage of the file server depends on the FSERV parameter in the NDBPARM parameter module.

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.

Natural for DB2 Using CAF

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.

Natural for DB2 Using DB2 DL/I Batch Support

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.

If your PSB is generated with CMPAT=YES, all Syncpoints are executed and you must issue an END TRANSACTION statement before you end your Natural session; otherwise, any 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.

Top of page

Integration with Predict

Predict, Software AG's open, operational data dictionary for fourth-generation-language development with Natural, is a central repository of application metadata and provides documentation and cross-reference features. Predict lets you automatically generate code from definitions, enhancing development and maintenance productivity.

Since Predict supports DB2, direct access to the DB2 catalog is possible via Predict and information from the DB2 catalog can be transferred to the Predict dictionary to be integrated with data definitions for other environments.

DB2 databases, tables and views can be incorporated and compared, new DB2 tables and views can be generated, and Natural DDMs can be generated and compared. All DB2-specific data types and the referential integrity of DB2 are supported. See the relevant Predict documentation for details.

In addition, the Predict active references support static SQL for DB2 as described in WITH XREF Option in Preparing Programs for Static Execution.

Top of page

Integration with Natural Security

When run in an environment that is controlled by Natural Security, the use of certain features of Natural for DB2 can be restricted by the security administrator, for example:

For further information, ask your security administrator.

Top of page

Incompatibilities and Constraints

This section lists the known incompatibilities and constraints against DB2 when using Natural for DB2 to access data from DB2.

Top of page

Messages Related to DB2

The message number ranges of Natural system messages related to DB2 are 3275 - 3286, 3700-3749, and 7386-7395.

For a list of error messages that may be issued during static generation, see Static Generation Messages and Codes Issued under NDB/NSQ in the Natural Messages and Codes documentation.

Top of page

Terms Used in this Documentation

Term Explanation
DB2 DB2 refers to IBM's DB2 UDB for z/OS.
DBRM Database request module
DDM Data definition module.
DML Data manipulation language (Natural).
File Server In this document, the term "file server" refers to the Natural file server for DB2.
NDB This is the product code of Natural for DB2. In this documentation the product code is often used as prefix in the names of datasets, modules, etc.
SQL/DS SQL/DS refers to IBM's DB2 Server for VSE and VM.

Top of page