WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

624 WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

JOBNAMES *NOT SUPPORTED*

OPTIONS MINIMUM

WRITER *NONE*

As in previous releases, you can set up an error log using the coupling facility or using a

DASD-only log stream for a single WebSphere Application Server or shared error log for

several servers. If you decide to use the feature, use a coupling facility log stream that is

shareable across the sysplex.

You can view the error log records using the log browse utility (BBORBLOG) located in the

/WAS_product_image_path/util/zos/EXEC/ directory.

For more information about using BBORBLOG EXEC, go to the following website:

http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.webspher

e.zseries.doc%2Fae%2Frprf_tuneztrace.html

If you are using Transaction XA partner logs or SIP recovery log streams, use coupling facility

log streams. For more information, go to the following website:

http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.webspher

e.installation.zseries.doc%2Fae%2Fcins_logstrm.html

For information about JDBC tracing, go to the following website:

http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.webspher

e.nd.multiplatform.doc%2Fae%2Frtrb_jdbccomp.html

For internal tracing tips, go to the following website:

http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.webspher

e.nd.multiplatform.doc%2Fae%2Frprf_tuneztrace.html

17.10 Tuning workload management on z/OS systems

This section discusses the tailoring needs and benefits of workload management on z/OS

systems in conjunction with WebSphere Application Server.

17.10.1 The concept of workload management on z/OS systems

Workload management consists of categorizing, prioritizing, routing, and reporting on

requests. On z/OS systems, the Workload Manager (WLM), which is an operating system

component, allows the system programmer to configure the rules that are used to differentiate

and organize units of work. When classified, WLM can determine the service level agreement

(SLA) for this type of work. WLM then assigns system resources to units of work from that

workload, making a best attempt to allow all work to meet the specified goals. Less important

work is sacrificed to meet the goals of more important work if necessary.

Chapter 17. Performance tuning 625

WebSphere Application Server for z/OS uses this facility for workload classification by default.

It uses a controller-servant region mechanism and can run several instances of servant

regions for a single WebSphere Application Server, called a

dynamic servant region

expansion

. WLM manages these servant instances in a dynamic application environment.

The instances are started as dictated by workload within the guidelines of the WLM MIN/MAX

SERVANT parameters. WLM then routes work to the appropriate servant based on the

classification rules. It also uses sophisticated algorithms to choose the best candidate if

multiple servants are bound for the same service class.

All application work that runs inside WebSphere Application Server runs under

WLM-managed enclaves. Proper WLM goals can significantly affect application throughput.

To allow servants to start in parallel, use the wlm_servant_start_parallel custom property.

For more complex scenarios and to understand the overall workload goals in your

organization, consult with your WLM systems programmer.

For more information about WebSphere Application Server and the z/OS WLM, go to the

following website:

http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.webspher

e.nd.multiplatform.doc%2Fae%2Ftrun_wlm.html

17.10.2 Classification rules

The work priority of location service daemons and controllers must be higher than the priority

for servants. Work inside controllers and daemons is categorized based on started task

control (STC) classification rules, where a servant’s classification is more complex.

The WebSphere Application Server’s servant lifecycle with WLM includes the following

phases:

 The start phase before the servant is bound to a service class queue

 The initialized phase after the servant is bound to a service class queue

During the first phase, the servant is guided by the STC classification rules, which are most

likely of the velocity type. During the second phase, application work runs in enclaves that are

guided by CBtype classification rules. Specify achievable response time goals with a

percentile here. You can also classify work using the collection name of the cluster. WLM

performs better with less service classes.

Velocity™ goals for application work are not meaningful and must be avoided.

If running in multi-instanced servant environment, use WLM classification and define unique

service classes for different priority work that is running in the same server. Also be sure to

allow for at least one servant per unique service class.

For more information about controlling WLM dynamic application environment, go to the

following website:

hhttp://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphe

re.nd.multiplatform.doc%2Fae%2Fcontainer_data_concepts.html

Using non-enclave threads: z/OS V1.12 introduced a parameter to bind non-enclave

threads to the goals of the STC service class for the life of the servant. This IEAOPTxx

parmlib member parameter is called MANAGENONENCLAVEWORK. It applies to

supporting tasks (such as garbage collection threads) inside the servant. It can be set

dynamically, and WLM policy is refreshed as part of the SET OPT=xx command.