Ivica Loncar's List: zos

• The Rational Developer for System z UT hosts the actual z/OS operating system on an x86-based Linux platform. Rational Developer for System z UT also comes packaged with a preconfigured set of "typical" IBM z/OS software solutions which you are entitled to use only for development and test activities in the Rational Developer for System z UT environment.
• z/OS V1.10 and V1.11, including sub-features
• WebSphere Application Server for z/OS V7.0

1 more annotation...

• using any of these without passing a Charset is suspicious
• The plugin is available for download here: https://github.com/rewbs/DefaultEncodingDetector/archives/master

• Java™ can provide a simple way to submit z/OS® batch jobs to run -- but that is just the beginning. You can also use Java, from any platform, to check on the status of your z/OS batch jobs. This article is a follow-on to developerWorks article, Submit batch jobs from Java on z/OS.

• You can classify incoming HTTP, IIOP, and message-driven bean work requests with different service classes using an XML workload classification document, and assign XML file transaction classes (TCLASS) to the incoming requests. The TCLASS value will be passed to the WLM, which will ultimately associate the TCLASS to a service class and to a report class, if specified.

     

  See the WebSphere Application Server V6.1 Information Center for guidance on  using the XML workload classification document and classifying in the WLM.
• Be aware that not all Web applications are able to use URI-based classification. Examples of such applications are those that use frameworks such as Struts, Ajax, and so on, where the URLs requested from the client would be identical for different kinds of requests. These types of applications prevent you from classifying different business transactions based on URI.
• WebSphere Application Server is designed to process a large number of parallel short-time tasks, and work queues and thread pools are two components that are used often to handle parallel workload.
• Across all platforms, WebSphere Application Server implements a thread pool to process requests from clients. WebSphere Application Server for z/OS combines a work queue mechanism with the thread pool to serve the client requests. The control region of WebSphere Application Server for z/OS inserts requests into the work queues associated with servant regions, which then select requests from the bound work queues and process in the thread pools inside.
• By default, a J2EE server on z/OS has one servant region. In this scenario, the servant region does not bind to any specific service class, which means all work requests will be selected by the single servant region and get serviced there. However, if a performance bottleneck occurs that could be alleviated by using multiple servant regions, the WLM will not be able to start additional servant regions because the multiple servant region feature is not enabled. Thus, such an application server environment with a single servant region is called an “unmanaged” application environment.
• In this scenario, all requests with different service classes will all be executed in the servant region concurrently. Within the servant region, the worker thread (TCB) will be running with the service class of the enclave representing the requests.
• at any given time, any servant region will only bind to a single specific service class work queue and select requests from there.
• f WLM can start a new servant region (because the maximum number of servant regions has not already been reached), then it will. WLM does not simply convert any servant region from CBDEF to CBHI; it will only convert a servant region’s bound service class work queue to another one when it has no other choices (for example, if the number of current servant regions reaches the servant region maximum limitation).
• In general, do not classify WebSphere Application Server applications into  more service classes than the maximum number of servant regions.
• As mentioned earlier, WebSphere Application Server for z/OS has a thread pool inside each servant region to serve the client requests. This thread pool management is a bit different from distributed versions of WebSphere Application Server.
• When a request comes in, the WebSphere Application Server control region receives the request from the network and creates an enclave to represent the request. Before the request is processed by the servant region, it’s put inside the WLM work queue. Unlike distributed WebSphere Application Server, WebSphere Application Server for z/OS does not need to use the threads to hold the requests, using the WLM queue as the placeholder instead.
• For a distributed WebSphere Application Server system handling relatively high stress workload, you might need a larger number of threads to hold the client requests; the system overhead will be higher because of intensive context switch. At this point, WebSphere Application Server for z/OS gives you much easier management for the thread number. You only need to set a proper number of worker threads for workload execution, without having to consider the number of client requests.
• In WebSphere Application Server, request processing is performed on a worker thread. Large system benchmarking has shown that for an application that is well designed and implemented, having a number of worker threads that is two to three times the number of the CPUs can saturate the processor resource of the LPAR. Depending on the nature of the application workload, you can indirectly control the number of threads in the servant region using the administrative console

• In the WebSphere Application Server admin console, you can set these workload profiles:

     
   
  • ISOLATE: 1 thread
   
  • CPUBOUND: (number of CPUs - 1), minimum value = 3
   
  • IOBOUND: (number of CPUs * 3), minimum = 5, maximum = 30; this is the default profile for a server.
   
  • LONGWAIT: 40
• For some applications that will have the worker thread suspended for a long wait remote call to outside systems, such as ERP, CRM, or some legacy applications, you will definitely need more threads to improve system utilization and overall throughput by concurrently serving more requests. For such applications, LONGWAIT is an appropriate setting which, by default, results in 40 threads.

13 more annotations...

• In WAS for z/OS, the Control Region Adjunct (CRA) is activated in every bus member application server. The CRA is a new address space introduced in WAS for z/OS V6. It's the special servant region in which a messaging engine of the SIBus runs.
• Messaging Engines: The messaging engine is the component providing the core messaging functionality inside the application server. As mentioned above, it runs in the CRA. Conceptually the messaging engine is equivalent to a queue manager in WebSphere MQ. Messaging engines can communicate with each other. But the intercommunication is different from WebSphere MQ's. Once the messaging engines are defined in a bus, the intercommunication is implicit without explicit configuration.