On z/OS® platforms, configure the Resource
Access Control Facility (RACF®) to allow the application
servers to call the ATRSRV macro. The ATRSRV macro allows
a server to commit and back out transactions for other servers. This
process differs from peer restart and recovery support, where the
other server is started on another system. The ATRSRV macro is provided
by MVS™ Resource Recovery Services (RRS).
The
user ID that the application server controller region runs under must
have ALTER access to the MVSADMIN.RRS.COMMANDS.
gname.
sysname resource
in the FACILITY class, where
gname is the RRS logging
group (usually the SYSPLEX name), and
sysname is
the system name. To allow access to all logging groups and systems,
use wildcards in the resource name, for example MVSADMIN.RRS.COMMANDS.*.
Note: Because
the controller region runs as an authorized address space, it implicitly
has ALTER access to this resource class, unless the RACF configuration
explicitly restricts access. By explicitly allowing access to this
resource, you are not relying on the authorized state of the controller
region.
For more information about the ATRSRV macro and
setting the appropriate RACF permissions, see Chapter 8
of MVS Programming: Resource Recovery, SA22-7616-02.
Configure the transaction log directory setting for each
server in the cluster. You can configure the location of
the transaction log directory by using either the administrative console
or commands. The configuration is stored in the serverindex.xml node-level
configuration file.Each server in the cluster must be able to access
the log directories of other servers in the same cluster. For this
reason, do not leave this setting unset. If you do not set a directory,
the application server assumes a default location within the appropriate
profile directory, which might not be accessible to other servers
in the cluster.
Each server in the cluster must also have a
unique transaction log directory, to avoid attempts by multiple servers
to access the same log file. For example, you could use the name of
each server as part of the log directory name for that server.
The storage mechanism that is used to host recovery
log files (for example, you can use IBM® Network
attached storage (NAS) and shared SCSI drives, but not simple network
share) and access to that mechanism (for example, through a local
area network (LAN)), must support the file-based force operation that
is used by the recovery log service to force data to disk.
In addition, configure the mechanism by which
the remote log files are accessed, to exploit any fault tolerance
in the underlying file system. For example, by using the Network File
System (NFS) and hard-mounting the remote directory containing the
log files (by using the -o hard option of the NFS mount command),
the NFS client will try again with a failed operation until the NFS
server becomes available again.
For more information about configuring
transaction log directories, see Configuring transaction properties for an application server.
Note: If you have migrated from a previous
version of WebSphere Application Server, be aware
that previous versions stored the recovery log configuration in the server.xml server-level
configuration file. If you run existing scripting that configures
the original recovery log settings, or migrate Version 5 application
servers to a later version of WebSphere Application Server,
the original transaction log directory configuration in the server.xml file
is updated. The administrative console detects this condition and
prompts you to save the configuration when you view the transaction
service panel. This save operation saves the changed configuration
to the serverindex.xml file, and resets the older
fields to null. Change your existing scripting to target the serverindex.xml file
at the earliest opportunity. New scripting should also target the serverindex.xml file.