When an update to one of the CA ACF2 for z/VM databases occurs, the CA ACF2 for z/VM service machine generates and sends a database synchronization request to the Database Synchronization Component service machine. These synchronization requests are sent according to the selection criteria specified in the DBSYNC VMO record. There are four main selection options:
Updates to logonid records are split between the LIDS criteria and the LASTACC criteria. The LIDS selection synchronizes updates to logonid records, except for updates to logonids that are due to a logon validation that just changes the last access information. The LIDS selection includes updates due to logon requests if the password field was changed.
The LASTACC selection includes updates to logonid records due to logon validations that just change the last access information unless the password field was changed. Also, the ONCEADAY selection limits the synchronization requests the LASTACC selection generates to just one synchronization request per logon per day. This lets your site eliminate the overhead of synchronization requests for last access information when a logonid has multiple logon validations on the same day, but can still see what day the logonid record was last used for a logon.
The Database Synchronization Component service machine records the synchronization request in its recovery file. The recovery file retains this request until the target machine accepts it. After recording the request in the recovery file, the synchronization request is sent to CCIVM. CCIVM then sends the request to the target system. If the VM system or the Database Synchronization Component service machine restart, the transactions that were not processed in the recovery file are processed when the restart is complete. The ACF2DSC PARMS file defines several options for the Database Synchronization Component service machine, including the nodes the synchronization requests are sent to. This file is located on the 100 disk. All synchronization request activity can be written to journal files to allow for problem solving if necessary.
Incoming database synchronization requests come in to the Database Synchronization Component service machine through CCIVM from the originating system. They are then sent on to the main CA ACF2 for z/VM components. CA ACF2 for z/VM then makes the appropriate updates to the databases as follows:
Synchronization requests for the Logonid database are field level updates if the logonid record already exists in the receiving database. In other words, if the NAME field is changed on the sending system, only the NAME field (and the last update time stamps, and so on) is changed on the receiving system. If the logonid record does not exist, then the entire logonid record from the sending system is inserted into the receiving system database.
Synchronization requests for these database records are full record replacements. The full record from the sending system is inserted or replaced into the receiving system database. When a synchronization request is received in this case, the time stamp (TOD format) of the synchronization request record is compared to the time stamp of the record in the database. If the time stamp of the synchronization request record is not higher, the synchronization request is rejected. This prevents a synchronization request that was delayed because a link or process was down from replacing a more recent update to the database. For this reason, it is critical that all systems that are involved in database synchronization have their clocks synchronized to the same TOD (time of day clock) value.
If a synchronization request for a record to delete is received, then the time stamp of the delete (not the record) in the synchronization request is compared to the time stamp of the record in the database. If the time stamp of the delete is not higher, then the synchronization request is rejected.
Because there is a separate synchronization request generated for each change to a CA ACF2 for z/VM database record, subject to the selection options, be sure to take care when doing mass changes to the databases. A CHANGE LIKE or CHANGE IF can generate hundreds or thousands of synchronization requests. Larger sites should be aware of some of the CA ACF2 for z/VM settings, including the SYNCQLMT setting in the DBSYNC VMO record and the size of the recovery file. Also, the Database Synchronization Component service machine should be tuned so that it can get the resources it needs when it gets a large number of requests.
We strongly recommend that you limit changes to the databases that would generate a large number of requests to a relatively low activity time frame, such as a normal maintenance window. You can disable synchronization on each system, then perform the mass change on each individual system. After the changes are done, re‑enable synchronization. CA ACF2 for z/VM provides the ACFSERVE DISABLE SYNC and ACFSERVE ENABLE SYNC commands for this purpose.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|