We have a situation that is continually biting us that maybe you can help provide some guidance with. For our process,...
we have files open to CICS as read-only -- the share-opts are (2,3). In batch, we are updating these files on a continuous basis. There are times when a batch process has updated the VSAM file, however, when the user goes to retrieve these records they may not reflect the current information. Of course, when we open and close these files to CICS, they can see the correct info, but this is not a good long term solution. These files are defined as VB with a max size of about 28K. Do we need to address our CA and CI sizes, share options, etc. Any info you could provide would be great.
The consensus view on this one is that you are using too many buffers within the CICS region for your VSAM accesses. As you are only accessing the file in read-only mode, these buffers will contain exisiting bits of records and if nothing has occured which means that a new bit of data has to be fetched from the file (such as a the record not being found in the buffers or the buffer is dirtied in some fashion or parallel access requires resue of a buffer) you will get -- as you observe -- an ancient record. So, try reducing the number of buffers, which forces more reads from the file. This may, however, upset your performance. It's a trade off between accuracy and speed.
Another approach is to implement RLS for these VSAM files. This will enable batch updates at the same time as CICS reading them -- but this is probably going to be too much of an overkill. The best description of this (strangely) is in the migration from CICS 4.1 book.
Here is a sneaky design which will probably do most of what you want.
You don't say what the impact of doing these batch updates is upon the functions of your CICS region -- in other words, how vital is it that the accuracy of the info is up-to-date, is there an acceptable latency? I'm also wondering how you decide to CEMT CLOSE/OPEN the relevant VSAM files and what happens to the existing applications when they get a NOTOPEN condition. Let's assume that these applications will retry a few times before abending.
I'm fairly relaxed that the VSAM file records as seen by CICS will not be viewable until the batch job has finished doing its stuff. So, what you want to accomplish is the closing and immediate reopening of the VSAM files that have been altered by the batch jobs. Thus, why don't you add a step in the JCL to issue these CEMT commands. Just write a program in the CICS region that uses the File Control SPI and reads the names of the files from a Commarea. Then invoke this program using EXCI from the batch job into all the regions that contain the file.
I've done all the hard work for you in one of my SupportPacs. My utility will work from inside a Rexx Exec -- or even a pipe -- so you just add a little TSO step and trivially call your program in the required CICS regions. If you have a whole chunk of batch jobs going through, schedule this operation at the end of the sequence.
Also think about closing and opening the files in a timed CICS transaction (run every hour?) if you want something more predictable.
This should be good enough to force a buffer rebuild and so get the up-to-date info accessible by your applications. You also will not suffer any great performance penalties by artificially restricting the number of buffers used to access the file.
Dig Deeper on IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs? Continue Reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology. Continue Reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.