We've just found out that as of the next z/OS release, the DIAGxx parm ALLOWUSERKEYCSA is being removed. This will mean that any program running in storage key 8 or above will no longer be able to allocate or update common storage - see https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/BCP_vsm-rsm_userkeyCA_v2r3.htm
We currently run IDMS and CICS in key(8), so will probably change IDMS to run in key(4). The issue we face is that we (1) have some home written code which runs in CICS but reads the IDMS ESE/ERE areas and (2) modify the IDMSINTL interface to both read and update the ERE extension.
Obviously this change is going to cause us some issues, and we're looking at ways round them. Has anyone else run across this situation, and if so what steps did you take to get round the storage key issues?. Running CICS in anything other than key(8) is a non-starter, and a lot of the code that's affected is old code that is thoroughly embedded in out application design, so a wholesale re-write is probably a sub-optimal solution.
Thanks in advance for any comments/suggestions.
BT IDMS DBA
I think you can run authorized like the old days, startup module, tckr, chkusr loaded from an authorized steplib.
The CV will be authorized to zap any storage key it wants to… A pain but it should work.
Andrew G. Daly
Senior Computer Scientist
988 San Felipe Avenue, San Bruno, CA USA
DXC | office: 650.615.0707 | mobile 650.339.2847 | email@example.com | www.dxc.technology
Yes, we've got that far, that process is fairly simple and well documented. Our issue is more that we used the fact that ESE/EREs were in ECSA storage to allow code running in CICS to update EREs. This was fine as long as CICS & IDMS were running in the same key. As CICS can only run in key(8) we face the issue where the code in CICS can no longer access the ESE/EREs. We were just curious as to whether anyone else out there had faced a similar issue.