Re: VSAM file discrepancies
It sounds like your program has not implemented the IBM SHROPT(4 3) requirement for how to use ENQ/DEQ: "If your program is updating, after the update has completed the ENQ/DEQ bracket, the reader must determine the required operations for control block refresh and buffer invalidation based on a communication mechanism or assume that everything is not at the latest level and refresh each request." See https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idad400/crso.htm Most likely the function missing in your application is "buffer invalidation based on a communication mechanism" -- ENQ/DEQ is not enough if doing it at the individual update level (which sounds like what your program is doing). On Wed, Jan 20, 2021 at 2:19 AM Steff Gladstone wrote: > Greetings, > > We are trying to figure out how a VSAM file became compromised. That is, > even though the primary key is unique, when we do a REPRO, we see that the > data contains an extra record with the same key. > > The file is updated from two different computers via a batch COBOL program. > The share options are (4,3) and an enqueue (with parameter SYSTEMS) is > performed (using an assembler subroutine) before any update is done. The > site has a 3rd-party product from CA that propagates the ENQ from one > computer to the other. We even tested the ENQ and saw that an update from > the second computer was blocked when the first computer previously issued > an ENQ prior to its update. > > It looks as if an update in one computer has not been committed from memory > to disk before the update in the second computer occurs. Which definitions > are lacking that would prevent this from happening? > > Thanks in advance, > Steff Gladstone > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file discrepancies
I would create a second VSAM Dataset and REPRO the prior dataset into the new dataset. That should expose a duplicate key. Paul D'Angelo -- Original Message -- From: Steff Gladstone To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM file discrepancies Date: Tue, 19 Jan 2021 18:58:24 +0200 The duplication exists in the data, not in the index. On Tue, 19 Jan 2021 at 18:22, Cameron Conacher wrote: > A KSDS with duplicate full primary key values? > Are you sure? > > Sent from my iPhone > > > On Jan 19, 2021, at 10:19 AM, Steff Gladstone > wrote: > > > > Greetings, > > > > We are trying to figure out how a VSAM file became compromised. That is, > > even though the primary key is unique, when we do a REPRO, we see that > the > > data contains an extra record with the same key. > > > > The file is updated from two different computers via a batch COBOL > program. > > The share options are (4,3) and an enqueue (with parameter SYSTEMS) is > > performed (using an assembler subroutine) before any update is done. The > > site has a 3rd-party product from CA that propagates the ENQ from one > > computer to the other. We even tested the ENQ and saw that an update > from > > the second computer was blocked when the first computer previously issued > > an ENQ prior to its update. > > > > It looks as if an update in one computer has not been committed from > memory > > to disk before the update in the second computer occurs. Which > definitions > > are lacking that would prevent this from happening? > > > > Thanks in advance, > > Steff Gladstone > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file discrepancies
W dniu 19.01.2021 o 17:22, Cameron Conacher pisze: A KSDS with duplicate full primary key values? Are you sure? I'm sure it is possible. VSAM is just set of data... Data set on disk. ;-) Yes, it is hard to have duplicate key WHEN USING VSAM (access method). However is is enough to use CI mode or just ditto or file manager to make things interesting. However I admit - I cannot imagine how it could happen when using "regular" application. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file discrepancies
The duplication exists in the data, not in the index. On Tue, 19 Jan 2021 at 18:22, Cameron Conacher wrote: > A KSDS with duplicate full primary key values? > Are you sure? > > Sent from my iPhone > > > On Jan 19, 2021, at 10:19 AM, Steff Gladstone > wrote: > > > > Greetings, > > > > We are trying to figure out how a VSAM file became compromised. That is, > > even though the primary key is unique, when we do a REPRO, we see that > the > > data contains an extra record with the same key. > > > > The file is updated from two different computers via a batch COBOL > program. > > The share options are (4,3) and an enqueue (with parameter SYSTEMS) is > > performed (using an assembler subroutine) before any update is done. The > > site has a 3rd-party product from CA that propagates the ENQ from one > > computer to the other. We even tested the ENQ and saw that an update > from > > the second computer was blocked when the first computer previously issued > > an ENQ prior to its update. > > > > It looks as if an update in one computer has not been committed from > memory > > to disk before the update in the second computer occurs. Which > definitions > > are lacking that would prevent this from happening? > > > > Thanks in advance, > > Steff Gladstone > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file discrepancies
A KSDS with duplicate full primary key values? Are you sure? Sent from my iPhone > On Jan 19, 2021, at 10:19 AM, Steff Gladstone > wrote: > > Greetings, > > We are trying to figure out how a VSAM file became compromised. That is, > even though the primary key is unique, when we do a REPRO, we see that the > data contains an extra record with the same key. > > The file is updated from two different computers via a batch COBOL program. > The share options are (4,3) and an enqueue (with parameter SYSTEMS) is > performed (using an assembler subroutine) before any update is done. The > site has a 3rd-party product from CA that propagates the ENQ from one > computer to the other. We even tested the ENQ and saw that an update from > the second computer was blocked when the first computer previously issued > an ENQ prior to its update. > > It looks as if an update in one computer has not been committed from memory > to disk before the update in the second computer occurs. Which definitions > are lacking that would prevent this from happening? > > Thanks in advance, > Steff Gladstone > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VSAM file discrepancies
Greetings, We are trying to figure out how a VSAM file became compromised. That is, even though the primary key is unique, when we do a REPRO, we see that the data contains an extra record with the same key. The file is updated from two different computers via a batch COBOL program. The share options are (4,3) and an enqueue (with parameter SYSTEMS) is performed (using an assembler subroutine) before any update is done. The site has a 3rd-party product from CA that propagates the ENQ from one computer to the other. We even tested the ENQ and saw that an update from the second computer was blocked when the first computer previously issued an ENQ prior to its update. It looks as if an update in one computer has not been committed from memory to disk before the update in the second computer occurs. Which definitions are lacking that would prevent this from happening? Thanks in advance, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
