Skip to Content

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

  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

You must be Logged on to comment or reply to a post.
    • Thanks Krishna!!
      Actually what happens is when the job already started i.e. running at the time of uprgrade the RNS1 program will move the state of job in suspended, if just have a look at it code you will see SJB for Jobs that were suspended for upgrade and excatly opposite happens when doing rescheculing by other programs which takes care of it


  • Hi Laksh,

    The subject matter of your blog is very productive for the BW Support projects. It helps us to explore on the Standard programs(BTC*)developed by SAP.


  • Hi Laksh,

    The analysis that you made for this programs are very usefull indeed. It help us in avoiding the lot of tedious work that we always do for suspending the process chains.
    Great Work Laksh… keep it up 🙂


  • I have found those programs on my ECC system.  It will be interesting to see how they work on my sandbox system.  I know we haven’t used them before.

    Great tips!


  • HI Laksh Arora,

    Unfortunately this did not work. I scheduled three process chains for 1:00:00, 1:15:00 and 1:30:00 on development.

    Run the program at 12:58:00, it suspended all the jobs with Released status and changed status to “Rescheduled due to Upgrade”.

    Run the program at 1:33:00, it changed the status of jobs to “De-scheduled due to upgrade” and all the process chains started executing at 1:33:00 itself.

    But I want the process chains to follow the sequence and execute with 15 minutes time difference.

    Is there any workaround for this?

    Please let me know.

  • Hi Laksh,

    That was a very useful information for all of us working in support. This will save a lot of time and will avoid any kind of confusion.