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!