IBM Mainframe Forum

There is one requirement to halt execution of a batch program (sleep for some time) in some specific case say(dead lock or resource not available), after that it will again start executing again.

How to solve this.

Now why on earth would you want to lock an initiator for some time, thus preventing other work from processing.

You need to look at all possible causes for the problems and schedule the jobs so that the do not cause problems

There is one requirement to halt execution of a batch program (sleep for some time) in some specific case

This "requirement" comes from someone who knows nothing about mainframes. There is NEVER a valid reason to cause a batch job to "sleep" like you want. If the batch job cannot get needed resources, either schedule it to run at a different time or ensure the job doesn't start until the resources are available.

Hello and welcome to the forum,

There is NO good reason to put a process to sleep over a deadlock. . .

Indeed, there is no good reason to encounter a deadlock. If a deadlock happens, it is because of a design problem with the code in the conflicting modules. . .

You didn't say for HOW LONG you wanted it to stop. Do you mean for a few seconds? A few minutes? A few hours?

How long does the job run now? What is causing the deadlock?

I am just a LITTLE bit more accepting that there could POSSIBLY be a VALID reason for a real deadlock. I've seen it happen where certain systems are required to be up during the batch window. That can lead to multiple update attempts at the same moment. It's rare, but it is real in this day and age.

How much flexibility do you have to implement a change here? Can you add files to an existing COBOL program (and its JCL)? Can you get a schedule change made? Or are you the guy that got yelled at and needs to find a way to something that takes zero effort and has zero impact and makes the problem go away?

Oh, another question...is this an IMS or DB2 program with checkpointing? Or is it just a flat file job? Do you know about the deadlock BEFORE anything gets updated for that customer/case/whatever?

Hello,

What is causing the deadlock?

In my experience, every deadlock that i've helped resolve was due to code that should have been done differently. . .

Ahh...
I think I interpreted "deadlock" a little more loosely. I think of it as "not having access to something because something else is using it." As in, the system is doing a backup, or, another program has updated the segment and hasn't taken a checkpoint yet.

I think the rigid definition of deadlock has something to do with program A has record A locked, but needs to update record B; while program B has record B locked, but needs to update record A. I always called this a "deadly embrace." You coded around this by making sure all of the programs updated databases in the same order.

Yup, "deadly embrace" and "deadlock" are the same - and are preventable. Sometimes preventing this does take a bit of work, though (due to poor design). . .

"not having access to something because something else is using it."

Typically causes a "timeout" in a database.

d

in case of a deadlock both program will sit there <halted> waiting for the other to free the resource needed
a deadlock will be resolved only by <killing> one of the offending partners

Hello,

in case of a deadlock both program will sit there <halted> waiting for the other to free the resource needed
a deadlock will be resolved only by <killing> one of the offending partners

Long ago this was typically the case.

Currently (in all of the databases i've used in the last many years), the task that issues the lock that would cause the deadlock is terminated and the other proceeds with no error.