Page 1 of 1

Functions to get total number of records

Posted: Wed May 26, 2010 4:48 am
by rameshkm
Hi Gurus ,

I have a situation like want to get how much records inserted in the target, and also status of the job in a table during runtime, is there any functions or logic in dastage parallel, please help in this regard thanks in advance.

[* Note - Title changed to be relevant to topic - Andy *]

Posted: Wed May 26, 2010 6:22 am
by chulett
Please use meaningful subject lines, it helps searchers of the site. Your Subject and Additional Info should have been swapped, that or just skipped the whole "Hi" part as we're quite the friendly bunch and are all about the solutions. :wink:

All that can be done "after job" from either your O/S or by another job, simplest would be from a Server job because of the BASIC functions that do this. Check your online help for all of the DSGet* functions or the equivalents using dsjob from a command line script. Read about that in the Command Line Interface chapter of either Developer's Guide pdf.

I need in Parallel only

Posted: Wed May 26, 2010 7:29 am
by rameshkm
chulett wrote:Please use meaningful subject lines, it helps searchers of the site. Your Subject and Additional Info should have been swapped, that or just skipped the whole "Hi" part as we're quite the friendly bunch and are all about the solutions. :wink:

All that can be done "after job" from either your O/S or by another job, simplest would be from a Server job because of the BASIC functions that do this. Check your online help for all of the DSGet* functions or the equivalents using dsjob from a command line script. Read about that in the Command Line Interface chapter of either Developer's Guide pdf.
Thanks for your Immediate reply, but it very thank full if u give solution in Parallel.

Posted: Wed May 26, 2010 7:33 am
by chulett
These are not workarounds, they are your solutions. :?

If for some silly reason you insist on using a PX job for this, include a BASIC Transformer in the job.

Posted: Wed May 26, 2010 8:10 am
by asorrell
Because of the way DataStage is architected, it is much easier to get job metadata using server routines. For parallel jobs the alternative is to write and integrate custom C programs which most sites do not have the skill to create, and are much more difficult to maintain.

Because there is no need to get job metadata in parallel, it is usually easier to write a custom routine in DataStage BASIC, then call it from a server job or sequencer.

Posted: Wed May 26, 2010 8:21 am
by chulett
Isn't that what I said? You just used way more words, Andy. :wink:

(and nice sig, perhaps I should switch from silly quotes to titles, awards and my phone number, too) LOL

Posted: Wed May 26, 2010 10:38 am
by agpt
If I simply copy the target stage to some other stage, wouldn't it give me total number of records processed which in fact is number of records in target?

Using Basic Trancformer In Px

Posted: Thu May 27, 2010 12:55 am
by rameshkm
chulett wrote:Isn't that what I said? You just used way more words, Andy. :wink:

(and nice sig, perhaps I should switch from silly quotes to titles, awards and my phone number, too) LOL


Thanks for all your suggestions, but when i am using Basic Transformer in Parallel Job the performance is very slow , more over the job is running panthom process for long time, please tell me if any special things to care while using basic transformer in PX, ie care on Partitions or any other things to do .
Thanks In advance.

Posted: Thu May 27, 2010 7:13 am
by chulett
I really, really (really) do not understand the fear of Server jobs, especially in cases where they supply the perfect solution to the need. :?

Posted: Thu May 27, 2010 11:25 am
by ray.wurlod
I do (understand the fear) but disagree totally with it.

The main issue, it seems to me from my experience, is the concern about needing to maintain two skill sets.

Posted: Thu May 27, 2010 12:21 pm
by chulett
ray.wurlod wrote:I do (understand the fear) but disagree totally with it.
Which is, of course, exactly what I meant. Totally disagree with the notion that they should be avoided at all costs, out of fear or skill set concerns or... what-knot. :wink: