Posted: Mon Feb 10, 2020 5:09 pm Post subject: Does the Path actually contain data
Hi,
Strange to be posting a rather basic VSAM question but I have read the relevant section on VSAM Demystified and am still mystified.
When I define an AIX and define the PATH and do the BLDINDEX (we use KWIKKEY)- does the dataset that represents the PATH now contain all the data that's in the base cluster but in the order of the AIX?
I mean I can go to 3.4 and browse the dataset that represents the PATH.
I am confused because I saw a line on a website that said "Path name will have a catalog entry but path does not contain any records."
And also the fact that the very basis for the AIX and Path is to avoid having different "versions" of the VSAM dataset organised in different physical sequences. VSAM Demystified says " AIX eliminate the need to store the same data in different sequences in multiple clusters "
It also says " When a program opens a path for processing, both the base cluster and the alternate index are opened. "
So if that's the case then when I browse the Path am I really looking at the base cluster's data?
Is that why when I max to the bottom it says "Record numbers unknown"?
If I get more clarity on this, then I do have a follow-up question regarding how STARTBR and READ NEXT work in CICS...
Joined: 15 Dec 2009 Posts: 12 Topics: 0 Location: Atlanta
Posted: Mon Feb 10, 2020 6:00 pm Post subject:
Quote:
does the dataset that represents the PATH now contain all the data that's in the base cluster but in the order of the AIX?
This is the first misconception -- the PATH is a CATALOG entry and does not represent an actual data set. The PATH relates the alternate index to the base cluster name. The PATH is how you use the AIX to get to the base cluster.
If you look at the catalog for a VSAM sphere, you will see 7 entries -- base cluster name, base cluster data component name, base cluster index component name, AIX name, AIX data component name, AIX index component name, and PATH name. Only the data and index components have sizes because they are the only ones that contain data -- the other three are only catalog entries. The AIX stores the AIX key and its associated primary keys but nothing else of the data in the base cluster is stored in the AIX -- if you see data other than keys, you are looking at the base cluster.
does the dataset that represents the PATH now contain all the data that's in the base cluster but in the order of the AIX?
This is the first misconception -- the PATH is a CATALOG entry and does not represent an actual data set. The PATH relates the alternate index to the base cluster name. The PATH is how you use the AIX to get to the base cluster.
If you look at the catalog for a VSAM sphere, you will see 7 entries -- base cluster name, base cluster data component name, base cluster index component name, AIX name, AIX data component name, AIX index component name, and PATH name. Only the data and index components have sizes because they are the only ones that contain data -- the other three are only catalog entries. The AIX stores the AIX key and its associated primary keys but nothing else of the data in the base cluster is stored in the AIX -- if you see data other than keys, you are looking at the base cluster.
Thanks Robert. So when I browse the path, I'm seeing a view of the base cluster that has been resorted on the fly to reflect the AIX?
Joined: 15 Dec 2009 Posts: 12 Topics: 0 Location: Atlanta
Posted: Tue Feb 11, 2020 10:35 am Post subject:
Quote:
So when I browse the path, I'm seeing a view of the base cluster that has been resorted on the fly to reflect the AIX?
No, not at all. For each AIX, the record consists of some overhead bytes followed by the AIX key (which comes from the base cluster data set) followed by one (or more, if nonunique keys are allowed) primary key. If there can be multiple primary keys for the AIX, they are stored in the AIX record in the sequence that they were added in. So for the initial AIX build, the records will be in primary key sequence for each AIX key -- but if UPDATE is allowed and additional primary keys are added for the AIX key, they are stored at the end of the AIX record. Which means that, unless the data set is unloaded and rebuilt periodically, once updates start happening the order of primary keys presented when reading the AIX (PATH) will NOT be sorted.
So when I browse the path, I'm seeing a view of the base cluster that has been resorted on the fly to reflect the AIX?
No, not at all. For each AIX, the record consists of some overhead bytes followed by the AIX key (which comes from the base cluster data set) followed by one (or more, if nonunique keys are allowed) primary key. If there can be multiple primary keys for the AIX, they are stored in the AIX record in the sequence that they were added in. So for the initial AIX build, the records will be in primary key sequence for each AIX key -- but if UPDATE is allowed and additional primary keys are added for the AIX key, they are stored at the end of the AIX record. Which means that, unless the data set is unloaded and rebuilt periodically, once updates start happening the order of primary keys presented when reading the AIX (PATH) will NOT be sorted.
Robert Sample wrote:
Quote:
So when I browse the path, I'm seeing a view of the base cluster that has been resorted on the fly to reflect the AIX?
No, not at all. For each AIX, the record consists of some overhead bytes followed by the AIX key (which comes from the base cluster data set) followed by one (or more, if nonunique keys are allowed) primary key. If there can be multiple primary keys for the AIX, they are stored in the AIX record in the sequence that they were added in. So for the initial AIX build, the records will be in primary key sequence for each AIX key -- but if UPDATE is allowed and additional primary keys are added for the AIX key, they are stored at the end of the AIX record. Which means that, unless the data set is unloaded and rebuilt periodically, once updates start happening the order of primary keys presented when reading the AIX (PATH) will NOT be sorted.
Hi Robert,
Thanks for your forbearance. I find that we do have jobs that rebuild the AIX on a nightly basis.
I guess what I meant to say was that when I do view/browse the path (using FileAid or VSAM utitlities or whatever) I get to see the entire records this time in the order of the AIX. But it's obviously because the AIX is being first read and the matching record retrieved from the base cluster.
Wonder how many it retrieves at one go!
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
