Overview

#### Search Results

Search

# Overview

- Architecture overview

- Installation structure

- Natural Batch Considerations

- Performance Considerations

- Db2 Considerations

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.

##### zIIP utilization comparison diagram

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.

## Architecture overview

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.

## Installation structure

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 .

## Natural Batch Considerations

- Build

- Execution

- Failover Mechanism

### Build

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.

### Execution

#### TSO Db2 Interface (DSNELI) – Considerations

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.

#### DB2=(NDZSRV=) sub parameter

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.

### Failover Mechanism

#### Failover to NDB when NDZSRV is unavailable

    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.

## Performance Considerations

- Client WLM enclaves under NDZ started task

- Db2 DIST enclaves

- Automatic profile reload

### Client WLM enclaves under NDZ started task

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’.

### Db2 DIST enclaves

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’.

### Automatic profile reload

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.

## Db2 Considerations

- Connection and trusted context

- Password encryption

- Db2 security considerations

- Static preparation and execution

### Connection and trusted context

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.

#### Connection Pool

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

### Password encryption

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.

### Db2 security considerations

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.

#### Accounting

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.

### Static preparation and execution

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.

### On this page

- Architecture overview
- Installation structure
- Natural Batch Considerations
- Performance Considerations
- Db2 Considerations