Stan alertly points out:
> Glenn asks:
> > Surely this is the only instance in which a backup utility needs to
> > *inspect* the contents of what is being backed up. (Of course, it also
> > inspects the contents of its own "indirection" file, if one is specified.)
> >
> > Is there anything else on the horizon that has this "inspect me to see
> > what you *really* need" characteristic?

> CM KSAM?  Sure would be nice for STORE to automatically backup the key file
> if you specify only the data file (barring, of course, a keyword that says
> "hey...don't do that!")
>
> OTOH, CM KSAM key files aren't such a problem any more.

Good call! I'll get back to this momentarily...

> > Would there be any point in establishing a standard -- either a directory
> > or a naming convention -- which would say "whenever 'x' is to be backed up,

> A naming convention wouldn't help with IMAGE, I suspect.
> Instead, it would be Real Nice to have a facility whereby
> code/products/subsystems/applications could register with the
> root file the fact that file xxxx should be considered part of
  ^^^^^^^^^
> the database for the purpose of store, restore, secure, release,
> and/or purge.  This has been discussed a few times in the past
> couple of years, in SIGIMAGE.

Here the term "root file" is used because it applies to Image,
but what about the CM KSAM file mentioned above? Should the
data file in CM KSAM be considered a "root file"?

> > (One could argue that the root file already serves this
> > purpose, but it just seems wacky that a backup utility must examine
> > the contents of a given file type to know what REALLY needs to happen.)

> OTOH, what *else* should it examine?  Any other location is by definition
> disjoint from the root file, and therefore subject to getting out of
> synch with it.

I hear that loud and clear. Any time we talk of information that is
logically linked but stored in more than one physical location,
there is the possibility of getting out of sync. Such concerns
were, in fact, at the root of this thread.

Let's think about your idea above, but phrase it a bit differently:

  It would be Real Nice to have a facility whereby
  code/products/subsystems/applications could register
  with a "metafile mechanism" the fact that a reference
  to file xxxx should include a specific file SET for the purposes
  of store/restore, secure/release, and maybe purge.

I'm sure such a system could be devised. It would be of a consistent
format so that backup (and other) utilities would be free of understanding
the internals of various file formats. These utilities would not have to be
modified when a new feature (and a new supporting file) is added.

The single biggest problem I see with this is how to transport this
"metafile mechanism" to another system, so that it still applied to
the original fileset, but in its new location.

--Glenn Cole
  Software al dente, Inc.
  [log in to unmask]