halt execution of a batch program in some specific case



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

halt execution of a batch program in some specific case

Postby rdrsaurabh » Thu Oct 20, 2011 3:58 pm

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.
rdrsaurabh
 
Posts: 6
Joined: Wed Oct 19, 2011 9:03 pm
Has thanked: 0 time
Been thanked: 0 time

Re: halt execution of a batch program in some specific case

 

Re: halt execution of a batch program in some specific case

Postby expat » Thu Oct 20, 2011 4:33 pm

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
expat
 
Posts: 382
Joined: Sat Jun 09, 2007 3:21 pm
Has thanked: 0 time
Been thanked: 1 time

Re: halt execution of a batch program in some specific case

Postby Robert Sample » Thu Oct 20, 2011 4:44 pm

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.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 222 times

Re: halt execution of a batch program in some specific case

Postby dick scherrer » Thu Oct 20, 2011 10:44 pm

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. . .
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: halt execution of a batch program in some specific case

Postby Ed Goodman » Fri Oct 21, 2011 1:59 am

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?
Ed Goodman
 
Posts: 342
Joined: Thu Feb 24, 2011 12:05 am
Has thanked: 3 times
Been thanked: 17 times

Re: halt execution of a batch program in some specific case

Postby dick scherrer » Fri Oct 21, 2011 2:55 am

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. . .
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: halt execution of a batch program in some specific case

Postby Ed Goodman » Fri Oct 21, 2011 9:59 pm

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.
Ed Goodman
 
Posts: 342
Joined: Thu Feb 24, 2011 12:05 am
Has thanked: 3 times
Been thanked: 17 times

Re: halt execution of a batch program in some specific case

Postby dick scherrer » Fri Oct 21, 2011 10:09 pm

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
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: halt execution of a batch program in some specific case

Postby enrico-sorichetti » Fri Oct 21, 2011 10:44 pm

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
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2644
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 130 times

Re: halt execution of a batch program in some specific case

Postby dick scherrer » Fri Oct 21, 2011 11:02 pm

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Next

Return to JCL

 


  • Related topics
    Replies
    Views
    Last post