using the commandline-Interface dsjob within a UNIX environm
using the commandline-Interface dsjob within a UNIX environm
This is a topic for an orphaned message.
I would like a list of all the Ascential tools and/or executables that should not be used in a production environment.
thanks,
Doug
-----Original Message-----
From: Ray Wurlod [mailto:ray.wurlod@Informix.Com]
Sent: Friday, September 14, 2001 1:43 AM
To: datastage-users@oliver.com
Subject: RE: using the commandline-Interface dsjob within a UNIX environment
My four main reasons to prefer job control routines over dsjob.
1. dsjob is a SAMPLE program. It is supplied as an example of how to use the DataStage C API. In places (places it seems Wolfgang doesnt use) its a bit flaky. For example (in 4.0) the -wait option fails to wait. This is not good if you then immediately fire up the bulk loader!
2. Granularity of information gathering is coarse in dsjob. For example, all you can do is get a few lines of information about a job (with the -jobinfo option) which you then have to parse (perhaps using an awk
script) to extract the item of information you require. Using the job control function DSGetJobInfo you can isolate the item of information to the exact item you require, for example DSGetJobInfo(hJob,DSJ.JOBSTATUS). And what do you do with a mix of UNIX and NT? dsjob is portable (exists on both), but the scripting language (by default) is radically different!
3. Only one byte is available for exit status, which has led to more than a little confusion (and more than a few support calls) when using dsjob. No such restrictions exist within the DataStage environment.
4. Ultimately, the C API functions invoke their BASIC counterparts, so that dsjob (or any other program using the DataStage C API) is at best an interlude. You are not exercising direct control over anything that happens in DataStage. Only indirect.
In my opinion, the BASIC programming language is far more flexible than shell scripting languages. Just the size of the manual (887 pages?) should suggest that this is so.
Finally, it is arguable that job control routines are "native", and therefore closer, to DataStage.
thanks,
Doug
-----Original Message-----
From: Ray Wurlod [mailto:ray.wurlod@Informix.Com]
Sent: Friday, September 14, 2001 1:43 AM
To: datastage-users@oliver.com
Subject: RE: using the commandline-Interface dsjob within a UNIX environment
My four main reasons to prefer job control routines over dsjob.
1. dsjob is a SAMPLE program. It is supplied as an example of how to use the DataStage C API. In places (places it seems Wolfgang doesnt use) its a bit flaky. For example (in 4.0) the -wait option fails to wait. This is not good if you then immediately fire up the bulk loader!
2. Granularity of information gathering is coarse in dsjob. For example, all you can do is get a few lines of information about a job (with the -jobinfo option) which you then have to parse (perhaps using an awk
script) to extract the item of information you require. Using the job control function DSGetJobInfo you can isolate the item of information to the exact item you require, for example DSGetJobInfo(hJob,DSJ.JOBSTATUS). And what do you do with a mix of UNIX and NT? dsjob is portable (exists on both), but the scripting language (by default) is radically different!
3. Only one byte is available for exit status, which has led to more than a little confusion (and more than a few support calls) when using dsjob. No such restrictions exist within the DataStage environment.
4. Ultimately, the C API functions invoke their BASIC counterparts, so that dsjob (or any other program using the DataStage C API) is at best an interlude. You are not exercising direct control over anything that happens in DataStage. Only indirect.
In my opinion, the BASIC programming language is far more flexible than shell scripting languages. Just the size of the manual (887 pages?) should suggest that this is so.
Finally, it is arguable that job control routines are "native", and therefore closer, to DataStage.