Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi All,
Is there anyway to implement the Shared Data Table concept for alternate indexes...
From the manuals...
Quote:
Only the base VSAM cluster can have a CICS-maintained data table based on it. Read requests via alternate index paths do not use the data table, but changes to the source data set via alternate index paths are reflected in the data table.
In our system we are having a VSAM which is having around three alternate indexes. The file is accessed frequently. We were thinking of having this file as an SDT (CMT) as this will help our performance. But we are noticing the above issue now only... Any sugestions ?
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi All,
Assuming this is not possible... ..
Continuing on with the requirement. ...
The data we are planning to use in this table is reffered to frequently so the guess is maintaining the data in CMT is the best option... Which of the following approaches are better ...
Approach 1
Maintain the read as alternate index. This would mean data each AIX READ is done from the source data set (DASD)
Approach 2
In case of situations where we need to do Alternate Index... a sequential read will be done on the same VSAM...
Considering performace to be a main factor, what are the suggestions on which approach we could folllow ?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Binop,
Just a guess, but what would be the effort (in Batch) to convert each alternate index to its own VSAM cluster, defined as a CMT, as long as each is Read Only?
CMT/Read-Only clusters also have an advantage as they can be defined to an FOR/DOR for all AOR's and the I-O is from memory, not DASD.
If you need to update a CMT, then you might as well make it a normal VSAM file, with optimized characteristics and optimal LSR buffering.
Would these clusters be large?
I understand the overhead you're considering if left as a Prime cluster with three Alternate indices. Once you have more than one Alternate Index defined to a Primary, then VSAM performance has the potential to degrade.
The problem you'll have is informing the CICS application, which cluster to read?
If you write a GLUE Exit-Program (or a TRUE) to intercept the READ of the Primary and then alter the RIDFLD, FILENAME and KEYLENGTH of the API in the Exit-Program, to one of the three Alternate File Name's, you could avoid Application Program changes. But, I'm over simplifying this and it may not be worth it as the Exit-Program would require specific intelligence to make these correct alterations.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
The literature implies that a vsam file with multi-alt indexes is not a good candidate for SDT.
have you gone thru the checklist for SDT candidates?
have you investigated other possibilities of improving your performance?
not knowing anything about your vsam file, except you are having performance problems,
I tend to suggest alternatives,
but,
instead of having AIX's to the vsam file, you could build other KSDS's,
which would be:
alt-key (as primary key of this new file)
primary-key of original file (as data in this new file)
then load all 4 ksds files as SDT's.
the above suggestion would improve your access performance
but would require additional programming to accomodate
deletes
new record inserts
updates involving changing of alt-key
again, the above suggestion is made because
existing logic is not the performance problem
the base vsam is not HUGE
there is multi-regional activity
i just noticed Bill O'Boyle posted before I could submit my thoughts,
but, since Bill and I seem to echo one another, I will leave my post as is.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi All,
Apologize for the delayed response...
Bill O'Boyle wrote:
Just a guess, but what would be the effort (in Batch) to convert each alternate index to its own VSAM cluster, defined as a CMT, as long as each is Read Only?
The effort should be minimal only... and to my knowledge the file is mainly for read purpose only... Very rarely the file could get updated..
Bill O'Boyle wrote:
Would these clusters be large?
Not really... The VSAM would have around 150 records with 25 bytes each...
Bill O'Boyle wrote:
If you write a GLUE Exit-Program (or a TRUE) to intercept the READ of the Primary and then alter the RIDFLD, FILENAME and KEYLENGTH of the API in the Exit-Program, to one of the three Alternate File Name's, you could avoid Application Program changes. But, I'm over simplifying this and it may not be worth it as the Exit-Program would require specific intelligence to make these correct alterations.
actually for file reads we have a control program to do some file related processing before doing the actual read/write operation.. As of now this behaves like the GLUE program...
dbzTHEdinosauer wrote:
have you gone thru the checklist for SDT candidates?
have you investigated other possibilities of improving your performance?
Actually i started with UMTs suggested my one of my senior.. the research led to CMT as a better option to UMT... and to my negligence.. .. didn't notice initially the constraint on alternate indexes... after progressing a little only noticed this issue...
dbzTHEdinosauer wrote:
hen load all 4 ksds files as SDT's.
again, the above suggestion is made because
existing logic is not the performance problem
the base vsam is not HUGE
there is multi-regional activity
As told above, the VSAM is comparitively of small size.. As Bill also suggested, I am inclining towards this approach of having 4 different sets of VSAM with each loaded as SDT...
..
.. didn't notice initially the constraint on alternate indexes... after progressing a little only noticed this issue... 
