Exploit z/OS specific features to minimise impact of Java security changes to JCE RACF keystores

Why:
Following implementation of OSB 8181692, the KeyProtector.java function increased the number of times that keystore data is encrypted from from 20 to 200,000 times.

This had the effect of significantly increasing the cost when retrieving the keystore data.

In our applications this had the effect of increasing the transaction cost by up to 60 times the cost prior to the change.

What:
The option to choose where the keystore data is accessed from, when the original data held in a RACF keyring, may improve the response time to retrieve the decrypted keystore data plus reduce any impact from security driven changes in Java that may affect performance, both in terms of cost (which may be somewhat mitigated with the use of specialty processors) and response times (which is not mitigated by the use of specialty processors).

RACF is a highly optimised and secure database and which is highly responsive and scales for 10's of thousands of users.

If it were possible to choose to access the relevant keystore data directly from RACF each time it was required to be decrypted, there would be several benefits:
1) To exploit z/OS specific features for their designed purpose, which potentially reduces the impact from changes driven by the Java world.
2) Potentially (to be measured) improve the response time of decrypting the keystore data at the time it is required to be accessed in the clear.