Careful and complete planning is critical for a successful implementation
of the file system capability within OAM. There are a number of considerations
that must be coordinated between the Unix System Services environment
and the OAM implementation.
A directory location within the Unix file system hierarchy can
be associated with each object storage group in which the OAM file
system support will be implemented. IBM recommends that a unique directory
location be specified for each object storage group and that this
directory location contains a mounted file system specifically for
the storage group (similar to the unique DB2 object storage tables
for the DB2 sublevel of the OAM storage hierarchy). This provides
for object data isolation, may improve performance, facilitates file
system backup and other maintenance, and allows for future growth.
Each installation is unique and your planning must consider the maximum
number of objects that can be contained within each storage group
(which depends upon, and could be limited by, the underlying file
system). The following considerations apply to the directory location
under the assumption that a file system specific to the storage group
is mounted at the directory location as recommended by IBM:
- The directory location specified must be exclusively for OAM usage.
OAM will create subdirectories and files at this location, which should
be treated as a “black box”. No deleting, renaming, movement,
or any other manipulation of these directories and files or their
attributes should be performed. Additionally, no other user data should
be stored in the Unix file system hierarchy at or beneath the specified
directory location.
- The directory location (L2DIR) specified may contain symbolic
links. This, however, will introduce a dependency upon the continued
existence of the symbolic links for successful OAM operation. The
contents of any symbolic links must be understood, recorded, and archived,
in case the symbolic links are ever intentionally or accidentally
removed or altered. OAM will create directories and files within the
specified directory location and these OAM-created directory names
and file names cannot contain any symbolic links and, if symbolic
links are present, they will cause an error.
- A strategy must be developed to ensure that the OAM address space
is stopped before Unix System Services is shut down. Your local procedures
should be updated to incorporate this important activity. Failure
to stop the OAM address space before shutting down Unix System Services
can have unpredictable results, including abends and hangs, and can
adversely affect OAM operation.
- A strategy must be developed to ensure that the file system is
mounted whenever OAM in is operation to ensure that OAM can successfully
write, read, or delete files within the specified directory location.
- For file system space planning, assume that the OAM file name
itself can be up to 255 characters. This will consume larger amounts
of disk space for each file's directory entry and should be taken
into account when allocating space for file systems. Also take into
account any other file system overhead for the file system you are
using. For NFS, you must investigate the NFS server configuration
to ensure that sufficient directory space is available for the OAM
file name entries.
- In general, file system performance can degrade significantly
when hundreds of thousands of files are stored in a single directory.
For OAM file system planning, it is recommended that you plan to
use multiple object storage groups to limit the number of objects
stored in the file system sublevel for any given object storage group.
Note also that to mitigate performance degradation, OAM may create
up to 2053 individual subdirectories in any given directory, so ensure
that this creation of at least 2053 subdirectories is supported by
the file system you plan to use with OAM.
- A strategy must be developed to ensure that the file system will
be backed up regularly and coordinated with the backup of other OAM
data and metadata (such as the DB2 object storage tables and DB2 object
directory tables). See z/OS UNIX System Services Planning for
backup techniques, which include use of the Tivoli Storage Manager
product, the DFSMShsm feature of z/OS, and the DFSMSdss feature of
z/OS. You also will need to include the CBROAMxx PARMLIB
member in your backup strategy, as it contains essential file system
location information required for proper OAM operation.