View previous topic :: View next topic
|
Author |
Message |
Abhi Nature
New User
Joined: 14 Dec 2011 Posts: 17 Location: India
|
|
|
|
Hello,
'DEFINE ALTERNATEINDEX' creates and relates the alternate index to the cluster. So why is it necessary to 'DEFINE PATH' which does the same (relates)?
Thanks. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Perhaps you can provide links to the documentation which shows they are the same? |
|
Back to top |
|
|
Abhi Nature
New User
Joined: 14 Dec 2011 Posts: 17 Location: India
|
|
|
|
Syntax for 'DEFINE ALTERNATEINDEX'
DEFINE
ALTERNATEINDEX
(NAME(entryname)
RELATE(entryname)
.
.
Other parameters.
Creates and relates (to base cluster) the alternate index.
Syntax 'DEFINE PATH'
DEFINE
PATH
(NAME(entryname)
PATHENTRY(entryname)
.
.
Other parameters.
If 'DEFINE ALTERNATEINDEX' creates and relates the alternate index to the base cluster, what is the use of 'DEFINE PATH'? |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
|
|
Back to top |
|
|
Abhi Nature
New User
Joined: 14 Dec 2011 Posts: 17 Location: India
|
|
|
|
I did read the manual before posting the question. But I don't think it answers the question.
I do understand that 'DEFINE PATH' is there due a reason, but I was wondering why would a PATH be required if we have already related it to the cluster during creation of alternate index.
In my opinion, the RELATE parameter (while creating alternate index) should already create PATH. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
|
|
|
|
Abhi Nature wrote: |
I do understand that 'DEFINE PATH' is there due a reason, but I was wondering why would a PATH be required if we have already related it to the cluster during creation of alternate index. |
Because DEFINE ALTERNATEINDEX indicates what cluster the alternate index is to be built from, but does not actually create a logical relationship between the base cluster and the index (if you access the alternate index directly, you will get data from the index, not the cluster). DEFINE PATH does create that relationship; you can access the path as if it were a KSDS with the alternate index as its primary.
Quote: |
In my opinion, the RELATE parameter (while creating alternate index) should already create PATH. |
:shrug: Take the matter up with IBM. My own opinion is that the RELATE parameter does not have anything to do, even by implication, with creating paths. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
The RELATE in the alternate index definition gives IDCAMS the base cluster data from which the data for the alternate index is read. Once the build of the alternate index is done, it exists INDEPENDENTLY of the base cluster -- the alternate index has a DATA component and an INDEX component just like the base cluster.
The DEFINE PATH establishes the connection between the alternate index and the base cluster. The DEFINE ALTERNATEINDEX does not do this -- it merely reads the data to build the index. If you refer to the alternate index with a DD statement, you get the alternate index -- and only the alternate index. If you refer to the PATH on the DD statement, the system opens both the alternate index AND the base cluster (since they are related via the PATH). |
|
Back to top |
|
|
Abhi Nature
New User
Joined: 14 Dec 2011 Posts: 17 Location: India
|
|
|
|
Okay. To conclude...
PATH is there due to one way in which VSAM was designed. There could have been another approach whereby PATH could have been avoided (like creating the path in first few bytes of the alternate index). But obviously PATH would be the most efficient way to use the alternate index (since IBM chose it).
Thanks everyone for your time and help. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Fine Manual wrote: |
The DEFINE PATH command defines a path directly over a base cluster or over an alternate index and its related base cluster. |
How would the DEFine of the alternate index do the first part? |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
Quote: |
Syntax for 'DEFINE ALTERNATEINDEX'
Code: |
DEFINE
ALTERNATEINDEX
(NAME(entryname)
RELATE(entryname) |
|
the general logical construct for things like that is ( usually )
( just forget about the quirks of idcam parenthetization )
DEFINE <the type of the entity> <name of the entity> <a list of the attributes of the entity >
and for an alternate index the attribute list contains/is the name of the base cluster
would it have been clearer if instead of RELATE the keyword would have been
Code: |
DEFINE
ALTERNATEINDEX
(NAME(entryname)
BASECLUSTERNAME(entryname) |
? |
|
Back to top |
|
|
Abhi Nature
New User
Joined: 14 Dec 2011 Posts: 17 Location: India
|
|
|
|
I agree that the important thing is what the parameter holds rather than what its name suggests. Instead of RELATE it could have been BASECLUSTER, but in either case 'DEFINE ALTERNATEINDEX' relates base cluster with its alternate index, or so it seems. If it does, then why 'DEFINE PATH' is needed, there was the confusion. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
the current design is to have the AIX and the BASE CLUSTER processing unbundled as much as possible,
for example
I have had a few times the need to process the AIX by itself,
quite a few IBM and non-IBM products have the same need
if the design had been the way You are proposing there would be no way to do what I outlined
anyway read and meditate on the redbook for which I posted the link. |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 590 Location: London
|
|
|
|
It is simple and logical..
The Base cluster is defined with a KEY to access the records, e.g looking from position 0 for a length of 8. You cannot have more than one key specified for the base cluster.
The AIX is defined with a different KEY to the base cluster, e.g. from position 10 for a length of 6, but the RELATE to the base cluster means you're looking at the same records in the base cluster.
You then do a BUILDINDEX which copies all the AIX key parts of the records in the base cluster into the AIX.
You then define the PATH which is a different name to the Base cluster and relate it to the AIX using the PATHENTRY.
Now, when you specify the PATH name to access the Base cluster, it uses the KEYS in the AIX to access the records in the base cluster. |
|
Back to top |
|
|
|