Job contention with CICS issue

valadezm · New User Joined: 05 May 2006 Posts: 4

I have a situation which I hope some of you have encountered and have resolved.

We run a batch job around noon, the steps in this job, deallocate the vsam files via DADS in CICS in order to process. However, on multiple occasions the job was abending with file contention on the files we had previously deallocated.

After some research we found out that certain transactions were being executed in cics by the clients that would open the files in question causing the job to abend.

We came up with a temp solution. I added a step to the batch job that would

1. deallocate the files
2. disable the transactions (2 of them) that were causing the file open.
3. allocate and enable the transactions at the end of the job after program execution.

This has been working great so far until today, where when the batch job issued the disable command for the transaction, the transaction was actually executing in cics at the time of the disable command and it stopped updating causing some issues for the client.

Does anyone have any other ideas on how to handle this type of situation?

Thanks

dick scherrer · Posted: Fri Jul 18, 2008 10:14 pm Post subject:

Hello,

Is there a true business reason this batch job must be run in the middle of the day? What would be the cost to the organization if this did not run until after the online quiesced? Could the process run 2 tmes - once before the online and once after the online?

Several of my clients tried to do this in the past and all were unsatisfied because of the logistics. Most also discovered that the mid-day run was only a "want" rather than a "need".

These days, multi-user databases allow the concurrent execution of the batch jobs and the online in most situations.

valadezm · New User Joined: 05 May 2006 Posts: 4

Unfortunately there is business requirement as we need to meet a DTC (depository trust) requirement, so it does need to process at that time.

dbzTHEdinosauer · Posted: Sat Jul 19, 2008 4:27 am Post subject:

the design is incorrect. you should be generating some kind of esds log, timestamped - does not have to be a db2 timestamp, just a good down to millisecs timestamp. This will be used to provide a start and end point for your daily strip.

any decent online system that posts financial transactions to 'accounts/customers - whatever' normally has a simultaneous GL (general ledger) report (log file) generated. Then the esds is stripped by whatever application filter job to obtain the necessary data concerning events during a period. This esds file would never have contention - normally the report/log entries would be sent via TDQ (TDQ'S allow for recovery incase cics comes down) to start a task to format and actually do the esds write. Sometimes MQS queues (depends on whether the customer can afford to use something other than darkages technology), which trigger batch processes.

yeah, sounds like this idea would be a lot of work to an existing system. But over the years, I have learned to stay away from vsam (or db2) masterfiles during the online sessions. and the easiest way to do it is generate a 'report' item and send it someplace that everybody can access.

it's late, sorta long winded.

Terry Heinze · Posted: Sat Jul 19, 2008 9:49 am Post subject:

I contracted at a shop once that would run a batch update program against a file that was open to CICS. The batch job would generate a CICS transaction with the required parameters to accomplish the update. It's an expensive way to go but it is an option. Sorry, I don't recall the name of the software that allows this to take place. Maybe Google could help?