This section covers the following topics:
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.
Natural for Db2 is supported in the following environments:
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.
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 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.
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-conversational mode, set the keyword
subparameter FSERV
of Natural profile parameter DB2 to ON
and provide a file server file in the CICS region.
If you do not provide a file server file in the CICS region and the keyword subparameter
CONVERS
of Natural profile parameter DB2 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.
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 setting the keyword subparameter CONVRS2
of Natural profile parameter DB2 to ON
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! |
The usage of the file server depends on the FSERV parameter in the NTDB2
macro.
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.
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 usage of the file server depends on the FSERV parameter in the NTDB2
macro.
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 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.
The usage of the file server depends on the FSERV parameter in the NTDB2
macro.
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.
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.
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.
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:
Access to the Natural system library SYSDB2
Individual functions
Static generation can be disallowed by
restricting access to the Natural system library SYSDB2,
disallowing the module CMD,
restricting access to the libraries that contain the relevant Natural objects,
disallowing one of the Natural system commands CATALOG
or STOW for a library that contains relevant Natural
objects.
If a library is defined in Natural Security and the DBID and FNR of this library are different from the default specifications, the static generation procedure automatically switches to the DBID and FNR specifications defined in Natural Security.
For further information, ask your security administrator.
This section lists the known incompatibilities and constraints against Db2 when using Natural for Db2 to access data from Db2.
Most SQL database systems support packed decimal numbers with a maximal precision of 31 digits and a scale (fractional part of the number) of up to 31 digits. The scale has to be positive and not greater than the precision. Natural allows precision and scale of up to 29 digits.
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 in the Natural Messages and Codes 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 data sets, modules, etc. |