This topic applies only on the z/OS operating system.

GRS tuning tips for z/OS

WebSphere for z/OS uses GRS to communicate information between servers in a sysplex. When there are multiple servers defined in a system or a sysplex, a request may end up on the wrong server. To determine where the transaction is running WebSphere uses GRS. Therefore, if you are using global transactions, WebSphere will issue an enqueue for that transaction at the start of the transaction and hold on to that enqueue until the transaction ends. WebSphere for z/OS uses GRS enqueues for the following:

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

Avoid trouble: [aug2010] If you 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: If you have servers with duplicate cell names within the GRS environment, WebSphere Application Server 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. [aug2010]
aug2010
gotcha



Related reference
Tuning parameter hot list
Reference topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 11:08:29 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-mp&topic=rprf_tunezgrs
File name: rprf_tunezgrs.html