This document describes the components of the Natural IMS TM Interface.
The following topics are covered:
The front-end module receives control from the IMS TM program controller
DFSPPC20, except in the server environment where it is called by
the call interface NIIBOOTS.
The front-end module must be built during the installation process of the Natural IMS TM Interface described in the Installation for z/OS documentation. The front-end-module consists of the following:
The environment-dependent interfaces are supplied as the following load modules:
NIIBMP for the batch
message processing environment,
NIICONV for the
conversational
dialog-oriented environment,
NIINONC for the
non-conversational
dialog-oriented environment,
NIINTRD for the
message-oriented
environment,
NIISFE for the Natural Development Server/Natural Web I/O Interface
server environment, and
NIISRVD for the server environment.
The load modules are supplied on the installation medium. You can
configure the environment-dependent interfaces with the
NTIMSP macro of the
Natural parameter module. See also Natural under IMS TM -
Configuration.
The Natural
parameter module is built during the installation. In addition to
the parameter settings you need to adapt for your Natural environment, you must
specify at least one NTIMSPT parameter macro for
the Natural IMS TM Interface. See also Natural under IMS TM -
Configuration.
The Natural parameter module and the individual parameters and macros that can be specified with the Natural parameter module are described in the Parameter Reference documentation.
The NATWKFO module is delivered as part of the base
Natural. It is used for work file and print file handling for work files and
print files defines with AM=STD. It is
applicable to the BMP environment, including off-line DL/I batch regions, the
message-oriented environment and the server environment. It is not applicable
to the dialog-oriented environments.
Some Natural products, such as Natural for DB2 and Natural for DL/I, require that their modules be linked to the Natural IMS TM front-end module. For further information, see the appropriate product documentation.
The Natural IMS TM Interface module has to be created during the installation process and is common to all environments.
The interface module consists of the following components:
The interface module is fully reentrant and can run above the 16 MB line. It is therefore eligible for the ECSA in order to have only one copy of the interface module for all IMS TM environments.
The Natural IMS TM nucleus NIINUC is delivered as a load
module and contains all the runtime routines required by the Natural IMS TM
Interface.
The message text module NIIMSGT is part of the Natural IMS
TM Interface module and is supplied both as a load and a source module. For
each possible Natural IMS TM runtime error, it contains the corresponding
message text. Each entry is generated by the macro NIMMSGT.
For a detailed description of the macro NIMMSGT, see
NIMMSGT Macro
Parameters.
The DL/I language interface ASMTDLI is part of IMS TM.
The physical input edit routine is required only in a dialog-oriented, non-conversational environment. It is used to insert the transaction code preceding the message sent to the terminal. This is required as Natural runs in MFS bypass mode and the message sent to the terminal does not contain a transaction code.
The physical input edit routine is generated by using the
NIMPIXT macro. For further information on the NIMPIXT
macro, see NIMPIXT Macro
Parameters.
Once the physical input edit routine is generated, its name must be
specified in the TYPE or LINEGRP macros of your IMS
TM system definition. For all terminals on which the non-conversational
environment is supposed to run, you must enable physical editing by using the
EDIT parameter in the TERMINAL macro.
The delivered user message table DFSCMTU0 is required only
in a dialog-oriented, non-conversational environment. It contains the error
messages for errors detected by the physical input edit routine.
The user message table DFSCMTU0 must be integrated into the
existing user message table of your IMS TM installation. In case of conflicts
with already existing user message numbers of your IMS TM installation you may
change the message numbers of the delivered DFSCMTU0 by modifying
the EQUATES PIXTE and SIPSE to create new message
number ranges. The new start value of the message number range must be
specified in the NIMPIXT macro.
These components are used in dialog-oriented environments only.
Natural session-related information is held in the Natural thread. With
each terminal output, the content of the Natural thread is saved either in a
roll file or by using the roll server. The medium is defined by the
ROLLSRV
keyword subparameter in the NTIMSPE macro (Natural parameter
module) described in the Parameter Reference
documentation.
To use roll files, the
ROLLSRV
keyword subparameter is set to OFF.
A roll slot in the roll file is reserved for each Natural user at
Natural session initialization time. The identifier of the slot is the IMS TM
LTERM at which the Natural session is started. You must therefore
ensure that all terminals that use the same set of roll files have different
LTERM names. This is always the case if the roll files are used by
a single IMS TM. The slot is freed when the Natural session terminates
normally. In case of an abnormal termination, the roll slot remains allocated,
but will be reused when the same user (identified by his LTERM)
starts a new Natural session.
Roll files are accessed under the DD statements ROLLF1 -
ROLLF5. The number of roll files used is defined by the
ROLLFN
keyword subparameter in the NTIMSPE macro.
If your Natural transaction code is scheduled in more than one MPP region or if you switch between transaction codes running in different MPP regions, you have to use the same roll files in all MPP regions.
If you reformat the roll file(s), make sure that no Natural transactions are active. If a transaction is scheduled after the roll file has been reinitialized, it cannot locate its roll slot on the roll file and abnormally terminates. To avoid this problem, it is recommended that you cold-start IMS TM after the roll file has been reformatted.
The roll files used by Natural under IMS TM have the same layout as the roll files used by the Roll Server and are formatted by the same utility program.
Note:
The roll files used by Natural under IMS TM must not be shared with
the Roll Server. If you use roll files for Natural under IMS TM and the Roll
Server at the same time, you must assign an own set of roll files to the Roll
Server.
To use the roll server, the
ROLLSRV
keyword subparameter is set to ON.
Instead of using roll files which have to be allocated to each MPP region, you can use the Natural roll server. The roll server offers the following advantages:
No DD statements in each MPP region.
One central address space is responsible for access to the roll files.
Support of main storage buffers to reduce disk I/Os to the roll files.
A slot in the roll server is reserved for each Natural user at Natural
session initialization time. The identifier of the slot (roll server user ID)
is the IMS TM LTERM at which the session is started, concatenated
with the z/OS host ID and the IMS TM subsystem ID of the IMS TM dependent
region in which the corresponding Natural transaction is scheduled. The slot is
freed when the Natural session terminates normally. In case of an abnormal
termination, the slot remains allocated, but will be reused when the same user
(identified by his LTERM) starts a new Natural session.
In a z/OS Parallel Sysplex environment you must use the roll server.
For further information on roll files and the roll server, see Roll Server in the Natural Operations documentation.
The Natural Authorized Services Manager is required in the following cases:
In a dialog-oriented, non-conversational environment; see Special Considerations for a Non-Conversational Environment).
If Monitoring or Broadcasting is used; see Monitoring or Broadcasting.
If Accounting is used and the accounting information is written to SMF; see Accounting.
If buffer pool propagation is used; see the profile parameter
BPPROP.
In the first two cases, the optional SIP function must be made available during startup of the Authorized Services Manager.
In a z/OS Parallel Sysplex environment, the SIP must be located in a Coupling Facility.
In an IMS TM environment, the Natural nucleus is always separated from the environment-dependent interface (driver). This means that you have to install the shared Natural nucleus. The same Natural nucleus can be shared by all Natural IMS TM environments.
Since Natural under IMS TM is executable in more than one MPP region, it is recommended that the Natural buffer pool be a global buffer pool.
Although you can use a local buffer pool, this is not recommended in terminal-driven environments for performance reasons.
For further information, see Natural Global Buffer Pool in the Natural Operations documentation.
In order to access the Natural system file and Adabas user files, the Adabas interface is required.
By default, the appropriate Adabas interface is dynamically loaded at runtime.
In terminal-driven dialog-oriented environments, the Adabas IMS TM
Interface module ADALNI is used.
In all other environments, the Adabas batch interface module
ADALNK is used.
You can overwrite the name of the Adabas interface to be used by
specifying the Natural profile parameter ADANAME.
 |
Warning: You must not use the reentrant version of either of these interface modules. |
It is no longer required to use a preload list with the Natural IMS TM Interface, but for performance reasons it is recommended that you add the names of the following modules to the preload list for the Natural regions:
the Natural IMS TM front-ends,
the Natural IMS TM Interface module,
the Natural shared nucleus,
the Adabas interface.