Re: error retrieving temp location

kavithak,

This thread is many years old. Instead of resurrection it, can you post a new one with the issue you face?

Try the following solution first- Article Number 000418579



######

Symptoms

When configuring CFS on secondary serer you may get error in headstart.out file “Error retrieving temp location”

Cause

As the error is found on the second server it is likely that the second server cannot see or find the file_system_path of primary location.

Resolution

1) Share out the location and update the file_system_path to a UNC path accessible by both servers

OR

2) Create the location on the second server on the file system

OR

3) Change temp location for dm_location object i.e.

DQL> select * from dm_location where object_name=’temp’

Create the new directory with the same permissions: i.e.temp1

Example: ‘D:DOCUMENTUMsharetemp1’

Now update the object: Try from DQL:

DQL>update dm_location object set file_system_path='<new path directory>’ where object_name=’temp’

Note: You will need to copy everything under the temp directory to the new location, because there are some references that you will need in the new location.

Now run the CFS configuration secondary server. once this is done. Revert changes to temp.

####################

Related:

how does the Load Balancing for CFS exporter and Importer Workers work?

There are using 4 CPE/CFS/ICI Servers. Means that 4 instances if CFS Exporters are running and 4 instances of CFS importers are running. How does the Load Balancing for CFS exporter and Importer Workers work? One CFS/ICI/CPE Servers process one single rule completely OR even for 1 rule, different chunk / batches of resultset are processed by different CFS Exporters instances/Importer Instance? Any threshold for the size of filter to be able to pickup/process by different server?

Related:

The PureScale CF stucked in PEER mode

We have DB2 GDPS on following level:

Instance “nprodftm” uses “64” bits and DB2 code release “SQL11010”
with level identifier “0201010F”.
Informational tokens are “DB2 v11.1.0.0”, “s1606081100”, “DYN1606081100AIX”, Fix Pack “0”.
DATA #2 : System Info, 416 bytes

System: AIX psinstancecf1a 1 7 00FA90FF4C00

There is a problem once one of CFs goes down (in this case manually for maintanance purpose). The db2instance list shows following status:

ID TYPE STATE HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
— —- —– ——— ———— —– —————- ———— ——-
0 MEMBER STARTED psinstancedb1a psinstancedb1a NO 0 0 psroce1db1a.domain.co,psroce2db1a.domain.co,psroce3db1a.domain.co,psroce4db1a.domain.co
1 MEMBER STARTED psinstancedb1b psinstancedb1b NO 0 0 psroce1db1b.domain.co,psroce2db1b.domain.co,psroce3db1b.domain.co,psroce4db1b.domain.co
128 CF ERROR psinstancecf1a psinstancecf1a YES – 0 psroce1cf1a.domain.co,psroce2cf1a.domain.co,psroce3cf1a.domain.co,psroce4cf1a.domain.co
129 CF PEER psinstancecf1b psinstancecf1b NO – 0 psroce1cf1b.domain.co,psroce2cf1b.domain.co,psroce3cf1b.domain.co,psroce4cf1b.domain.co

As we can see, one of CFs is stucked in PEER state. We also need to mention is that state above is interim. Once error host is brought up, cluster goes back to normal state.

The expected behavior is that other CF takes over and becomes PRIMARY:

ID TYPE STATE HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
— —- —– ——— ———— —– —————- ———— ——-
0 MEMBER STARTED psinstancedb1i psinstancedb1i NO 0 0 psroce1db1i.domain.co,psroce2db1i.domain.co
1 MEMBER STARTED psinstancedb2i psinstancedb2i NO 0 0 psroce1db2i.domain.co,psroce2db2i.domain.co
128 CF ERROR psinstancecf1i psinstancecf1i YES – 0 psroce1cf1i.domain.co,psroce2cf1i.domain.co
129 CF PRIMARY psinstancecf2i psinstancecf2i NO – 0 psroce1cf2i.domain.co,psroce2cf2i.domain.co

Related:

DB2 PureScale CF is not taking over once other CF is down.

We have DB2 GDPS on following level:

Instance “nprodftm” uses “64” bits and DB2 code release “SQL11010”
with level identifier “0201010F”.
Informational tokens are “DB2 v11.1.0.0”, “s1606081100”, “DYN1606081100AIX”, Fix Pack “0”.
DATA #2 : System Info, 416 bytes

System: AIX psinstancecf1a 1 7 00FA90FF4C00

There is a problem once one of CFs goes down (in this case manually for maintanance purpose). The db2instance list shows following status:

ID TYPE STATE HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
— —- —– ——— ———— —– —————- ———— ——-
0 MEMBER STARTED psinstancedb1a psinstancedb1a NO 0 0 psroce1db1a.domain.co,psroce2db1a.domain.co,psroce3db1a.domain.co,psroce4db1a.domain.co
1 MEMBER STARTED psinstancedb1b psinstancedb1b NO 0 0 psroce1db1b.domain.co,psroce2db1b.domain.co,psroce3db1b.domain.co,psroce4db1b.domain.co
128 CF ERROR psinstancecf1a psinstancecf1a YES – 0 psroce1cf1a.domain.co,psroce2cf1a.domain.co,psroce3cf1a.domain.co,psroce4cf1a.domain.co
129 CF PEER psinstancecf1b psinstancecf1b NO – 0 psroce1cf1b.domain.co,psroce2cf1b.domain.co,psroce3cf1b.domain.co,psroce4cf1b.domain.co

As we can see, one of CFs is stucked in PEER state. We also need to mention is that state above is interim. Once error host is brought up, cluster goes back to normal state.

The expected behavior is that other CF takes over and becomes PRIMARY:

ID TYPE STATE HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
— —- —– ——— ———— —– —————- ———— ——-
0 MEMBER STARTED psinstancedb1i psinstancedb1i NO 0 0 psroce1db1i.domain.co,psroce2db1i.domain.co
1 MEMBER STARTED psinstancedb2i psinstancedb2i NO 0 0 psroce1db2i.domain.co,psroce2db2i.domain.co
128 CF ERROR psinstancecf1i psinstancecf1i YES – 0 psroce1cf1i.domain.co,psroce2cf1i.domain.co
129 CF PRIMARY psinstancecf2i psinstancecf2i NO – 0 psroce1cf2i.domain.co,psroce2cf2i.domain.co

Related:

The directory or file cannot be created.

Details
Product: Windows Operating System
Event ID: 82
Source: Kernel
Version: 5.0
Component: System Resources
Symbolic Name: ERROR_CANNOT_MAKE
Message: The directory or file cannot be created.
   
Explanation

One of the following errors occurred:

1. The file or folder name already exists.
2. The folder path cannot be found.
3. The root folder is full or there is not enough space on the disk for the new file or folder.
4. The folder name contains unacceptable characters or is a reserved file name.
5. The disk is not properly formatted.

   
User Action

Verify the path. If there is not enough disk space, delete some files and try again. Verify that the file name you are using is compliant with the type of file system your are using.

Related: