System requirements
Before you install the product, make sure that your environment meets the hardware and software requirements.
Product compatibility matrix
This topic provides information about items that require special consideration or action before you use PACLOG.
Software environment
The minimum software environment for using this release of PACLOG is as follows:
OS/390 or z/OS
DB2 version 7.1 or later
ISPF version 3.1 or later
Archive log data sets processed by PACLOG can be used in a recovery by the NGT Recover product or DB2 RECOVER.
PACLOG installation
PACLOG is installed by using the BMC Software OS/390 and z/OS Installer.
Important
Before you install the product, review the section about installation considerations for PACLOG in the .
The installation process does not require any modifications to DB2. However, it does require that you choose values for certain PACLOG options. For more information, see PACLOG installation options.
The installation process is for a single DB2 subsystem. To install PACLOG on additional subsystems using the same operating system after the initial installation, you simply add the new subsystems to the PACLOG control information and create the new history files.
For more information, see Installing PACLOG on multiple DB2 subsystems.
Shared PACLOG and RECOVERY MANAGER features
When the PACLOG and RECOVERY MANAGER for DB2 products coexist in a DB2 subsystem, they should use the same options file.
You can designate that the two products share a common options file during product installation.
Sharing the same options file ensures that both products use the same archive history file, time stamp value, DB2 load library, and work data sets, all of which are specified in the options file. For a discussion of the archive history file, see BMC archive history file.
For more information, see Integrating.
PACLOG authorizations
You must have the following authorizations to run PACLOG:
ALTER authority for DB2 active log data sets
DELETE and DEFINE authority for DB2 archive log data sets 1, 2, 3, and 4
READ authority for the DB2 BSDS
UPDATE authority for the archive history file
Authorization for the XCA compression started tasks as follows:
For advanced communications function 2 (ACF2) security, authorize BMCP and BCSS as started tasks under started task control.
For resource access control facility (RACF) or TOP SECRET security, authorize BMCP and BCSS as started tasks in the started task table.
Authorized program facility (APF) authorization for a ll STEPLIB and JOBLIB libraries (PACLOG and XCA)
Note
When all of the following circumstances exist, add ALMUMAN to the list of commands in the TSOCMDS module:
You use the PACLOG logging environment modeling tool
You use the CA Technologies CA-ACF2 security system
Your shop restricts TSO commands
DB2 environment settings
BMC Software recommends that you always set up your DB2 environment as follows:
Use dual active logs to provide backup in the event of a disk failure that affects one log.
Use the PACLOG logging environment modeling tool to calculate the optimum size for your active log data sets.
Keep a minimum of three active logs to allow operation to continue unimpeded in the event of a failure involving one of the logs. If you use PACLOG and keep one archive log on disk, you do not need more than three active logs. This practice helps to reduce log data redundancy because active data is replicated in the archive log.
Keep 1,000 entries in the BSDS.
Recommended archive log processing practices
When you use PACLOG, BMC Software recommends that you follow these guidelines.
These should be considered in conjunction with the information provided in PACLOG in disaster recovery.
Use dual archive logs at your local site. If a DB2 forward recovery becomes necessary at the local site that requires the use of the archive log, dual archive logging provides backup if the primary log fails.
If you plan to use archive logs for disaster recovery, create both primary and secondary offsite copies of the archive logs. Although dual logging does allow you to send the local backup copy offsite, if that copy were needed at the local site, the required data would be unavailable and the DB2 subsystem would hang. See the RECOVERY MANAGER for DB2 User Guide for more information about the use of offsite archive logs in disaster recovery.
To help you decide how frequently to run PACLOG against the local site archive logs, you can use the ALMEX01 sample job in the .SAMP data set. This example shows how to run PACLOG in simulation mode to determine the effect of processing multiple logs during processing. You can also find this example in Determining archive log size reduction.
If you are making offsite copies of archive log data sets as part of your disaster recovery contingency planning, run PACLOG as soon as practical after archiving the active log. For example, run PACLOG after the DB2 -ARCHIVE LOG command that forces the active log to be archived and prior to backing up the OS/390 and tape management catalogs. If practical, use the DB2 archive completion message to start PACLOG.
Use the LIMIT option when you begin using PACLOG; otherwise, PACLOG attempts to process all cataloged archive log data sets. Use LIMIT until all existing original log data sets have been processed. For more information, see Deciding which logs to process.
Catalog all original archive log data sets. PACLOG does not process uncataloged log data sets.
When you archive the active log, archive it to disk.
PACLOG and NGT Recover compatibility
NGT Recover fully supports log data sets that are created by PACLOG.
If you have any questions about how the products work together, contact your BMC Software technical support analyst for NGT Recover.
Comments
Log in or register to comment.