DSXchange

... unless, of course, you have an explicit "Failure" trigger, whose existence causes it to have priority over the automatic handler.

Hashed files don't go away either.

I've already mentioned that it's not UniVerse. However, a query like the one you postulated, terminated with a semi-colon, will dump the contents of a particular job log.

What are you trying to achieve? This particular wheel may already have been invented.

There are options (new in version 8.1) in the DSParams file that govern location of DataStage job logs. You can Search DSXchange for details.

It's not DS_OBJECTS, it's DS_JOBOBJECTS.

Use ODBC driver for text files.

No. The advice relates specifically to Switch and Filter stages. The Copy stage is more efficient for renaming and dropping columns than is the Transformer stage.

The short answer is no. If you're running version 8.1 you get a choice of storing logs in the unified metadata repostiory or in the local DataStage project repository. Secondly, the DataStage engine has not been UniVerse since prior to version 6.0. Thirdly, every job has a separate hashed file, name...

You should not even be allowed to copy in production; production should ideally be a protected project.

Use the Data Set Management Tool (or equivalent orchadmin commands) to view the record schema and data in Data Sets.

Things changed between the two releases. The Transformer stage now compiles to an (efficient) transform operator. This was not the case in earlier versions.

Check in Web Console for IBM Information Server - you may just have made everyone a DataStage Administrator (rather than doing things the correct way)!

It's not an error; it's an alert that your job design may be doing something foolish that might result in data loss. Search DSXchange for more information; it's been posted many times before.

Or do you want an operating system level command? If so you're out of luck unless you create DataStage components (maybe a job) that you can invoke using dsjob.

You can not remove the eof character - the operating system needs this to tell it when to stop reading the file.

Make sure that every line in the file, including the last line, has a correct line terminator. Your metadata expects it to.

I've also seen this error on a machine in which one of the memory chips started throwing parity errors. It might be worth getting the machine's memory verified.