DSXchange

I think that the ExecuteCommandActivity should call a UNIX shell script that you can write which then does your loop for you.

A multi-instance job is only in the DS_JOBS one time, the instance information is found only in the log file for that job.

Rachel, perhaps you could confirm that your Premium/Charter membership has paid off The "2 1 1" and "2 1 4" are the command line options for File Type, Modulo, Group Size respectively. For this file the group size is not important - I think it is a matter of taste for some of the old timers , I alwa...

If you look at the code for the two routines you will see where they execute the command EXECUTE "CREATE.FILE SDKSequences 2 1 1" in one and Call DSExecute("UV", "CREATE.FILE SDKSequences 2 1 4", Output, Code) in the other. If you go to your ADMINistrator tool and execute the command line "CLEAR.FIL...

Rachel, if you recall in the beginning of this thread, I asked if you could check the file sind I recalled that it was a type 2 and shouldn't contain many records. This would account for the slow performance you are seeing. You most likely called this up one time and passed it key numbers instead of...

Rupesh,

DS is only supported on Red Hat Enterprise Linux AS. You stated you have RedHat 9.3 Aurix so the answer that Ray gave stands. By the way, I looked at RedHat's site and couldn't find any reference to "Aurix"

If the database has it declared as CHAR(1) then why are you declaring it differently in DS and what happens if you keep the CHAR(1) in you DataStage job?

Isn't the c++ compiler on UNIX limited to a given number of concurrent compiles, so if that limit is reached the compiler waits until it can compile? That might explain some slowdowns in compilation times.

Unless you explain nobody will know the point.

1. What is your column defined as in your database DDL?
2. What is your column defined as in your source stage accessing the database in DataStage?

If your file is defined in a simple COBOL copybook without OCCURS DEPENDING ON or similar complex construct you won't even have to use a CFF stage to read it.

You cannot do lookups on a sequential file, but you can load that file to a hashed file stage and do lookups on that.

How are you calling DSAttachJob? I can't recall the "correct" way at the momen, but I usually will check for a JobHandle value gt 0 although the handbook states one shouldn't rely on that.

You should check for errors on DSAttachJob() and the -1 is a DSJE.BADHANDLE (I'm not sure if I have the code right from memory, but it's something like that).

The routine will be faster. but How are you planning on getting your 500,000 x 11 [10 cols + 1 key] pieces of information into your routine? If your routine does a hashed file lookup to get this information then your scenario 1 is suddenly the better one, since you can pre-load the data to memory an...

The most common reason for not being able to write to RT_CONFIG<nnn> files is insufficient UNIX access rights, often caused by not setting the user's umask correctly. The second most common cause is a full disk.

Do you have your deadlock daemon set up or running on this system? You could try to use the "dsjob -log <project> <job>" to see if you can get at the logs another way or if that process is also hanging.