Within MCS, there are several options for monitoring ID management activity, including logging ID management events, viewing the status of allocated IDs, and reclaiming inactive IDs.
By default, when you log ID management events ot the MCS event log, only error logging is selected, but you can log additional events. To minimize unnecessary consumption of system resources, you should select additional event logging options only when troubleshooting ID management activities.
MCS provides several timeout values that work together to allow you to more safely reclaim allocated IDs that are no longer in use but which have not been released. Use caution when reclaiming allocated IDs; if you're not absolutely sure that an ID is no longer in use, there is some risk that duplicate IDs will be issued.
At the pool level, MCS provides two timeout options: Inactivity Timeout and Lease Timeout. These are pool properties, which are set when you configure a pool or edit its properties. At the global level, MCS provides a Communication Timeout and a Quarantine Timeout. These are general properties, which can be set at any time.
The inactivity timeout period and the lease timeout period (if implemented) are used together to determine whether an ID should be quarantined. For clients that don't implement those options, or for pools where those values have been omitted or set to zero (0), the communication timeout period performs a similar function.
When the quarantine timeout period elapses, the ID is eligible to be reclaimed. Quarantined IDs can be automatically reclaimed by MCS, or they can be manually reclaimed on a case-by-case basis. When an ID is reclaimed, it becomes available to be allocated to another client.
|Monitoring Applications and Sessions, Overview|
|Setting Options for Automatically Reclaiming IDs|
|Manually Reclaiming an ID|
|Configuring MCS Event Logging|
|Managing Host Access IDs, Overview|