DSXchange

Hi All ,In datastage is it possible to store a output record content created in parallel job level in the form of variable and parses it to sequence level ? I am able to do this by the storing o/p in a file and then parsing this value after reading it using excute command activity sequence job .Is there any inbuilt function which datastage is able to do the same. ?

Only via a Server job and USERSTATUS. Does your job that creates this 'output record content' really need to be a Parallel job?

Or you may be able to accomplish that in a Parallel job by using a Server Shared Container for that USERSTATUS portion but I'd have to leave that to others to confirm / deny...

Thanks for the response.The idea,for each time when this job run its creates a sequence number referred as run id , so that it can tied up with all records inserted that time.This run id value (output content ) should be parsed to next attached jobs ,and this runid value be stored as a variable ,instead of referring it from a table where the records are inserted.

Server job. USERSTATUS. Pass as a Job Parameter to all downstream jobs that need it.

Thanks for response, I tried search for dsuserstatus in the routine list through basic transformer , i guess its missing in my client .Could you pls let me me know where I can find that .? or should we create a custom routine instead ?

You need to look for DSSetUserStatus and provide a wrapper for it as noted in this post as one example. There are many.

Thanks Craig ! ! It worked

Craig, One more query regarding this- I dont if this a stupid one. Will it creates any issue when we run this particular job as a multiple instance ? Like userstatus created by one instance may override the userstatus of the value created by another,when many instance are running simultaneously ?

That's a perfectly valid question! I'm going to take a guess as I don't remember ever actually testing that in my time with DataStage. I believe that since there still is only one job under the covers and one job log that you basically get 'views' into to see the instance logs, the answer will be that yes it would be a problem and what you'll find in USERSTATUS would be the value from the most recent instance.

Perhaps someone will chime in with a definitive answer. In the meantime it shouldn't be hard to build a simple test, try it out yourself.

UserStatus area is separate for each instance. In general it won't be a problem.

Because of how and where it's stored, you should in general avoid storing dynamic arrays in the User Status area of multi-instance jobs. This is the only way I know to break the mechanism.

Good to know. I could see either answer being true, thanks for the clarification. I wonder if an instance's USERSTATUS value is lost when the log records for its run get purged? Compiling a job clears them all, FYI.

chulett wrote:Or you may be able to accomplish that in a Parallel job by using a Server Shared Container for that USERSTATUS portion but I'd have to leave that to others to confirm / deny...

No. This won't work. It is currently impossible to manipulate the Userstatus-variable from within parallel-jobs.

The behaviour of many Basic-routines is quite strange when used from within a parallel-job. DSWarn will produce a warning in the job-log, for example, but the job will finish successfully, anyhow. The engine simply ignores user-generated warnings.

Thank you all ! I tested the above multiple instance scenario(using server job) with different test scenarios.Its working perfectly fine.