Unconventional way of Dealing with Jobs during Upgrades with the help of programs

[former_member210615]

  Generally in support scenario we deal with situations wherein we require the need to either do upgrades or do hotfixes, then first thing that comes to our mind is what will happen to all my jobs as the upgrades are generally done by taking systems offline.

Immediately pops the question about process chain what will happen to them especially those one which will run during that upgrade period or should we remove them from schedule or add a delay to them.... so get trap into that vicious circle of thinking about those SM37 jobs, sometimes we miss out here is when we are dealing with the pretty widespread landscapes then it becomes quite difficult to keep a track of what all process chains we will be rescheduled or delaying, even when taking utmost diligence still can lead to huge escalation which proves to be nightmare for the people who are doing monitoring(both BASIS and BI).

while replying to one of the queries on SDN, i thought will be it will be a good idea to share my thought through my blogs about how we can tackle these kind of situations by taking an off the beaten track which can possibly avert a faux pas

When we are dealing situation what doesn’t trickle through our mind are few special programs that SAP has bestowed to us BTCTRNS1 and BTCTRNS2, these can prove to really handy.

BTCTRNS1 program suspend/de-schedule all the scheduled jobs, i.e. it move jobs to Status “Rescheduled due to Upgrade”. It will take all Scheduled and Released jobs and give them a "special" status by setting the status flag of each released job to Z. Although it won’t cancel running jobs and one more important functionality of this it won’t reset the time schedule of these jobs

Once you are finished with the upgrade and you are ready to restore them to their previous status simply run BTCTRNS2 which works the opposite to that of BTCTRNS1.

BTCTRNS2 would change the status of all jobs with the status 'De-scheduled due to upgrade' to 'Released', in a rescheduling them. it will stop temporarily a job called rdisp/btctime, which fetches Scheduled background jobs from TBTCT and TBTCS tables so that it might not lead to overflows

Let me give brief insight of this important parameter rdisp/btctime which is actually used in controlling background scheduler’s runtime, it generally has a default value of 60 sec. so if a job is scheduled to be executed and a background work process is available, the background scheduler passes the job to be processed to the available work process so that it can execute the job.
If the parameter value rdisp/btctime = 0 disables the background scheduler, so jobs scheduled for a specific time cannot be executed.

The batch scheduler which runs in dialog mode does not start any batches with status=Z, after running this program all the jobs are scheduled back to start immediately depending on parameter rdisp/btctime and number of BTC work processes.

All or some jobs start every rdisp/btctime seconds, until the queue of waiting jobs is emptied and this way so with the use of these two programs it also eliminates the next question that strike to us whether all the jobs will start at once leading to either delayed or sleep status to job as this overhead will be done by BTC. one thing to kept in mind is these programs don't effect any running jobs

SAP Note: 37425 might be relevant for scenarios like these