× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Try DMPOBJ on a traditional logical file - you'll see 5 component objects, some internal, some external. There's
*FILE (MI type 1901) - a kind of header, I think - this is the external object type - DSPFD gets stuff from here
*FMT (MI type 1951) - describes the field layout - DSPFFD works from this?
*MEM (MI type 0D50) - cursor (member?, sort of, or pointers to?) RTVMBRD?
*QDDS (MI type 0B90) - data space
*QDDSI (MI type 0C90) - data space index


These all combine to describe an access path - the order of the records and a means for retrieval. I'm not clear on the function of each of these, but the last one looks like what describes a keyed access path. Maybe the *MEM is the funnel through which the data flows.

A multiple-member file has multiple *MEM cursor thingies (that's a technical term, ya' know!). And files can have multiple *FMT internal objects.

Every database system (or organized data storage and retrieval system) has stuff like this - has to - with defined areas that describe column layout and the order of record retrieval. dBase III+ had it in some form, even things like SYLK spreadsheet format have similar elements.

DMPOBJ does not show the actual data - you can get to it in SST but I'd need to dig a little to remember where everything is. But you can take the names of each section into SST Dump/Alter/... and see some interesting things. Do we hear knees knocking? <g>

Cheers

Vern

At 08:42 PM 4/24/2003 -0400, you wrote:
midrange-l-request@xxxxxxxxxxxx wrote:

>   4. access path (Leif Svalgaard)
>
>I have been working on and with this machine for upwards
>of two sunspot cycles, and I have a confession to make:
>I see references on this list and elsewhere to an "access
>path" to a file. I have studied the internals of this machine,
>I have looked far and wide, but I'm still baffled: what the
>h*** is an "access path"? where is it? what does it do?
>Why must it be "rebuilt" at times and what does that entail?
>Somebody enlighten me...

"...enlighten..."? Well, we'll see.

>From the venerable _IBM System/38 Technical Developments_ chapter 'System/38 data base concepts':

"All online data in System/38 is stored as records in data base files. A data base file has three primary attributes: the _format_ of records within that file, the _access path_ for the records within that file, and the _members_ of that file." And "The access path for a file defines the ordering of records within that file and provides for either random or sequential accessing of those records."

The interesting part is the reference to "attributes". Perhaps not an 'object' at all as such, but simply located at some offset in some space of the file object?

More detail is in the book, but none seems clear enough to help.

Tom Liotta



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.