DSXchange

This can be a trap, because dsenv runs in Bourne shell (check out line 1). Anyone used to automatically exported environment variables (like in some of the newer, "cleverer" shells) is likely to forget to include the export commands, even though there are already some there!

And are the old RT_LOGnn, RT_CONFIGnn (etc.) files deleted?

There's no reason in theory that you shouldn't do what you want, but you're taking a risk that the system might be stopped during your long sleep. Or that an administrator may clean up apparently idle processes. I'd advise researching a different approach, perhaps finish gracefully now and schedule ...

Only if your job is running as a user with DBA privilege could it perform any DBA commands.
Probably the easiest thing to do is to create a shell script (or invoke a stored procedure) that executes with DBA privilege and performs the set integrity operation.

The SLEEP statement has two formats. SLEEP seconds SLEEP hh:mm But the second format only works within a day. If hh:mm is in the past, SLEEP does not wait. To sleep until 02:00 you need to resort to something like: SLEEP 23:59 SLEEP 120 SLEEP 02:00 Or, of course, you can calculate the number of seco...

Can you identify the processing node associated with Player 5? (The metaphor here is an orchestra; there is a conductor, section leaders and players.) If you can, then you can narrow your search to configuration and other factors associated with that processing node, such as whether all required com...

When you do, you will find that user name and password fields are disabled. The localuv data source is predefined in the uvodbc.config file.

Such a pointer can be created, but it does not treat the directory as an account. Rather it treats the directory as a table, the file names within the directory as key values, and the file contents as data records. Not all of which will be readable (hashed files, for example) via queries. Also, you ...

No, because they're on Windows and are probably using the Microsoft ODBC driver.

Attention to detail, lad!

Not true at all - the code is using BCI functions. The statement being executed is a CALL statement. I'd be a bit concerned at using a number as the target of put_line in the stored procedure, but you claim it works. The BASIC language is documented in the DataStage BASIC manual, which you will find...

Duplicate keys are not possible in hashed files, and DS_JOBS is a hashed file with NAME as its key. That's why duplicate names are not possible. Under some circumstances, however, you can see duplicate key values in corrupted hashed files, or hashed files with corrupted indexes. Check that DS_JOBS i...

Renaming the job does not change the job number, and therefore retains the original log, status and config files. All renaming the job does, after a number of sanity checks, is to modify the DS_JOBS entry and some entries in DS_JOBOBJECTS, particularly the ROOT and V0 entries for that job. Exporting...

Learn patience, grasshopper! If it's huge, it will take a long time to open. You can request that the job log be cleared from Status view, which helps somewhat, but the pre-clear process still involves a goodly amount of checking, which means a table scan, which takes time. Start it before you go ho...

... but introduces a Y10K problem and doesn't handle BC dates

Search the forum for SETFILE. This is a command for creating a pointer in the VOC file. Chuck will chime in soon with a plug for his utility CreateVocPtr.