(ZOS) Tune GRS when using global transactions in z/OS

WebSphere Application Server for z/OS uses global resource serialization (GRS) to communicate information between servers in a sysplex. When there are multiple servers defined in a system or a sysplex, a request might end up on the wrong server. WAS for z/OS uses GRS to determine where the transaction is running.

If we are using global transactions, WAS for z/OS issues an enqueue for a transaction when the transaction starts and holds on to that enqueue until the transaction ends.

WAS for z/OS uses GRS enqueues in the following situations:

• Two-phase commit transactions involving more than one server
• HTTP sessions in memory
• Stateful EJBs
• "Sticky" transactions to keep track of pseudo-conversational states.

If we are not in a sysplex, we should configure GRS=NONE, or if you are in a sysplex, we should configure GRS=STAR.

This requires configuring GRS to use the coupling facility. All of the WAS enqueues are issued with RNL=NO, which prevents misconfiguring the GRSRNLxx with inappropriate values. See the GRS documentation for details on setting this up.

If we are using a GRS ring to attach one or more monoplexes to a sysplex environment, the cell name of any servers running in any of the monoplexes must be unique within the entire GRS environment. This requirement means that the cell name of a server running in any of the monoplexes:

• Must be different from the cell name of any servers running in the sysplex
• Must be different from the cell name of any servers running in another monoplex that is attached to the sysplex

If we have servers with duplicate cell names within the GRS environment, WAS for z/OS cannot differentiate between the sysplex cell and the monoplex cell, and treats both servers as part of the same cell. This inaccurate cell association typically causes unpredictable processing results.

Tasks

• If we are not in a sysplex, configure GRS=NONE.

• If we are in a sysplex, configure GRS=STAR.

Tuning parameter hot list