Um, be careful about drawing any conclusions from a simple test other than the syntax is close. Data sharing is a very complex issue with gotcha's aplenty. You cannot possibly test every variation of access, update, and timings. The VSAM folks have, IMHO, done a fine job of preventing you from screwing up too bad. But VSAM is still not a DBMS and doesn't claim to be.
If the philosophy cannot change, then maybe neither can the solution. Yes, it can be really that simple. Now, this is not to say that one couldn't forge right on and things would seem to work just fine, maybe for years. Or maybe not. 'Unpredictable results' include seemingly successful tests. Imagine corruption slowly creeping in and not discovered until the last good backup has rolled off and the tape reused. I believe what you want to do is doable. But you just gotta follow the rules. If you do, then CICS and VSAM can work together to avoid corruption and enhance performance. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Kovach Sent: Thursday, April 05, 2012 3:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: A deep question about VSAM SHR(4) - can you help? Thanks Robert. That is exactly what I was thinking. Will be running a test early next week. Regards, Mike Kovach ________________________________ From: Robert A. Rosenberg <hal9...@panix.com> To: IBM-MAIN@bama.ua.edu Sent: Thursday, April 5, 2012 4:03 PM Subject: Re: A deep question about VSAM SHR(4) - can you help? At 07:16 -0700 on 04/05/2012, Mike Kovach wrote about A deep question about VSAM SHR(4) - can you help?: > I have a VSAM KSDS CLUSTER which is written to by ONLY ONE PROGRAM in ONLY > ONE CICS REGION. Currently, this file is defined in CICS with STRNO(1). The > file is defined with SHR(4,3) because while being written ONLY in CICS, it is > being read by a non-reentrent ASSEMBLER program running in BATCH. SHR 4 > forces VSAM to harden each I/O (yeah, I know!) so the BATCH gets the current > information. Please spare me all the comments about how poor this solution is > as it stands. It has been in place for decades and due to a myriad of > reasons, the philosophy CANNOT change. My specific question is this: I want > to introduce multi tasking so that 5 copies of the program can update the > file concurrently. If we change STRNO(1) to STRNO(5) on the CICS FCT > Definition, will VSAM be smart enough to manage the writes to the file so we > don't break it and the BATCH still gets the current information? So long as you are still using one CICS Region, I do not think you will run into problems. The STRNO(5) will allow you to have 5 CIs being updated at a time (one CI per copy of the program). If more than one copy attempts to access records from the same CI, it should cause the subsequent requesters to wait for the owning copy to finish its update and release/write the CI (just make sure that all your VSAM is being done by SubTasks which I think CICS does automatically). You should increase the number of buffers so there are enough for all the copies. > I am interested in any discussion you might share, but I am most >interested in a specific reference to a reliable document. Please >help. Thanks Mike Kovach > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
