Q
Problem solve Get help with specific problems with your technologies, process and projects.

Current information not reflected in VSAM files in CICS region

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

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchWindowsServer

SearchServerVirtualization

SearchCloudComputing

Close