Hi Patrick,

Thanks for the response.  My next questions are with regard to our
specific IMAGE application, AMISYS.  We have a dataset called 'SERVICE',
whose paths are as follows:

    SERVICE          Detail                  Set# 173  Chunk Count: 2
       Entry:                     Offset
          CLAIM#               X12     1  (!CLAIM-A(SERV#))
          SERV#                X16    13  (SERVICE-A)
          MEMBER#              X12    29  (MEMBER-A(YMDEFF))

This application supports a lot of OLTP.  A doctor, or a member, might
call and inquire about their claims, and thus it would make sense for us
to REPACK the dataset using the MEMBER#.  That way, a customer service
rep could pull up all the claims incurred for a given member, and
proceed in assisting the caller.  

From another perspective, it would also make sense to REPACK the dataset
using the CLAIM#, because a given claim might contain multiple SERVICE
records.  

As for SERV#, it would not make sense to REPACK by this path because
this key only leads to one service record in the data-set.

So then.... since a given claim is only for a single member, would it
make sense to REPACK the database using the SORTED+ option, by MEMBER#
first, and by CLAIM#, secondarily?  That way, retrieving service records
by MEMBER# would be quick, as well as by CLAIM#.

Eben

-----Original Message-----
From: Patrick Mullen [mailto:[log in to unmask]] 
Sent: Tuesday, January 21, 2003 8:39 AM
To: Eben Yong
Cc: [log in to unmask]
Subject: Re: [HP3000-L] ADAGER REPACK question: difference between
SORTED+ and CHAINED+

Eben,

>With regard to the REPACK DATASET option, I would like to know the
>difference between the SORTED+ and CHAINED+ options, IF the
>reorganization takes place based upon the primary index key in a detail
>dataset.  In other words, if I select SORTED+ and tell it to repack
>based upon the primary index key in a detail dataset, how does that
>differ from selecting CHAINED+ and repacking based upon the primary
>index key in the detail dataset?


The Chained option repacks detail entries with like search field values
physically adjacent on disc while maintaining their chronology.  The
final
order of the search field value groupings in the detail is determined by
the master's physical order.

The Sorted option repacks detail entries based upon the 'sort key's
value'
(you can choose any field in the set as a sort and up to 4 fields).

In your query, you ask about using the primary path's value as the
'sort' key.
That would repack the detail as chained optimization would plus it would
produce a physical sort of the detail based upon the sort key's value.

Although the sorted option was created to repack the detail for
optimizing
serial access, you may use it as you describe, however.  From a point of
view of system resourses and elapsed time, the sorted repack would be an
order of magnitude or two greater than repacking with the chained
option.

If your intent is to optimize chained reads, I would suggest that you
use
the 'chained' option which Adager offers as a default.

Hopes this answers your question.

Patrick
 _______________
|               |
|               |
|            r  |  Patrick                   [log in to unmask]
|          e    |                            http://www.adager.com
|        g      |  Patrick Mullen
|      a        |  R & D Labs / Technical Support
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000             U.S.A.
|               |
|_______________|

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *