Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Alternate Indexes for Shared Data Table (SDT)

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Mon Sep 27, 2010 12:17 pm    Post subject: Alternate Indexes for Shared Data Table (SDT)
Reply with quote

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 ?
Back to top
View user's profile Send private message

Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Tue Oct 12, 2010 3:54 pm    Post subject:
Reply with quote

Hi All,

Assuming this is not possible... icon_smile.gif ..
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 ?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Tue Oct 12, 2010 4:28 pm    Post subject: Reply to: Alternate Indexes for Shared Data Table (SDT)
Reply with quote

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.

This is where a DB can come in real handy.

There doesn't seem to be an easy answer.

Bill
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6968
Location: porcelain throne

PostPosted: Tue Oct 12, 2010 4:43 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Oct 15, 2010 8:53 pm    Post subject:
Reply with quote

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... icon_razz.gif

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.. icon_redface.gif .. didn't notice initially the constraint on alternate indexes... after progressing a little only noticed this issue... icon_sad.gif

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... icon_smile.gif

Thanks a lot for your valuable suggestions.. icon_smile.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts copying data without knowing location arunsoods DFSORT/ICETOOL 6 Thu Jul 20, 2017 1:03 pm
No new posts VPUT SHARED cvnlynn CLIST & REXX 4 Wed Jul 19, 2017 9:46 pm
This topic is locked: you cannot edit posts or make replies. Fetching data from BAI File arunsoods JCL & VSAM 1 Wed Jul 19, 2017 4:28 pm
No new posts Loading data to table gives wrong for... Raghu navaikulam DB2 18 Thu Jul 13, 2017 2:11 pm
No new posts SQL - select data available in index Nileshkul DB2 3 Mon Jun 26, 2017 1:30 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us