Return Code 13: Could not open work files

[thisismondweep]

Hi,

We dropped a file of 163 MB into the folder were the DSTX system (running under an event server with 'Concurrent Map Run =32') polls. The system was triggered but resulted in an error:-

Return Code 13: Could not open work files

The error description says:
There may not be sufficient disk space on the drive where the install directory exists to create necessary importer work files.

I read some help in the internet which said this error could occur if Workspace --->Workfile Prefix--->MapName instead of Workspace --->Workfile Prefix--->Unique. But upon reading further, realised this is only required if the map is run from the Command server. However, since our map runs under the Event Server, I do not think this is an issue.

Then, I checked the Unix disk space in the install folder(where the event server is installed):-

df -k 8.0
Filesystem kbytes used avail capacity Mounted on
/dev/md/dsk/d0 39571315 11292405 27883197 29% /


As almost 27883197kbytes is available in that folder, I am unable to correlate the error information with this.

Please advise.

Thanks!

 

[OllyC]

Under the event server, its still a good idea to have uniquely named files otherwise your maps will all go to single thread.

Possibly the resource manager has got confused and tried to run the map before a previous map has completed? Possibly TX got an IO error when it tried to open the files (so some temporary IO glitch caused the problem).

So - does the problem happen consistently?
What happens when you try to run the same map from the command line?

 

[thisismondweep]

Hi,

The problem occurs in only one of our 4 testing environments. The TX infrastructure maps are exactly the same in all 4 environments.All 4 environments run under 4 different event servers.

This makes me think that some parameter in this particular event server settings is defined diffently in the environment where the file fails. The problem is very recent. It has had not been happening even in this environment in the last 8 months of testing. It seems to me that somehow-after all these testing- the event server thinks that not much space is available to it to store the workspace files.

Is there any way by which I can find out how much space the event server allocates itself to create "create necessary importer work files."

Cheers,
Mondweep.

 

[thisismondweep]

Hi,

Following is a snapshot of the event server(when the error occurs):-

<?xml version="1.0"?>
<!DOCTYPE EventServer SYSTEM "C:\Ascential\DataStageTX_8.0\snapshot.dtd">
<EventServer EventServerName="batch.msl" HostName="abc" Port="41033" DateTimeStamp="25/05/07, 01:11:48">
<Summary MemoryUsage="0" CPUUsage="0" SystemStatus="Running" ActiveComponentMaps="0" ActiveListenersUp="1" ActiveListenersDown="0" ActiveConnections="3" StartTime="00:57:10" SuccessTime="00:12" FailureTime="00:00" UpTime="14:22" PendingInitialization="0" PendingInitializationMaximum="1" PendingResource="0" PendingConnection="0" PendingTotal="0" HistorySuccesses="1" HistoryFailures="0" HistoryTotal="1" HistoryConnectionFailures="0" HistoryDeadlocksDetected="0" HistoryFunctionFailures="2" />
<StatusInfo>
<AdapterConnections_StatusInfo Adapter="DB" Open="1" Active="0" Idle="1" Pending="0" />
<AdapterConnections_StatusInfo Adapter="MQS" Open="1" Active="0" Idle="1" Pending="0" />
<AdapterConnections_StatusInfo Adapter="SHL" Open="1" Active="0" Idle="1" Pending="0" />
</StatusInfo>
<History>
<AdapterConnections_History Adapter="DB" Requests="1" New="1" Reused="0" Successes="1" Failures="0" />
<AdapterConnections_History Adapter="MQS" Requests="1" New="1" Reused="0" Successes="1" Failures="0" />
<AdapterConnections_History Adapter="SHL" Requests="1" New="1" Reused="0" Successes="1" Failures="0" />
<FunctionFailures Component="abc" FunctionName="Failed at Run function" Arguments="bcd" Reason="13" />
<FunctionFailures Component="abc" FunctionName="Failed at Run function" Arguments="bcd" Reason="13" />
</History>
<Configuration>
<System MaximumConcurrentMaps="32" MaximumConcurrentMapsPerWatch="10" PendingInitializationHigh="0" PendingInitializationLow="0" />
<AdapterConnections_Configuration Adapter="(default)" IdleTime="00:00" KeepTime="00:00" KeepMinimum="0" AdvisoryLimit="4" MandatoryLimit="0" />
<AdapterConnections_Configuration Adapter="DB" IdleTime="00:00" KeepTime="00:00" KeepMinimum="60" AdvisoryLimit="66" MandatoryLimit="66" />
<AdapterConnections_Configuration Adapter="MQS" IdleTime="00:00" KeepTime="00:00" KeepMinimum="60" AdvisoryLimit="66" MandatoryLimit="66" />
</Configuration>
</EventServer>

As shown above, a function failure occurs in component 'abc' having argument 'bcd'.

Cheers,
Mondweep.

 

[Samji]

Hi,

Please change the Concurrent Maps to 20 and then try again.
IBM suggests to use the Max no as 20 and more than 20 may lead to more CPU utilization.

Regards,
Srinivas.M

 

[OllyC]

is it a run map that is failing rather than a system map?
if so its advisable to set unique workfiles or even use work files in memory.

 

[thisismondweep]

Hi,

The problem has been resolved as follows:-

The problem was that permissions to the folder where the application map is deployed was
drwxrwxr-x 2 dstx dstxdep 1536 May 9 13:46 map .

It was changed to to group dstxdep last week for better change management of the dstx application maps.

The event server however runs under a different user id. The application map has the following settings:-
Workspace=File; Page Size=64; PageCount=8; Directory=Map; WorkFilePrefix=MapName;Action=Delete


The section 'Directory=Map; WorkFilePrefix=MapName;Action=Delete
' shows that the map tries to create temporary workfiles within the map folder. The map is run by the eventserver userid. However, this userid was not a member of dstxdep; and hence was not able to write to that folder. We included dstxdep as one of the goups for the event server user id.After that the event server was restarted.

I then tried to drop the same 163 MB file for transformation. This time the transformation did happen. However, it did take around 5 minutes to transform the whole file(possibly because of the big size).