Suggestions from the "CICS TS for VSE" Service Team
Ingolf24 120000DRN3 Visits (662)
Today my colleague, Mike Poil, from the CICS service team want to give some suggestions to avoid CICS problems after a z/VSE upgrade.
The following suggestions are based on CICS PMRs that we have received, and from experience before joining IBM when I worked in a team that provided technical support for customers.
1. CICS Service Level
CICS is normally stable, but you can never say that it is completely bug-free. As previously mentioned in this blog, all CICS APARs are listed here, If a PTF is flagged as PE (PE = PTF in error - non-blank in the "Fixing APAR if PE" column), there is a BIG risk if it is applied but the fixing PTF is not applied. We don't have many PEs, but when they do occur, they normally have very high impact if you use that bit of CICS function.
I completely understand the "if it isn't broken don't fix it" argument, so this is not a recommendation to mass-apply CICS PTFs, but a z/VSE upgrade may result in a higher CICS service level. However, more than one customer has been caught out, because they were on an old z/VSE release and did not consider that a preventive service application policy may have merit when new function is being exploited.
2. Non-CICS Service Level
CICS is not immune from bugs in z/VSE and Vendor products. A z/VSE upgrade will make changes in both of these areas, hence both installed, avai
3. Code Cont
This is one of the hardest problems to diagnose as the symptoms are often very obscure and dramatic, and may hit one VSE system but not another.
It can happen when there are old CICS phases outside of PRD1.BASE that are pulled in and used to work before the upgrade but don't work now. Look for duplicated DFH phases and/or use an SDAID PGMLOAD trace when testing to check where each phase comes from.
In one case, a customer force applied very old PTFs and the damage was so extensive that they had to reinstall z/VSE. Always check the age and relevance of PTFs even if it is somebody in CICS Service that is giving you a suggestion or recommendation. For example, we are sometimes asked about problems such as "GETVIS leaks" and any suggested UQnnnnn PTFs for CICS bugs have been long since been integrated in the z/VSE base.
4. Testing an Upgrade
A couple of simple suggestions.
5. Matching Environments
Do Test and Production environments match in terms of data and file physical structures (e.g. level of VSAM disorganisation, VSAM catalog and data space fragmentation), IBM, Vendor and application code levels, z/VSE and product configuration and possibly even hardware (e.g. the same number of CPs)? If not, there is a risk. One high priority PMR for an unstable CICS production environment was the result of a different service level for one key product in test, which was not producing the problem seen in production..
Make sure that all CICS configuration done for the old CICS systems is repeated for the new one if you did not use FSU (Fast Service Upgrade). Try to keep a list of all configuration tasks, no matter how small, to avoid them being forgotten by you or by somebody else that does not know the system as well as you do.
6. Latent Application Errors
Although it is not that common, I have known application problems to be hidden until an upgrade, when something changed in the new environment to make them manifest.
Weekend is coming. Have a good one.