TestStand 4.1.1 vi search path

    This is so low-level I'm almost embarassed to ask. I'm using TestStand 4.1.1 over LabView 8.6, both of which are licensed as full development systems.
In order for our organization to make better use of (non-NI or Labview) source control, we've created a common directory structure for several developers over several large TestStand/LabView projects. This includes areas for "common VIs" that are reused across projects. So I'm in the process of migrating a rather complex project into a new directory structure. The sequences and VIs in question were working perfectly under TestStand 4.0/LabView 8.5 prior to this attempted migration.
   My test sequences (and sub-sequences) can't seem to find needed VIs, even though they exist in directories that are included in the search paths I configured. (An annoying sub-problem is that TestStand appears to "hang" while the LabView interface underneath the TestStand window is prompting for a VI's location. I have to click the LabView item in the Windows menu bar to get LabView "on top" and see what the problem is.)
   I've already added several paths to both the LabView and TestStand VI search paths, and I've even checked the "search subdirectories" box, but the items are not being found. It's going to take weeks to lead TestStand and LabView by the nose to find all this stuff.
   I can't believe this would really be a bug. I tried searching the forums for an answer and had no luck. I can't be the first one with such a problem, so help me out with some search terms so I don't have to clutter the forum with such basic stuff. Thanks.
-M

trosier, Neurotika,
It appears as if LabVIEW is having trouble finding your VIs, not TestStand. When TestStand loads the VI you have designated as a code module into memory, if you have the LabVIEW development environment designated in the LabVIEW adapter settings, we tell LabVIEW to load the VI via its ActiveX interface.
If TestStand is unable to find the top-level VI, you will see a dialog like this:
If LabVIEW is unable to find a sub-VI, you will see a dialog like this:
Notice that the TestStand dialog has an additional checkbox at the bottom that allows you to select an absolute path. Also notice that TestStand specifies what file its looking for in the Files of Type box while LabVIEW allows you to choose All LabVIEW Files. Which dialog are you seeing?
Another way to test this is to try to open one of your VIs from disk (by double-clicking on it). If you get a Searching for SubVIs dialog, then it is LabVIEW that can not find the dependencies.
Or if you open the specify module pane of the sequence editor, if TestStand cannot find the top-level VI, you will see a file not found warning like this:
If TestStand can find the file, but LabVIEW cannot find a sub-VI, then you will not get a warning or error until the VI is loaded.
The reason that this matters is that TestStand and LabVIEW do not share their search directory lists. If you have moved files, you will need to know which application cannot find its files.
Message Edited by Josh W. on 04-23-2009 11:27 AM
Josh W.
Certified TestStand Architect
Formerly blue
Attachments:
subVI not found by LabVIEW.JPG ‏31 KB
TestStand file not found.JPG ‏7 KB
VI not found by TestStand.JPG ‏31 KB

Similar Messages

How to define Containing Project Directory in the TestStand Search Path?

In TestStand Search Path one of the list is "Containing Project Directory". How can I define this?

Legal Engineer -
TestStand does expose the "containing project directory" in the search directories dialog box. It only has meaning for the FindFile API function when the "currentSequenceFile" parameter is set to a project file. I agree that it is confusing in that it does not apply to steps finding code modules. If you unchecks this setting and you reload a workspace, any projects that use relative paths to specify their files may no longer find their files.
In general the suggestion is to leave it checked and ignore it.
Scott Richardson (NI)
Scott Richardson
National Instruments

Including a LLB into the Teststand search path

Hello everyone,
on a testsystem I am using Teststand 2013 and Labview 2013. There are different measurement instruments in my system and right now I have all the VIs for controling these instrumtens saved as VIs on my system. Now I want to change this into an LLB. But when I do that, Teststand is no longer able to find the VIs inside the LLB, although the LLB is in the serach path of Testand. Since a lot of Sequence files access these VIs, it would be a lot of work to manually edit each VI call. Is it possible to include the LLB into the search path?
Thank you very much for your help!
Felix

Hi,
The search within a LLB is not supported within TestStand.
You need to update your vi path in the step settings like "MyLLB.llb\In An LLB.vi"
i.e. modify the path as llbname\\existingviname.vi.
If you put the llb in a relative path it should be fine.
Regards,
Ravi

Office 2013 with Service Pack 1 installation error about "search path"

I have an automated installation technique that has worked fine with Office 2010 Pro Plus (32-bit), incorporating the latest Service Pack into the network administrative installation point (under \updates), adding 10 foreign languages to the network administrative
installation point, creating a custom .msp with the OCT (that goes into \updates too), editing the config.xml files, and then running setup.exe from that network administrative installation point. This works on 32-bit Windows XP clients and on 32- and 64-bit
Windows 7 clients.
For Office 2013 Pro Plus, I have built the network administrative installation point exactly the same way (original DVD files + languages + SP1 updates + config.xml updates), but the installation is failing with every type of client, all with
the same error message. The network administrative installation point is readable by the normal installing account, but I even get the same error when I login as me and initiate setup.exe manually, and I have all rights to this point.
Here's the critical point from a log file:
2014/03/11 11:53:49:691::[2372] DistributionPoint parsed. The distribution point is now set to: \\archive.ads.college.edu\archive\KBOXalt\Office2013
2014/03/11 11:53:49:691::[2372] COMPANYNAME specified in config.xml.
2014/03/11 11:53:49:691::[2372] USERNAME specified in config.xml.
2014/03/11 11:53:49:800::[2372] Setupexe Resiliency Mode is set to [PerformIfApplicable]; thus Resiliency is [disabled] for the [InstallExecutionMode]
2014/03/11 11:53:49:910::[2372] Searching for default versions of resource files under the folder [\\archive.ads.college.edu\archive\KBOXalt\Office2013].
2014/03/11 11:53:50:019::[2372] Error: GetDirectories: search path \\archive.ads.college.edu\archive\KBOXalt\Office2013 does not exist
ErrorCode: 0(0x0). Failed final attempt to load a setupexe resource file.
2014/03/11 11:53:50:019::[2372] Error: GetDirectories: search path \\archive.ads.college.edu\archive\KBOXalt\Office2013 does not exist
Type: 34::InvalidDirectory.
2014/03/11 11:53:50:019::[2372] WER element [SuppressModal] is set to value [true]
2014/03/11 11:53:50:019::[2372] WER element [P4] is set to value [InvalidDirectory]
2014/03/11 11:53:50:019::[2372] Catalyst execution finished: 03/11/2014 11:53:50. Return code: 30034. Exception caught: InvalidDirectory.
2014/03/11 11:53:50:019::[2372] PERF: TickCount=894821 Name=RunSetup Description=End function
I cannot find any references to this exact error anywhere on the Internet. Can anyone tell me what this means, and how I fix it?

As automated, the utility that runs setup.exe maps a drive letter to
\\archive.ads.college.edu\archive\KBOXalt using a kboxmap AD account, which has read access to the whole \KBOXalt tree. I used that same kboxmap AD account manually to simulate what the utility does, and hit the same problem. But here's what's
odd: right next to that
\\archive.ads.college.edu\archive\KBOXalt\Office2013 directory is an
\\archive.ads.college.edu\archive\KBOXalt\Office2010 directory, both created the same way, and the Office 2010 installation has always worked perfectly using the kboxmap AD account. I don't understand why Office 2013 is only working for an account with
read/write access, where Office 2010 worked fine for an account with only read access. Especially when the Office 2013 resource kit documentation clearly states that the account running the installation should only have read access, nothing more. (All this
KBOX stuff comes from the fact that our deployment environment is a Dell KACE KBOX 1000. However, that plays no part in the problem: ignoring the KBOX 1000, I can manually recreate the problem every time.)

VI Search Path not working in LV2011 for VI Server Plug-ins with exe

I have found what seems to be a problem with the search path when a LabVIEW 2011 built executable calls a Plug-in VI.
When the plug-in VI has subVI’s from vi.lib on its diagram the executable has to know where to find them. Not all VI’s in vi.lib are part of the run time engine or the dll’s that may get generated as part of the build. The things you have to do to make plug-ins work for an executable are explained in several Developer Zone articles. The article titled “How Can I Change or Set the VI Search Path for LabVIEW Executables” describes the ini file setting viSearchPath. When this is set to the vi.lib directory I have not encountered problems with previous versions up to and including LabVIEW 2010.
I have come across an example in LabVIEW 2011 where it doesn’t work. I have attached an example (I am using LV2011 SP1). It demonstrates the basic plug-in architecture. Everything works in the development environment. But it doesn’t work from a built exe. I haven’t included the actual built exe in the zip file in case that causes a problem downloading it. If you run the build spec from the src directory project file the exe should get generated in the bld directory. The problem appears to occur when certain VIs from the analysis library are in the Plug-in. In the example attached, the Plug-in VI is very simple but I have placed the troublesome SubVI on the diagram. The VI in this example where there is a problem finding it is the Butterworth Filter VI. I have placed it on the diagram in a conditional disable structure so it is easy to enable and disable. When enabled and you run the test Plug-in VI the error 1003 is raised, meaning a subVI cannot be found in the dynamically called VI (for example see this post). Note that a way round this may be to incorporate the Plug-in VI into the built exe but this shouldn't be necessary. It’s not a problem with this specific filter VI, as it occurs for other VIs I try on the diagram. However if you place an FFT VI on the diagram there is no problem. I suspect that one is built into the Run-Time Engine.
I also note I am running Win7 64 bit and 32 bit LabVIEW (note the relevant viSearchPath in the ini file – you may need to change if you are on different version of Windows). If the example is converted to LabVIEW 2010 everything works as expected for the built exe. I tried that on a colleague’s computer running XP and 2010 but I am pretty sure in still also works on Win 7.
Things I am suspicious of are that the analysis VI’s are part of a LabVIEW library (lvlib) and perhaps something has changed there? I understand there is a problem with OOP in LabVIEW 2011. Perhaps it is related to that as that seems to be an issue in 2011 (see this Discussion Forum post). Perhaps it is related to OS version?
I also tried generating a Source Distribution to extract out all the vi.lib VI’s and place them directly in the Plug-in directory. That didn’t help.
Interested in whether anyone else reproduces this behaviour. In any case something is different in 2011.
Attachments:
LV 2011 test Plug-in.zip ‏42 KB

I found some more out about this issue working with my local NI rep here in Australia. Apparently something has changed in the compiler between LabVIEW 2010 and 2011. Using the viSearchPath token in the ini file, as described in various Developer Zone articles, now guarantees that the Plug-in will not work. The only way to make it work appears to be to create a Source Distribution. I noted in my original post that I had already tried this and it would not work. It turns out that having the viSearchPath token in the ini file when using a Source Distribution causes the error 1003 to occur. When the token is taken out of the ini file the Plug-in (containing an analysis VI) with a Source Distribution works - in the simple example I posted.
Well I then found its a bit more complicated than this. It all worked for the simple example I posted. Recall we found the error when there was an analysis VI in the Plug-in VI. In our actual application (which is a large one) that calls Plug-ins - we still got the error 1003. By trial and error I found a workaround. There are certain Build Spec settings for the calling exe that I set and found worked. On the Additional Exclusions page I found that I had to make sure that I left unchecked "Modify Project Library File after removing unused members". I've always had trouble understanding the need for this setting. In the Build Spec Help on that page it notes that the build will take longer. In most builds you remove polymorphic VI instances, remove unused members of Project libraries and also Modify the project library file after removing the instances (this is a sub setting of the previous). This makes the exe smaller in size and a quicker build time. Obviously modifying the project library caused a problem. In the big application exe calling Plug-in, I probably have the same analysis VI on the diagram (I haven't actually checked and also whether it is the same polymorphic instance) and in the simple example I posted I definitely did not have VI in the calling exe example - so there may be some clue there. I should try putting the same analysis VI on the calling exe diagram in the simple example to see what happens but I'm running out of energy on this one :-(
So none of this gives me much confidence and I wish I could get a better explanation from NI regarding this behaviour to be sure I am not going to encounter a different problem for different calling exe and Plug-ins. I was advised that a CAR would be issued. Perhaps this is now expected behaviour for 2011 but it would helpful if some definitive explanation could be given about what has changed from LV2010. And an update of Developer Zone articles on the subject would be helpful.

Reader X Search doesn't differentiate cached search paths for reselection

I use the Search quite a bit (or did).
Specifically the "All PDF Documents in" option, where the paths of locations that have previously been browsed to are presented for reuse.
Previous Reader versions shortened long paths so as to display the last part of the pathname, which is normally sufficient to identify the path required.
X does not, so, with no Tooltip either, it is now impossible to differentiate paths with common starting paths longer than that displayed. Update FAIL.
Widening the whole search panel does not widen the field. Update FAIL.
AND when you start the search you STILL don't get to actually see what path is being search due to truncation. Again widening the panel does not widen the fields. Update FAIL.
And why can't we have the normal search term field in the toolbar for seraching the curent document? Although as it took me too long (I think) to even work out how to get any search button on the toolbar, maybe I mssed that. Update FAIL (x2).
And all my old search paths from the previous version have been binned. Update FAIL again.
So much for ease of use, do developers actually test sw "in use" rather than some neatly defined functionallity test scrpit - make the developers use the product is always a good way to fix this I find.
Honestly, if there wasn't enough resource available in Adobe to sort out this kind of trivial ease-of-use functionallity (that I found in just 5 mins use) then how can anyone have faith that the serious stuff has been properly tersted?
Not a good start for 5 mins use. And I see the downgrading doesn't work. Stuffed again.

Any ideas on how I get Quicktime to work that does not include disks?
Pacifist does not require an optical drive for use. Simply "drag 'n drop" the downloaded "QuickTime769_Leopard.pkg" installer file as downloaded from Apple or the OldApps.com site to the Pacifist Window, select the "QuickTime Player App under the "Applications" entry, and tell Pacifist to extract the app. Then it is simply a matter of dragging the app to your root "Applications" folder.

Wine + idtech3 = faulty search path?

i was trying some games installed on W7 (dual boot) via Wine. now, the majority of them work, but here are some exceptions: every game based on the idtech3 engine. i know they're all compatible with Wine (also know there are linux versions of them, but that's beside the point), but for some odd reason, the engine fails to recognize the actual search path for their base folder/cfg file when i try to wine the .exe. the funny thing is, i am able to play those games (base folder found), if i use the Wine Windows Program Launcher on the .exe, which is a half solution only as i need to optirun it (optimus).
vblank_mode=0 optirun -b primus wine ~/.../alice.exe
American McGee's Alice win-x86 Nov 13 2000
----- FS_Startup -----
Current search path:
H:\/base
----- CL_Shutdown -----
Couldn't load default.cfg
anyone met this before or have some hints for a solution?
Last edited by wootsgoinon (2013-11-27 21:52:04)

Fixed it. ran winetricks 2005 and winetricks 2008.
Last edited by canuckkat (2011-10-05 01:40:43)

Labview doesn not care about "vi search path "?

We've had some problems with labview taking sub vi's from other library files than wanted. To clean up the mess once and for all I wanted to include the path to the active library files, and remove the <foundvi> from vi search path.
The added path is something like "\\acanova5\common\...", also tried the version "\\192.168.0.50\common\..."
So far so good, but when I open a vi that need sub vis (before located in now deleted lib files) LV don't find them. When then manually point to the lib file and point to the vi it is ok, but why doesn't it work as I expect?
I looked in labview.ini, and my path is the first in "vi search path" list.
Ola

We've had some problems with labview taking sub vi's from other library files than wanted. To clean up the mess once and for all I wanted to include the path to the active library files, and remove the <foundvi> from vi search path.
The added path is something like "\\acanova5\common\...", also tried the version "\\192.168.0.50\common\..."
So far so good, but when I open a vi that need sub vis (before located in now deleted lib files) LV don't find them. When then manually point to the lib file and point to the vi it is ok, but why doesn't it work as I expect?
I looked in labview.ini, and my path is the first in "vi search path" list.
Ola

Vi search path

Hello all,
I have a problem with "vi search path" in Labview.
First, here are information about our directories architecture to understand the problem.
We are using the following architecture for our developments:
Each project is located in a specific directory.
ex: Project 1 is located in D:\Data\PRJ1
Project 2 is located in D:\Data\PRJ2
In the project directory, there is a subdirectory called "TestTools".
All Labview developments for a given project are located in this directory
and its subdirectories.
ex: D:\Data\PRJ1\TestTools
In the TestTools directory, there are subdirectories:
--> ...\TestTools\Tests : containing test VIs (top level)
ex: D:\Data\PRJ1\TestTools\Tests\Test1.vi
D:\Data\PRJ2\TestTools\Tests\Test45.vi
--> ...\TestTools\Utils : containing sub-vi for the tests.
ex: D:\Data\PRJ1\TestTools\Utils\HF\HF_cfg.vi
D:\Data\PRJ2\TestTools\Utils\CAN\CAN_start.vi
If I add "[topvi]/*" in the "vi search path" menu, Labview will search
the sub-VIs for my application in the directory of the toplevel VI (and its sub-directories).
ex: if I open "D:\Data\PRJ1\TestTools\Tests\Test1.vi", Labview will search the sub-VIs
in the following directory: "D:\Data\PRJ1\TestTools\Tests".
Labview will not be able to find the sub-VI called "HF_cfg.vi" which is
located in "D:\Data\PRJ1\TestTools\Utils".
I can add "D:\Data\PRJ1\*" in the "vi search path" menu but It will work only for Project 1,
and it will not work for Project 2.
I must replace it by "D:\Data\PRJ2\*" to work with Project 2.
If I don't do that, Labview will not find sub-VIs for the tests of Project 2.
(or it will find wrong sub-VIs located in the directory of Project 1 !!)
This is a problem because we often switch from one project to another.
We close and re-open Labview when we switch from one project to the other to be sure
that Labview is not using VIs already loaded in memory, but we still have problems
with "VI search path".
Is there a way to configure Labview to search sub-VIs from an upper directory
that the topvi directory?
Something like that: "[Topvi]\..\*"
(the parent directory of the topvi directory, and all its sub-directories).
I tried "[Topvi]\..\*" but Labview does not support this type of directory.
Someone suggested me to use "Source code control".
I am using Labview Full Dev (not Labview Professional) so I can't use "Source Code Control".
Is there another solution for my problem?
Thanks for your support.
NLu

Dear NLU,
the behaviour is somehow strange. I have projects with some similar folder layout in which sub-VIs are located under ..\..\DMS\sub.vi relative path from the toplevel VI. The search path is set to default. These VIs are really sub VIs not dynamically loaded. The toplevel VI holds the relative path to its sub VIs if they are on the the same drive and the absolut path if the drive is different. This is a least true from LV 3.0.1 to LV 7.1 under all Windows OS I have used (95 and ME I haven't used).
Unloading LabVIEW when changing the project is absolutly neccessary since LV holds a list of all folders where it have found VIs during a session. If you switch from PROJ1 to PROJ2 LV will load VIs with the same name in PROJ1 and PROJ2 but with different paths from the path used during working with PROJ1. Unfotunatly there is no menu entry for "Empty VI found list".
The solution provided by Evan can be made simplier. Create a shortcut to LabVIEW and use the command line parameter -pref to load the desired preference file. Look in the help under "LabVIEW-Defined Command-Line Arguments" for the exact usage.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

How to create search path for the file on the desktop..

hello experts..
      I have used gui_upload module to upload the data from flatfile to the internal table, in that how can i create search path for the file selection in the selection screen, also please help me the code to update the ztable.
thanks

HI
If iam not wrong you want to select a file from a location that you don't know so if this is ur problem then use the function module
F4_FILENAME
this FM helps to locate and select the desired file from the system.
Sample code that you can check is
How to get windows filename
PARAMETERS: lv_file LIKE rlgrap-filename.
Method 1
    CALL FUNCTION u2019KD_GET_FILENAME_ON_F4u2019
    EXPORTING
    MASK = u2019,.txt,.*u2019
    STATIC = u2019Xu2019
    CHANGING
    FILE_NAME = LV_FILE.
Method 2
CALL FUNCTION u2019F4_FILENAMEu2019
EXPORTING
         program_name = syst-cprog
         dynpro_number = syst-dynnr
         field_name = u2019 u2019
     IMPORTING
         file_name   = LV_FILE.
Regards
Pavan

What are the advantages of using LabVIEW projects in TestStand, as apposed to just a path to a vi

What are the advantages of using LabVIEW projects in TestStand, as apposed to just a path to a vi ?
I am modifying an existing workspace for a new product, and it seems like more work to add the vi's into a LabVIEW project
does it gain anything in the long run

Hi Rusty,
I wanted to quickly clarify on the integration between TestStand and LabVIEW Projects.
As Jeff mentioned, some of the big benefits of using LabVIEW Projects is to organize code and to namespace them.
For instance if you had a project called "Power Supply" that housed all your power supply code and had a VI in that called "Initialize", and another project called "Temperature Chamber" that also had a VI called "Initialize", both these VIs are namespaced by the project, so there is no longer confusion about which "Initialize" VI is being used.
Now from a TestStand point of view, in prior version of TestStand, we lost some of this benefit because TestStand did not know about TestStand projects and called VIs simply as un-namespaced VIs. However, in TestStand 2010 (released last year, free eval available at ni.com/teststand), we added the ability to (optionally) call VIs within the context of their projects. This means that:
VIs are now namespaced by their project, even when called from TestStand
VIs can use project specific constructs like NI-DAQmx tasks and conditional compilation settings
Note: When creating deployments, the VIs maintain their projects and namespacing, so this benefit holds true for deployments as well.
Additionally, someone had mentioned looking into using lvlibs to namespace your VIs for deployment. Two comments:
With TestStand 2010, this is no longer neccessary since the project itself namespaces the VIs
You might also want to look into LabVIEW Packed Project Libraries, which combined several VIs into a single file. Think of it as a DLL specific to LabVIEW that is as easy to call as normal LabVIEW VIs. TestStand 2010 can call VIs that are exposed by PPLs. In addition, the deployment utility can automatically pack your VIs into PPLs for deployment.
Hope this is helpful!
Jervin Justin
NI TestStand Product Manager

Can we define search paths for an SQR ( just like -i for SQC )

Is it possible to define search paths for an SQR ?
Ie at run time, we would like the system to look for the SQR in c:\sqr1\ if not found then look in c:\sqr2\ and so on .. until c:\sqr4\
Right now this feature exists ONLY for the SQC via the -i flag
( ex: c:\ps_home\bin\sqr\ora\BINW\sqrw.exe c:\xrfwin.sqr -ic:\sqr1\;c:\sqr2;c:\sqr3;c:\sqr4\ )
We would like to be able to do it VIA:
1) The process Scheduler. ( Where do we set it up ? in PSPRCS.CFG ? Not sure how )
2) Command line. ( We can't find any flag that could satisfy this need )
Note: We heard about a few hints ( SQRPATH, psprcs file, @FILE flag, PSSQR ) but not able get any of them cleared out.
This is delaying our development and it's quite crucial for us.
Any thoughts or hints would be VERY APPRECIATED !!
Thanks

Kelvin wrote:
1) The process Scheduler. ( Where do we set it up ? in PSPRCS.CFG ? Not sure how )From the link below, do a search for "SQR Section" and you'll find PSSQR1, PSSQR2, PSSQR3 and PSSQR4 for sqr search paths
http://docs.oracle.com/cd/E28394_01/pt852pbh1/eng/psbooks/tprs/book.htm?File=tprs/htm/tprs16.htm#H3002
2) Command line. ( We can't find any flag that could satisfy this need )I'm not aware of any equivalent for cmd line, but most of the time you know where it has been stored when running it manually. You could get more in the Peoplebooks :
http://docs.oracle.com/cd/E28394_01/pt852pbh1/eng/psbooks/tsql/book.htm?File=tsql/htm/tsql08.htm#H3019
If you don't find anything and the cmd line is really needed, you could probably write your own script (ie .bat or .cmd) looking for the sqr which you could give as a parameter.
Nicolas.
Edited by: N Gasparotto on May 24, 2012 10:10 PM

Open Directory, third party LDAP search path problem on Snow Leopard

Happy new year folks,
I ran into an interesting problem this past week in regards to a third party LDAP directory in the Search path (which used to work on previous versions). The issue brings the server to its knees eventually. I'm still digging through the logs, but here's the general breakdown...
1. Add third-party LDAP to the OD node list. This has always worked on previous versions, and appears to still work at the most basic level. I can navigate the node with DSCL, read records, etc.
1. Add third-party LDAP to the OD search path.
2. Wait a few minutes....
3. The server begins to slow down. Apache, SSH, ServerAdmin service stop responding. I'm able to run "top" briefly, which shows an increase of threads.
4. Restart the server and quickly remove the directory from the OD search path
5. Server goes back to being rock solid with very nice response times for Apache, SSH, ServerAdmin, etc.
If anyone has any debugging suggestions, or has seen this before, let me know.
Jaime
--- Below is some console output leading up to the chaos. Before adding to search path, everything looks good --------------------
bash-3.2# dscl
Entering interactive mode... (type "help" for commands)
read /LDAPv3/ldap.itd.umich.edu/Users/jaimelm cn
dsAttrTypeNative:cn:
Jaime Magiera
Jaime L Magiera 1
Jaime L Magiera
--- Add to Search Path, which hangs ------------------------------------------------------------------------------
bash-3.2# dscl /Search -append / CSPSearchPath /LDAPv3/ldap.itd.umich.edu
--- DSCL in debug mode contains the following ----------------------------------------------
2010-01-01 19:26:25 EST - T[0x00000001037A5000] - Client: ipfw, PID: 1097, API: libinfo, Server Used : libinfomig DAR : Procedure = getprotobynumber (13) : Result code = 0
2010-01-01 19:26:25 EST - T[0x00000001037A5000] - Client: sso_util, PID: 1103, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16779669 : Requested nodename = /Search
2010-01-01 19:26:25 EST - T[0x00000001037A5000] - Plug-in call "dsDoPlugInCustomCall()" failed with error = -14292.
2010-01-01 19:26:25 EST - T[0x00000001037A5000] - Port: 27151 Call: dsDoPlugInCustomCall() == -14292
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16779
707 : Requested nodename = /LDAPv3/ldap.itd.umich.edu
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAR : 2 : Dir Ref = 16779707 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 167797072010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16779707
: Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAC : Dir Ref 16779707 :
Data buffer size = 1282010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16779
707 : Requested nodename = ConfigNode2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAR : 2 : Dir Ref = 16779
707 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: Requesting dsOpenDirNode with PID = 1114, UID = 0, and EUID = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsOpenDirNode(), Configure Used : DAC : Dir Ref = 16779707 : Node Name = /Configure
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsOpenDirNode(), Configure Used : DAR : Dir Ref = 1677970
7 : Node Ref = 33556926 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 16779707
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16779707 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsGetDirNodeInfo(), Configure Used : DAC : Node Ref = 33556926 : Requested Attrs = dsAttrTypeStandard:OperatingSystemVersion : Attr Type Only Flag = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsGetDirNodeInfo(), Configure Used : DAR : Node Ref = 33556926 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsGetDirNodeInfo(), Search Used : DAC : Node Ref = 33556924 : Requested Attrs = dsAttrTypeStandard:LSPSearchPath : Attr Type Only Flag = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsGetDirNodeInfo(), Search Used : DAR : Node Ref = 33556924 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsDoPlugInCustomCall(), Search Used : DAC : Node Ref = 33556924 : Request Code = 444
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Checking for Search Node XML config file:
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - /Library/Preferences/DirectoryService/SearchNodeConfig.plist
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Have written the Search Node XML config file:
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - /Library/Preferences/DirectoryService/SearchNodeConfigBackup.plist
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Setting search policy to Custom search
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - CSearchPlugin::SwitchSearchPolicy: switch - reachability of node </LDAPv3/127.0.0.1> retained as <true>
2010-01-01 19:26:36 EST - T[0x000000010070A000] - CSearchPlugin::CheckNodes: checking network node reachability on search policy 0x0000000000002201
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - CCachePlugin::EmptyCacheEntryType - Request to empty all types - Flushing the cache
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Client: Requesting dsOpenDirNode with PID = 0, UID = 0, and EUID = 0
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : DAC : Dir Ref = 16777216 : Node Name = /LDAPv3/127.0.0.1
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : DAR : Dir Ref = 16777216 : Node Ref = 33556929 : Result code = 0
2010-01-01 19:26:36 EST - T[0x000000010070A000] - CSearchPlugin::CheckNodes: calling dsOpenDirNode succeeded on node </LDAPv3/127.0.0.1>
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsCloseDirNode(), LDAPv3 Used : DAC : Node Ref = 33556929
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsCloseDirNode(), LDAPv3 Used : DAR : Node Ref = 33556929 : Result code = 0
2010-01-01 19:26:36 EST - T[0x0000000103181000] - mbr_mig - dsFlushMembershipCache - force cache flush (internally initiated)
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Client: Requesting dsOpenDirNode with PID = 0, UID = 0, and EUID = 0
2010-01-01 19:26:36 EST - T[0x0000000103181000] - Membership - dsNodeStateChangeOccurred - flagging all entries as expired
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : DAC : Dir Ref = 16777216 : Node Name = /LDAPv3/ldap.itd.umich.edu
2010-01-01 19:26:36 EST - T[0x000000010070A000] - CLDAPNodeConfig::InternalEstablishConnection - Node ldap.itd.umich.edu - Connection requested for read
2010-01-01 19:26:36 EST - T[0x000000010070A000] - CLDAPNodeConfig::FindSuitableReplica - Node ldap.itd.umich.edu - Attempting Replica connect to 141.211.93.133 for read
2010-01-01 19:26:36 EST - T[0x0000000102481000] - CCachePlugin::SearchPolicyChange - search policy change notification, looking for NIS
2010-01-01 19:26:36 EST - T[0x0000000102481000] - Internal Dispatch, API: dsGetDirNodeInfo(), Search Used : DAC : Node Ref = 33554436 : Requested Attrs = dsAttrTypeStandard:SearchPath : Attr Type Only Flag = 0
------- From another screen, I do "id jaimelm", which hangs ------------------------------------------------------------------------
: Requested Rec Names = jaimelm : Rec Name Pattern Match:8449 = eDSiExact : Requested Rec Types = dsRecTypeStandard:Users
2010-01-01 19:36:55 EST - T[0x00000001082A2000] - Internal Dispatch, API: dsGetRecordList(), Search Used : DAC : 2 : Node Ref = 33554436 : Requested Attrs = dsAttrTypeStandard:AppleMetaNodeLocation;dsAttrTypeStandard:RecordName;dsAttrTy peStandard:Password;dsAttrTypeStandard:UniqueID;dsAttrTypeStandard:GeneratedUID; dsAttrTypeStandard:PrimaryGroupID;dsAttrTypeStandard:NFSHomeDirectory;dsAttrType Standard:UserShell;dsAttrTypeStandard:RealName;dsAttrTypeStandard:Keywords : Attr Type Only Flag = 0 : Record Count Limit = 1 : Continue Data = 0
2010-01-01 19:37:03 EST - T[0x0000000108325000] - Client: httpd, PID: 157, API: mbr_syscall, Server Used : process kauth result 0x0000000102022B30
2010-01-01 19:37:03 EST - T[0x00000001083A8000] - Client: httpd, PID: 151, API: mbr_syscall, Server Used : process kauth result 0x0000000102022C50
2010-01-01 19:37:05 EST - T[0x000000010842B000] - Client: httpd, PID: 203, API: mbr_syscall, Server Used : process kauth result 0x0000000102022D70
2010-01-01 19:37:15 EST - T[0x00000001084AE000] - Client: httpd, PID: 994, API: mbr_syscall, Server Used : process kauth result 0x0000000102023890
2010-01-01 19:37:26 EST - T[0x0000000108531000] - Client: httpd, PID: 198, API: mbr_syscall, Server Used : process kauth result 0x0000000102023980
2010-01-01 19:37:31 EST - T[0x00000001085B4000] - Client: httpd, PID: 161, API: mbr_syscall, Server Used : process kauth result 0x0000000~

Hi
I'm in agreement with harry here but what I'm struggling to understand is why you are seeing this as a problem? I'm also struggling to see this as being a possibility in a single server environment if I understand your post correctly?
Promotion to OD Master with all that entails absolutely rests on a properly configured and tested internal DNS Service. The Kerberos Realm's foundation (and with that the ability of the server to perform its function as KDC and offer LDAP services) entirely depends on what is configured in the DNS Service. This will include the server name, domain name and tld. The Kerberos Realm automatically configures itself using that information. Likewise the searchbase.
Its more than possible to change the Realm name and with it the LDAP search base (in certain circumstances) and have an OD Master, however Kerberos won't start it won't need to as the KDC will be elsewhere. You generally see this when augmenting Windows AD with MCX. In that situation Realm name and search base will reflect what is set on the Active Directory. Client computers will use what is set there for contact and authentication information before looking at the OD Master for anything else.
Does this help? Tony

Can I programmatically change the VI Search Path?

I'm writing a simple program to periodically mass compile certain directories of my source code. In my directory structure I try to enforce rules about what is allowed to depend on what, so I want to programatically enforce this during the mass compile. To do this, I'd need to modify the VI search path before each directory is compiled. Is there any property or method available for changing the VI Search Path?

There is, but it's a private property, so it's not documented, and its behavior and/or availability can change with subsequent releases of LabVIEW:
Message Edited by smercurio_fc on 10-24-2007 05:24 PM
Attachments:
Example_BD.png ‏2 KB

Forte WS6U1 - Search path SunWS_Cache directory needs write permission

Forte 6 U1, needs write permission to search path SunWS_Cache directory.
When I build a file locally checked out from the baseline directory, and the baseline SunWS_Cache directory needs write permission.
Lets say,
/home/zeebra/baseline/util - is the directory where the baseline is.
Having local workarea as /home/user/work/util
The local work has the baseline in search path. But the local -user does not have write permission on baseline/util/SunWS_Cache.
The local compilation goes thro fine, but when linking it just hangs. As soon as I give the write permission to baseline/util/SunWS_Cache, the linking completes.
Is it a bug? Do we have patch already for this problem for Forte6 Update 1?
Thanks!

The SunWS_Cache directory must have write permission. The cache contains state information that must be locked when a compiler is being run, to avoid trashing the state information if another compilation runs in the same directory at the same time. (Sun C++ supports dmake and gmake for running multiple compilations in parallel.)
A non-writeable template cache is not an available option.
Starting with C++ 5.5 (Sun ONE Studio 8 Compiler Collection), the template cache is no longer required, and by default is not used. If you are having problems involving the cache, you should consider upgrading to this new release.

TestStand 4.1.1 vi search path

Similar Messages

Maybe you are looking for