|
[This, we profoundly hope, is the final resolution to "Is it real or is
it Memorex?" Tony and Barbara have signed off.]
Problem: Users can change a volume's identity via DCL and make the
ACS information stale. What should Argus do?
Case: ACS says "FRED is mounted on DUA5:"
$GETDVI says "MARY is mounted on DUA5:"
(The user went behind our backs and changed the volume name
or reinitialized the drive or something.)
Client issues a GET request with a filter matched by MARY
or FRED or both.
Potential complications:
1. ACS may have user data for volume FRED and device DUA5:
2. The server may determine that the current DUA5: is a different
disk from the DUA5: in the ACS (different geometry, etc.)
Resolution:
(1) First of all, this is an edge condition. Virtually any
decision will do.
(2) We ignore complication 1.
(3) If the current and former DUA5: are the same,
delete FRED from the ACS (including any user data)
create MARY in the ACS
hook MARY to DUA5: in the ACS
return MARY
return a TNT_STATUS1 indicating that the volume identity
changed
(4) If the current and former DUA5: are different,
delete FRED from the ACS (including any user data)
delete the old DUA5: (including any user data)
create MARY in the ACS
create DUA5: in the ACS
hook MARY to DUA5: in the ACS
return MARY
return a TNT_STATUS1 indicating that the volume identity
and disk identity changed
(5) If the client GET request would be satisfied by FRED but
not by MARY,
return nothing and make no ACS changes.
(6) We can imagine pathological cases where these rules
do the wrong thing. TS.
|