This document applies under CICS only. It covers the following topics:
See also:
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. 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 Natural Remote Procedure Call (RPC)).
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 frontend.
There are different server stubs for DB2, for RPC and for others.
There is nothing specific to define when installing the Natural CICS interface in order to serve as a Natural server envionment. There are no requirements on thread type or type of rolling (CICS roll facilities or roll server).
Actually, Natural server sessions may share a Natural under CICS environment with "normal", for example, terminal bound Natural sessions. The difference is that, in case of a Natural server session, the Natural CICS interface does not deal with a principal facility, such as a terminal or printer, but with a server stub. In terms of CICS, a Natural server session is a series of asynchronous CICS tasks, and the session context (session restart data) is maintained by the server stub using a unique 8-byte session ID.
The following restrictions apply when Natural is used as a server under CICS:
Natural server sessions under CICS can only run in
pseudo-conversational mode. A Natural server session cannot run in
conversational mode, as the Natural CICS interface always has to pass control
back to the server stub; therefore PSEUDO=ON is
forced for Natural server sessions under CICS. Because of the same reason
RELO=ON
is forced for Natural server sessions using
TYPE=GETM
threads.
3GL programs called by Natural should be aware of the fact that Natural server sessions are running asynchronously in CICS, that is, no CICS terminal (TCTTE) is available.
The profile parameter ADAMODE should be
set to 1 or 2, otherwise Adabas may build a different UQE ID for each dialog
step of the Natural server session.
The profile parameter PROGRAM or
equivalend backend program settings by Natural are not honored, as the logic
flow at session termination from the Natural CICS interface to the server stub
must not be interrupted and/or falsified by a potential backend program.
Care should be taken when using the NCIPARM
terminal ID variable
&TID in the file name setting for Natural print and work
files: As a Natural server session runs asynchronously, there is no (unique)
terminal ID or other unique four-character session identifier to insert. In
CICS/TS 1.3 and above, the CICS interface internally uses the
QNAME option when dealing with CICS temporary storage for such
Natural print and work files, that is internally a 16-byte temporary storage
queue name is used (the 8-byte unique server session ID is appended to the
file's DEST specification). This means on the other hand
that such CICS temporary storage queues can only be accessed by the originating
session.
