DSXchange

Hashed files aren't "files" in the traditional sense. Commands like cat or type simply don't work with hashed files.

There is no modulus operator in Information Analyzer rule definition expressions - you need to use the Mod() function as indicated.

The usual security problem with MetadataServer.sh is usually the file ../MetadataServer.info which is heavily protected (-rw-------). You may need to check who is the owner of this file.

You have nowhere to import them from. Prefer a Column Generator stage.

You can buy DataStage jobs from Peoplesoft to work with their data structures. So... delivered?

Stick with OBIWAN. Use the force!

This is a simplistic explanation but, I trust, a comprehensible one. The Hash algorithm adds together the values of all the characters in the key then divides by the number of nodes. The remainder (integer division) is the node number to which the record is directed. The unstated complexity is a &qu...

Try being more explicit with data types. VarChar is very forgiving. Change TR1 to integer and expirydate and effective_dt to date (with a format string of "%dd/%mm/%yy").

In a sequence detect that the job has finished with warning (specifically about usage of reject link) and generate email using Notification Activity. You can also code this yourself in an after-job subroutine.

Even Informatica could not detect identity theft of this kind. You should be able to narrow it down fairly easily - who knows your password? Or who has/had access to your computer when you left it logged in?

(There's a certain pattern here.)

The osh script generated by a parallel job being compiled is in a directory called RT_SCnnn. Here, nnn is the job number, which is mapped to the job name via the DS_JOBS table. SELECT NAME FROM DS_JOBS WHERE JOBNO = 'nnn'; Note that JOBNO is a VarChar, so single quotes are needed. The osh script gen...

Shift-In and Shift-Out are sometimes used to indicate a change of mapping (particularly in Japanese character sets). Beware that these might be important characters before arbitrarily discarding them. Once they're inside a job, they should be able to be discarded with a simple Convert() function.

Are you using DB2 Load (or direct write from an Enterprise or Connector stage)?

As a test can you write the results of the QS job into a Copy stage, to determine whether the slowness is in QS or DB2?

Do you have the canned DataStage jobs supplied by PeopleSoft? If so, use those - they are purpose written.

DSParams and all other configuration files are picked up in a file system backup of the server and can be restored from that if your failure is bad enough to have lost file system objects. There is no need to be able to restore finer granularity than "file", unlike with DataStage projects....