Easy access of Job Description

StefL · Post by **StefL** » Thu Apr 14, 2005 2:46 am

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?

ArndW · Post by **ArndW** » Thu Apr 14, 2005 5:21 am

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.

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)

StefL · Post by **StefL** » Thu Apr 14, 2005 5:40 am

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?

chulett · Post by **chulett** » Thu Apr 14, 2005 6:42 am

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

StefL · Post by **StefL** » Thu Apr 14, 2005 6:52 am

Thanks a heap Craig!

That seems to have solved my problem; I figured I needed to include some file like that but since my experience with the BASIC programming is still limited I wasn't sure of precisely what.

You made my day!

/Stef

chulett · Post by **chulett** » Thu Apr 14, 2005 7:00 am

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.

StefL · Post by **StefL** » Thu Apr 14, 2005 7:11 am

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

kduke · Post by **kduke** » Thu Apr 14, 2005 8:10 am

I would not attach to every job in your project this way. There are lots better ways to do this.

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)

would be better if

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

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.

ArndW · Post by **ArndW** » Thu Apr 14, 2005 8:16 am

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.

kduke · Post by **kduke** » Thu Apr 14, 2005 8:21 am

You are probably correct but I have had lots of problems when developers attach to every job. Most think the detach is optional. This code will not live beyond this release either way. That is my bet.

ArndW · Post by **ArndW** » Thu Apr 14, 2005 8:26 am

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.

StefL · Post by **StefL** » Thu Apr 14, 2005 8:42 am

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

ArndW · Post by **ArndW** » Thu Apr 14, 2005 8:56 am

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

mhester · Post by **mhester** » Thu Apr 14, 2005 9:00 am

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.

StefL · Post by **StefL** » Thu Apr 14, 2005 9:00 am

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