This document applies under z/OS only. It covers the following topics:
Besides being a programming language, Natural can also act as a server in a client/server environment. It can provide services, such as the execution of Natural subprograms. Part of the server functionality is the enhanced batch driver. There are a lot of underlying protocols for the client/server communication, such as the execution of stored procedures for DB2 and the execution of remote procedure calls, see the Natural RPC (Remote Procedure Call) documentation.
Natural as a server runs in a separate region or within the server subsystem region, for example, for DB2 stored procedures. To run Natural as a server, a service-specific server stub is required. This server stub is supplied as part of the server product. It controls all service requests and is the only interface to the Natural server front-end.
There are different server stubs for DB2, for Natural RPC and for others.
The Natural batch driver (that is, for example, NATOS
under z/OS) has been enhanced to act as the environment-specific interface
component which maintains the Natural server sessions and supplies
environment-specific services to Natural. It can be linked to the server stub
module or loaded by the server stub as a separate module.
The batch driver is able to create and to control multiple sessions by using storage threads including functionality for thread storage compression, decompression and rollout to external storage devices.
When the batch driver is called by the server stub for the first time (during server initialization), the storage threads are created in main storage. The number and size of the storage threads is determined by the server stub. Then a static Natural session is initialized. This includes profile parameter evaluation and the allocation of static storage buffers. The resulting pre-initialized storage thread is saved in main storage separately. For every new Natural session, this initial 'session clone' is copied into the thread.
When decided by the server stub, a session can be rolled out to be resumed at a later point of time. The Natural Roll Server is used by the driver to save the compressed thread storage of a session. As an alternative, main storage can be used to save the compressed thread storage. In this case, the number of sessions in rolled-out state is limited by the region size.
The Natural nucleus and its batch driver are designed to support both, server and non-server environments. For the server-specific definitions and requirements, please refer to the specific documentation (for example, to the Natural RPC (Remote Procedure Call) documentation or to the Natural for DB2 documentation).
If the number of sessions is not limited to a small number and if the
server type supports session rollout, the Natural
Roll Server must be installed and be started before the server
initializes. To do this, ensure that the SUBSID parameter in
the Natural parameter module is set
to the correct value. For the server, the Adabas link interface
(ADALNK) must be generated so that ADALNK is also
reentrant, in addition to the server.
You can use a local or a global Natural buffer pool. If you define a local buffer pool, it will be shared by all sessions within the server region.
If a logical print or work file number is to be used for processing
within any server session, it must be associated with an access method at
session start time. This can be done in the Natural parameter module with the macros
NTWORK
and NTPRINT,
as in the following example, if you want to allow the full range of all print
and work file numbers possible:
NTPRINT (1-31),AM=STD,OPEN=ACC,DEST=* NTWORK (1-32),AM=STD,OPEN=ACC,DEST=*
The subparameter DEST=* defines generic DD name generation
during the first DEFINE WORK
FILE or DEFINE
PRINTER statement, OUTPUT clause (see below).
Subparameter OPEN=ACC avoids pre-opening of the files at
program start time. The open is issued upon the first access of the file.
When running many concurrent sessions in one region, there may be
resource conflicts with external print and work files. The logical names (DD
names) for print and work files are defined by the subparameter
DEST of macro
NTPRINT,
respectively NTWORK
or its dynamic equivalents, PRINT or
WORK
(defaults CMPRTnn and
CMWKFnn). For normal Natural batch
processing, these files are defined in JCL by a logical (DD) and a physical
data set name.
However, DD names are reserved by the operating system for exclusive use by one task, respectively session, that is, if CMWKF01 is opened by one session for processing, no other session could use this file until it is closed again. Other sessions would get an error if they would try to open it.
In a server environment, all print and work file requests are handled by a dedicated I/O subtask. This ensures data set integrity and avoids resource contention. It enables the shared usage of print and work files across Natural session boundaries, that is, multiple sessions can access the same file concurrently. This is true only for print and work files whose DD-name starts with CM. All other files are considered as exclusive and cannot be shared.
For exclusive usage of print and work files, Natural offers the following two features to support print and work files in a server environment (both require a special implementation within the Natural application programs for the server environment):
DEFINE WORK
FILE or DEFINE
PRINTER statements, OUTPUT clause and
dynamic data set allocation (application programming interface
USR2021N, see SYSEXT -
Natural Application Programming Interfaces).
The DEFINE WORK FILE and the DEFINE PRINTER
statement OUTPUT clause can be used
to define the logical DD name for a work or print file, or
to define the physical data set name, or
to define an output spool class.
If a DD name is specified, the access method checks whether the data set
is allocated. If not, an error is issued. The data set can be allocated by any
Natural program using the USR2021N subprogram supplied in library
SYSEXT.
If a physical data set name or a spool file class is specified, the
access method itself allocates the data set dynamically during the execution of
the DEFINE ... statement. To ensure that a unique DD name is used,
DEST=* should be predefined in the
Natural parameter module. This
avoids any DD name conflicts.
If the application is using the application programming interface
USR2021N, it may specify an asterisk value for the DD name
variable to get back a unique DD name from the access method. This DD name can
be used for a subsequent DEFINE ... statement.
By default, the access properties of the server job are used for print and work files. Some server types, for example, Natural Development Server and Natural RPC, support impersonation, that is, the access properties of the individual client account is used for exclusive print and work files. For more information, refer to the corresponding section in your server documentation.