debugger

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
rakeshcv
Participant
Posts: 8
Joined: Mon Apr 12, 2004 9:27 pm
Location: delaware
Contact:

debugger

Post by rakeshcv »

Hi,
I thank you all for the replies i have got. It is really wonderful to be a part of this.I have another question and would appreciate if someone helps me out in this.
can anone tell me how to use debugger to test the data flow and fix jobs?

Regards,

Rakesh.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Have you used any other debugger in the past?

Debuggers allow you to step through execution at human speed rather than at computer speed. While doing so you are confirming or rejecting hypotheses about what should be happening.

Your arsenal of tools, in any debugger, consists essentially of three things.
  • :arrow: Breakpoints are a mechanism for specifying where, or under what conditions, the program should pause.
    :arrow: Step commands allow you to specify where you want to go next, or to discover which piece of the program will be executed next.
    :arrow: Watch commands allow you to view values (and thus to check whether an expected value has been generated). (Some language debuggers also allow you to change to values of variables, to see what would happen. This is not possible with the DataStage debugger.)
In the DataStage debugger you set breakpoints by selecting a link; usually the first link in the job. Then choose "toggle breakpoint" from the pop-up menu, the Debug menu, or the Debug toolbar (enable this from the View menu). By default, execution pauses every row, but you can change this to "every N rows" or "when expression becomes true" by editing the breakpoint.

When the job is running in the Debugger, and reaches a breakpoint, job execution pauses and you can inspect values of columns on any link that is in scope (attached to the active stage and already executed), stage variables, management variables, and so on. You can add selected ones to the Watch list, segregating them so that changes in their values are readily spotted.

From a breakpoint you can choose:
  • :arrow: Next Link, which verifies which link is executed next. If a reference lookup fails, the Debugger does not count its link as executed, so you can appear to skip that link. Verify based on the reference key expression's value that this is correct behaviour.
    :arrow: Next Row, which completes execution of the current row as far as possible (for example the row disappears into the maw of an Aggregator stage) then begins processing of the next row, continuing until the first breakpoint is encountered.
You do not have to let the job run to completion in the Debugger. If you're finished you can issue a Stop Job instruction from the Debugger. The job is in a Stopped state, and would need to be reset before being executed; this reset is automatically performed if you invoke the Debugger again.

The Debugger does not fix jobs. This is for you to do using Designer, based on the information that you have used the Debugger to reveal.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply