This document explains the features of Natural Advanced Facilities specific to a CICS environment.
NATSPOOL accumulates all reports generated during a
Natural user session in the spool file. To physically print a report,
NATSPOOL schedules a Natural session at the physical printer by
EXEC CICS START command.
This new Natural session, the
NATSPOOL spool server,
retrieves various dynamic parameters from the task which has issued the
The logical connection between the two Natural sessions used by
NATSPOOL is shown below.
To install NAF in a CICS environment, set the
parameters listed below.
You can also specify these parameters with Function 30.5 (Set Spool Option) as described in Layout of Spool File. After Natural Advanced Facilities has been installed, use Function 30.5 to set the CICS options.
||Specifies whether the NAF initialization exit is executed. This exit requires exclusive control (ADABAS EXU USER) by the spool file.|
||Specifies whether the initialization exit sends messages to the console.|
||Specifies whether the initialization exit sends messages to the CICS log file.|
||Specifies the CICS SYSID that performs the initialization exit.|
||Specifies the default CICS
||Specifies the CICS transaction ID of the spool server. The name
specified must be identical to the corresponding name specified as transaction
ID in the CICS PCT. This PCT entry must point to the Natural load module, that
For performance reasons, we highly recommend that you select different names for the spool server transaction ID and the terminal transaction ID.
||Specifies that the spool server terminates and another task
starts each time a single report has been printed.
You can omit a parameter or set the value (
name) assigned to blank.
The following rule of precedence applies to the use of parameters:
For all parameters that have not been defined in
or have been set to blank, the corresponding values defined in the spool file
Parameters that have been defined in the
parameter module by setting the value not equal to blank rank before the values
defined on the spool file. As a result, you can use the
parameter module to set certain options for certain tasks only. This can be
useful for several CICS environments sharing the same spool file.
CICS contains a facility called Intercommunication Support, which allows different CICS regions to share resources and communicate with each other. Multiple Region Operation (MRO) is a CICS facility which provides such support for regions within the same processor.
The MRO function-shipping option allows programs in the "application-owning" (local) region to access resources in the "resource-owning" (remote) region, by shipping appropriate requests to the remote region.
These requests are carried out in the remote region by a mirror transaction provided by CICS. The resources accessed can also be transactions, in which case the process is known as Remote Transaction Initiation.
Using the MRO approach, it is possible to ship the
request of the asynchronous
NATSPOOL spool server to a remote
region (that is, to print in such a region).
The MRO option is useful if growth of tasks is anticipated, because there are constraints on the number of tasks a CICS region can manage.
When a spool server is started, three different types of dynamic parameters apply:
- Parameters set up by the spool server itself
To allow for dedicated Natural Advanced Facilities threads of minimum size, the spool server always allocates buffers of minimum size. Most sizes are set to 0.
- Parameters passed from the user session to the spool server
The spool server and the user session which started the spool server always use the same system files (
FSPOOL), the same buffer pool (
BPID), and the same setting of the
- Parameters defined in the Natural parameter module
All further parameters not mentioned above are taken from the Natural parameter module.
The definition of the system file(s) in the Natural parameter module
can be overwritten by the user. This is accomplished by specifying any of the
corresponding file parameters (
FSPOOL) dynamically when starting a Natural session. The
actual values will then be transferred by the originating terminal task to the
spool server. This holds both for spool servers started automatically and for
spool servers started by using
processed, the supplied value is also applied to the spool file
Once the spool server has been started, it will observe these file
definitions for as long as the task is active. Reports will be printed only
from the file defined by the currently active
FSPOOL, even if
there are reports with the same Destination/Form on another
In this way a unique CICS spool server is able to manage reports created on different spool files under the same CICS (for example, for production or test processing).
Before starting a spool server,
NATSPOOL checks if the
terminal status of the printer allows internally generated session requests to
create a session (
If this is not the case, for example after VTAM
NATSPOOL forces this status and then tries to start the spool
After startup of CICS, when the first Natural session is invoked, the
spool file is scanned for printers or reports interrupted during the previous
CICS session. Interrupted printers which are not in status
are reset to status
FREE, interrupted reports to status
TOBE. 20 seconds after this first stage of initialization, all
interrupted printers are restarted with the interrupted Destination/Form. The
interval of 20 seconds allows this first stage of initialization to finish as
an exclusive user of the spool file.
The Natural initialization ensures that the spool file is to be updated under exclusive control of this first session. Other starting sessions will be delayed until this part of the initialization has finished.
If an error is encountered during scanning the spool file, the system operator is notified, the scan is terminated normally, and Natural initialization continues.
This scan is performed for the defined spool file, that is, dynamic
FSPOOL is also taken into account.
If the spool file is shared among CICS sessions, the spool file scan
must be disabled (see Function
30.5 and the
NAFPARMC parameter module in
Advanced Facilities under CICS on z/OS or
Installing Natural Advanced Facilities under CICS on z/VSE)
because it requires exclusive control of the spool file.
If a spool server terminates normally, each printer is checked for
INOP. If a printer is found to be in status
INOP and no alternate printer is available, the printer is set to
PEND, and the spool server tries to start again on that
printer. If the printer becomes
INOP again, the same procedure is
repeated twice. Afterwards, a restart is no longer attempted on that
Support for SNA character string (SCS) printers is provided.
The data stream to SCS printers may only contain user data and SCS control codes. It must not contain a write control character (start printer bit) or orders (such as the end-of-message character). The SCS control codes perform functions similar to orders, in that they allow the output to be formatted, however, the range of control is greater.
The only SCS control codes used by
FF (form feed) and
NL (new line).
It is only possible to have one spool transaction ID per Natural transaction ID.
The operation mode of the spool server can be defined with
NAFPARMC parameter module as described in
Advanced Facilities under CICS on z/OS or
Installing Natural Advanced Facilities under CICS on
By default, the
NATSPOOL spool server operates as a
pseudo-conversational CICS task (that is, in
mode). The spool server will then be terminated (and another task will be
started) each time a single report has been printed. Pseudo-conversational mode
of operation is recommended if there are several physical printers active at
the same time.
Terminate Task=N to run in conversational mode.
The same CICS task prints all reports with the same Destination/Form.
Conversational mode is recommended if not many physical printers are active at
any one time, and fast printing is required. Otherwise, the maximum number of
active CICS tasks (
AMXT keyword in CICS SIT) may be reached.
Before sending output to a printer, the spool server rolls out the session to release the thread. This allows the thread to be released if the printer is interrupted while printing, for example, when running out of paper or switched off. After the output has been sent successfully, the session is rolled in again. Since relocation is turned off during this roll request, the same thread is selected.