Querying the log of a multi-instance job
Moderators: chulett, rschirm, roy
Querying the log of a multi-instance job
I would like to query the log of a multi-instance job. I would like to see if any of the instances ever encountered a warning. I thought of querying RT_STATUSnnn files in the project but I am not sure how to do it. Any ideas? Is there any other way that this can be done?
Well... lots of discussions here but it can be a bit of a pain to wade through them looking for the bits you are interested in.
There are basically two places you can access the job information via the API: your server's command line or the BASIC routine API. Both have the same set of functions. Both the command line interface and BASIC API are fully documented, or at least they were and I assume they still are. From the command line you would use the "dsjob" utility, the same one that amongst other things can start/monitor/stop jobs. Then there are all of the various "DSGetJob***" options you can call in a custom BASIC routine and leverage in a Sequence or Server job.
For the previous discussions, I'd suggest an exact search here for "multi-instance" and/or "dsgetjob". Shouldn't really matter how old they are as this is core functionality that has not changed. Keep in mind the fact the multi-instance job invocations are all stored in the same log, identified by their InvocationID. The Director can make them look like they are stored separately, but it is basically using a "view" in the table to filter each one.
There are basically two places you can access the job information via the API: your server's command line or the BASIC routine API. Both have the same set of functions. Both the command line interface and BASIC API are fully documented, or at least they were and I assume they still are. From the command line you would use the "dsjob" utility, the same one that amongst other things can start/monitor/stop jobs. Then there are all of the various "DSGetJob***" options you can call in a custom BASIC routine and leverage in a Sequence or Server job.
For the previous discussions, I'd suggest an exact search here for "multi-instance" and/or "dsgetjob". Shouldn't really matter how old they are as this is core functionality that has not changed. Keep in mind the fact the multi-instance job invocations are all stored in the same log, identified by their InvocationID. The Director can make them look like they are stored separately, but it is basically using a "view" in the table to filter each one.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
As what user? Don't know what "ABSHOME" is but if it is Java based, from the error it would seem that $JAVA_HOME may not be set. Are you running this with the proper user with the proper / full set of expected environment variables set?
Others will need to provide specific guidance, sorry but after all these years I'm only good for the general stuffs.
Others will need to provide specific guidance, sorry but after all these years I'm only good for the general stuffs.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Easy way to do it is to create a SERVER job with a HASHED file stage feeding an output link. Set the filename to RT_LOGnn and then go VIEW-DATA. You may have to setup a few column names, one being defined as a key.
3NF: Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key. So help me Codd.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Logs are also accessible from the DataStage Operations database (DSODB). This is fully documented in the IBM Knowledge Center, with example queries. Since InvocationID is a column in the JobExec table, it is easy to filter for a particular query, or to group by InvocationID.
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.