Natural as a Server under CICS

This document applies under CICS only. It covers the following topics:

See also:

Functionality

Natural as a Server

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 (see Natural for DB2) and the execution of remote procedure calls (see Natural RPC (Remote Procedure Call)).

Natural Server Stub

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 RPC and for others.

Natural CICS Interface Installation in a Server Environment

There is nothing specific to define when installing the Natural CICS Interface in order to serve as a Natural server environment. 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.

Restrictions

The following restrictions apply when Natural is used as a server under CICS:

  1. 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.

  2. 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.

  3. 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.

  4. The profile parameter PROGRAM or equivalent back-end 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 back-end program.

  5. Care should be taken when using the parameter TERMVAR (&TID) in the macro NTCICSP 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.