IBM Information Management System (IMS) - Group home

Problem: the need for database encryption

I had already looked at the prior technique IBM® IMS™ supported for database encryption and decided it was too much coding. We use compression on almost every segment in every database. I had also read about a new z/OS® encryption technique and was hoping IMS support would soon follow.

Shortly thereafter, I read about the new IMS encryption technique using an OSAM (Overflow Sequential Access Method) LDS (Linear Data Sets). This type of encryption sounded promising.

It seemed straightforward from an IMS DBA perspective to set up this encryption. You unload an OSAM database and reload it into a VSAM cluster LDS using a few new IDCAMS keywords. It seemed like all the heavy lifting was done by z/OS.

If you have a database that needs extra security, but it’s not OSAM, convert to an OSAM LDS.

The experiment

I had always been curious about LDS: Db2® uses them as does DEDBs. I experimented with a complex full-function structure, an 8K HIDAM (not a HALDB) OSAM database. It has multiple data set groups, multiple secondary indices, sparse indices, dupdata, compression, and just about every IMS full-function feature except logical relationships: a little over 25 million segments with a dozen segment types.

I decided that because I am a performance-type person that I’d do the conversion in two steps.

This only works on IMS 15.2 or later.

Here are the steps I followed:

Step 1: Convert the database from OSAM to OSAM LDS and do primarily batch (DLI/DBB) testing.

Step 2: Convert from OSAM LDS to encrypted OSAM LDS and do full online performance testing. Again, the only difference in the unload/reload would be different IDCAMS parameters input to the cluster definition.

Cluster definitions

Here’s a quick look at one of the cluster definitions used to convert for Step 1 (LDS only, no encryption):

DEFINE CLUSTER -          

(NAME(A.B.LDSNOENC) -     

VOLUME(VPOL01) -          

CONTROLINTERVALSIZE(8192) -

SHAREOPTIONS(3 3) -       

CYLINDERS (999 999) -     

DATACLAS(STRIPED) - ß easiest way to get an extended format DS     

LINEAR)   ß indicates an LDS                

One item worthy of note is that z/OS encryption requires an extended format data set. Even though this test was for LDS only, I decided to add DATACLAS(STRIPED) because extended format data sets use an extra double word (8 bytes) at the beginning of each block/CI, and we wanted to know early on if there were any other surprises since we usually do not use extended format data sets.

Also, keep that extra 8 bytes in mind if you are close to the OSAM 4 or 8 GB limit (depending on block size).

The other parameter input to the IDCAMS cluster definition that actually invokes the encryption/decryption z/OS services is as follows:

KEYLABEL(OSAMTEST)   - this was set up using AES256 encryption

Only a z/OS systems programmer with superuser authority is able to configure a parameter like this in ICSF (Integrated Cryptographic Services Facility).

Another item worthy of note is that it's only the main data set groups, not primary or secondary index data sets, that get encrypted. All other data sets stay as they are. There are no changes to primary and secondary index cluster definitions.

More about the experiment: methods of conversion

I ran the conversion (simple unload/reload) three times by using: 

1. IMS standard utilities
2. IMS Tools speedy utilities
3. BMC Tools speedy utilities

All these worked just fine. The documentation had indicated that despite this odd situation of an OSAM access method being used against a VSAM cluster definition (LDS), it was unnecessary to change any OSAM buffer definitions at all. That turned out to be true, as I altered nothing at all, and everything worked. I ran some DLT0 jobs just to sequentially read through the entire database. Again, oddly, worthy of note, OSB (OSAM Sequential Buffering) continues to work in all cases with no changes.

Forget which databases are encrypted? Not a problem

One other useful tidbit is that if you did lose track of which databases are encrypted and which are not, in case you ever for some reason just wanted to convert to an LDS, you can just do a LISTCAT and look for the encryption flag to be set, or not set.

ENCRYPTIONDATA                  

  DATA SET ENCRYPTION-----(NO)

OR

ENCRYPTIONDATA                     

  DATA SET ENCRYPTION----(YES)      

  DATA SET KEY LABEL-----OSAMTEST ß AES256 as explained prior

It’s also quite secure—any attempt by a non-AUTH USERID to access the database is met by the usual RACF messages as follows:

ICH408I USER(TKSPG28 ) GROUP(GR#ADMN ) NAME(GANDOLFO,PAUL J     )

  OSAMTEST CL(CSFKEYS )                                          

IEC161I TKSPG12.ENCLDS.EQPMNTDP,,ICFCAT.TSO3                     

  INSUFFICIENT ACCESS AUTHORITY                                  

  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )                

Things we did not spend too much time testing

We did not spend much time testing Image copy, Recovery, Change Accumulation, or HALDBs. We do not have many HALDBs. All the basics above seemed to function with very minor clock/CPU increases.

We also did not encrypt our IMS OLDS but are aware of other data centers that did this, again, with little effect on clock/CPU performance, or day-to-day operations.

We have not yet implemented the IMS catalog or managed ACBs.

Let's see some stats

Here are some statistics that I reran under IMS 15.3 with details from the jobs that ran DLI (batch).

All jobs ran while the system was very lightly loaded. The call statistics are from the //DFSSTAT ddcards. Note the overhead of the conversion to LDS, and encryption itself are very small, likely negligible in most cases.

Where did the increases come from?

We needed to find something that could measure where the very small increase (mostly in SRB time) occurred. We tried STROBE and TMON (monitor for MVS). They showed nothing unusual whatsoever.

Further research confirmed that almost all current z/OS CECs (Central Electronic Complexes) these days include one or more crypto cards, and somehow, unlike the overhead involved with enclave switching to a zIIP or a zAAP, there is almost no CPU overhead involved with switching from a CPU to a crypto card, or back.

Enter the following command to see your crypto card information:

D ICSF,CARDS

CRYPTO EXPRESS6 COPROCESSOR 6C00                            

  STATUS=Active               SERIAL#=93AAAX77 LEVEL=6.7.18z

  REQUESTS=0000114718  ACTIVE=0000                              

CRYPTO EXPRESS6 COPROCESSOR 6C01                            

  STATUS=Active               SERIAL#=93AAAX20 LEVEL=6.7.18z

  REQUESTS=0000114711  ACTIVE=0000                              

We were now determined to find a way to measure this and also see if we could overwhelm the crypto cards with encrypt/decrypt processing. We activated the relatively new (no charge) feature called CPUMF/HIS (CPU Measurement Facility/Hardware Instruction Services) trace and reran many of my DLI-batch tests.

Explaining how to do this and how to interpret much of the returned data is beyond the scope of this blog, but suffice it to say, CPUMF/HIS counter number 77 (aka “AES CYCLE COUNT”) had  ever increasing hex digits in it while we did testing.

Next, I put the database online and proceeded to do more targeted performance testing, and also, exercise the database much more than was possible in pure batch (DLI). We have  extensive online MPP and BMP batch benchmarks with many concurrent updaters.

Concurrent with all the above IMS based activity, we also added a whole suite of “non-IMS” encryption/decryption activities such as encrypting/decrypting very large sequential files.  We actually had the overall CPU activity on this LPAR fairly busy. Once again, no surprises, and everything worked just as it had before with very little performance impact as in DLI/batch. We tried very hard to overwhelm the crypto cards but were unable to do so.

Minor bumps along the way and suggestions

We did encounter some minor issues as follows.

·      Our local DBAs were used to making very quick copies of our OSAM DBs using IEBGENER or even using the TSO 3.3 copy function. Nicety of OSAM.

• IEBGENER does not open any VSAM nor does TSO 3.3 copy. The DBAs would then generate the indices of those DBs using index build utilities, or quickly copy them as well using IDCAMS. To solve this problem, we incorporated the copy of the two “main” OSAM LDS involved into the existing IDCAMS copy of the indices.

·      You can no longer use the TSO/PDF/ISPF browse or view functions to look at or search a DB. 

• TSO doesn’t easily allow access to any VSAM. We have another 3PSW tool that does allow browsing and searching of VSAM.

·      In rare instances of problems with a DB, it used to be very easy to print a block or two of an OSAM DB. That is no longer the case.

• This does not happen very often, but sometimes you need a way to print a block of a DB. You might need to look at DB pointers, FSEs (Free Space Elements, etc.). Again, this rarely happens anymore, but it is no longer easy to do. We suggested to IBM IMS that some function be incorporated into one of the IMS Tools to do this. 

·      We asked IMS to incorporate a flag into all the IMS utilities (reorg tools, image copy, recovery, etc.) to indicate when a DB data set is encrypted. Stated another way, this encryption is so very transparent, and we thought over time it might be easy to lose track of which DB data sets were encrypted and which were not.

•  It would also be nice to have a flag in the applicable IMSPA (IMS Performance Analysis) reports, such as DBTRACE, denoting whether a DB is encrypted or not.

·      The 8 bytes extra prefix that extended format data sets add to every block is worth further investigation.

• We often use half-track blocking in non-IMS data set block sizes. We were surprised when some of the non-IMS data sets we used that we encrypted for the performance/stress tests doubled in size in terms of DASD tracks used. The extra 8 bytes put the data sets over the half-track block size.

·      Encrypted data sets are not compressible via hardware and some software services. 

• IBM recommends using access method compression. However linear data sets are not eligible for access method compression. This results in increased space usage for backups.

Our implementation

Despite all the good news above, we decided to implement very cautiously. Segment(s) that contained data that needed to be secured/encrypted would be incorporated into their own data set group, thereby limiting the amount of data within a DB that was encrypted. This is easy to do since OSAM LDS encryption occurs by data set, not by DBD.

Summary and conclusion

IBM and IMS have largely succeeded in developing a method of encryption that is very low overhead both CPU and clock time, transparent to the applications using the data, and very secure.

--------------------------

Paul Gandolfo has worked in IMS for over 40 years in various capacities (applications, DBA, IMS support, performance, etc.) and currently works at Ericsson and can be reached at Paul.Gandolfo@ericsson.com.