A VSAM file with an Alternate Index is updated online. Before doing the update, the alternate index is read through the path to see if it is a duplicate record. It is not getting the duplicate record error and the records are being written again. Could this be a buffer problem? We are running OS/390 2.10 and TS 1.3 and use LSRPOOLS for our VSAM files. The file is defined with SHR (2,3).
I assume you are reading the Alternate Index to see if there is the potential for a duplicate-record failure when you add the new record to the base cluster. And, that you are doing that because you do not allow duplicate keys in the Alternate Index. This technique will only work if you are using an Upgradeable Alternate Index so that the new alternate key is immediately available through the alternative access path.
Why not just rely on a VSAM update failure (with the upgradeable Alternate Index) if you attempt to add a record to the base cluster and thereby get a duplicate alternate key (when you do not permit duplicates via the AMS definition)?
CICS Technical Strategist -- CICS expert at Search390.com
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our .VO7aaqqaAFk.0@/search390>discussion forums.
Dig Deeper on IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs? Continue Reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology. Continue Reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.