× 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.



Hi Dave

You first said that LFs were not radix tree indexes - that is simply not the case - they are.

You have jumped to a different question.

If you look at the files in a library from the green screen, indexes, views, and DDS-based logicals ALL are listed as LFs.

An LF with a key is an index for all intents and purposes - same thing underneath - the code paths are identical for building both. Now an index IS an LF - with different attributes - this is an object-based system, so you have MI types of x19 for spaces (files, whether display or physical or logical) with subtypes that distinguish them from one another at the object level. Indexes and views have exactly the same subtype as non-SQL logicals - but there is some byte or flag or attribute area that identifies them as an SQL object and them which type - look at DSPFD on the green screen.

The fact you cannot see data in an index or even a view (at least from the green screen using non-SQL methods) is not surprising - you can't see data in an LF, either, unless you use RUNQRY, say. In fact, I just used RUNQRY () LIB/INDEX to see the data through an SQL index. I am seeing actual data. And you can name an SQL index in an RPG F-spec and it will work just fine.

A regular LF does NOT contain data - it contains an Access Path - that is the radix tree - always has done that. The matter of an LF having the ability to set a subset of the columns is not pertinent to its use as an index by the SQL optimizer.

Here are some examples

Work with Files

Type options, press Enter.
1=Create 3=Copy 4=Delete 5=Display phy
8=Display file description 9=Save 10=R

Opt File Library Attribute Text

CUSTDX01 VERN LF
CUST36IX VERN LF
ORDFILL VERN LF

CUSTDX01 is an SQL INDEX - as seen here in DSPFD on it

10/02/08 Display File Description
DSPFD Command Input
File . . . . . . . . . . . . . . . . . . . : FILE CUSTDX01
Library . . . . . . . . . . . . . . . . . : VERN
Type of information . . . . . . . . . . . . : TYPE *ALL
File attributes . . . . . . . . . . . . . . : FILEATR *ALL
System . . . . . . . . . . . . . . . . . . : SYSTEM *LCL
File Description Header
File . . . . . . . . . . . . . . . . . . . : FILE CUSTDX01
Library . . . . . . . . . . . . . . . . . . : VERN
Type of file . . . . . . . . . . . . . . . : Logical
File type . . . . . . . . . . . . . . . . . : FILETYPE *DATA
Auxiliary storage pool ID . . . . . . . . . : 01
Data Base File Attributes
Externally described file . . . . . . . . . : Yes
Linked to data dictionary . . . . . . . . . : No
File definition . . . . . . . . . . . . . . : DFN CUSTDX01
Data dictionary . . . . . . . . . . . . . : DTADCT VERN
SQL file type . . . . . . . . . . . . . . . : INDEX

Notice that it says "Type of file" = Logical
Further specialization occurs in DB File Attributes where it gives the "SQL file type"

Yes, indexes have a different page-size - that, however, is an operational control, not the higher level attribute of what KIND of file it is.

So that is just part of what you are missing, I believe. IBM has always said that views and indexes are special types of logical files - you really can believe them on this one.

Regards
Vern

-------------- Original message ----------------------
From: "Dave Odom" <Dave.Odom@xxxxxxxxxxxx>
Vern, et al,

Where I get my info there is a difference between a LF that may be an access
path and an true index created by the CREATE INDEX command, is from how they
look in the system and via Navigator. I"m also not sure a LF is constructed
underneath like an index either but you all probably know more about that.

When I take a look at a logical file it seems to have a structure, much like a
PF. You can see actual data. When I take a look at an index, I don't see the
same thing. The LF also doesn't seem to have the same page size, the index
being much bigger. It seems in a LF, you can have SQL to create a view and
therefore do things that don't seem to be available with an index. It appears a
LF can be accessed via a program to sort and present the data to a program in a
different way than how the data exists in a PF. An index is accessed "under the
covers" and from what I can see, can't be accessed directly by a program. Just
some of the differences I see.

On the system I work on, there a MANY LFs/access paths but they don't show up as
indexes via Navigator but an index does.

That, coupled with the traditional use of an index in a relational database vs.
a VIEW (LF to you all) makes them different animals. Why are my observations
so different between the two but yet you all say they are the same? What am I
missing?

Dave

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.