IN FOCUSWhat a Service Execution Process actually does
A Service Execution Process (SEP) runs application code inside an Enterprise Server region. After completing a request it becomes available for another; when every SEP is busy, incoming requests wait. The manuals explain both the execution path and the operational consequences of changing this capacity. [1] [2]
Read the full briefing
A process with four cooperating components
The SEP brings together an application container, a transaction-management component, a request handler, and a resource-manager interface. The container is the COBOL runtime adapted for Enterprise Server. For container-managed services, the transaction component coordinates COMMITs and ROLLBACKs. The request handler decodes incoming requests and formats output for the client; the resource-manager interface handles access to resources such as databases and files. The cited page describes handlers for SOAP and the Micro Focus Binary Protocol, including configurable user exits for the SOAP request handler. [1]
Follow a request through the region
In the processing path described by the manual, the region’s communications manager receives the client request and queues it in shared memory for scheduling. An available SEP calls the application container, which invokes a request handler. That handler uses mapping information created by the Interface Mapping Toolkit to translate request parameters into the COBOL application’s call interface. After the application finishes, the container calls the handler to format the output, then passes the response to the communications manager for delivery to the client. [1]
Concurrency has a persistence detail
The 12.0 manual states that a newly created region contains two SEPs. A SEP becomes available again after returning a response; if all are occupied, requests wait. The optimum SEP count depends on workload variables, and the manual advises experimentation. It also distinguishes a live adjustment from the configured value: changing the count while the server runs lasts only until the server stops. The count then returns to the value specified when the server was added or its details were edited. [2]
“If all the SEPs are busy handling requests, incoming requests must wait for one to become free.” [2]
Read monitoring figures as a changing snapshot
The TranClass Status page displays registered and available SEP counts, pending requests, and tables for active SEPs, available SEPs, and queued requests. These are monitoring observations. The manual explicitly warns that transaction state can change while the display is being acquired: a pending transaction may be assigned to a SEP, or a transaction may complete. Transactions are not locked for this monitoring operation, to minimize its processing overhead. Consequently, the displayed information can be incomplete; an individual snapshot should be interpreted with that documented consistency caveat. [3]