This document describes the concept and the architecture of the Natural Development Server (product code NDV) which is designed for use under SMARTS on BS2000.
The following topics are covered:
A Natural Development 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 (development server
stub NATRDEVS) that uses the Natural front-end to dispatch Natural
sessions and to execute functionality within these sessions.
The Natural remote development server architecture basically consists of:
SMARTS is used to implement a server runtime environment for the execution of the NDV server.
The stub NATRDEVS is launched to initialize a Natural
Development Server. It listens for incoming transactions and dispatches the
appropriate Natural session for executing the transaction.
The module NATGWSTG provides for interaction between the
Natural runtime system and the front-end stub. NATGWSTG is already
included in the Natural nucleus and is called by the Natural runtime system to
exchange the necessary request data.
Transaction processors are called by the front-end stub. The application logic of each individual transaction is implemented within a transaction processor.
Natural Driver
Natural is driven by the Natural Com-plete interface
NCF-SERV.
A monitor task allows the administrator to control the server activities, to cancel particular user sessions or to terminate the entire server, etc.
SMARTS is an acronym for "Software AG Multi-Architecture Runtime System". It constitutes a runtime layer that allows POSIX-like applications to run on mainframe operating systems. Software AG products communicate with the operating system through the SMARTS layer.
SMARTS implements a server runtime environment for the execution of the NDV server. Technically, SMARTS represents a C runtime system and implements a nearly full-blown POSIX system. It drives a family of tasks which either process dedicated functionality or process the application payload in parallel-executed worker tasks. The tasks with a dedicated functionality are the main or oc task, the system thread loop task (started as second task), the socket communication task, the pfs task and the sequential file IO task. The pfs task is optional; it processes all IO operations on the POSIX file system (PFS). The PFS is used for NDV work/print file access method, thus allowing the testing of programs which execute access to work or print files.
SMARTS offers a configurable set of resources to process the application workload. These resources are mainly threads and (worker-) tasks. The actual workload is scheduled by the SMARTS kernel using these resources. In case of momentary shortages of one or the other resource, SMARTS is able to queue incoming requests and to roll-out inactive threads.
All data, processed by SMARTS or a SMARTS application, is located in one common memory pool, the data pool. All code modules, except for some smaller bootstrap routines, are loaded as shared code into another common memory pool, the code pool.
The worker-tasks are the processes (TSNs) by which the Natural runtime is executed. The amount of storage requested by Natural is located in the SMARTS threads within the data pool during the execution of a transaction. If the number of sessions to be processed exceeds the number of threads defined, an internal facility is invoked for rolling the threads. Threads rolled out are placed in compressed format in a so-called roll bufferpool which resides in the data common memory pool as well.
The multi-user, multi-tasking, front-end stub NATRDEVS is
launched to initialize a Natural Development Server.
The following topics are covered below:
The task executing the server initialization (TMain)
basically is the main listener which waits for incoming requests from the
remote development client (Natural Studio). 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, a command issued by the user on the client
side (in the menu of Natural Studio) 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 processes the request (indeed initializes a new
Natural session if the client sends a CONNECT request) and replies
to the client.
After the reply, TWork listens on that connection for
successive requests of that particular client. TWork remains
active until the user on the client (Natural Studio) side switches the focus to
a different environment (the local or a different mapped environment).
If the user activates the environment again, TMain
launches a new TWork subtask that resumes the existing Natural
session from the previous TWork.
That is, each client owns one subtask TWork on the Natural
Development Server and multiple remote Natural sessions (one for each mapped
environment). This subtask remains active as long as the mapped environment on
Natural Studio is the currently active environment. Each remote Natural session
remains active until the user disconnects/unmaps the corresponding environment
on the client side. Consequently, a Natural session can be executed under
different subtasks if the user switches among multiple environments.
Within a Natural Development Server session, the following Natural system variables are used:
*TPSYS contains
SERVSTUB,
*DEVICE contains VIDEO,
*SERVER-TYPE contains
DEVELOP.
The Natural runtime system allows I/O execution in the same way as in an online environment:
A Natural Development Server intercepts the I/O and sends the 3270 data stream to Natural Studio.
Natural Studio internally starts a terminal emulation window and passes the 3270 stream to that window.
After I/O execution, the I/O data is sent back to the server.
The front-end stub invokes the front-end to continue processing after I/O.
The front-end is called (together with the Natural runtime system) by the front-end stub for session initialization/termination, request execution and session roll-in/roll-out.
The transaction processors are Natural programs in the library
SYSLIB that process transactions (for example, "save
source", "get library list") requested
by the remote development client. The transaction processors are invoked by the
front-end stub.
The gateway module NATGWSTG is already included in the
Natural nucleus.
To enable the administrator to monitor the status of the Natural Development Server, a monitor task is provided which is initialized automatically at server startup. Using the monitor commands, the administrator can control the server activities, cancel particular user sessions, terminate the entire server, etc. See Operating the Development Server.
The following figure illustrates the interaction of Natural Studio used as a remote development client with a Natural Development Server.
Natural Studio (the client) sends a remote development request to the
Natural Development Server (NDV) using the port number specified with the NDV
configuration parameter PORT_NUMBER.
The Natural Development Server dispatches the Natural session using
the Natural front-end you have specified with the NDV configuration parameter
FRONTEND_NAME (NCFSERV in this example).