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 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, specify the Natural for DB2 parameter
FSERV=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
Natural for DB2 parameter CONVERS is
set to ON, Natural for DB2 switches to conversational mode
whenever terminal I/O operations are performed 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/O operations.
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/O operations 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! |
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 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/O operations, but database modifications made before 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/O operations, but database modifications made before 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 and 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 operation, Natural issues a COMMIT
WORK command to simulate CICS or IMS TM Syncpoints. Therefore,
database modifications made before 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. |