IBM Support

Wonder why WebSphere Application Server address spaces on zOS won't start sometimes with V WLM, RESUME?

Technical Blog Post


Abstract

Wonder why WebSphere Application Server address spaces on zOS won't start sometimes with V WLM, RESUME?

Body

 

In a WebSphere Application Server zOS environment, workload management stops the creation of new server address spaces when one of the following conditions exist:

 

  • JCL errors in the procedure associated with the application environment
  • Coding errors in the server code which cause five unexpected terminations of server address spaces within ten minutes
  • Failure of the server address space to connect to workload management due to an invalid invocation environment or invalid parameters

 

The application environment first enters the STOPPING state, then the STOPPED state after all systems in the sysplex have accepted the action.

 

In STOPPED state, no new servers are created. Any existing server address spaces continue to process work, and workload management is able to accept new work. If there are no existing servers, then workload management rejects any new work requests.

 

 

The STOPPED dynamic application environment of the WebSphere Application Server can be started by issuing the VARY WLM RESUME console command.

 

 

RESUME
Restart the server address spaces for an application environment that was previously quiesced, or was stopped by workload management when it detected an error condition (RESUME).

 

 

Now this doesn't start the WebSphere address spaces if there is no new work queued to this application environment.

 

 

You will need to issue the WLM QUIESCE and then RESUME for the application environment which in turn causes WLM to start the Application Server address spaces.

 

 

WLM mechanics on why this happens..
When an application environment is in the STOPPED state and a RESUME is issued, the application environment block (AEB), TEB and SEASs are all freed so that the application environment can start fresh since the reason for the stopped state is unknown. When work is inserted into the queue (with QINS), the control blocks are rebuilt and application environment servers are started. In other words, in a {stopped->resume} state, a new server is not started until it is needed which is detected with a QINS.  A new QINS for that Application Environment will allow a server to be started and you will see the IWM034I procedure started message.

 

 

Also, the MVS Planning: Workload Management manual (SA22-7602-18) also specifies the following to reiterate and confirm the logic.
Note: If you want to ensure all servers are restarted after a STOPPED state, especially after the JCL procedure or libraries have been modified, you should issue a quiesce function prior to the resume.
This ensures there are no servers remaining active that are using back-level information.

 

 

Many thanks to Dianne Gamarra from WLM for her invaluable insight on this behavior.

 

 

 

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"","label":""}}]

UID

ibm11080591