AdHoc Proposal & Market survey:
 
(Quest knows nothing about this until they read this - sorry - just an idea)
 
 Introduction:
 
 Quest has a set of routines that directly replace system Intrinsics that
support their Image database shadow products and stuff like NFS client.  HP
sells this under the name Share/Plex.
 
 The purpose of the Intrinsic replacement layer is to capture data before it
makes its way to the real Image (or system) routines.  Then the Quest layer
can do stuff with the data - like pipe update transactions across a network
to shadow another system, for example.
 
 The power to manipulate Image database update activities seem endless, but
noble of Quest not to interfere or alter the original (intended) transaction
that is passed on to IMAGE DBPUT, DBUPDATE, DBDELETE.
 
 Enter META data.  What is that?  Meta data describes things about an
activity or process, but isn't the actual process.  A good example for 3000
users is the SCHEMA meta data held in an IMAGE root file that describes the
function and structure of an Image database.
 
 ---
 
 My proposal:
 
 Someone (Quest or others) develop  a set of Meta routines that the intended
purpose _is_ to alter data before the DBPUT or DBUPDATE, that can capture
environment information and then can pass this information on to Image.
 
 "pass this on to Image" means:
 
  - Develop a naming convention (like QUEST-META-TIMESTAMP, QUEST-META-USER)
so that on a DBOPEN, the intercept routines can look for these names in the
Image root file and prepare to checkpoint what meta data needs to be passed
on.  There could be a large general purpose field that you could specify
fine grained field by field alterations or an exclusion field set to trigger
meta data collection.  The finer the grain - the uglier things get.
 
  - Meta data must be either edited within the Item list and data buffer or
simply done separately before the real Image update call.  Why before?
Because the item list can revert back to the application call after it is
done.  For the *; construct, a "last list" must be preserved somewhere or a
hook needs to be in image to query the last item list posted.
 
  - There needs to be a switch (a new mode?) to either view or not to view
meta data when an Image DBGET is performed.  This switch could be a wildcard
subset of programs that actually update or read the database - and let other
programs view the meta data.  All this info is available in the MPE environment.
 
  - Transformation functions like ADAGER would be largely ignored. So, there
needs to be a switch to allow a user to "select and set" meta data based
upon an AdHoc utility.
 
 
 What use is this?
 
 
 - The number one reason: if I could TIMESTAMP a record in IMAGE of the last
modification date/time without changing thousands of applications, I could
extract and export changed data to dissimilar systems (Solaris, NT, RS/6000,
IBM Iron).
 
 - The number two reason: I could add a unique SEQUENCE number to my DETAIL
sets, thus having MBF ODBC/SQL work for me much better!  HiComp Dennys, are
you listening?
 
 - If I had a Third Party Indexing Scheme (Omnidex, Superdex) or Image BTREE
feature I could use a chron job to simply wake up, do a fast date-time range
extract of changed records to other systems.  The BIG advantage here is
flexible synchronization abilities, all I have to do is alter a date-time
range to re-sync any period of time if bad things happened on the
distributed system.
 
 -  As distributed data becomes popular, I could use QUEST-META-USER to
audit who changed the records or fields.
 
There is sooooo much market potential here, I'm ready to write it myself!
But hey, 90% of this stuff already exists around third party vendors.
 
This is your wake-up call!