CA OPS/MVS lets you merge live OPSLOG data from one or more systems into a local OPSLOG. To merge live OPSLOG data, use the OPSLOG Merge OPSVIEW panel (Option 7.1.5). The panel lets you merge live OPSLOG data from selected systems for a specified date and time range. The merged data is loaded into a local OPSLOG also specified on the panel. The local OPSLOG that contains the merged data can then be browsed, profiled, accessed through the OPSLOG built-in function, and viewed with OPSLOG Webview, just like any OPSLOG.
The OPSLOG merge function requires the CA OPS/MVS MSF facility and MSF license.
Note: For more information about how to use the OPSLOG Merge panel, see How to Merge Live OPSLOG Data from Multiple Systems (Option 7.1.5) in the OPSVIEW User Guide.
Consider the following information and configuration requirements before you perform an OPSLOG merge:
The merge process loads the extracted OPSLOG data into a local OPSLOG specified by log name on the OPSLOG Merge panel. The specified OPSLOG must be read-only and activated, and it cannot be the local live OPSLOG. The specified OPSLOG can be either an in-storage OPSLOG or an OPSLOG DIV dataset. If the OPSLOG specified on the panel does not exist and the Create parameter on the panel is set to Y, a maximum size, in-storage OPSLOG is created automatically with the specified name.
Loading the merged records into an OPSLOG is not required. If you specify a log name of *NONE* on the panel, the records are sorted into a merge dataset, but not loaded into an OPSLOG. The *NONE* option is most useful when used in conjunction with a value of Y for the panel Save Data parameter. When you set Save Data to Y, the merge dataset is saved and can later be loaded into an OPSLOG dataset using the OPSLOG Load OPSVIEW panel (7.1.6).
Note: To create a local OPSLOG to contain the merged data, see the OPSLOG-related content in the Initialization section.
During the merge process, several work datasets are allocated on the requesting and selected systems. The work datasets include the following datasets:
An extract dataset is allocated on each system that is selected for the merge. The selected system writes the requested local live OPSLOG data to the extract dataset.
A merge dataset is allocated on the requesting system. The requesting system sorts the records from all extract datasets into the local merge dataset.
Sort message and control datasets are allocated on the requesting system during the sort of extracted records into the merge dataset.
After the records in the merge dataset are loaded into the specified OPSLOG, all work datasets except the merge dataset are deleted. Deletion of the merge dataset is controlled by the panel Save Data parameter. If Save Data is set to N, the merge dataset is deleted. If Save Data is set to Y, the merge dataset is saved.
The dataset names for the work datasets are a combination of the dataset name prefix that the OPSLOG merge panel specified, the internal request number, and system identifiers for the requesting (origin) and selection (target) system. The additional qualifiers are automatically appended to the dataset name prefix.
Work dataset formats:
dsnpref.osmfidx.reqnum.tarsys.tarsub – extract datasets
dsnpref.osmfidx.reqnum.SORTMSGS – sort message dataset
dsnpref.osmfidx.reqnum.SORTCNTL – sort control statement dataset
dsnpref.OPLGMGosmfidx.reqnum.OUTn – merge dataset (sort output dataset)
Specifies the dataset name prefix. The prefix allows up to 17 characters and the prefix conforms to standard dataset naming conventions of up to 8 characters per qualifier.
Specifies a number 1 through 9 appended to the .OUT qualifier of the merge output dataset. The number is appended automatically and provides for up to 10 output datasets with the same prefix and request number.
Specifies the origin (requesting) system smfid and the fourth character of the origin system CA OPS/MVS subsystem identifier (represented by x).
Specifies the request number in format Rnnn. The nnn indicates the 1-34 digit internal request number.
Specifies the target (selected) system sysname.
Specifies the target (selected) system OPS/MVS subsystem.
The work datasets are allocated with the following allocation values:
Extract Datasets
Note: CA OPS/MVS calculates the space that is required for the allocation automatically based on the number of records that are extracted on the selected system. Additional allocation parameters available for panel specification are UNIT, VOLUME, STORCLAS, MGMTCLAS, and DATACLAS. The combination of allocation parameters must result in the extract dataset being allocated on DASD shared between the requesting and selected systems.
Allocation and security requirements for extract datasets:
Merge and Sort Datasets
Note: CA OPS/MVS calculates the required space for the sortout/merge dataset based on the number of records that are extracted on the selected system.
Allocation and security requirements for sort datasets:
You can use several available merge methods for the extraction process. For each merge request, the OPSLOG Merge panel specifies the method for extraction. The following list describes the available methods and their associated configuration requirements:
The process for extracting the live OPSLOG records into the extraction dataset is performed in an OSF server on each selected system.
The OSF server must have the correct security to create, allocate, and write to the extraction dataset.
The process for extracting the live OPSLOG records into the extraction dataset is performed under a started task running on each selected system. The task starts and stops on each selection system for each merge request.
The started task must have the correct security to create/allocate and write to the extraction dataset.
Important! The TSO user that initiates the merge request must have the authority to start the task on the selected systems.
The distributed CCLXCNTL library provides a sample started task that is named OPSLOGXT. Copy the sample started task to a procedure library that is accessible by each selection system. Update the started task for your environment.
Note: If you only use the OSF merge extract method, the STC configuration steps are not necessary.
Consider the following security definition and configuration requirements:
The merge process creates, allocates, reads, writes, and deletes extract datasets. The extract dataset name begins with the specified dataset name prefix.
The TSO user that initiates the merge request requires access to read and delete the extract datasets on the initiating system.
If you select the OSF method, and you set OSFSECURITY to CHECKUSERID, the initiating TSO user requires access to create, allocate, and update the extract datasets on the selected systems. If you set OSFSECURITY to NOSECURITY, the OSF server user id requires access to create, allocate, and update the extract datasets on the selected systems. If you select the STC method, the started task user id requires access to create, allocate, and update the extract datasets.
To provide security for extract dataset access, make sure your system security definitions for the initiating TSO user id provide the appropriate access to datasets with the specified dataset name prefix as the high-level qualifier.
The merge process creates, allocates, reads, writes, and deletes merge and sort datasets. The merge and sort dataset names begin with the specified dataset name prefix.
The TSO user that initiates the merge request requires access to create, allocate, read, write, and delete the merge and sort datasets on the initiating system.
To provide security for merge and sort dataset access, make sure your system security definitions for the initiating TSO user id provide the appropriate access to datasets with the specified dataset name prefix as the high-level qualifier.
The merge process utilizes global variables for generating the internal request number, cross-system communication and status. The request number global variable begins with the prefix GLOBAL0.#OPSLOGX#. The request number global variable is preserved across restarts. The communication and status global variables begin with the prefix GLVTEMP0.#OPSLOGX#.
Note: These variables are not preserved across restarts.
The TSO user that initiates the merge request requires read and update authority on the initiating system.
If you select the OSF method, and you set OSFSECURITY to CHECKUSERID, the initiating TSO user requires read and update authority on the selected systems. If you set OSFSECURITY to NOSECURITY, the OSF server user id requires read and update authority. If you select the STC method, the started task user id requires read and update authority on the selected systems.
To provide security for global variable access using CA OPS/MVS security rules, define security rules for global variable prefixes GLOBAL0.#OPSLOGX and GLVTEMP0.#OPSLOGX#. The following example shows an event definition for the rule:
)SEC OPSGLOBALGLOBAL0.#OPSLOGX#*
)SEC OPSGLOBALGLVTEMP0.#OPSLOGX#*
To provide security for global variable access with CA OPS/MVS external security, create security definitions for the following resources:
Resource: OP$MVS.OPSGLOBAL.GLOBAL0.#OPSLOGX#
Resource: OP$MVS.OPSGLOBAL.GLVTEMP0.#OPSLOGX#
Sample security rules for global variable access are available in the distributed CCLXRULS library. The sample rule names are SECLOGM1 and SECLOGM5.
The merge process utilizes MSF for communication.
The TSO user initiating the merge request requires read and update authority on the initiating system.
If you select the OSF method, and you set OSFSECURITY to CHECKUSERID, the initiating TSO user requires read and update authority on the selected systems. If you set OSFSECURITY to NOSECURITY, the OSF server user id requires read and update authority on the selected systems. If you select the STC method, the started task user id requires read and update authority on the selected systems.
To provide security for MSF access using a CA OPS/MVS security rule, define a security rule for OPSCTL MSF. The following example shows an event definition for the rule:
)SEC OPSCTL*
To provide security for MSF access with CA OPS/MVS external security, create security definitions for the following resource:
Resource: OP$MVS.OPSCTL.MSF
A sample security rule for MSF access is available in the distributed CCLXRULS library. The name of the sample rule is SECLOGM2.
The merge process utilizes underlying OPSLOG functions to access OPSLOG on both the initiating and selected systems, read records from OPSLOG on the selected systems, define, activate, delete, and deactivate an in-storage OPSLOG on the initiating system, and load records to an OPSLOG dataset on the initiating system.
The TSO user initiating the merge request requires authority to write records into a local OPSLOG, and potentially create an OPSLOG.
If you selected the OSF method, and you set OSFSECURITY to CHECKUSERID, the initiating TSO user requires authority to read records from an OPSLOG on the selected systems. If you set OSFSECURITY to NOSECURITY, the OSF server user id requires authority to read records from an OPSLOG on the selected systems. If you selected the STC method, the started task user id requires authority to read records from an OPSLOG on the selected systems.
To provide security for accessing OPSLOG on the initiating system using a CA OPS/MVS security rule, define a security rule for OPSCTL OPSLOG.
The following example shows an event definition for the rule:
)SEC OPSCTL*
To provide security for accessing OPSLOG, and to create an OPSLOG on the initiating system with CA OPS/MVS external security, create security definitions for the following resource:
Resource: OP$MVS.OPSCTL.OPSLOG
A sample security rule for OPSLOG access is available in the distributed CCLXRULS library. The name of the sample rule is SECLOGM2.
To provide security for reading records from OPSLOGs on selected systems using a CA OPS/MVS security rule, define a security rule for OPSBRW. The following shows an event definition for the rule:
)SEC OPSBRW
To provide security for reading records from OPSLOGs on selected systems with CA OPS/MVS external security, create security definitions for the following resource:
Resource: OP$MVS.OPSBRW
A sample security rule for OPSLOG access is available in the distributed CCLXRULS library. The name of the sample rule is SECLOGM3
The merge process utilizes the OPSRMT function to launch the extract process in an OSF server on the selected systems, when you select the OSF method.
The TSO user that initializes the merge request requires update authority on the initiating system.
To provide security for the OPSRMT access using a CA OPS/MVS security rule, define a security rule for OPSRMT. The following example shows an event definition for the rule:
)SEC OPSRMT*
To provide security for OPSRMT access with CA OPS/MVS external security, create security definitions for the following resource:
Resource: OP$MVS.OPSRMT
A sample security rule for OPSRMT access is available in the distributed CCLXRULS library. The name of the sample rule is SECLOG4.
Note: TSO user ids with OPER authority have access to CA OPS/MVS functions and they do not require the previously mentioned security definitions for global variable access, MSF access, OPSLOG access, and OPSRMT access. You grant OPER authority using your system security definitions.
CA OPS/MVS lets you load merged OPSLOG data from a previously saved merge dataset into a local OPSLOG. When you set Save Data to Y on the OPSLOG Merge panel, the merge dataset containing the sorted, merged records is saved. The records in the merge dataset can later be loaded into an OPSLOG dataset using the OPSLOG Load OPSVIEW panel (Option 7.1.6).
To load saved merged OPSLOG data, use the OPSLOG Load OPSVIEW panel (Option 7.1.6). The panel lets you load OPSLOG data from a specified saved merged dataset into a local OPSLOG also specified on the panel.
Note: For more information about how to use the OPSLOG Load panel (Option 7.1.6), see the OPSVIEW User Guide.
Consider the following information and configuration requirements before you perform an OPSLOG load:
The load process loads saved merged OPSLOG data from a merge dataset into a local OPSLOG. The specified OPSLOG must be read-only and activated, and it cannot be the local live OPSLOG. The specified OPSLOG can be either an in-storage OPSLOG or an OPSLOG DIV dataset.
Note: To create a local OPSLOG to contain the merged data, see the OPSLOG-related content in the Initialization section.
Consider the following security definition and configuration requirements:
The load process allocates and reads records from saved merge datasets. The merge dataset name begins with the specified dataset name prefix.
The TSO user that initiates the load request requires access to allocate and read the merge dataset on the initiating system.
To provide security for merge dataset access, make sure your system security definitions for the initiating TSO user id provide the appropriate access to datasets with the specified dataset name prefix as the high-level qualifier.
The load process utilizes underlying OPSLOG functions to access an OPSLOG and load records into an OPSLOG on the initiating system.
The TSO user initiating the load request requires authority to access and load records into a local OPSLOG.
To provide security for accessing and loading an OPSLOG on the initiating system using a CA OPS/MVS security rule, define a security rule for OPSCTL OPSLOG.
The following example shows an event definition for the rule:
)SEC OPSCTL*
To provide security for accessing and loading an OPSLOG with CA OPS/MVS external security, create security definitions for the following resource:
Resource: OP$MVS.OPSCTL.OPSLOG
A sample security rule for OPSLOG access is available in the distributed CCLXRULS library. The name of the sample rule is SECLOGM2.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|