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 which 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 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.
The
storage mechanism that is used to host recovery log files, and access to that
mechanism (for example you can store the logs on another i5/OS server by using
the NetClient file system (QNTC), which provides access to data on a remote
system using the Server Message Block (SMB) protocol), 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 using the -o hard option of
the NFS mount command, the NFS client will retry 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.