Page 1 of 1
Fetching userstatus from commandline whilst detecting abort?
Posted: Thu Aug 20, 2015 8:39 am
by JKenklies
Using a ServerJob, I'm Setting the Userstatus depending on an SQL requets result. Say if the rowcount of a table equals Zero or not, the userstatus is set to 1 or 2.
When running this Job within a sequence, it's possible to fetch the userstatus and use it as condition or as Parameter for the next job in sequence. Also if the job aborts, the Sequence can still react on that.
But if the Job is run by commandline, it seems that I have to make a decision between the UserStatus and the JobStatus. Using dsjob -run -userstatus will set the exit code to a value derived by the userstatus. Now if the Job aborts for some reason, the exit code still contains the userstatus, which is leaving me with the question: How would a parent process know that the job aborted? How does the sequence do?
Posted: Thu Aug 20, 2015 10:13 am
by chulett
To be honest, while I used USERSTATUS more than my fair share in the past, I never leveraged the "-userstatus" option from dsjob. I would suggest going back to the normal "-jobstatus" so you can know what happened to the job, did it end gracefully or not. If it did RUN_OK and you need to move on, you can then fetch the current USERSTATUS value from the command line using dsjob again. Sorry, I don't have that syntax off the top of my head but it's all documented.
Posted: Thu Aug 20, 2015 5:05 pm
by ray.wurlod
The -userstatus option on the dsjob command returns the contents of the job's user status area. No more, no less.
In particular it does not return an exit status. That is the purpose of the -jobstatus option.
Posted: Fri Aug 21, 2015 5:22 pm
by JKenklies
Thank you for replies, fast as always.
ray.wurlod wrote:In particular it does not return an exit status. That is the purpose of the -jobstatus option.
I made tests on a suse linux machine. I wrote a ServerJob:
Code: Select all
ORA --link1--> TRA1 --link2--> TRA2 --link3--> SF
ORA SQL:
Code: Select all
select #value# as status from dual;
TRA1 sets the UserStatus to the Content returned in dslink1.status
TRA2 aborts if link1.status = 20
SF leads to /dev/null
It turned out that if I used both the -jobstatus and the -userstatus option, the jobstatus always wins. The userstatus will only be returned if the -jobstatus option is omitted. Otherwise, the userstatus hasn't even been printed to stdout.
I checked the last exit code after each job run with:
In all cases using the -jobstatus option, the exit code was equal to the jobstatus. The userstaus has been ignored completely.
Using the -userstatus option, the exit code behaved like this:
Code: Select all
value user status exit code
0 0 0
-1 -1 0
1 1 1
255 255 255
123456 123456 255
'hello world' 'hi globe' 0
20 20 20
Note that the Job aborts on value=20, but the shell would not notice the diferece between a successful 20 and an aborted 20.
I'll check the -jobinfo option next week. Thanks for that idea!
Running a job twice is not a valid move, even if its a harmless job. Time will come and someone uses this construct as template for something where runnig twice is poison.
Posted: Sat Aug 22, 2015 7:23 am
by chulett
JKenklies wrote:I'll check the -jobinfo option next week. Thanks for that idea!
You will need to parse it out of the output from the command but it's very straight forward... grep / cut or something similar.
Posted: Mon Aug 24, 2015 7:03 am
by JKenklies
Ok, this should work:
Step 1:
Run the Job Setting a UserStatus. Do not use the -userstatus option. use the -jobstatus option.
The Exit code will tell you, if the Job has run ok or not.
Step 2:
Use this command to retrieve the user status:
Code: Select all
dsjob -jobinfo <project> <jobname> 2>/dev/null | grep -e "User Status.*" | sed 's/User\sStatus\s*:\s*\([0-9]*\)/\1/g'
Thank you :)
Posted: Mon Aug 24, 2015 5:52 pm
by ray.wurlod
Yes, that will work. Fewer resources might be used by
Code: Select all
dsjob -jobinfo project jobname | grep 'User Status:' | cut -d: -f2
(assuming there are no ":" characters in the user status value.