Further to my previous post, I recalled that there was a Washington System Centre manual on VSAM Sharing, written by Penny Hallsworth way back. (I believe Penny was the architect of batch LSR. She was definitely the only IBM UK employee I encountered who had any knowledge of VSAM in its very early days, when its Record management was "troublesome" to early users, myself included!).
In my archives I have a copy of it! GG22-9043 dated 1980. And it makes informative, if not gripping, reading. From it I have drawn the following conclusions based on your sharing issue. >From your description, I assume that both CICS and the batch job execute in the same LPAR. Therefore, only the first of the SHAREOPTIONS applies. That is (4). In addition, you indicate that the CICS application adds to the end of an ESDS, passing relevant information as to what and where to the batch job at submission time. SHR(4) does not allow "add to end" processing on an ESDS, since it could result in a change to the HURBA (which is maintained on a CI boundary for ESDS). Technically, you MIGHT get away with one or two additions if the CI still has space to accommodate them, but it is too risky, so it is banned. So SHR(4) is out of the question. That leaves SHR(3). SHR(3) allows multiple Reads and multiple Writes, but VSAM does not exercise any control or offer any assistance at all over such activity. It is up to the user to manage it with the Facilities available. There is a Catalog entry, a set of control blocks, a set of buffers, and the OPEN/CLOSE/ENQ/DEQ macros, all of which can influence what happens. OPEN, as part of its processing, creates a set of control blocks, one of which is the ARDB, which contains the HURBA sourced from the Catalog. If records are subsequently added to the end of the file, the ARDB is updated. The Catalog is not. CLOSE has two variants. * Full CLOSE flushes all buffers and writes any relevant changed data back to the Catalog (including the HURBA - from the ARDB) and dismantles the control block structure. * CLOSE TYPE=T is a "CLOSE-lite" in that it flushes all buffers and writes back all the changed data to the Catalog (including the HURBA from the ARDB) but does not dismantle the control block structure. A subsequent OPEN in the same address space recognises that a TYPE=T CLOSE was executed and uses the existing control block structures. At the risk of stating the obvious, you must ensure that a READ and a WRITE do not take place at the same time. Hence ENQ and DEQ can be employed to ensure synchronisation in both applications. As I am sure you are aware, you must carefully consider the deployment of these macros in a CICS environment. Within the CICS ENQ/DEQ I would suggest the sequence is WRITE, CLOSE TYPE=T (updating the Catalog and physically writing out any outstanding records), OPEN, and within the Batch ENQ/DEQ the sequence would be OPEN, READ (using the latest HURBA update to the Catalog and the records written due to the buffer flush), CLOSE (full). No warranties, etc, but I hope this helps Mike Kerford-Byrnes ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
