SFS Log Name Table Changes
Additions to the file pool log name table occur automatically when new participants are recognized or when old participants change their log names or communications characteristics, obsoleting previous entries. Occasionally you may consider deleting obsolete entries to make room for additional space in the table.
- Local fully qualified LU name, representing the local source of SNA network communications
- Remote fully qualified LU name, representing the target for SNA network communications
Whenever an SFS user initiates communications with a file pool, there is an initial exchange of log names between the file pool and the recovery server at the originating application node. This ensures the file pool and the CRR recovery server each have consistent log data about the units of work that might require resynchronization. Both the file pool and the recovery server record their communication partner's log name in their own log name table, identified by LU names and TPNs as described above.
- SNA network IDs (first part of the fully qualified LU name)
- Gateway names (second part of the fully qualified LU name)
- SFS file pool IDs
- CRR recovery server startup parameter (fully qualified) LU name which is the basis for formulating the recovery server's identifying TPN
- From TSAF or ISFC to SNA communications, or from SNA communications to TSAF or ISFC
- When changing identifiers such as file pool IDs and gateways (changing gateways affects fully qualified LU names for SNA network participants) be certain not to select names that already exist in the name space. For file pool IDs the name space is a TSAF or CS collection; for gateways it is the SNA network.
- Where the change is SFS originated, such as a change in the file pool identifier, use the QUERY LOGTABLE operator command to identify all recovery servers affected by the change, and notify the appropriate administrators to clean up their log name entries accordingly. Where the change is recovery server originated, the file pool administrator is notified by the CRR recovery server administrator. For more information, see QUERY LOGTABLE.
- Avoid inconsistencies by making changes only after quiescing CRR activity. If the change is file pool originated, such as changing the file pool identifier, CRR activity is usually quiesced as a byproduct of the step below, involving the erasing of the obsolete log name table entry. When there is outstanding CRR work, the attempt to do this erase fails. When the outstanding work completes, the erase can be completed. It is probable that changes are CRR application user or recovery server originated, such as a change in communications path to the file pool. In this case the quiesce is accomplished by the CRR administrator by stopping the associated recovery server. If a change is made during usual CRR activity, you could encounter inconsistencies in log name entries.
- Clean up obsolete log name entries for the file pool using the
ERASE LUNAME operator command. For more information,
see ERASE LUNAME.
Note: Although SNA network identifiers (first part of the fully qualified LU names) would not usually change, in this case you should erase log name entries before the network change takes place. These entries are those that include fully qualified LU names based on the old network identifiers.
See CRR Log Name Table Management for an example of changing the gateway used to communicate with a CRR participant. SFS commands for log name table query and erase are similar to those used for recovery server log name table maintenance, which are described in CRR Log Name Table Management. The file pool is one example of a participant that could be affected by such a change.
For changing the file pool identifier, see Changing the File Pool ID.