Execution Group Specific ENVFILEs
RandyMiller 1000007D5Q Visits (2271)
Have you explored the benefits of using Execution Group (EG) specific ENVFILEs on your WebSphere Message Broker (WMB) running on zOS yet? I am often surprised to learn that some people are unaware of this capability despite it having been available for some time now.
Originating from client requests, support of EG specific environments has been in place since the availability of WMB V220.127.116.11 and has been continued with all additional V7 and V8 releases to date. This capability does not exist in the V6.1 broker on zOS.
So what is it and when can it be beneficial?
EG specific ENVFILEs allow one or more EGs to have their own unique runtime environment. This allows the ability to effectively tune an EG based upon it's specific workload. Before this function was provided, all EGs used the same ENVFILE of the parent process (main task). So in that case making a change to a specific environment variable for the benefit of one EG could cause undesirable effects to one or more of the remaining EGs. Once an EG specific ENVFILE is configured, the EG uses the parent ENVFILE as the default environment but then adds to, or overrides, any variables which are defined in the environment variable for the main task.
This can be highly useful when IBM Support makes tuning recommendations based upon analysis of traces, dumps, etc. This also facilitates tuning efforts by enabling IBM support to collect various sets of component level statistics for a specific EG versus having to enable this for all EGs.
Any environment variable used on a V7 or V8 broker can be overridden by specifying the same variable with a different value in the EG specific environment file.
Some of the more commonly overridden variables include:
TZ - Timezone _CEE_RUNOPTS - LE Runtime options IBM_JAVA_OPTIONS - JVM options CLASSPATH - Classpath loading MQSI_UTILITY_TRACE - Tracing of some of the mqsi* executables
Setting up an EG specific environment is really quite simple.
First, take a copy of BIPEPROF and rename the copy of the file to be the same as the execution group label in the component dataset, using the following rule:
The name should equal the last eight characters of the execution group label. Also, any characters that are not valid for a STEPNAME are replaced with the @ character. Furthermore, if the first character of a STEPNAME is not an alphabetic character, that character is replaced with an A.
So for example, an execution group address space with the label 'TestEGroup', will need an execution group specific profile called STEGROUP. This may seem a bit odd but it provides the best chance for creating unique names. Here's a screenshot showing the setup for my execution group labeled 'TEST1EG'.
Next, you will create a step in the BIPGEN member to point to the new TEST1EG member.
Now when BIPGEN is run, it will locate the added step and call BIPEGEN which in turn builds an environment file called ENVFILE.TEST1EG. This is the ENVFILE that EG TEST1EG will use when initializing it's environment during startup.
A quick check of this ENVFILE shows that the new LE runtime options are now specified.
You can easily determine which EGs are running with their own customized ENVFILE by viewing the PROCSTEP on the SDSF.DA screen. A label of EGENV in the procstep denotes that an EG specific ENVFILE was detected and is being used.
That's all there is to it! Please keep this capability in mind should you have a case where you need to customize one or more of your EG environments.
For additional information related to setting up EG specific environments have a look at section "Creating an execution group specific environment file" in the information center.