Skip to Content
-1

Background job

Jul 06, 2017 at 11:44 AM

182

avatar image

Hi,

In my project they have configured a Autosys tool in which all the jobs have been scheduled. My basic question is i need to debug one of the SAP job which is scheduled there.

There are more than 100 jobs which runs in a hierarchy in that Autosys box. One job in this box is used to create material grid. It created a idocs for material grid creation.

I kept the external debugger in the Z function module in the process code and was waiting to stop, but it never did.

How to achieve this. Please help me.

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

3 Answers

Uwe Fetzer Jul 06, 2017 at 12:09 PM
4

This is the result of a simple search....


debug.png (97.5 kB)
Show 1 Share
10 |10000 characters needed characters left characters exceeded

Uwe,

Debugging a background job id from AUTOSYS.

Since i have the process code and a Z-FM for that outbound idoc, it will be difficult for me to get the pre-requisites to run that FM.

Please let me know your thoughts

0
Sandra Rossi Jul 06, 2017 at 08:40 PM
0

You simply can't debug background jobs as usually (it's not like HTTP, RFC, dialog, ...) Uwe told you to search and read the answers; they probably all say to run the job interactively with the okcode "jdbg" in SM37 (or even modify the code to add an endless loop). If it's not possible, could you tell us why you can't?

You also have the possibility to intercept a given job based on criteria, so that they don't start (you can then run it with jdbg). Search more information about program INITXBP2, transaction CRIT.

Show 1 Share
10 |10000 characters needed characters left characters exceeded

Sandra,

Thanks for letting us know the existence program INITXBP2 and transaction CRIT.

Will explore it.

K.Kiran.

0
Kiran K Jul 06, 2017 at 12:58 PM
-1

Siva,

Debugging a background job in PRD is not advisable.

Is this AUTOSYS tool configured to schedule the jobs even in Q for your testing ?

If not,identify the job name and find out the pre-requisites for this job and simulate in Q manually.

K.Kiran.

Show 15 Share
10 |10000 characters needed characters left characters exceeded

First of all thanks for the reply Kiran.

I have the box in Q as well. I can identify the job name. But is there any way to find out the pre-requisites for that job since the documentation of the process not so clear.

So you are saying like if i get the job name and pre-requisites, i can manually trigger only that job from AUTOSYS and then put the external debugger in abap code, so that the control will stop there. Please clarify.

0

Siva,

Read your comment for Uwe.

Identify an existing IDOC for this IDOC Type and use WE19 for debugging in Q.

K.Kiran.

0

"Not advisable". Why's that then? I've been doing it for years in order to identify and fix problems.

0
Matthew Billingham

With all due respect,I still standby what I said for obvious reasons ie Debugging is not advisable in PRD.

K.Kiran.

0

If you are a professional then there are no problems about debugging in production. You know what you are doing and in some cases it's the only place to replicate the problem. That is why a lot of companies have 'FIRECALL' logons which have sapall in PRD but are logged every step of the way.

If you don't trust your developers then you should either a) Change your job, or b) Change your developers. If you are a developer and you don't trust yourself I suggest you see a psychiatrist....

I agree with @Mathew Billingham on this

1

I'm reminded of "Yes Minister" (A political sitcom from the 80s).

Humphrey: And, with respect, Minister-
Hacker: Don't-don't use that filthy language to me, Humphrey.
Humphrey: Filthy language, Minister?
Hacker: I know what "with respect" means in your jargon. It means you're just about to imply that anything I'm about to suggest is beneath contempt.

:-D

1

<chuckles>

0

There's another exchange that goes something like:

Humphrey:With respect minister...

Humphrey:With great respect minister...

Humphrey:With the greatest possible respect, minister...

Hacker: Humphrey, I will not tolerate such rudeness!

0

@Kiran - "I still standby what I said for obvious reasons ie Debugging is not advisable in PRD"

That just means "I think I'm right". You've not explained why you think like this. What are these "obvious reasons".?

0
Matthew Billingham

OMG :-).

Seems,I stroked the Hornet Nest.

K.Kiran.

0

I'm genuinely interested in what these obvious reasons are. Why not share them and we can discuss. (And I'm sure you didn't mean "with all due respect" disrespectfully .-D ).

0
Matthew Billingham

Matt,

I know you are an esteemed Member of SCN Community and I have learned many things going through your responses to various threads.

It is just the risk of doing it wrong in PRD which makes me feel it is not advisable to debug in PRD.

Usually when we have tens of developers working on a Project and we have a window for debugging in PRD then in most cases it creates a lacklustre approach towards tackling the issue. It is not just in terms of Developers but also from the Functionals. Instead of replicating the issue in Q they approach the developer with an option of debugging in PRD with all due approvals in hand :-).

More or less people see that as an option to tackle the issue faster (severity levels :-) and end up doing it wrong) rather than replicating it in Q and understanding it to the core.

Agree these are the issues related to perception and have to be tackled at a personal level.

K.Kiran.

0
Show more comments

There can be several issues. There are always risks of doing the wrong thing (it's not the question of trusting the developers, as Richard says). It's why it's not advisable to debug in a production system. But it doesn't mean you can't debug in production.

For instance, sometimes you need to do an operation other than debug to allow the debug, and a "little" mistake happens.

The debug increases the risk of stopping a program (timeout while debugging/yes sometimes it happens if you have to interrupt your debug for something else), and if the program is badly written with COMMIT everywhere (I think more of custom programs) it may increase the risk of issues.

And I'm not speaking about systems not using the Two-Process debugger, as the old debugger was committing all the time (I don't know if it's still possible to keep the old option with the latest releases).

Moreover, there's the question of the "jump to statement", should it be allowed or not.

0

If you can't change values in the debugger (which is a pre-requisite for debugging in P), then you can't "jump to statement". I have needed to use debug change in production twice in twenty years - it's a very exceptional circumstance, and only granted on an as-needed basis.

In BW, it's built into the application that you can debug - there's logic from SAP that says: if flag set -> go into debug. This is in DTPs and InfoPackages. Also if you run a query in SAPGui and it fails, you'll be dropped into the debugger (not because of a dump!).

A blanket statement that "it's not advisable to debug in production" is simply incorrect. It is often just not possible to replicate an issue in the test system. And how can you replicate it when you're still trying to figure out why it's not working.

I do find it funny that some companies don't trust developers in production, but do trust basis - who by the very nature of their job can do anything at all.

3