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?
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
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
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
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?