DSXchange

Need a memory upgrade. Hmm.

Maybe. Can you post the code generated by the Transformer stage? It's in a subdirectory called RT_SCnnn in your project, where nnn is the job number.

ODBC is OK, but you have to remember that each Worksheet is visible to the ODBC driver for Excel as a system table. Worksheets must be in tabular form, with "column names" in row $1:$1. Of course, you will also need to find (and possibly license) an Excel ODBC driver for UNIX to be able to use this ...

This means that you are not running version 7.5x2 which is the ONLY Windows-based version (until 8.0 is available) on which parallel jobs can be run. You have only one solution available if you want to run parallel jobs (or compile parallel jobs that contain Transformer or Build stages), and that is...

I wonder if it's an issue with the Data Direct ODBC licence? According to the Parallel Job Developer's Guide manual and IBM's training classes, sparse lookup is only supported for DB2/UDB and Oracle Enterprise stages. So you may have exhausted the grace period on the licence for your ODBC driver.

Is your operating system Windows XP Pro with service pack 2 and, if so, do you have the DataStage patch for this combination installed?

Was Sybase shut down or quiesced before or while this job was running?

Maybe your computer is too fast! It could be exhausting the number of retries before the timeout kicks in. Search the Forum for information about the SPINTRIES and SPINSLEEP configuration variables that can be used to tune mutex lock behaviour. You might also increase the timeout on your IPC stages.

Which command line?

What precisely is the error message?

Did you make any typing errors when entering the query? It may be that the query environment has not been advised that the backspace key is also the erase key.

Some specific commands are blocked in the Administrator client. You can successfully executed them from a telnet session. I didn't think that LIST DICT was one of them, however. It may be that the particular table name is blocked - that would be easily gotten around by defining a synonym. You did no...

It's impossible to capture the records that were not lookup up when performing a lookup, unless you immediately delete the successes from the reference table (hashed file) and inspect the survivors afterwards. In SQL you might use a NOT IN comparison to a subquery that included all your matches. Doi...

It's not UniVerse, it's DataStage, as noted elsewhere. DS_JOBOBJECTS has three key columns, OBJTYPE, OBJIDNO and OBJNAME OBJTYPE is a single letter, either "J" for job or "C" for container OBJIDNO is the job number, which maps to DS_JOBS.JOBNO or DS_CONTAINERS.CONTAINERNO so that job/shared containe...

DS_JOBOBJECTS is not a UniVerse table, it's a DataStage table. It has different record structures, some with up to 216 columns. The vendor has chosen not to reveal the structure of those records via column definitions. Therefore, without "hacking" (which violates the clause in your licence agreement...

Ask your UNIX administrator about at and cron. Jobs just for today are scheduled using at, while repeats are scheduled using cron. You may be permitted to use at but not to use cron. The UNIX administrator controls this through files called at.allow and cron.allow respectively.

Without prior deletion you can only ever INSERT a particular key once into an Oracle table that has a primary key defined. Perhaps you need to revisit the design of that table if there are to be more than one run with the same process date. Or maybe you're just not generating the seconds part of the...