Assessing IBM® IMS™ OSAM encryption performance

Worried about database security for your enterprise? Who isn't? Do you want to spend days and weeks updating applications just because you want to use z/OS encryption? Of course not!

If you want to take advantage of z/OS encryption for IMS Overflow Sequential Access Method (OSAM) databases, check out our blog about this exciting new announcement in IMS 15.2.

You probably also want to know whether there is any impact to performance while taking advantage of the new OSAM encryption capability. In this blog, I'll walk you through the performance testing results.

OSAM Encryption

IMS 15.2, IMS’s first continuous delivery release, provides new OSAM encryption capability. The IMS performance team conducted evaluations to measure the CPU cost of encrypting OSAM databases.

Traditional OSAM Physical Sequential (PS) data sets use an efficient and optimized I/O driver that is only specific to IMS. To enable OSAM data set z/OS encryption, OSAM PS data sets need to be converted to VSAM Linear Data Sets (LDS). This allows IMS to use a z/OS-supported I/O driver (Media Manager) that provides z/OS data set encryption. Throughout this blog, we will use the term "OSAM LDS" to refer to OSAM data sets that use VSAM LDS as their underlying data set format. Note that OSAM PS is still supported by IMS; however, to encrypt an OSAM database, you must convert to OSAM LDS.

Measurements were done on an IBM z15 LPAR Model 8561 (T01) z/OS 2.3 LPAR configured with four dedicated CPUs and FICON Express 16SA channels operating at 16Gbps speeds, using a lightweight test application with simple business logic to emphasize the IMS code pathlength changes. Measurements were collected in a shared environment and had a run-to-run variability between +/- 2%.  Your results may vary based on application business logic, workload characteristics and configuration.

To encrypt the databases, the IBM Crypto Express7 (CEX7C) Cryptographic Coprocessor was used with protected keys. Integrated Cryptographic Service Facility (ICSF) was configured with CHECKAUTH(NO).

Generally, the CPU cost of encryption is proportional to the number of I/O operations executed against an encrypted data set. The CPU cost of encrypting OSAM databases was evaluated using both online and batch workloads described in the sections below.

Online (MPP) workload

The online workload is made up of an assortment of transactions and full-function databases. The types of transactions include teller system, inventory, hotel and warehouse transactions that issue read, replace, delete and insert calls. The types of databases include 16 High Availability Large Database (HALDB) and 16 replicates of non-HALDB.

Each HALDB consists of:

• One Partitioned Indexed HDAM (PHIDAM) with four 1GB partitions
• Four OSAM data sets

Each non-HALDB replicate consists of:

• A mix of Hierarchical Direct Access Method (HDAM) and Hierarchical Indexed Direct Access Method (HIDAM) databases
• 32 databases
• 21 OSAM data sets

The MPP program in this workload on average makes 24 DB calls and 10 to 11 OSAM DB I/Os per transaction. The total number of OSAM data sets in this workload is 400.

The total CPU time spent per transaction^[1]:

• Using OSAM LDS was approximately 7% higher with an absolute difference of 21 microseconds versus using OSAM PS
• Using OSAM LDS with encryption enabled was approximately 4% higher with an absolute difference of 12 microseconds versus using OSAM LDS
• Using OSAM LDS with encryption enabled was approximately 11% higher with an absolute difference of 33 microseconds versus using OSAM PS

For comparison, the total CPU time spent per transaction using VSAM with encryption enabled was approximately 5% higher with an absolute difference of 20 microseconds versus using VSAM.

Figure 1 below compares the total CPU microseconds per transaction using the same application but with different database access methods (OSAM PS, OSAM LDS, OSAM LDS with encryption enabled, VSAM and VSAM with encryption enabled).

^[1] Total CPU time spent per transaction was calculated using the following formula: Total CPU time spent per transaction (in microseconds) = (Number of CPs * CPU % Busy * 1000000)/Transaction Rate

Figure 1: MPP total CPU time per transaction comparison

Table 1 below shows a similar CPU cost (total CPU time per transaction) comparison but in terms of absolute value increases for different database access methods. The numbers in parentheses show the additional time in microseconds between each database access method. OSAM PS starts out costing less per transaction as compared to VSAM.

Table 1: MPP total CPU time per transaction absolute value comparison

The absolute cost to go from non-encrypted OSAM LDS databases to encrypted OSAM LDS databases is actually less (an extra 12 µs per transaction) than the cost to encrypt VSAM databases (an extra 20 µs per transaction). However, OSAM LDS is a different I/O driver than OSAM PS, and there is additional CPU overhead to use the more generalized Media Manager interface. Even with additional CPU overhead, OSAM LDS with encryption enabled is still more efficient in terms of CPU usage per transaction compared to VSAM.

The transaction response time in the online workload was reduced by about 3% in OSAM LDS runs as compared to OSAM PS.

The online workload showed a 160KB decrease in DLI 24-bit LSQA storage going from OSAM PS to OSAM LDS with encryption enabled. It also demonstrated a 2MB increase in DLI 31-bit user private storage, which is under investigation. This blog will be updated if additional data becomes available.

Batch (BMP) workload

The batch workload runs an application executing 16 million total DB calls (91% read calls, 9% replace calls) against a 32-partition HALDB PHIDAM database with each partition 2GB in size. The BMP program has no business logic associated with it and it only executes DLI calls to stress the IMS database path. The performance was evaluated with Sequential Buffering (SB) enabled and disabled.

SB is an extension of the normal buffering technique used for OSAM database data sets. OSAM SB performs a sequential read of ten consecutive blocks with a single I/O operation, while the normal OSAM buffering method performs a random read of only one block with each I/O operation. SB can improve batch processing time for programs that are themselves inherently sequential (such as a program that reads through an entire database a record at a time).

The CPU cost of encrypting OSAM databases using the BMP workload was evaluated with SB enabled and disabled as described in the sections below.

BMP without Sequential Buffering:

The total CPU time spent per DB Call^[2]:

• Using OSAM LDS was approximately 17% higher with an absolute difference of 0.70 microseconds versus using OSAM PS
• Using OSAM LDS with encryption enabled was approximately 11% higher with an absolute difference of 0.52 microseconds versus using OSAM LDS

^[2] Total CPU time spent per DB call was calculated using the following formula: Total CPU time spent per DB call (in microseconds) = (Total IMS CPU time/Total number of DB calls) * 1000000

• Using OSAM LDS with encryption enabled was approximately 29% higher with an absolute difference of 1.23 microseconds versus using OSAM PS

For comparison, the total CPU time spent per DB call using VSAM with encryption enabled was approximately 8% higher with an absolute difference of 0.53 microseconds versus using VSAM.

Figure 2 compares the total CPU time spent per DB call without SB for OSAM PS, OSAM LDS, OSAM LDS with encryption enabled, VSAM and VSAM with encryption enabled.