We were ESP for TVS back in the day. The product held a lot of promise for (I would say) larger shops who had to do VSAM updates during a limited batch window. The problem to solve was recovering from some kind of failure. From the dawn of time, the logic was to back up everything in sight before beginning the update cycle. If a serious failure occurred, everything would be restored and restarted. This was a time-consuming procedure.
TVS allows a program to update a file that was concurrently open for read. No more need for mass backup/restore. But application programs for decades have been written to expect backup/restore. They would almost certainly need to be modified/rewritten to work with TVS. The end result would be great but difficult (read expensive) to achieve. We ended up not implementing the GA product. The cost of the product was less an issue than the cost of accommodating it. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Joe Monk Sent: Friday, October 30, 2020 4:41 PM To: [email protected] Subject: (External):Re: VSAM-RLS and DFSMStvs basic questions *** EXTERNAL EMAIL - Use caution when opening links or attachments *** Radoslaw, He is asking about shareoption (4 x) not (x 4) aka cross-region sharing, not cross-system sharing. In VSE, Shareoption(4) allows vsam file sharing among partitions (similar to a z/os address space). VSE manages that automatically, for the user. Joe On Fri, Oct 30, 2020 at 6:22 PM R.S. <[email protected]> wrote: > W dniu 30.10.2020 o 23:51, Tony Thigpen pisze: > > 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? > > IMHO no. > > Some remarks: > 1. Any migration will require some work to do. Sometimes little less > effort give you much worse results. > 2. SHR (x 4) means cross-system sharing. Why it is cross-system? Why > don't you consolidate it into one system? What are the reasons? > 3. VSAM RLS is almost free - that means it is not licensed, but it > require Coupling Facility - even in single system configuration. Such > kind of Parallel Sysplex. Even when you want to have single CPC, you > still need CPU engine for CF, that is ICF processor. It is approx. > 250k$ (for big machine). And some memory. However tvs is not necessary. Note: > tvs is paid, because there are ISV options. And there are some IBM > add-ons like CICSVR, etc. > 4. Let's go back to point 1 - maybe it is good time to move from VSAM > to Db2? Note, there is special software product which allow VSAM > application to work with Db2 with minimal changes. And of course you > would have a lot of Db2 advantages over VSAM, and any new development > could directly interface with Db2, not Db2 under cover of VSAM. Of > course neither the product, nor Db2 is free, but... > > > -- > Radoslaw Skorupka > Lodz, Poland ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
