IBM Information Management System (IMS) - Group home

Assessing IBM® IMS™ OSAM encryption performance

By JASDEEP SINGH posted Thu January 21, 2021 12:31 PM

  

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 specific to IMS only. 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 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.

 

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.

·       Data Set Type

·       Total CPU time per transaction (microseconds)

·       OSAM PS

·       300

·       OSAM LDS

·       321 (+21)

·       OSAM LDS with Encryption

·       333 (+12)

·       VSAM

·       397

·       VSAM with Encryption

·       417 (+20)

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.

Figure 2: BMP total CPU time per DB call comparison without SB

Table 2 shows the absolute cost to encrypt OSAM and VSAM database access methods. The numbers in parentheses show the additional time in microseconds between each database access method. Similar to the online workload results, OSAM PS starts out costing less per DB call as compared to VSAM.

·       Data Set Type

·       Total CPU time per DB call (microseconds)

·       OSAM PS

·       4.24

·       OSAM LDS

·       4.95 (+0.70)

·       OSAM LDS with Encryption

·       5.47 (+0.52)

·       VSAM

·       6.94

·       VSAM with Encryption

·       7.47 (+0.53)

Table 2: Total CPU time per DB call absolute value comparison

The batch workload without SB demonstrated a reduction in elapsed time going from OSAM PS to OSAM LDS or OSAM LDS with encryption enabled in the range of 28% (with zHPF enabled). This could significantly help reduce the batch window time in customer shops.

Figure 3 compares the elapsed time without SB for OSAM PS, OSAM LDS, OSAM LDS with encryption enabled, VSAM and VSAM with encryption enabled.


Figure 3: BMP Elapsed time comparison without SB

BMP with Sequential Buffering:

 

The total CPU time spent per DB Call:

 

  • Using OSAM LDS was approximately 2% higher with an absolute difference of 0.05 microseconds versus using OSAM PS
  • Using OSAM LDS with encryption enabled was approximately 17% higher with an absolute difference of 0.62 microseconds versus using OSAM LDS
  • Using OSAM LDS with encryption enabled was approximately 18% higher with an absolute difference of 0.67 microseconds versus using OSAM PS

Figure 4 compares the total CPU time spent per DB call with SB for OSAM PS, OSAM LDS and OSAM LDS with encryption enabled. SB is applicable to OSAM access only, hence no comparison data with VSAM.


Figure 4: BMP total CPU microseconds per DB call Comparison with SB

Table 3 compares the CPU cost in terms of increase in absolute values for different database access methods.

·       Data Set Type

·       Total CPU time per DB call (microseconds)

·       OSAM PS

·       3.69

·       OSAM LDS

·       3.75 (+0.05)

·       OSAM LDS with Encryption

·       4.37 (+0.62)

Table 3: Total CPU time per DB call absolute value comparison

Using SB with the BMP workload also significantly reduces elapsed time, and OSAM LDS reduces it even further, again helping reduce the time needed for batch window processing

Figure 5 compares the elapsed time with SB for OSAM PS, OSAM LDS, OSAM LDS with encryption enabled.


Figure 5: BMP Elapsed time comparison with SB

zHPF Disabled Data:

To evaluate the benefits of zHPF, additional tests were done with zHPF disabled for comparison.

The online workload did not show any noticeable performance differences with zHPF enabled or disabled.

The batch workload demonstrated the following elapsed time savings with zHPF enabled compared to zHPF disabled:

  • 30% for OSAM LDS without SB
  • 29% for OSAM LDS with SB

Figure 6 compares the batch workload elapsed times comparison for OSAM LDS with and without zHPF.


Figure 6: BMP Elapsed time comparison with and without zHPF

Figure 7 compares the Total CPU time per DB call with and without zHPF. The CPU cost per DB call differences were within noise range with zHPF enabled or disabled.


Figure 7: BMP total CPU time per DB call comparison with and without zHPF

Summary

 

Our performance evaluations show while there is a CPU overhead associated with changing from OSAM PS data sets to OSAM LDS, the new OSAM LDS database access method continues to provide a high-performance alternative to VSAM databases, while also allowing you to protect your data with encryption.  Additionally, for batch workloads, OSAM LDS databases demonstrated a significant reduction in elapsed time processing, especially when combined with sequential buffering and zHPF.