How Processing Works

Each user online session does not directly invoke the  API. Instead, it writes an API request to the message queue file. The API request is read from the message queue file by a started task that is referred to as the server. Integration for the Natural Environment operates in a client/server fashion to provide an interface between user online sessions and . Requests are processed in the following manner:
ce18
Each user online session does not directly invoke the 
CA Endevor
 API. Instead, it writes an API request to the message queue file. The API request is read from the message queue file by a started task that is referred to as the server.
CA Endevor
 Integration for the Natural Environment operates in a client/server fashion to provide an interface between user online sessions and 
CA Endevor
. Requests are processed in the following manner:
  • The server submits the API request to 
    CA Endevor
    , receives the API response, and writes it to the message queue.
  • The user online session reads the API response from the message queue and provides appropriate output to the user. The following flowchart shows how user online session requests are processed in 
    CA Endevor
     Integration for the Natural Environment.
How the Natural Interface processes requests
How the Natural Interface processes requests
Servers and Session Response Times
Each server started task is a single-threaded processor. For multi-threaded processing, multiple servers can be configured and run simultaneously. The optimal number of servers that are required at a site depends on the number of users and the frequency with which they simultaneously run 
CA Endevor
 Integration for the Natural Environment online sessions.
The server is a stateless server, meaning that it treats each request as an independent transaction that is unrelated to any previous request. Each request is processed on a first-in-first-out basis without regard to which user submitted it. Due to the nature of the server processing, a dedicated server task is not required for each user.
A single server has no limit to the number of supported users. If 100 users are running concurrent sessions, all of their list requests and action requests are processed. However, users do experience a relatively slower response to their requests than if the concurrent sessions were fewer in number. The response time can vary widely from minute to minute, depending upon whether requests are submitted simultaneously. For example, one user's request is unaffected by 100 other request submissions, so long as the submissions are not simultaneous. In this case, it is as if each user has the server all to themselves.
You may want to improve session response times if:
  • Your site has multiple concurrent users who believe that their response time is unacceptably slow.
  • A review of the server logs shows that many requests are regularly processed in close succession during certain times (suggesting that multiple requests are often simultaneously queued up). 
To improve the session response times, you can alter the class or priority of the server task, add more server tasks, or both.
Administrators can change the server and API timeout values in the startup user exit, UEXIT00. The timeout values limit the time for the server to begin processing a request and for the API to complete processing of the request. If the timeout intervals are exceeded, the user regains control and can continue to wait for the request to complete or return to 
CA Endevor
 Integration for the Natural Environment. If the user chooses not to wait for the request to complete, the request continues to be processed. A request sent to the API cannot be terminated. All records associated with the request are automatically cleared from the message queue file at a later time.
Server Operational Guidelines
The following guidelines apply to operating the 
CA Endevor
 Integration for the Natural Environment Server:
  • Although the server can be run as a long-running batch job, the server typically runs as a z/OS started task.
  • There is no need to periodically shut down the server unless Adabas requires shut down.
  • Before starting a server, ensure Adabas is up and running.
  • If Adabas is shut down while the server is up, the server should be shut down and restarted after Adabas comes back up.
How to Startup the Server
If configured as a started task, start the server using the S command and the server name.
Example: Server Startup Command
A server named CASCMMN1 is started with the following operator command:
S CASCMMN1
How to Shutdown the Server
To shut down a server, submit its corresponding shutdown task (or batch job).
Example: Server Shutdown Command
If a server task has a corresponding shutdown task named CASCMSTP, then the shutdown task is started with the following operator command:
S CASCMSTP
Server Logs
You can review startup and API transaction information in the following server logs.
Server Startup Log
At startup time, the server writes startup information to data set CMPRT25, which may be useful in diagnosing configuration problems. This output includes a report on all site symbolics as extracted from the EN$TROPT report.
API Transaction Log
The server writes a summary of all API transactions processed to data set CMPRT01.
Example: API Transaction Log - CMPRT01
*** 2006-11-17 10:57:31.5 *** API function: EADQ ; User: MXJ1 ; Return code: 0000 ; Reason: 0000 ; Hi Msg ID: AP00000I *** Request ID: D4E7D1F1404040400633308936805F * *** 2006-11-17 11:07:34.6 *** API function: LELQ ; User: MXJ1 ; Return code: 0000 ; Reason: 0000 ; Hi Msg ID: AP00000I *** Request ID: D4E7D1F1404040400633308944507F