Netware cluster volume name causing app problems

Last post 06-25-2008 7:41 AM by jpruneda. 3 replies.

Page 1 of 1 (4 items)
	Sort Posts: Previous Next

06-21-2008 1:24 PM

JimMulenos
Joined on 02-19-2003
Posts 13

Netware cluster volume name causing app problems

Reply Contact

We have two Netware 6.5sp7 servers talking to an iScsi target on a third Netware 6.5sp7 server. The cluster is failing-over and back perfectly. The iscsi target shared volume is VOL1: which we universally map to Drive Q:. O/S and hardware are good.

PervasiveSQL Server is installed per the latest Pervasive Clustering docs with Pervasive loading in the Cluster Load Script after VOL1 is mounted. Pervasive is working great through PCC, we can create, modify and delete databases on the Pervasive Engine instantiated on the Cluster volume as M3C_CLUSTER. PSA tests the server engine perfectly. All is good here too.

Our problem is with a Pervasive-enabled application by Data Access Corporation called Visual Dataflex (aka, "VDF") that we have been using for years. Here is what is happening:

1) When we map Drive Q to VOL1: via NDS like this "MAP Q:=M3C_CLUSTER/VOL1:", we can use the VDF IDE, compile, use all their tools and do everything in VDF _except_ run programs. The Pervasive error is 3012, always and only at runtime.

2) When we map Drive Q to VOL1: directly like this "MAP Q:=VOL1:", VDF works perfectly.

Here is the problem: Using the first method Drive Q fails over perfectly on server fail-over for every application but VDF. Using the second method VDF runs perfectly but since VOL1: is implicitly mapped to whatever server node is master at login time, the mapping fails at server fail-over, and VDF goes with it. Trouble.

Error 3012 seems to say that Pervasive is confused about where the engine is or what it's name is and I believe the issue is with Pervasive not VDF since the problem occurs only when we try to run compiled programs. The ideal of course is to get VDF running AND operating through the server fail-over. Your suggestions would be most appreciated. Many thanks.

Jim

06-23-2008 3:34 PM In reply to

jpruneda
Joined on 06-11-2007
Posts 265

Re: Netware cluster volume name causing app problems

Reply Contact

It could be a DNS issue where the Pervasive dll’s can’t resolve the cluster name M3C_CLUSTER. Are you able to ping M3C_CLUSTER and does it resolve to the correct IP address? If not, you would want to add that address to the clients system32\drivers\etc\hosts. file. If pinging works OK, it would be helpful to see a trace of the application when it gets the 3012 using the Pervasive client trace dll’s. The instructions for doing that would depend on the version of the Pervasive client being used.

Phil

06-23-2008 5:06 PM In reply to

JimMulenos
Joined on 02-19-2003
Posts 13

Re: Netware cluster volume name causing app problems

Reply Contact

Phil

No problem pinging the cluster volume by ip address 192.168.2.106 or by host name M3C_CLUSTER. Hosts file is correct. I would love to resolve this and would appreciate your help to learn how to trace this in Pervasive version 8.70. Thanks.

Jim

06-25-2008 7:41 AM In reply to

jpruneda
Joined on 06-11-2007
Posts 265

Re: Netware cluster volume name causing app problems

Reply Contact

This information is from the "What's New" manual. The resulting trace may require analysis by Pervasive Support. This would require that you open an Support ticket.

TracingRequestersTracing requesters for Btrieve are now provided on your installation CD-ROM. These requesters are compiled so that they produce diagnostic output that can be used to troubleshoot application problems. If you are an advanced user or developer, you may copy these DLLs into your product installation in order to helptroubleshoot problems you have not been able to solve otherwise._ To configure the trace requesters1 Get the trace requesters from the directories listed below on your installation CD-ROM, and copy them into the BIN directory of your Pervasive.SQL installation. Be sure to back up the originalfiles before starting, or note that the original requesters are copied to the CD-ROM at \clients\trace\release. The BIN directory is c:\pvsw\bin by default.Win32 (Windows 9x/NT/2000/XP)\clients\trace\trace\w3bif1xx.dll (BIF)\clients\trace\trace\w3mif1xx.dll (MIF)\clients\trace\trace\w3nsl2xx.dll (NSL)Win16\clients\trace\trace\w1bif1xx.dll (BIF)\clients\trace\trace\w1mif1xx.dll (MIF)\clients\trace\trace\w1nsl2xx.dll (NSL)2 Run an application such as the Btrieve Function Executor thatloads the Btrieve DLLs.3 When the trace DLLs load, they look for configuration settings that control the diagnostic output. If the configuration settings are not present, the trace DLLs create the settings and set them to generate no output. You need to adjust the settings to force the trace DLLs to generate output. The settings vary by platformas follows:Win32 - Settings are in the registry underHKEY_LOCAL_MACHINE\SOFTWARE\PervasiveSoftware\Communications Requester\DiagnosticsWin16 - Settings are in <windir>\BTI.INI under [Diagnostics]1-29Improved Networking SupportConfigure the diagnostic settings:4 Exit and restart the application. The output is generated in the file specified in the Trace File setting. The file is held open only when writing individual trace messages, so you don’t necessarily need to wait until the application finishes to view the file. Note however that if the requester DLLs can’t open the file (forexample, if you have the file open with Notepad) they write the trace output as a message box instead.The general format of the output is:[process_ID,thread_ID]timestamp module_name - trace_messageThe format and content of trace_message varies. Typically, each message begins with the name of the routine writing the message. You should be able to glean important information by looking for specific status codes returned to the application, or by reading through the output in order to follow the flow of therequester’s processing. The trace requesters should be used primarily for gathering information to send to Pervasive Customer Support. These requesters run slower than the normal requesters and as such shouldbe used sparingly. If you misplace the original requesters, they are on your installation CD-ROM at \clients\trace\release.Table 1-7 Trace Requester SettingsSetting DescriptionTrace Append Always set to “yes”.Trace BufferLengthControls how much of the key and data buffers theBIF and MIF dump to the output file. Start with thedefault (32 bytes) and increase if needed.Trace File Set to a specific file name (i.e. c:\trace.txt) whereyou want the output to appear. The file is createdas needed.Trace Level Controls the level of detail in the output. It issuggested you set it to “verbose” for maximumoutput.Trace Modules Determines which modules write debug output.Set to “all” or to the name of the specific DLLs,such as “w3nsl107” or for multiple DLLs,“w3mif10a, w3nsl107”.

Page 1 of 1 (4 items)