In the past, it was often acceptable for a CICS system to be available during normal daytime business hours, perhaps for a total of twelve hours. This left plenty of time for the CICS system or application to be shut down and for supporting batch work to be run. There was no requirement to make business data available on the Internet.
CICS typically is active and then shut down in preparation for running batch work for some period of time each day. As soon as CICS has stopped, backups are taken of key data sets as a point of recovery. Then, batch jobs can be scheduled to run. If we have several jobs that update the same data set, they will run sequentially, because they could not share the data set for update. After the batch updates are complete, there may be a job to read the updated data and produce reports. Probably, another backup will be done at this stage. When this is complete, CICS can be restarted and will be active again. DFSMStvs allows us to extend the CICS window of availability.
How to extend CICS availability
There is increasing pressure to extend the availability of CICS systems. This is because of the need for better customer service which in turn requires longer service hours, or because 24 hours per day Internet access to core business applications is desirable to improve competitiveness, extend the range of customers served, or reduce costs.
You will probably start to use DFSMStvs so that you can meet new or changing business objectives. These objectives might include:
In each case, there will be new pressures on availability of your systems. One consequence of the need for greater availability will be that you cannot afford the CICS down-time caused by your existing batch window. The actions that you will need to take will depend on whether you can still tolerate a batch window (although it will be a shorter window) or whether you must aim for continuous availability: 24 hours a day, 7 days a week.
Reducing the batch window
There are several techniques to reduce the batch window, but each has drawbacks.
You can use the External CICS Interface (EXCI), which allows a non-CICS application program to call a CICS program. You would change application programs to use EXCI to pass data to a CICS server transaction, which would then perform the updates with all the facilities available to CICS. However, this needs major application changes, and requires that you provide a server transaction, but it does completely remove work from a batch window.
You can remove a data set from CICS file control while CICS is still running. You use the CEMT transaction to close the data set and re-open it as read-only. You could then copy the file and make batch updates to the copy while still providing read access to the original. After the updates are completed, you deallocate the old version and allocate the new, updated version to CICS. This does not remove work from the batch window, but does offer limited (read-only) access while updates are being done.
You can force VSAM to allow sharing by using SHAREOPTIONS (3) or SHAREOPTIONS(4) but all integrity and recovery issues concerning locking and logging become an application responsibility. The application changes needed to give you complete integrity and recoverability are probably too large to contemplate. For example, you would need to provide logging, locking, and commit, backout protocols such that a CICS transaction backout would not remove updates that were performed correctly by a batch job.
Finally, you can change transactions to collect updates while a data set is being updated in batch and apply the changes later. A memo file is used to collect new records, and transactions are changed to switch between the main file and the memo file when the main file is not available for updates or additions.
Inquiries must also check the memo file first. When the main file update or reorganization is complete, the contents of the memo file are copied into the main file and the switch is reset so that all accesses are now performed solely against the main file. This may have integrity problems depending on the functions that you provide. Adding new records may be safe, but updating existing records opens up the possibility of updating a record that has been updated elsewhere.
These methods provide some relief at the expense of added complication or reduced integrity and recoverability. It is clear that a more general solution to the problems of running batch updates for CICS VSAM data is needed.
VSAM Related Interview Questions
|IBM - VSAM Interview Questions||JCL Interview Questions|
|File Maker Interview Questions||IBM DB2 Interview Questions|
|COBOL Interview Questions||IBM-JCL Interview Questions|
|DB2 Using SQL Interview Questions||IBM-JCL&VSAM Interview Questions|
|IBM Mainframe Interview Questions||COBOL, CICS, JCL, VSAM, DB2 Interview Questions|
|Cisco Interview Questions||IMS/DB Interview Questions|
|Mainframe DB2 Interview Questions|
Vsam Problem Determination And Recovery
Managing Your Vsam Data Sets
Vsam Record Level Sharing
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.