RE: Efficient Code

["jt" <jt@xxxxxx>]

Didn't recall that was in TYPE(*MBR).  The query was to answer the question
"how many indices is the system actually keeping".  Optimizing was a
question I wasn't trying to answer.  I'm still not sure that it would be
that difficult to reformat *MBR output into something usable a-tall.. but,
as you said, pesky details...;-)

Btw, don't recall if it was you or who posted link to OS Director.  Looked
interesting, but only skimmed and didn't see pricing.  Looks like another
step towards Much More Advanced "autonomous computing systems", a la (what
we called in 80's and 90's) "Service Director"/Project eLiza.

| -----Original Message-----
| [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Buck

| >> "would be nice to have" report needing to show the files
| >> that could share the same access path, the ANZDBF*
| >> commands aren't much better than running the DSPFD
| >> commands.  There'd still be (a lot of?) programming
| >> to do to put it together
|
| > I'm unclear as to why a simple query wouldn't do the job??  Is the
| > information lacking in DSPFD *ACCPTH, to find (not only *LF
| relationships
| > but) number and names of the actual indexes being created by
| the system??
|
| TYPE(*ACCPTH) describes the key list, but not whether the file is actually
| sharing an access path.  TYPE(*MBR) will tell you what file owns
| this access
| path.  The programming bits (devil in the details) come in when
| you want to
| identify the candidates for access path sharing,