A client application changes its current working directory and subsequent MFClass object creations fail to find the services_def file.
During programatic creation of an MFClass object, an error similar to the following is reported:
E-09/23/08 10:16:15-MFClass::readServices(): Cannot open services_def file: /opt/ibm/wfo/subscriber/config/services_def
Diagnosing the problem
Each time an MFClass object gets created within ITCL, the services_def file and the itbl_fields file are read in, based on the value of DATADEF_FILENAME in the application's .cnf file. When an application changes its working directory programmatically, it causes a problem because, by default, the DATADEF_FILENAME specifies a relative path. In this case, any subsequent MFClass object creations will result in an error indicating that the services_def and itbl_fields files can not be found. The result of this is that the MFClass object fields (populated by information in the services_def and itbl_fields files) are undefined.
Resolving the problem
The solution is to set the DATADEF_FILENAME to be an absolute file path reference. This will keep the services_def file (and the files it references) from being read in every time an MFClass object is created. Here is an example of an absolute file reference in an application's .cnf file:
GENERIC_ENTRY DATADEF_FILENAME /opt/ibm/wfo/subscriber/config/services_def
NOTE #1: The fields files referenced from the services_def file (for example, itbl_fields) must be located in the same directory as services_def. Setting the absolute path of the fields files in the services_def file will not work.
NOTE #2: When using an absolute path to the services_def file, the DOS-style path format is not supported. For example, /IBM/subscriber/config/services_def will work (on both Windows and Linux/Unix) but C:\IBM\subscriber\config\services_def will not.