This section covers the following topics:
See also Natural Roll Server Operation.
With the Natural Roll Server, Natural can execute in a multiple-address-space system like CICS or IMS TM; these address spaces may be located in multiple z/OS images (z/OS Parallel Sysplex environment). You can, of course, also use the Roll Server if you are running a single z/OS system.
When Natural performs terminal I/O, it must save the application's context data (the thread): Before the terminal I/O is started, the thread is given to the Roll Server which keeps it in its Local Roll Buffer, or in the roll file. This is referred to as "roll out". When the terminal I/O is completed, Natural requests the thread from the Roll Server, and continues the application. This is referred to as "roll in". In a z/OS Parallel Sysplex environment, the Roll Server keeps information about the threads (the roll file directory) in a data structure in the Coupling Facility. Thus, it is possible for a Natural application to execute in different z/OS systems at different times: A thread can be given to the Roll Server on one system, and requested back from another system.
Before a roll out is performed, Natural compresses the thread into one contiguous buffer, and decompresses it after the roll-in is performed. Depending on the Natural version installed at your site, the CPU load of compression and decompression can be taken off the hosting TP system and moved to respective routines within the Roll Server. If you want to take advantage of the compression/decompression feature, install the appropriate Roll Server module described in the respective installation step in the section Installing Natural on z/OS in the Installation for Natural on z/OS documentation. In addition, Natural Batch for zIIP (extra product license required) must be available to the Natural nucleus (see the respective installation step) in Installing Natural on z/OS.
The Roll Server runs in its own address space. It provides its services as PC routines. In a z/OS Parallel Sysplex environment, one instance of the Roll Server must be started in each participating z/OS image.
A list of applied Roll Server Zaps is displayed in the
JESMSGLG data set of the Roll Server started task, and by the
SYSTP utility,
function code R, line command Z.
Note concerning Natural under CICS: The
CICS System Recovery Table should include the z/OS system abend code
0D6.
When the Roll Server receives a thread through a write request (before terminal output), it checks whether enough space is available in the local roll buffer (LRB). If there is, the thread is copied to the LRB. If not, the thread is written to the roll file. If the thread is larger than the roll file slot size, additional overflow slots are allocated to accommodate the thread. Allocation of overflow slots is restricted to the roll file that the Natural session was initially assigned to. If the roll file does not have enough free space to allocate the necessary overflow slots, an error is generated and the requesting Natural session terminates abnormally. Overflow slots are implicitly freed by a subsequent write request with a smaller thread.
When the Roll Server receives a read request for the thread (after terminal input), it tries to locate the thread in the LRB. If the thread is found, it is copied from the LRB to the requestor's address space. If not, the thread is read from the roll file and copied to the requestor's address space.
To ensure that the system performs well and that there is always enough space in the LRB, there are "water marks". If the LRB's high water mark is reached, the staging task is activated and copies the LRB content to the roll file until the low water mark is reached. Where the high water mark and the low water mark are placed is therefore an important issue of performance tuning. For more information on performance tuning, see the section Roll Server Performance Tuning. For a Roll Server running in a single z/OS system, the default high water mark is 80 percent and the low water mark 70 percent.
In a z/OS Parallel Sysplex environment, the Roll Servers in the participating z/OS images communicate through the Coupling Facility's (CF) XCF Signaling Services, and the roll file directory resides in an XES data structure.
When the Roll Server receives a thread through a write request (before terminal output), it checks whether enough space is available in the local roll buffer (LRB). If there is enough space, the thread is copied to the LRB. If there is not enough space in the LRB, the thread is written directly to the roll file. The roll file directory in the CF structure is updated accordingly. Thread overflow is handled as described under Roll Server in a Single z/OS System.
You can also set high and low water marks in a Parallel Sysplex environment. This option is not provided by older Natural versions. The staging task writes threads to disk until the low water mark is reached only when the LRB high water mark is reached. If a thread is requested from another z/OS image and has not yet been written to disk, the Roll Server on the other z/OS image sends a stage request message for this particular thread. The requested thread is then written to disk regardless of the high and low water marks.
Anmerkung:
When you specify a high water mark of zero, the Roll Server performs
identically to earlier versions of Natural in that all threads are immediately
scheduled for staging to disk. For a Roll Server running in a Parallel Sysplex
environment, both the default high and the low water marks are zero.
When the Roll Server receives a read request for a thread (after terminal input) and the last write request was issued in the same z/OS image, the Roll Server copies the thread directly from the LRB into the requestor's address space. If the last write request did not come from the same z/OS image, the thread is read from the roll file and then copied into the requestor's address space. If the thread does not yet reside on the roll file, the Roll Server on the other z/OS image receives a stage request message. When the thread resides on the roll file, it is read from there and then copied into the requestor's address space.
Illustration of Roll Servers in a z/OS Parallel Sysplex Environment:
The roll file is a BDAM file logically subdivided into a
directory and fixed-length slots. The slot size is a parameter of the roll-file
formatting routine NATRSRFI. There should be at least as many
slots as there are active Natural sessions. The slot size should be large
enough to accommodate an average compressed Natural thread. Threads that are
larger than the slot size will occupy multiple slots. You can check the
distribution of Natural thread sizes with the
SYSTP utility,
function code R, line command R: Scroll down (using
PF8) to the page entitled Roll Server Peak Loads and
Thread Sizes.
The roll file directory contains one entry for each active Natural session, together with a timestamp of its last write request. In a single z/OS system, the directory resides in the Roll Server's address space. In a z/OS Parallel Sysplex environment, it resides in the Coupling Facility. The directory is written back to the roll file only when the Roll Server terminates.
The local roll buffer acts as a cache for the roll file. The roll buffer
is contained in a z/OS memory object and subdivided into fixed-length slots.
The LRB slot size is identical to the slot size of the corresponding roll file.
If the Roll Server is to run without a roll file, the LRB slot size must be
specified as parameter on the JCL EXEC statement. See
Natural Roll Server
Operation, Starting the Roll
Server.
The Roll Server can run with up to five different roll files. Each of these roll files is logically connected to one local roll buffer. If there are five roll files, there are five corresponding LRBs. Each roll file is accessed by its own dedicated read, write, and staging tasks. Thus, if the roll files are created on different disks on different channels, the roll files can be accessed simultaneously.
Natural users are allocated to the roll file that has the most free slots. You can use the NATRSU14 user exit to implement your own allocation method. For more information on this user exit, see the relevant section in Natural Roll Server Operation.
You can see how your user IDs are distributed in the roll files with the statistics function (function code ) of the SYSTP utility.