capture* files in /tmp directory

[durgaps]

Hi,

I got the following error message while logging into DS :

Error calling subroutine: DSR_STATIC (Action=1); check DataStage is set up correctly in project METL_DEV_R1
(Subroutine failed to complete successfully (30107))

One of the posts here suggested to do a check for disk space usage. I checked the /tmp directory on DS server. It was full(100%). DataStage had created a file as follows: capture0000012544aa1164078516 . And the size was 971776000 bytes. (close to 971 MB). I moved the file to a different directory out of /tmp and the above mentioned login message disappeared.

Now, the query is what is the significance of this capture* file, and its size is huge (971 MB). Why was this file created and with such a size ? How can this situation be avoided?

Cheers,

[kduke]

In BASIC when you

Code: Select all

execute Cmd capturing Output

Then one of these files is created.

[ray.wurlod]

And sometimes you do it without explicitly progamming it. DSExecute() uses this technique to capture the output, as do the before/after subroutines ExecSH, ExecDOS and ExecUV.

[durgaps]

Hi Ray/Duke,

Thanks for the reply. That explains the significance on the capture* files. One more thing thats on my mind is the size of the capture file. As I had mentioned before it was close to 971 MB.

So, is it:

1. For each EXECUTE cmd from different codes in the project, the output was appended to the particular capture file over the past couple of months(since the inception of the project). Also, there were other capture files apart from this (around 300-500 kb size) created at an earlier date.

OR

2. This capture file was created in one single instance. (I guess this wont be the case. Correct me if I am wrong).

Please throw some light on this and how to handle such situations. Any guidelines/info for cleanup-management of such files will make my day

Thanks in advance,
Durga P Sahoo
ETL Developer
NAB, Melbourne

[ray.wurlod]

The numbers in the capture (and other) file names include the process ID, so there should be no appending going on. The two characters on the end (usually "aa") are there to provide uniqueness if all else matches. So it would appear that whatever was captured was 970MB in size!

You might find this post enlightening; it contains a list of other things that might occur in the UVTEMP directory.

[vnspn]

Hi,

We did get this error and it halted our development process for a considerable time. We use a lot of this DSExecute command and our DS server is on Windows.

So, where does this capture file or its equivalent sits in the windows server?

Thanks.

[ray.wurlod]

Same place: the folder specified by UVTEMP in the uvconfig file.