With versions of SUPERDEX prior to TPI list processing was an issue in some
cases.  For example, when a DBUPDATE happens on only one item of a
concatenated/composite index which contains two items from a dataset.
SUPERDEX
must have both parts to find the index to update the one part that has changed
via DBUPDATE.  SAMELIST (*) constructs of a DBGET list could get into problems
when SUPERDEX went back to get the needed data (second item) since the list
was
not reset to its prior value and therefore samelist (*) would possibly get
different items.

TPI SUPERDEX should not be a problem with samelist (*) processing.

tj

At 11:29 AM 12/4/98, Lee Gunter wrote:
>Superdex uses a "!" list descriptor to indicate DBGETs of Superdex indices,
>only.  This descriptor is not transferred to Image, AFAIK, so whatever list
>was effective on the last Image call should still be in place for
>subsequent calls.  I don't recall if this was a problem early on, but it
>shouldn't be, now.
>
>Lee Gunter
>
>
>
>
>From: "Paul H. Christidis" <[log in to unmask]> on 12/04/98
>      10:28 AM
>
>Please respond to [log in to unmask]
>
>
>To:   [log in to unmask]
>cc:    (bcc: Lee Gunter/BCBSO/TBG)
>Subject:  Re[2]: Turbo Image List Processing
>
>
>
>
>A small flag on this whole Image list discussion.
>
>Years ago, when TPI first arrived on the 3K, I remember that their
>documentation included a 'warning' about Image lists.  They indicated that
>since they were 'intercepting' the Image calls 'your' original lists could
>be changed and thus 'discouraged' the usage of some/certain constructs.
>
>Does anyone, in such an environment, know if this is still true?
>
>Regards
>Paul H. Christidis
>______________________________ Reply Separator
>_________________________________
> 



   Tim Joseph
   425-485-8536 (phone)
   [log in to unmask] (email)
   425-485-7801 (fax)
   http://www.bradmark.com/