This document covers the following topics:
The Natural buffer pool is used to share Natural objects between several Natural processes that access objects on the same computer. It is a storage area into which compiled Natural programs are placed in preparation for their execution. Programs are moved into and out of the buffer pool as Natural users request Natural objects.
Since Natural generates reentrant Natural object code, it is possible that a single copy of a Natural program can be executed by more than one user at the same time. For this purpose, each object is loaded only once from the system file into the Natural buffer pool, instead of being loaded by every caller of the object.
The following topics are covered below:
Objects in the buffer pool can be any executable objects such as programs and maps. The following executable objects are only placed in the buffer pool for compilation purposes: local data areas, parameter data areas and copycodes.
When a Natural object is loaded into the buffer pool, a control block called a directory entry is allocated for that object. This control block contains information such as the name of the object, to which library or application the object belongs, from which database ID and Natural system file number the object was retrieved, and certain statistical information (for example, the number of users who are concurrently executing a program).
The buffer pool uses a standard locking mechanism which need not be configured by the administrator.
Depending on the individual requirements, it is possible to run different buffer pools of the same Natural version simultaneously on the same computer.
When a user executes a program, a call is made to the buffer pool manager. The directory entries are searched to determine whether the program has already been loaded into the buffer pool. If it does not yet exist in the buffer pool, a copy is retrieved from the appropriate library and loaded into the buffer pool.
When a Natural object is being loaded into the buffer pool, a new directory entry is defined to identify this program, and one or more other Natural objects which are currently not being executed may be deleted from the buffer pool in order to make room for the newly loaded object.
For this purpose, the buffer pool maintains a record of which user is currently using which object, and it detects situations in which a user exits Natural without releasing all its objects. It dynamically deletes unused or out-of-date objects to accommodate new objects belonging to other applications.
When using the Natural buffer pool, only minimum restrictions must be considered:
When a Natural session hangs up, do not terminate it by using the
OpenVMS command STOP.
If this session is currently performing changes to the buffer pool internal data structures, an interruption may occur at a stage where the update is not fully completed. If the buffer pool internal data structures are inconsistent, this could have negative effects.
Note:
This can only happen when the Natural nucleus is executing buffer
pool routines.
All resources must be shared among all users of one Natural buffer pool. Group membership of a process is used to give access rights for the buffer pool. This means that the shared memory can be changed by all group members, but not by anyone else.
Note:
OpenVMS group or system membership depends on the
buffer pool
assignments in the Configuration Utility.
Since on OpenVMS the common resource
"bufferpool" is administrated by the OpenVMS lock
manager, each buffer pool on each node has to be addressed by its own
cluster-wide unique lock resource name and global section descriptor name. To
ensure this, the installation procedure inserts for each node where it is
executed a new node-specific buffer pool section into the
natural.ini file. Consequently, the buffer pool service
has to be started on a given node using its specific buffer pool name,
therefore the
natetc:natbpenv_<node>.com
was changed. Also each Natural session has to be started using the buffer pool
name for the node where the user is currently logged on. To ensure this, the
symbol to start Natural contains the string BPID = BP
<node> (defined in the
LOGIN.COM for Natural). If applications with different
priorities are in use, then every application should have its own buffer pool
to avoid a system dead lock.
The buffer pool assignments are stored in the local configuration file. To set up a buffer pool, you have to specify specific values in the local configuration file using the Configuration Utility. For a list of these values, see Buffer Pool Assignments in the Configuration Utility documentation.
The buffer pool is created using the utility NATBPSRV.
Note:
The utility NATBPSRV should not be accessible to all
Natural users, because it can cause damage to the work of other buffer pool
users.
The following system privileges are required:
CMKRNL, PRMGBL, SYSGBL,
SYSNAM, SYSPRV.
NATBPSRV allocates the resources required by the buffer
pool and creates the permanent communication facilities (that is, shared memory
and semaphores) used for the buffer pool. The necessary specifications for the
resources and facilities are made with the Configuration Utility (see
Setting up a Buffer
Pool).
The NATBPSRV utility should only be used during
system startup, from within the startup procedure STARTUP_NAT<v>.COM
(where <v> in the file name stands for the
first digit of the Natural version number).
NATBPSRV without a parameter
starts the buffer pool NATBP. If another buffer pool is
to be started, you specify its name with the following NATBPSRV
command line option:
NATBPSRV BP = buffer-pool-name
If NATBPSRV discovers in the process of
creating a buffer pool that a buffer pool of the same name is already active,
it deletes the already active buffer pool. If the deletion fails,
NATBPSRV terminates with an appropriate error message.
The Buffer Pool Monitor is used to oversee the buffer pool's activity during its operation. The Buffer Pool Monitor can also be used to shut down the buffer pool when Natural must be stopped on a computer.
The Buffer Pool Monitor collects information on the current state of your Natural buffer pool.
If multiple buffer pools are active on the same computer and an object that is loaded to more than one buffer pool is modified by a Natural process, the object will only be removed from the buffer pool to which the modifying Natural process is attached.
For detailed information for how to use the Buffer Pool Monitor, see
Using the Buffer Pool Monitor
(NATBPMON).
This section describes problems that may occur when using the Natural buffer pool and how to solve them.
The following are typical command output examples, with an explanation of what went wrong during execution.
Either Natural or the Natural Buffer Pool Monitor (NATBPMON utility) cannot be
started.
The following examples describe the most typical problems you are likely to encounter as a Natural administrator or user. These problems occur when you start Natural or the Natural Buffer Pool Monitor, and the buffer pool is not active.
You try to start Natural with the following command:
NATnnURAL
The following message appears:
Unable to open Buffer Pool, Buffer Pool error: "unexpected system call error occurred" (20) Global shared memory could not be attached.: NATBP6340_NODE1 %SYSTEM-W-NOSUCHSEC, no such (global) section
You try to start the Natural Buffer Pool Monitor with the following command:
NATnnBPMON
When you enter the STATUS command at the
NATBPMON prompt, the following message appears:
%SYSTEM-W-NOSUCHSEC, no such (global) section Buffer Pool error: "unexpected system call error occurred" (20) Global shared memory could not be attached.: NATBP6340_NODE1
Start the buffer pool service from a sufficiently privileged account as shown in the following example:
$ @STARTUP_NAT<v>.COM STARTUP BP
where <v> in the file name stands for the first digit of the Natural version number.
This command procedure is either located in SYS$STARTUP or in the directory SAG$ROOT:[NATURAL].
Usually it should not be necessary to shut down and restart the buffer pool. This may only be necessary if the buffer pool should become unusable due to serious internal errors in the buffer pool, which is extremely unlikely to occur, or because the parameters defining the buffer pool structure became obsolete.
If the NATBPMON
utility is still able to access the buffer pool, proceed as
follows:
Shut down the buffer pool with the
SHUTDOWN command of the NATBPMON
utility.
Once the SHUTDOWN command is executed, new
users are denied access to the buffer pool.
Tip:
Active buffer pool users can be monitored by issuing the
WHO and STATUS commands
of the NATBPMON utility.
After the last user has stopped accessing the buffer pool, buffer
pool resources can be deleted by issuing the IPCRM
command of the NATBPMON utility.
To restart the buffer pool, call the file STARTUP_NAT<v>.COM from a sufficiently privileged account (where <v> in the file name stands for the first digit of the Natural version number).
You can use the FORCE option of the
SHUTDOWN command:
Shut down the buffer pool with the SHUTDOWN FORCE
grace-period command of the
NATBPMON utility.
This command - like the SHUTDOWN command
without options - denies new users access the buffer pool. However, the
terminate signal SIGTERM is sent to all active Natural sessions,
forcing them to log off from the buffer pool.
If the optional parameter grace-period is
omitted, this command waits until all active sessions have performed their
shutdown processing and then executes the IPCRM
command of the NATBPMON utility .
If the optional parameter grace-period has
been specified, NATBPMON waits the specified number of seconds
before it executes its IPCRM command - regardless of
the closedown status of the sessions logged on to the buffer pool. Therefore,
the value defined for the grace period should be sufficiently large to allow
the sessions to terminate in time.
Note:SHUTDOWN FORCE 0 is the same as
SHUTDOWN FORCE (without the parameter
grace-period).
To restart the buffer pool after successful execution of the
SHUTDOWN FORCE command, call the file
STARTUP_NAT<v>.COM from a
sufficiently privileged account (where
<v> in the file name stands for the first
digit of the Natural version number).
If the NATBPMON utility is not able to perform a clean
shutdown of the buffer pool, the buffer pool must be deleted by using operating
system commands. It is only possible
to rename the section file, because a section file cannot be deleted as long as
it is locked by another user. Then restart the buffer pool using
STARTUP_NAT<v>.COM and delete the renamed section
file after the next reboot.
