vivekgadwal wrote:1) According to the above post, XMETA and UniVerse databases both are being utilized to store DataStage information. Is there a way to make the tool use only XMETA?
While the use of the switch RT/ORLOGGING will let the runtime logging information be written to either the XMETA or the old UniVerse database tables, the product still requires a UniVerse (now renamend DataStage) engine to function. But the log data can be redirected entirely to XMETA
vivekgadwal wrote:2) If so, instead of worrying about "uv" commands while looking up such information, we can query (just selects) this database directly ... am I right ?
Yes, you can query the XMETA database directly. Note that the table names are intentionally cryptic and the tables and their relationships are not documented and will most likely never be officially documented.
vivekgadwal wrote:3) Where does OSH commands play a role in here? Are they like wrappers that, when run, will affect XMETA/UniVerse databases?
The OSH commands are used to execute Parallel jobs, they have nothing directly to do with where the logging information for the job runs is written. When you compile a Parallel Job in DataStage you generate an OSH-Script (and perhaps some .dll objects called by the script) and at runtime this is executed and parsed via OSH.
vivekgadwal wrote:4) Is there a place where OSH commands are documented?
Yes, the original Orchestrate documentation (available, but I don't know where, perhaps you could search here on DSXchange) documents some of the functionality. IBM also offers some documents on their web pages but the intent is to make this part of DataStage a "black box" and users are generally not intended to have to know this scripting language or methodology in order to use DataStage.
vivekgadwal wrote:5) I have read somewhere that there is a toggle flag called RTLOGGING and ORLOGGING. Where are they utilized?
several threads exist, here's one:
viewtopic.php?t=144824&highlight=rtlogging+orlogging