There are two ways to pass commands to the Database Synchronization Component service machine, through the SMSG command or through the ACF2DSC PARMS parameter file. The next two sections provide additional information.
The syntax of the SMSG DSC service machine command follows:
SMSG dscsm DSC {OFF|ON|KILL}
DSCOUT
DSCOUT(ID=userid)
DSCOUT(sysid)
DSCTRACE(ON|OFF)
ST
STATS
STATUS
RESETSTATS
SYSOUT {userid}
The following commands are transmitted to the Database Synchronization Component service machine through the ACF2DSC PARMS parameter file:
CCIVM(CCIVM|userid)
DSC {OFF|ON|KILL}
DSCADMIN(user1, user2, ..., user10)
DSCFILE(datasetname)
DSCLOCAL(sysid[(Jc)])
DSCNODES(sysid[([Jc][R])])
DSCOUT(ID=userid)
DSCTRACE(ON|OFF)
SYSOUT(userid)
The following list contains descriptions of each parameter:
Identifies the virtual machine that runs CAICCI, the Common Communications Interface component of CA‑CIS Services. The Database Synchronization Component uses CAICCI for communication requirements between nodes.
The entry method is the parameter file.
The user ID of the virtual machine that runs the CAICCI component of CA‑CIS Services.
Specifies whether the Database Synchronization Component is activated at startup. You must enter at least one of the DSC‑related control options at startup to use the Database Synchronization Component. If you do not specify one control option, DSC might not be activated until the next startup and no DSC control options are honored until that time.
The entry method is SMSG or the parameter file.
This node does not transmit or receive records from other nodes.
Loads DSC support modules into memory. Routing can start as soon as startup is complete.
The DSC subtask terminates and produces a dump of the virtual machine. Once the subtask is killed, you can reactive it using DSC(ON).
The following indicates that the user does not want to use the Database Synchronization Component.
SMSG dscsm DSC(OFF)
dscsm-Specifies the ID of the Database Synchronization Component service machine.
Identifies the virtual machines that are authorized to communicate with the Database Synchronization Component service machine through SMSG. You can specify up to ten virtual machine IDs.
The entry method is the parameter file.
Identifies the OS data set name containing the DSC recovery file. The data set must reside on the DASD volume or minidisk at virtual address x'600' of the server machine.
The entry method is the parameter file.
Contains the OS data set name of the DSC recovery file.
The following example indicates that the data set name for the DSC recovery file is CAI.ACF2.DSC.RECOVERY.FILE. Enter the following statement in the parameter file:
DSCFILE(CAI.ACF2.DSC.RECOVERY.FILE)
This file cannot be shared with another system.
Identifies the CCI sysid for this system and whether requests received from other CA ACF2 for z/VM DSC systems are written to a journal file.
The CCI sysid value for this system.
Creates a journal file for DSC commands received from other DSC systems.
Indicates a specific output class for DSC journal files. The default is A.
The following example identifies that the CCI sysid for this system is VMSYSA and that all incoming DSC requests are written to a journal file with a default output class of A.
DSCLOCAL(VMSYSA(JA))
Identifies the CCI sysids of the remote CA ACF2 for z/VM nodes from or to which DSC can propagate requests.
Note: When used in reference to the Database Synchronization Component, node refers to the unique identifier that is assigned to a node when it is defined using CAICCI. For more information on defining a node, refer to the CA‑CIS Reference Guide.
The entry method is the parameter file.
Specifies the CCI sysid of the remote CA ACF2 for z/VM nodes from and to which database sync requests are transmitted. For example, the following identifies nodes ABC123 and ABC456 as targets of DSC requests:
DSCNODES(ABC123,ABC456)
Creates a DSC journal file containing all Database Synchronization Component activity sent to this DSC node. This file is optional. The journal file is spooled class A as a default. You can change this by adding a class ('c').
For example, the following enables both nodes for journal files with ABC123 journal file as class A and ABC456 journal file as class E:
DSCNODES(ABC123(J),ABC456(JE))
Specifies this node is receive only. You can receive synchronization requests from another system, but you cannot send requests. For example, to make node ABC456 be receive only:
DSCNODES(ABC123(J),ABC456(JE,R))
Identifies the virtual machine that receives the DSC journal files. You can also use DSCOUT to close all or a selected DSC node journal file for output.
The entry method can be the parameter file. The syntax is:
DSCOUT(ID=userid)
Or the entry method can be SMSG, where the syntax is:
DSCOUT(sysid)
The user ID of the virtual machine to receive the DSC journal files. The default is id=SYSTEM.
The CCI sysid of the node whose journal is closed.
Note: When specified without operands, all DSC files are closed.
Enter the following command to close all DSC journal files for output:
SMSG dscsm DSCOUT
In the above example, dscsm represents the Database Synchronization Component service machine ID.
This option is used as a debugging tool. DSCTRACE allocates an internal DSC trace table. Use it only at the request of CA Technical Support.
The entry method is SMSG or the parameter file.
Activates the trace.
Indicates that trace is inactive or is deactivated. This is the default.
Performs both the STATUS and STATS functions described below.
Used mainly for techical support:
RPI= 233 VSD= 122 VSM= 122 VSU= 0 REC= 0 MRC= 111 MRP= 111
Count of sync requests from CA ACF2 for z/VM main processing. This count includes confirmations from CA ACF2 for z/VM main processing indicating that an incoming request was processed.
Count of sync requests sent out to target systems.
Count of acknowledgements received for outgoing requests.
Count of acknowledgements received for unknown requests.
Count of sync requests currently stored in the recovery file.
Count of sync requests received from target systems.
Count of acknowledgements sent back for incoming requests.
The VSD, VSM, and REC counters reflect multiple counts if there are multiple nodes defined. In other words, when a sync request comes in from CA ACF2 for z/VM main processing, it is converted into a separate request for each node it is sent to. Therefore, the VSD, VSM, and REC counts are incremented for these separate requests for each node instead of just by 1.
Returns the current status of the ACFSYNC machine. The values are very similar to the ACF2DSC PARMS file. Sample output follows.
DSC(ON) CCIVM(CCIVM)
DSCFILE 00% (CAI.ACF2.DSC.RECOVERY.FILE)
DSCADMIN(MAINT,OPERATOR,MIKE)
DSCOUT(SYSTEM)
DSCTRACE(INACTIVE)
DSCNODE(M002) STATUS(ACTIVE,SPOOL,RETRY) JOURNAL(031,Y)
SYSOUT(SYSTEM)
The percentage full for the recovery file displays on the DSCFILE line and the status of a particular node displays on the DSCNODE lines.
Resets the statistical counters displayed with the ST and STATS command. The REC= counter is not reset because it indicates the number of transactions in the recovery file.
Identifies the virtual machine that receives the server machine console log (which records operator communications, messages, and dumps).
The entry method for SYSOUT(userid) is SMSG or the parameter file.
The user ID of the virtual machine that receives the console log and server dumps. The default is SYSTEM.
Note:If the SYSOUT command is issued through SMSG without the user ID, the current console log is closed.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|