DSXchange

Is it possible to run 2 instances of DataStage within the same instance of
Solaris 8 (a scenario something like development and QA sharing the same
domain)?

Thanks.

thanks! Original Message: ----------------- From: Ray Wurlod rayw@mindless.com Date: Sat, 29 Mar 2003 23:27:54 +1000 To: datastage-users@oliver.com Subject: Re: Unix Job Detail Event Almost. dsjob -logdetail You can enter dsjob alone (gives overall syntax), or with just an option (for example "dsjob...

Almost. dsjob -logdetail You can enter dsjob alone (gives overall syntax), or with just an option (for example "dsjob -logdetail") for more targeted syntax. Its in the Server Job Developers Guide; from memory the chapter title is something like "Command Line Interface" - anyway, you can find it in t...

so would usage be(?) /dsjob -logdetail EventID $projname $jobname ? Original Message: ----------------- From: Ray Wurlod rayw@mindless.com Date: Sat, 29 Mar 2003 16:34:16 +1000 To: datastage-users@oliver.com Subject: Re: Unix Job Detail Event The function youre looking for is DSGetLogEntry() from Da...

ouch. Thats a good suggestion, but a lot of work. I may have to just write a BP and pass it jobname,projname and first/last ids. Thanks John Kenneth Bland wrote: >There is a possibility, but its not pretty. > >Every job has a set of corresponding hash files that >support the job execution: RT_BPxxx,...

The function youre looking for is DSGetLogEntry() from DataStage BASIC, or the option -logdetail from dsjob. In either case you need the log event ID (this is a sequence on the log), which you can determine via the DSGetNewestLogId() function in DataStage BASIC or the option -lognewest from dsjob. -...

Is it possible to retrieve a full,single event detail from the unix
prompt? (not logsummary)
without UV cmd?

john s

There is a possibility, but its not pretty. Every job has a set of corresponding hash files that support the job execution: RT_BPxxx, RT_LOGxxx, RT_CONFIGxxx, RT_STATUSxxx, where xxx is the job number found by cross referencing the job name to its number in the DS_JOBS hash file. The RT_LOGxxx file ...

Please can someone tell me how I get removed from this list? Regards Doug -----Original Message----- From: Xiong Li [mailto:Xiong.Li@team.telstraclear.co.nz] Sent: 28 March 2003 05:19 To: datastage-users@oliver.com Subject: RE: ORAOCI9 plugin issue. The problem is weve already close the properties w...

We process the lines as a generic string and use a transformer to assign substrings to the record variables. This approach does require that you have some way to identify the unwanted records other than position in the file. -----Original Message----- From: Thomas Nel [mailto:Tom@KnowledgeNetco.com]...

Thanks for the warning. As the webmaster for Tools and the DSX (http://www.datastagexchange.com) I try to be a watchdog for such things. Naturally, I can't do anything about the Oliver list but if you catch wind of whom the culprit is or of any similar behavior stemming from Tools or the DSX please let me know.

If you can generate/describe a reproducible case, open a support call. I have not seen this behaviour. ----- Original Message ----- From: Xiong Li Date: Fri, 28 Mar 2003 17:18:39 +1200 To: "datastage-users@oliver.com" Subject: RE: ORAOCI9 plugin issue. > The problem is weve already close the propert...

The problem is weve already close the properties window. The lock just cannot be released. Even worse, I must close all relative jobs, then the lock may be released. It really cannot be accepted. -----Original Message----- From: Ray Wurlod [mailto:rayw@mindless.com] Sent: Friday, 28 March, 2003 17:0...

Ive had this happen to me at a customer site as well. What Ive noticed is that if two clients are trying to access the same metadata at the same time in the ORAOCI9 stage. For example, if developer1 selects a column through either the sql builder or does "load" under column tab, until that user eith...

The query builder takes a lock on the table definition for the table(s) for which the query is being built, so that the underlying metadata are not changed while the query is being built. Its a standard lock in the DataStage Engine database, and is intended to prevent any other process from updating...