>Date: Fri, 1 Dec 1995 15:52:08 -0400
>Reply-To: Jon Diercks <[log in to unmask]>
>Sender: HP-3000 Systems Discussion <[log in to unmask]>
>From: Jon Diercks <[log in to unmask]>
>Subject: Re: Using TPI to extend IMAGE functionality: Field Time Stamps
>
>Great idea Eric, I'd love to be able to selectively implement record-level
>and/or field-level timestamping - while we're at it, we should try for
>user-stamping, so we can know who was the last user to modify a record or
>field.
 
The strategy would be to keep indexes intact as long as possible with a
planned "restart" break point.   However, I was only proposing time stamps
for synchronizing foreign systems.  Your introduction of other data (user,
etc.) requires modification of Image, like you said.
 
My idea is not "re-design" Image as you suggest, it is much more reasonable.
My idea could be implemented in a very short time frame but is far from the
ultimate, as you noted.  How long do you think it would take to modify the
internal file formats of Image and have that fly?  It only took 15 years to
get critical item update and that was a software re-engineering job!
 
No, I'm not prepared to bang on the doors of entrenched (1978) methodology
for the rest of my life.  It would be nice to have new features in the time
frame of an TPI product version release, say 6 to 8 months. How?
 
1) Create a new composite type of "ghost" to allow the insertion of a
dynamic time stamp information into the composite key.  Existing keyword
procedures can easily support data extractions and manipulations of these types.
 
2) Since composite items are made up parts of other fields, you can join
"ghost" data to "real" data - users choice.  The index software would simply
need to know which items are ghost fields so it can invoke a function to
obtain environment data rather than read/parse the data from an Image record.
 
3) If you re-build indexes, you have two choices.  a) Specify a single
default value for all ghost item values: a re-start point.  b) try to
export/import the ghost values.
 
4) My ideas are just that - mine:  Maybe there are good reasons not to do
anything like this or do it different?
 
Export/import of ghost data is problematic if your unique key for a detail
record number changes (and slows down re-builds).  However, this problem
could be solved if the export/import ghost data is tied to an index value
independent of physical detail record numbers.  This would handle Detpacks
or Master packs but not application changes to index values.  I'm not yet
convinced you need export/import.
 
I would option for a re-index single default value, easily encoded in the
TPI root definition.  Like I said, I was only proposing time stamps for
synchronizing foreign systems.  Your introduction of other data (user, etc.)
requires modification of Image - maybe.  It depends on the application at hand.
 
Yes, there are problems - but don't make my proposal more than what it is.
But for the immediate problem of tracking/extracting data changes in real
time - confined to definite restart cycles, this sounds good to me.
----------------------------------------------------------------
Eric J. Schubert                    Senior Data Base Analyst
Office of Information Technologies  Univ of Notre Dame, IN USA
(219) 631-7306                      http://www.nd.edu/~eschuber