Natural for Db2 for zIIP (NDZ) complements Natural for Db2 (NDB) Database Management Interface by adding the ability to run Db2 workloads on IBM System z Integrated Information Processors (zIIP).
Natural for Db2 for zIIP (NDZ) makes use of the zIIP capabilities by accessing Db2 through a remote DRDA protocol, instead of using conventional Db2 local attachments. Local calls to Db2 are not zIIP eligible, therefore accessing Db2 using the DRDA protocol enables Natural programs to run continuously on zIIP processors.
Java workloads running on z/OS are zIIP eligible, therefore Natural for Db2 for zIIP (NDZ) uses Java and Java Database Connectivity (JDBC) to access Db2 using the DRDA protocol. The following diagrams show an approximate comparison of the workload distribution when accessing Db2 using only NDB and when using NDB and NDZ at the same time.
Some workloads, e.g. I/O calls are not zIIP eligible. zIIP ineligible workloads require the respective Natural programs to run temporarily on the general processors. The ‘Processing on GP’ in figure 3 in below diagram represents the workload executed on General processor. This workload includes 40 percent of zIIP ineligible Db2 workload, part of Natural workload and part of NDZ workload that is not zIIP eligible. For example, NDZ server executes in General Processor during start up, shut down and while executing the modify operator commands.
To benefit from Natural for Db2 for zIIP (NDZ) capabilities, you must ensure that enough System z Integrated Information Processors (zIIP) are available in the target environment. Running NDZ workloads without the required zIIP capacity can lead to increased general processor utilization, due to zIIP eligible workload running on general processors. Please refer to the section Honor Priority in the manual z/OS MVS Planning: Workload Management.
Natural for Db2 for zIIP (NDZ) runs on its own address space. An instance of the NDZ Server is capable of handling requests from multiple Natural batch jobs. The following diagram represents the overall Natural for Db2 for zIIP architecture.
The following diagram represents requests from different clients executing Db2 statements
in a NDZ instance running in the started task NDZSTC.
Since NDZ uses multiple simultaneous client requests, it uses connection pool by the IBM Data Server Driver for JDBC and SQLJ to reduce the processing usage. It reuses the existing connections to minimize the impact of creating and closing the connection for each Db2 request.
The NDZ server comprises both a nucleus and a Java Virtual machine. During initialization, NDZ connects to Db2 through JDBC in a trusted context and creates both Java client tasks and a pool of Db2 connections that can be used later to process SQL requests on behalf of its clients. A Natural Batch client can select one NDZ server instance through the Db2 sub-parameter NDZSRV. When the client connects to the NDZ server instance, a new Db2 thread with the same user ID of the Natural Batch client job is created from one of the pooled connections.
Natural for Db2 for zIIP distribution consists of a native load library, TAR file and jobs to install and configure NDZ components. The native load library consists of the following load modules.
NDZ nucleus load module
NDZJVM load module
The NDZ installation directory extracted from distributed TAR file consists of following sub directories.
| classes | Contains executable jar files for NDZ. |
| bin | Contains executable scripts for the configuration and execution of NDZ. |
| etc | Contains ndz.properties and db2.properties file. These properties file allows you to specify the parameter for Db2 for z/OS and NDZ configurations. |
| static | Directory to store the static serialized profile information. |
For more detailed information on the NDZ installation jobs, refer to Installing Natural for Db2 for zIIP .
The Natural Batch nucleus needs to be link edited to do the following actions
Include NDBNDZ from Natural load library. This contains NDZ’s own DSNHLI interface to be included in Natural Batch nucleus.
Include Db2 interface module DSNALI or DSNELI based on the environment, renaming the entry point DSNHLI to DB2HLI.
For detailed information about the build step, refer to Installing Natural for Db2 for zIIP documentation.
If NDB is using TSO Db2 interface DSNELI a connection to Db2 will be created using DSN statement. If NDZSRV is specified in the job, the NDZ server will use its own connections from the connection pool and TSO connection is unused. If executed without IKJEFT01 the TSO connection won’t be created, but the failover mechanism won’t work as there is no explicit connection issued. It is better to use CAF DSNALI to avoid any unused connections and to fail over to NDB in case NDZ server is not available.
Specify NDZSRV parameter as part of DB2 parameters to utilize the NDZ server to execute the Db2 workloads on a zIIP processor. Make sure the NDZ server specified is up and running. For more details refer to NDZSRV.
NAT7380: NDZ server ":1:" is not available. NAT7382: Natural SQL interface active without Natural for Db2 for zIIP.
Natural for Db2 for zIIP complements the Natural for Db2 and executes the Db2 workloads executed on zIIP. If the NDZ server specified in NDZSRV parameter is not available, the following warning message is displayed and Db2 request will be handled through local connection and executed in a general processor.
This failsafe mechanism helps process a Db2 request even when NDZ server is unavailable.
A WLM enclave is created for each client connected with the specific qualifiers. Following are the NDZ set WLM qualifiers.
| Qualifier | Value set by NDZ |
|---|---|
| Correlation | Client Job ID |
| User ID | Client Job User ID |
| Process name | Client Job name |
| Transaction / Job name | NDZ started task name |
| Subsystem type | STC |
| Subsystem name | NDZ started task name |
You can create a WLM classification rule to place NDZ STC and/or enclaves into a different service/report class using these qualifiers. For more information, refer to IBM documentation ‘z/OS MVS Planning: Workload Management’.
DDF workloads run on specific designated enclaves. These enclaves are controlled by the WLM service class definitions. NDZ creates one thread per client connected. During Db2 thread creation, it assigns the following thread/connection values.
| Qualifier | Value set by NDZ |
|---|---|
| Client transaction or Application name (CTN) | Client Job name |
| Client user ID (CUI) | Client Job User ID |
| Client Accounting Information (CAI) | Client Job name |
| Correlation ID(CI) | Client Job name |
You can create a WLM classification rule to place DDF enclaves into a different service/report class using these qualifiers. For more information, refer to IBM documentation ‘z/OS MVS Planning: Workload Management’.
Every time the static profiles are created/updated in the NDZ static directory, NDZ static profile
cache need to be reloaded to pick updated profiles. NDZ provides an option to
automatically pick these changes and reload the static profile cache. The parameter
ndz.automaticProfileReload, determines whether to reload the
static profiles cache whenever the changes occur in the directory specified.
Note:
Setting Automatic profile reload means that a static directory is monitored for any
changes and will consume lot of resources. This option can be set to false to avoid this
resource usage. In that case, when a profile is changed, you need to manually reload the
static profiles using the modify command R.
For detailed information about static preparation process, refer to Preparing Programs for Static Execution.
NDZ has a single connection to Db2 using a trusted context and creates connections on behalf of its clients. You need to create a trusted context based on a system authorization id (ndzDb2user) and connection attributes.
When executing Db2 requests, a connection is established on behalf of the user who submitted the request without the need to authenticate the user at the Db2 server.
In the multi-threaded environment, opening and closing of each connection will be expensive and hence NDZ uses connection pool. The main advantage is that it promotes reusability and eliminates the need to open and close the connections.
NDZ creates one thread per client connected. For example, when there are four Natural batch jobs connected to NDZ there will be four simultaneous Db2 connections / threads. Once the client disconnects, when the Natural batch client job ends, the threads are terminated.
NDZ keeps pooled connections opened to be reused by clients. They will not appear in
the DIS THD(*) LOCATION(*) TYPE(ACTIVE) DETAIL command output
until assigned to a client. When a Natural Batch job client connects to NDZ, one of the
connections is assigned to it and a Db2 thread is created.
The following diagram describes the -DISPLAY THREAD output where two
clients are connected executing their Db2 workload via NDZ. They are connected to Db2
via trusted context created for ndzDb2user NATJAVA. Application name identifies the
jobname and plan identified as DISTSERV and this is same for all jobs
executed through NDZ as NDZ connects to Db2 remotely. AUTHID indicates the
user submitted the job and the SYSTEM AUTHID refers to the ndzDb2user.
DSNV401I = DISPLAY THREAD REPORT FOLLOWS -
DSNV402I = ACTIVE THREADS –
NAME ST A REQ ID AUTHID PLAN ASID TOKEN
SERVER RA * 8024 db2jcc_appli JAYM DISTSERV 00EF 13262
V485-TRUSTED CONTEXT=CTXNDZ,
SYSTEM AUTHID=NATJAVA,
ROLE= *
V437-WORKSTATION=DB2CALL
USERID=JAYM
APPLICATION NAME=NDZDS1K4
V442-CRTKN=NDZDS1K4
V445-GA144A3D.P510.DF9F35DB7498=13262 ACCESSING DATA FOR
::FFFF:10.20.74.61
SERVER RA * 8026 db2jcc_appli JAYM DISTSERV 00EF 13261
V485-TRUSTED CONTEXT=CTXNDZ,
SYSTEM AUTHID=NATJAVA,
ROLE= *
V437-WORKSTATION=DB2CALL
USERID=JAYM
APPLICATION NAME=NDZDS1K3
V442-CRTKN=NDZDS1K3
V445-GA144A3D.P50F.DF9F35DB7368=13261 ACCESSING DATA FOR
::FFFF:10.20.74.61
Natural for Db2 for zIIP (NDZ) provides a mechanism to safely store the password of ndzDb2 user.
The script <NDZ home directory>/bin/ndz-db2-pass.sh allows the user to
encrypt the password. During the execution, NDZ decrypts the password based on the key
file and uses it for Db2 connections. This is the recommended approach to store the
password for the ndzDb2 user.
Make sure you have a Execute access to the
ndz-db2-pass.sh script and write access to the NDZ library as NDZ will
create a <NDZ home directory>/var directory when you execute this
script.
Find more details in Db2 Password Encryption.
Natural for Db2 for zIIP (NDZ) connect to Db2 remotely using a Db2 distributed data facility. Any remote client applications that access Db2 via the Db2 distributed data facility are associated, by default, with plan DISTSERV. Hence, adding security via plan authorizations is not possible.
You can manage authorizations using GRANT/REVOKE on packages and collections.
Since NDZ connects to Db2 through DDF, the generation of accounting records is managed
by the Db2 subsystem parameters ACCUMACC and
ACCUMUID.
The ACCUMUID parameter specifies which qualifier of the thread
should be considered to identify a unique client. Depending on its value, all the NDZ
threads may be considered as the same client. In this case, a new accounting record will
be generated after the number of transactions defined by the
ACUMMACC parameter, when it is not set to NO.
Currently, NDZ sets the following Db2 thread / connection values:
| Qualifier | Value |
|---|---|
| Application Name | Client Job name |
| User ID | Client Job User ID |
| Client Accounting Information | Client Job name |
| Correlation Token | Client Job name |
The value of the parameter ACCUMUID should be set accordingly to
consider the Application name, and optionally the user ID, to uniquely identify
clients.
For example, 0 (User ID, application name and workstation name), 4 (User ID and
application name), among others. For more details about the parameters
ACCUMUID and ACUMMACC please refer to
Db2 Installation and Migration Guide.
Natural for Db2 for zIIP (NDZ) support static preparation and execution through SQLJ and it is independent from the static generation of NDB.
For detailed information about static preparation and Execution of Natural programs with NDZ, refer to About Preparation for Static Execution with NDZ.