Welcome to the first LE z/VSE blog entry for 2014! I hope that everyone had a great break over the Xmas and New Year period.
In this entry I would like to discuss performance of COBOL/VSE applications that are executed within a created re-usable run-time environment. This might be done by your own applications team or perhaps a vendor product you have installed utilises this LE z/VSE functionality to perform some or even the majority of their processing.
For any relevant application that uses re-usable COBOL environments, especially when even a few or perhaps many different COBOL/VSE routines are called many times over again, performance becomes an important issue. Especially if new COBOL/VSE routines are added to the application and the number of iterations steadily increase as development progresses. When this situation starts to occur you need to start reviewing any possible CPU consumption savings you can find.
The most common performance issue experienced with LE z/VSE application created and utilised environments is the continuous creation and destruction of the entire supporting run-time environment. Having a small overhead to create and destroy a fully functional run-time environment is not an issue if performed only a few times. If for some reason that run-time environment is being frequently created and destroyed for each iteration of an application or routine, then this overhead is compounded many times, with application performance ultimately becoming seriously compromised.
So what is needed is that the application utilising re-usable run-time environments minimises the amount of overhead caused by management of the run-time environment. For the COBOL/VSE service most commonly used to perform this function - IGZERRE - there is an option available to control a significant portion of the run-time environment management overhead.
Supplied with all supported LE z/VSE releases is an option module - IGZERREO - that can be tailored to configure how the re-usable run-time environments condition handling functionality is performed. By default the older DOS/VS COBOL and VS/COBOL II behaviour is used. This means that between the last executed COBOL/VSE routine "GO BACK" and the invocation of the next COBOL/VSE routine the entire LE z/VSE condition handling environment will be destroyed and then re-created. For an application designed to use IGZERRE very infrequently this would not create much of an overhead. But, as you can probably imagine, for an application designed to call COBOL/VSE routines very frequently this behaviour would start to pose quite a considerable execution over-head.
Before changing the default behaviour we should discuss the behavioural differences that will occur. The benefit from using the default setting is that should the non-COBOL/VSE driver program (HLASM routine) experience a failure of some kind no LE z/VSE condition handling processing will be invoked. Only standard z/VSE processing will occur. For non-COBOL/VSE driver routines that perhaps do not follow standard s/390 linkage conventions or perhaps have their own designed condition handling behaviour this may be a preferred setting.
For non-COBOL/VSE driver routines that do not have such requirements changing from the default behaviour will mean that should the non-COBOL/VSE driver experience any failure LE z/VSE condition handling will be invoked. This will result in console messages CEE3321C or CEE3320C being issued and relevant LE z/VSE condition handling processing. The standard or default z/VSE failure processing will not be performed.
To modify the default behaviour for any applications using IGZERRE, supplied in your LE z/VSE installation library is JCL member IGZWARRE.Z. Tailor this member according to your systems configuration. Set the "REUSENV" option to "OPT" for optimised performance (LE z/VSE condition handling will process all failures). The "COMPAT" setting, also the default supplied setting, is for using condition handling behaviour which is compatible with the older DOS/VS COBOL and VS/COBOL II re-usable run-time environment processing.
In this IGZWARRE.Z member there is also the "WARNMSGLMT" option. This option allows tailoring of how many repeated COBOL warning messages in a single enclave will be issued before the messages are stopped. At which point message IGZ0041W will be issued indicating that the number of warning messages issued has reached the limit. The "WARNMSGLMT" option allows the changing of the default value of 256. You can change this value to any positive whole number between 1 and 256.
When tailoring of the IGZWARRE.Z member is complete simply submit the JCL member to your z/VSE system and the new option settings for COBOL re-useable IGZERRE run-time environments and message warning limit will be set. No re-IPL is required. For CICS, the IGZERRE service is not available but if you want the WARNMSGLMT setting activated you will need to perform a COLD restart of the affected CICS systems to activate the setting. It is not possible to simply "newcopy" or reload the updated IGZERREO options module under CICS.