This document covers the following topics:
A Natural Subprogram Server is a multi-user, multi-tasking application. It can host Natural sessions for multiple users and execute their requests concurrently.
The concept is based on the "serverized" Natural runtime system. Its architecture
comprises a server front-end stub (NATRNPI subprogram server stub) that
uses the Natural front-end to dispatch Natural sessions and to execute subprograms
within these sessions.
The architecture basically consists of:
The NATRNPI stub is launched to initialize a Natural Subprogram
Server. It listens for incoming requests and initializes a Natural session for
executing the subprogram.
The front-end is called (together with the Natural runtime system) by the front-end stub for session initialization/termination and request execution.
The NATGWNPI module provides for interaction between the Natural
runtime system and the front-end stub. NATGWNPI is already included in
the Natural nucleus and is called by the Natural runtime system to exchange the
necessary request data.
Natural driver
Natural is driven by the Natural Driver, NATOS /
NATOSL.
Note
NATOSL is an extension of NATOS that supports IBM's Language Environment (LE).
LE allows different programming languages to be used within a single application.
Because the server is implemented in C and requires LE, the Natural front end must
always include both NATOS and NATOSL.
A monitor task allows the administrator to control the server activities and to terminate the entire server, etc.
NATRNPI is a multi-user and multi-tasking front-end stub, and it is launched to initialize a Natural Subprogram Server.
This document covers the following topics:
The task executing the server initialization, TMain, is the main listener which
waits for incoming requests from the Natural OpenAPI Server. It owns a session
directory to manage multiple clients (users) and their corresponding remote Natural
sessions. TMain has the task to accept all incoming requests and to
dispatch them to other subtasks (TWork). The process is as follows:
First, the Natural OpenAPI Server connects to TMain to establish a connection.
Next, TMain inserts the client into its session directory, attaches a new
TWork subtask, and passes the connection to TWork.
TWork initializes a new Natural session, processes the request, replies the result
to the client, terminates the Natural session, and terminates itself.
Each request is stateless. For each request, a separate Natural session is started. However, the session initialization is accelerated by cloning new sessions from a master session. At server initialization, a master session is initialized and kept in a user-independent state. For a new session, the master is just copied and connected with the user-ID of the request.
It is expensive to create a new worker task for each request. It is possible to keep created workers in a pool to reuse them for successive requests. If the configuration variable WORKER_DELAY is set to a value greater than zero, a worker waits after request execution for the defined time in seconds. The worker pool automatically adjusts its size based on the server’s workload. When there are many parallel requests, the pool grows to handle the increased load. As the workload decreases, the pool shrinks accordingly.
Within a Natural OpenAPI Server session, the following Natural system variables are used:
*TPSYS contains SERVSTUB.
*DEVICE contains BATCH.
*SERVER-TYPE contains CALLNAT.
The called subprogram must not do any screen-io. If a screen-io happens, the server dumps the content of the screen to its trace file and cancels the screen-io.
The Natural front-end required for a Natural Subprogram Server is a Natural batch front-end driver, which should be LE enabled. See sample installation jobs for details.
The NATGWNPI gateway module is already included in the Natural nucleus.
To enable the administrator to monitor the status of the Natural Subprogram Server, a monitor task is provided and is automatically initialized at server startup. Using the monitor commands, the administrator can control the server activities, terminate the entire server, etc. For more information, see Natural API Server > Natural Subprogram Server on z/OS > Operation > Monitoring the Natural API Server > Monitor Communication.
The following graphic illustrates the interaction of the Natural OpenAPI Server with a Natural Subprogram Server.
Natural OpenAPI Server (the client) gets a REST call. It converts it into a proprietary protocol and sends it to the Natural Subprogram Server using the port number specified with the Natural OpenAPI Server.
The Natural Subprogram Server initializes (clones) a Natural session using the Natural front-end
you have specified with FRONTEND_NAME, the Natural Subprogram
Server configuration parameter. In this example is NATOS.
