Easy access of Job Description
Moderators: chulett, rschirm, roy
Easy access of Job Description
I'm putting all jobs in a project into a Data Dictionary table defined by ourselves in a schema in the data warehouse we're building.
Getting all the jobnames in the project using DSGetProjectInfo is no problem, getting info for each job in the way I'd like to is though.
I just want to send all the job names into a transform and there get the Job Description and Full Job Description for each job. However, the function DSGetJobInfo, which seems to be the only channel to access these attributes, requires not a JobName but an attached JobHandle as input, and simply writing a routine that does a DSAttachJob to JobName, calls DSGetJobInfo and returns Description doesn't seem to work. The routine somhow aborts though.
Is there another way or am I simply just missing something, can you use a routine that attaches another job like this in a transformer stage?
Getting all the jobnames in the project using DSGetProjectInfo is no problem, getting info for each job in the way I'd like to is though.
I just want to send all the job names into a transform and there get the Job Description and Full Job Description for each job. However, the function DSGetJobInfo, which seems to be the only channel to access these attributes, requires not a JobName but an attached JobHandle as input, and simply writing a routine that does a DSAttachJob to JobName, calls DSGetJobInfo and returns Description doesn't seem to work. The routine somhow aborts though.
Is there another way or am I simply just missing something, can you use a routine that attaches another job like this in a transformer stage?
StefL,
you always need to use the DSAttachJob() call to get a valid handle; with the exception of the mnemonic DSJ.ME. The following code should always work for valid jobs; so you most likely have made an error in your programming.
you always need to use the DSAttachJob() call to get a valid handle; with the exception of the mnemonic DSJ.ME. The following code should always work for valid jobs; so you most likely have made an error in your programming.
Code: Select all
ProgramName = 'JobName'
JobHandle = DSAttachJob(ProgramName, DSJ.ERRFATAL)
IF (JobHandle = DSJE.BADHANDLE) THEN CALL DSLogFatal('Fatal','')
ShortDesc = DSGetJobInfo(JobHandle,DSJ.JOBDESC)
LongDesc = DSGetJobInfo(JobHandle,DSJ.JOBFULLDESC)
IgnoreMe = DSDetachJob(JobHandle)
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Thanks for the reply Arnd.
It doesn't seem however that I can use that type of code just like that in a Transform Function. When I do the compiler returns the following:
Compiling: Source = 'DSU_BP/DSU.GetJobDescription', Object = 'DSU_BP.O/DSU.GetJobDescription'
*
Array 'DSAttachJob' never dimensioned.
WARNING: Variable 'DSJ.ERRFATAL' never assigned a value.
WARNING: Variable 'DSJE.BADHANDLE' never assigned a value.
Array 'DSGetJobInfo' never dimensioned.
WARNING: Variable 'DSJ.JOBDESC' never assigned a value.
WARNING: Variable 'DSJ.JOBFULLDESC' never assigned a value.
Array 'DSDetachJob' never dimensioned.
3 Errors detected, No Object Code Produced.
And if I try declaring the DS-routine calls like:
DEFFUN GetJobInfo(MyHandle,DSJ.JOBDESC) Calling "DSU.DSGetJobInfo"
it compiles OK but still doesn't execute properly.
I'm not sure whether I expressed in detail in my first entry what I'm trying to achive; I want to have a job feeding job names into a Transformer Stage where JobName is assigned to one target column and JobDesc and JobFullDesc to two other columns. Am I at fault even trying to accomplish this?
It doesn't seem however that I can use that type of code just like that in a Transform Function. When I do the compiler returns the following:
Compiling: Source = 'DSU_BP/DSU.GetJobDescription', Object = 'DSU_BP.O/DSU.GetJobDescription'
*
Array 'DSAttachJob' never dimensioned.
WARNING: Variable 'DSJ.ERRFATAL' never assigned a value.
WARNING: Variable 'DSJE.BADHANDLE' never assigned a value.
Array 'DSGetJobInfo' never dimensioned.
WARNING: Variable 'DSJ.JOBDESC' never assigned a value.
WARNING: Variable 'DSJ.JOBFULLDESC' never assigned a value.
Array 'DSDetachJob' never dimensioned.
3 Errors detected, No Object Code Produced.
And if I try declaring the DS-routine calls like:
DEFFUN GetJobInfo(MyHandle,DSJ.JOBDESC) Calling "DSU.DSGetJobInfo"
it compiles OK but still doesn't execute properly.
I'm not sure whether I expressed in detail in my first entry what I'm trying to achive; I want to have a job feeding job names into a Transformer Stage where JobName is assigned to one target column and JobDesc and JobFullDesc to two other columns. Am I at fault even trying to accomplish this?
You need to add the following code so that the header file with the definitions of those Job Control functions gets compiled in as well:
Code: Select all
$IFNDEF JOBCONTROL.H
$INCLUDE DSINCLUDE JOBCONTROL.H
$ENDIF
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Yah, it's a big shiny lightbulb for all of us at some point. Possibly stating the obvious, but keep this in mind as you branch out and expand your Routine creation skills as there are other header files that come into play as you build more 'functional' things.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Yeah, well I'm not really surprised since I've done a fair bit of C programming. But the examples included in the repository are perhaps too simple since the ones I looked in at least didn't contain any header file references.
But now that I know at least that's a mistake I won't have to repeat. At least in Swedish the saying is 'it's from the mistakes you learn' - I guess that may be universal...
But now that I know at least that's a mistake I won't have to repeat. At least in Swedish the saying is 'it's from the mistakes you learn' - I guess that may be universal...
I would not attach to every job in your project this way. There are lots better ways to do this.
would be better if
I did all this from memory so there are probably some mistakes but it should be close. If you attach to a job then you need to detach. If you attach to the current running job and then detach it sometimes gets confused. There ways to speed this up by using a common but I will let you worry about that. It should be fast enough.
Code: Select all
ProgramName = 'JobName'
JobHandle = DSAttachJob(ProgramName, DSJ.ERRFATAL)
IF (JobHandle = DSJE.BADHANDLE) THEN CALL DSLogFatal('Fatal','')
ShortDesc = DSGetJobInfo(JobHandle,DSJ.JOBDESC)
LongDesc = DSGetJobInfo(JobHandle,DSJ.JOBFULLDESC)
IgnoreMe = DSDetachJob(JobHandle)
Code: Select all
open 'DS_JOBS' to DsJobs else stop
open 'DS_JOBOBJECTS' to DsJobObjects else stop
read JobRec from DsJobs, JobName then
JobNo = JobRec<5>
JobObjId = 'J\' : JobNo : '\ROOT'
read JobObjRec from DsJobObjects then
ShortDesc = JobObjRec<4>
LongDesc = JobObjRec<7>
end
end
Mamu Kim
Kim,
but my version (using the published UI) will work in 3 versions whereas I'd put heavy money on the direct access NOT working sometime in the future.
but my version (using the published UI) will work in 3 versions whereas I'd put heavy money on the direct access NOT working sometime in the future.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Kim,
It's just that I wrote so much code at versions 1,2,3 etc. which at some upgrade failed to run and I got my fingers slapped afterwards (even though I had coded comments and documented my transgressions because there were no options, the customers tended to "forget" that afterwards ) so now I will always use a documented interface even when I know that it is inefficient. Just a habit I've learned to stick to.
It's just that I wrote so much code at versions 1,2,3 etc. which at some upgrade failed to run and I got my fingers slapped afterwards (even though I had coded comments and documented my transgressions because there were no options, the customers tended to "forget" that afterwards ) so now I will always use a documented interface even when I know that it is inefficient. Just a habit I've learned to stick to.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Arnd and Kim
I'm very thankful for all opinions from both of you - so far my experience is that you are two main authorities on Data Stage on this forum (and I'm not saying this to suck up to you - well, not only at least... )
The job I'm creating at the moment is not something that will be run repeatedly but more at setup or restore of a host system holding the data warehouse (i.e 'once' in development, test and production) for each release. And I realise the implifications of not releasing a job, as well as having a job trying to attach or (worse?) detaching itself. This is more a 'meta' type job checking the actual 'job' jobs and adding them to the Data Dictionary table in the data warehouse.
So far the use of DSAttach, DSGetJobInfo, DSDetach seems to work, so I'll stick with it for now but I'm grateful to learn any other ways as well. The 'objects' you're referring Kim - DS_JOBS, DS_JOBOBJECTS - are they generally accessible from within any function provided JobControl.h is included, or are they something you defined yourself?
/Stefan
I'm very thankful for all opinions from both of you - so far my experience is that you are two main authorities on Data Stage on this forum (and I'm not saying this to suck up to you - well, not only at least... )
The job I'm creating at the moment is not something that will be run repeatedly but more at setup or restore of a host system holding the data warehouse (i.e 'once' in development, test and production) for each release. And I realise the implifications of not releasing a job, as well as having a job trying to attach or (worse?) detaching itself. This is more a 'meta' type job checking the actual 'job' jobs and adding them to the Data Dictionary table in the data warehouse.
So far the use of DSAttach, DSGetJobInfo, DSDetach seems to work, so I'll stick with it for now but I'm grateful to learn any other ways as well. The 'objects' you're referring Kim - DS_JOBS, DS_JOBOBJECTS - are they generally accessible from within any function provided JobControl.h is included, or are they something you defined yourself?
/Stefan
Stefl,
there are lots of experts here - and if Ray feels like adding comments to this thread I am sure he will!
Just a heads-up; I've discovered a bug at 7.5 (can't remember the GTAR number) where a job will hang if it attempts a DSAttachJob(DSJ.ME,DSJ.ERRFATAL) by mistake - don't try this at home
there are lots of experts here - and if Ray feels like adding comments to this thread I am sure he will!
Just a heads-up; I've discovered a bug at 7.5 (can't remember the GTAR number) where a job will hang if it attempts a DSAttachJob(DSJ.ME,DSJ.ERRFATAL) by mistake - don't try this at home
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
The objects that Kim is referring to are the repository files that the API references. Boh Kim and Arnd have valid points, but I would err on the side of caution and urge you to use the method Arnd has posted since this will not likely cause any issues from release to release. The field positions that Kim refers to have not changed for many releases (if ever) and is truly faster, but again you are bypassing the published API and when doing so you do this at your own risk.
You also need to interrogate the value of each API call since you may not get the expected results if the job is not in a runnable state etc... All subsequent API calls require a valid handle so make sure you have one before proceeding with further calls.
You also need to interrogate the value of each API call since you may not get the expected results if the job is not in a runnable state etc... All subsequent API calls require a valid handle so make sure you have one before proceeding with further calls.
Mike Hester
mhester@petra-ps.com
mhester@petra-ps.com
True - I forgot Ray whom I've also been helped by previously, respect to you too if you happen to be reading this!
About DSAttach, it does say in the documentation that a job cannot Attach to itself so I wouldn't try it on purpose, but I guess it would be better if attempting to do so resulted in an error than in the job hanging...
About DSAttach, it does say in the documentation that a job cannot Attach to itself so I wouldn't try it on purpose, but I guess it would be better if attempting to do so resulted in an error than in the job hanging...