Fetching userstatus from commandline whilst detecting abort?

[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?

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

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

[JKenklies]

Thank you for replies, fast as always.

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:

Code: Select all

# echo $?

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.

[chulett]

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.

[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 :)

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