On Feb 11, 2008 10:37 AM, Ivica Brodaric <[EMAIL PROTECTED]> wrote: > > Another approach we've used in the past is a common file on each > > system disk that lists the purpose and change history (e.g. @WHATSON > > THISDISK). > > But if you format that disk, you lose @WHATWASON THISDISK as well! :-)
I consider that a feature, because the contents of that file may not be correct when you replace the entire contents. Obviously you could have an automagic process that scans the disks for this file and and reports the disks where the file is missing (or pretty old compared to what's on the disk). The file could also have information about backup requirements so that you can validate whether your backup selection has not missed anything. Keeping the file on the disk itself has the advantage that access to that file is automatic. The disadvantage is that it may be gone when you want to restore it, so the automagic process above should harvest the files and keep a 2nd copy somewhere. That also helps detect changes in the files. > I actually have a MDISKMAP COMMENTS file that contains userid, address and > comments for critical minidisks. That file is then used by my MDISKMAP EXEC > which can then display comments in the right-most column of the 132-column > listing. And it uses PIPEs and LOOKUPs extensively. It depends on the relative size of your world. When other people must make changes to your inventory, things tend to get ugly. Oh, and if you use a file in NAMES format, you could even use VMLINK to link the disks. And you could include SFS directories as well. Rob
