Background job

[former_member522703]

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.

[UweFetzer_se38]

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

[former_member522703]

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

[kiran_k8]

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.

[former_member522703]

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.

[kiran_k8]

Siva,

Read your comment for Uwe.

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

K.Kiran.

[matt]

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

[kiran_k8]

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

K.Kiran.

[Former Member]

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

[Sandra_Rossi]

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.

[matt]

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.

[matt]

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.

😄

[matt]

@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".?

[kiran_k8]

OMG :-).

Seems,I stroked the Hornet Nest.

K.Kiran.

[Former Member]

<chuckles>

[matt]

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 ).

[matt]

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!

[kiran_k8]

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.

[matt]

Those are reasonable reasons. But I'm not sure I agree that they're obvious, and really they only apply to projects, not to operational support. The only risk from read-only debugging is timeouts and unexpected commits.

Unless you know what particular circumstances of data are causing an issue, you can't replicate it in tests. To figure out the circumstances, unless you've a copy of production data in your test system, you have to debug. Once you know the circumstances, you can then start setting up tests.

I'll compromise.

Do not debug in the production instance of an OLTP system objects delivered in a recent or ongoing project, except as a last resort.

I also suggest you invest in decent programmers if your current mob keep doing things incorrectly.

[Sandra_Rossi]

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.

[kiran_k8]

Sandra,

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

Will explore it.

K.Kiran.