"In their case, they use shareoption=4 so that they can update VSAM files from batch Cobol programs while at the same time CICS Cobol programs are also updating the files. They don't want to have to change their programs."
How do you plan to make that happen since in usually z/os CICS journals the changes to VSAM files and can back out updates? What happens if a record gets updated by CICS and then gets updated by a batch program to a different value, and then CICS backs out its original change? Joe On Fri, Oct 30, 2020 at 5:51 PM Tony Thigpen <[email protected]> wrote: > All, > > I have a z/VSE client that believes it is time to move to z/OS. But, > they have one big concern. They have a lot of ShareOption=4 VSAM files. > > For those that don't know it, ShareOption=4 files on z/VSE "work out of > the box" without any need for the application program to perform any > enqueue or dequeue. z/VSE automatically performs those functions, unlike > z/OS where the application has to handle the enqueue process. > > In their case, they use shareoption=4 so that they can update VSAM files > from batch Cobol programs while at the same time CICS Cobol programs are > also updating the files. They don't want to have to change their programs. > > From my initial research, it appears that this same function can be > reproduced on z/OS using DFHSMStvs. (And, it looks like VSAM-RLS is also > required to support DFHSMStvs.) > > Are we going down the right path? > > > Tony Thigpen > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
