I am attempting to setup our environment on a new server and have hit a wall in the part of our code where Texis tasks are spawned in the background by the main CGI web application... As far as I can tell, the only difference between this server and our other servers is that on this new one the script root is on a virtual drive (VMWARE Fusion is the software used to provide the virtual drive). Yes, I know this is a BIG difference, but these things *should* be fairly transparent, at least according to the VMWARE sales staff! The lines of code that spawns the background task are:
<strfmt "%s\\backgroundSearch" $scriptPath>
<$theCommand=$ret>
<exec bkgnd -- $texisPath $theCommand></exec>
On our other servers, scriptPath is defined as:
<$scriptPath="D:\Crosshairs\script\">
and texisPath is defined as
<$texisPath="C:\Morph3\texis">
That works fine on all of our servers other than the new one. As a first attempt on the new server, I created a mapped network drive for the VMWARE drive and assigned the drive letter D: to it, hoping that everything could remain the same. That did not work, and the following errors were written to the vortex log:
002 2013-04-11 14:54:19 D:\Crosshairs\script\backgroundSearch: Cannot open source file: No such file or directory
Strange, because that is absolutely the correct path (in mapped drive-ese!). So, I changed the definition of scriptPath to:
<$scriptPath="\\vmware-host\Shared Folders\Crosshairs\script\">
In this case the following error is written to the vortex log:
002 2013-04-11 14:59:25 Cannot open C:\MORPH3\: no SYSTABLES in the function ddopen
000 2013-04-11 14:59:25 Could not connect to . in the function openntexis
This makes no sense to me. In the latter case (i.e., using \\vmware-host\ etc.) a process id IS returned by <exec>, and possibly in the former case as well (not sure). In neither case, though, is the background task actually spawned as expected. I know this because debug lines at the top of the main function of the module backgroundSearch (which write to a file) are never hit and that debug file is never created.
I realize our code base is rather complicated, and it's likely I've left out some significant pieces of information, although I'm not sure what those could be. At this point I'm kind of groping in the dark. That said, can you think of where I might look for a resolution? It's frustrating.
Thanks.
<strfmt "%s\\backgroundSearch" $scriptPath>
<$theCommand=$ret>
<exec bkgnd -- $texisPath $theCommand></exec>
On our other servers, scriptPath is defined as:
<$scriptPath="D:\Crosshairs\script\">
and texisPath is defined as
<$texisPath="C:\Morph3\texis">
That works fine on all of our servers other than the new one. As a first attempt on the new server, I created a mapped network drive for the VMWARE drive and assigned the drive letter D: to it, hoping that everything could remain the same. That did not work, and the following errors were written to the vortex log:
002 2013-04-11 14:54:19 D:\Crosshairs\script\backgroundSearch: Cannot open source file: No such file or directory
Strange, because that is absolutely the correct path (in mapped drive-ese!). So, I changed the definition of scriptPath to:
<$scriptPath="\\vmware-host\Shared Folders\Crosshairs\script\">
In this case the following error is written to the vortex log:
002 2013-04-11 14:59:25 Cannot open C:\MORPH3\: no SYSTABLES in the function ddopen
000 2013-04-11 14:59:25 Could not connect to . in the function openntexis
This makes no sense to me. In the latter case (i.e., using \\vmware-host\ etc.) a process id IS returned by <exec>, and possibly in the former case as well (not sure). In neither case, though, is the background task actually spawned as expected. I know this because debug lines at the top of the main function of the module backgroundSearch (which write to a file) are never hit and that debug file is never created.
I realize our code base is rather complicated, and it's likely I've left out some significant pieces of information, although I'm not sure what those could be. At this point I'm kind of groping in the dark. That said, can you think of where I might look for a resolution? It's frustrating.
Thanks.