job status
Moderators: chulett, rschirm, roy
job status
How to change the status code inside data stage code. ?
Jobs are submitted from Mainfarme.
I am getting status=2 in two different jobs. in one is fatal and in the other one is OK
Thanks
Jobs are submitted from Mainfarme.
I am getting status=2 in two different jobs. in one is fatal and in the other one is OK
Thanks
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The only way you can influence the status code returned by a DataStage job is to write it:
- so that it generates no warnings or errors (returns 1)
so that it generates warnings but no fatal errors (returns 2)
so that it generates at least one fatal error (returns 3)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
I've run into this issue as well...
My sequence jobs are something like:
I'd like to keep the triggers for the downstream sequences as "OK". However, Job2 generates a warning (database reject due to key constraints). This isn't fatal (esp. in DEV), and I'd like the flow to continue.
I believe I can use the custom trigger:
to allow the flow to continue (and I believe this could apply to the OP's question if he's using sequence jobs).
However, I'd prefer to leave the triggers as "OK", but "force" a Warning to OK on a case-by-case basis per job.
Thus, it it possible to code something like:
ideally in the job itself somehow, otherwise in a sequence, then have that match the "OK" trigger for the downstream sequence?
P.S.: An OOTB trigger "OK or Warning" would be useful.
My sequence jobs are something like:
Code: Select all
SEQ_Main
SEQ_Lev1
SEQ_Lev1.1
SEQ_Lev1.1.1
Job1 --> Job2 --> Job3 --> JobN
I believe I can use the custom trigger:
Code: Select all
ActivityName.$JobStatus Matches "1":@VM:"2"
However, I'd prefer to leave the triggers as "OK", but "force" a Warning to OK on a case-by-case basis per job.
Thus, it it possible to code something like:
Code: Select all
If JobName.$JobStatus = 2 The JobName.$JobStatus = 1
P.S.: An OOTB trigger "OK or Warning" would be useful.
OK, this is what I've come up with. Say you have these sequence jobs:
where Job generates a warning.
Options:
1. Set Seq_Child compilation options - untick "Log warnings after activities that finish with status other than OK".
Pros:
Seq_Child will finish with OK, so downstream activities in Seq_Parent will execute with the OK trigger.
Job's log still shows the warnings
Cons:
While there is a message in Seq_Parent's log that Seq_Child finished with warnings, it's not obvious (no Event type = Warning)
2. Set trigger in Seq_Parent to custom Seq_Child.$JobStatus Matches "1":@VM:"2"
3. In Seq_Parent, create a Failed trigger, say to a Termination stage, and set an Otherwise trigger for the OK & Warning statuses.
I'm not sure which would be best case...still mulling it over. Leaning toward #2.
Additional input most welcome!
Code: Select all
Seq_Parent
Seq_Child
Job
Options:
1. Set Seq_Child compilation options - untick "Log warnings after activities that finish with status other than OK".
Pros:
Seq_Child will finish with OK, so downstream activities in Seq_Parent will execute with the OK trigger.
Job's log still shows the warnings
Cons:
While there is a message in Seq_Parent's log that Seq_Child finished with warnings, it's not obvious (no Event type = Warning)
2. Set trigger in Seq_Parent to custom Seq_Child.$JobStatus Matches "1":@VM:"2"
3. In Seq_Parent, create a Failed trigger, say to a Termination stage, and set an Otherwise trigger for the OK & Warning statuses.
I'm not sure which would be best case...still mulling it over. Leaning toward #2.
Additional input most welcome!
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Don't use literal constants ("1" : @VM : "2") - these values may change in future. Prefer DS Constants (DSJS.RUNOK : @VM : DSJS.RUNWARN).
There's no "best" - you do what's right in each case. Some exceptions at your site, Scott, require email to be sent. So your decision would be biased towards solutions that can accommodate that requirement.
There's no "best" - you do what's right in each case. Some exceptions at your site, Scott, require email to be sent. So your decision would be biased towards solutions that can accommodate that requirement.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 19
- Joined: Tue Jun 05, 2007 4:43 am
- Location: mumbai
- Contact:
Hi , Can we use the below code.
AAAiles_Seq.$JobStatus=DSJS.RUNFAILED Or AAAFiles_Seq.$JobStatus = DSJS.RUNWARN
intstead of using system variable @VM. Please share your ideas.
If not then what is the significance of using system variable(@VM A value mark (a delimiter used in UniVerse files), Char(253))
Thanks in advance
AAAiles_Seq.$JobStatus=DSJS.RUNFAILED Or AAAFiles_Seq.$JobStatus = DSJS.RUNWARN
intstead of using system variable @VM. Please share your ideas.
If not then what is the significance of using system variable(@VM A value mark (a delimiter used in UniVerse files), Char(253))
Thanks in advance
Shahid.Bakshi
Mumbai
Mumbai
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 19
- Joined: Tue Jun 05, 2007 4:43 am
- Location: mumbai
- Contact:
Matches was just easier to input - choose the right Activity variable once, then paste in the above. If BASIC had the IN operator I would use it.ray.wurlod wrote:Yes you can; in a trigger expression it's clearer to use OR conjunction.
shahidbakshi, @VM is the separator for the Matches function meaning "or", so Matches will return true if $JobStatus is 1 or 2. See the doc for more details.
OK...honestly...on this one, I'm not understanding why this isn't a good approach?chulett wrote:Hardly the best criteria for making the decision regarding which one to use.sbass1 wrote:Matches was just easier to inputray.wurlod wrote:Yes you can; in a trigger expression it's clearer to use OR conjunction.
I could code:
MyActivity.$JobStatus=DSJS.RUNOK or MyActivity.$JobStatus=DSJS.RUNWARN
MyActivity$JobStatus Matches DSJS.RUNOK : @VM : DSJS.RUNWARN
MyActivity$JobStatus IN (DSJS.RUNOK, DSJS.RUNWARN) (if this operator existed).
Other than someone supporting this code later and not understanding the syntax of the Matches operator, why is using Matches "worse"? One thing I can think of is if Matches is appreciably slower than coding the direct equality comparisons.
FWIW I think Matches is syntactically more elegant: one of my pet peeves in SQL is seeing something like:
WHERE VAR=1 or VAR=2 or VAR=3 or VAR=4 or VAR=5 ...
instead of
WHERE VAR IN (1,2,3,4,5)
In this example, I think the second form is clearer.
OK. There was a couple of reasons why, after much pondering, I made that comment. And since you asked understand this is all me, my personal opinion so take it cum grano salis as Ray might say.
First off I agree with your comment about matches being 'syntactically more elegant' and would vastly prefer there be an 'in' rather than 'matches' or having to string a series of 'OR's together, especially as the number of elements to check expands. One mitigating circumstance here, however, is the fact there are only two values to check.
The first issue I have with it is it is a very... 'techie'... solution. You touched on the point in your post, your 'other than someone supporting this code later' comment and why Ray (I assume) noted the 'or conjunction' was clearer. IMHO it's very important to consider future generations, Those Who Come After Us. Sure, it works, but 95+ percent of the people I've worked with over the years wouldn't have a clue what it means. They spend their time working in the GUI and never venture 'under the covers' into the dark underbelly of the product or architecture. They'll use routines and perhaps write very simple ones but they'd much rather let someone like me do the dirty work for anything 'complex'. And the matches function isn't really all that high on their Must Use list, even a relatively benign example of MATCHES "1N0N" could be just gobbledygook and it only gets worse when they get more complex. Throw any of the system variable marks like @VM or @FM into the mix and it's everyone man the lifeboats. I don't recall the last time I saw a 'matches' in a derivation that I didn't put there, accompanied by an annotation explaining what it was doing.
The second issue was what I quoted, something that touched one of my hot buttons - the simple statement that you chose that path because it was 'just easier to input'. I say this in a generic sense - it always irks me when I discuss options with someone and we boil things down to a small number of choices and I know they'll be taking the easiest path. Not the best, not the most robust, but the easiest. Human nature, I guess, to prefer the shortest path to a goal but there are times when the needs of the many outweigh the needs of the few. Or the one.![Wink :wink:](./images/smilies/icon_wink.gif)
So there you have it, why I made the comment, a brief peek into the dark recesses of my curmudgeon psyche. Hope that helps people understand where I was coming from with it.
![Laughing :lol:](./images/smilies/icon_lol.gif)
First off I agree with your comment about matches being 'syntactically more elegant' and would vastly prefer there be an 'in' rather than 'matches' or having to string a series of 'OR's together, especially as the number of elements to check expands. One mitigating circumstance here, however, is the fact there are only two values to check.
The first issue I have with it is it is a very... 'techie'... solution. You touched on the point in your post, your 'other than someone supporting this code later' comment and why Ray (I assume) noted the 'or conjunction' was clearer. IMHO it's very important to consider future generations, Those Who Come After Us. Sure, it works, but 95+ percent of the people I've worked with over the years wouldn't have a clue what it means. They spend their time working in the GUI and never venture 'under the covers' into the dark underbelly of the product or architecture. They'll use routines and perhaps write very simple ones but they'd much rather let someone like me do the dirty work for anything 'complex'. And the matches function isn't really all that high on their Must Use list, even a relatively benign example of MATCHES "1N0N" could be just gobbledygook and it only gets worse when they get more complex. Throw any of the system variable marks like @VM or @FM into the mix and it's everyone man the lifeboats. I don't recall the last time I saw a 'matches' in a derivation that I didn't put there, accompanied by an annotation explaining what it was doing.
The second issue was what I quoted, something that touched one of my hot buttons - the simple statement that you chose that path because it was 'just easier to input'. I say this in a generic sense - it always irks me when I discuss options with someone and we boil things down to a small number of choices and I know they'll be taking the easiest path. Not the best, not the most robust, but the easiest. Human nature, I guess, to prefer the shortest path to a goal but there are times when the needs of the many outweigh the needs of the few. Or the one.
![Wink :wink:](./images/smilies/icon_wink.gif)
So there you have it, why I made the comment, a brief peek into the dark recesses of my curmudgeon psyche. Hope that helps people understand where I was coming from with it.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
If you really want to get Craig (H) going, as about all those posters who want to create one generic job that can do everything. No, wait, who want US to create that job for them.
(I get somewhat worked up about that also. I believe - know - that DataStage was designed to be driven by the metadata, not the other way around.)
Bring on the RMM stage, I say!
(I get somewhat worked up about that also. I believe - know - that DataStage was designed to be driven by the metadata, not the other way around.)
Bring on the RMM stage, I say!
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.