All Posts

Wonderful thanks... For anyone using the code above... Set the version to 1 and be sure to assign the propertyIDs as an array. eg (VB). job = VixLibA.Connect(1, VixCOM.Constants.VIX_... See more...
Wonderful thanks... For anyone using the code above... Set the version to 1 and be sure to assign the propertyIDs as an array. eg (VB). job = VixLibA.Connect(1, VixCOM.Constants.VIX_SERVICEPROVIDER_VMWARE_SERVER, Nothing, Nothing, Nothing, Nothing, 0, Nothing, Nothing) Dim propertyIDS() As Object = \{VixCOM.Constants.VIX_PROPERTY_JOB_RESULT_HANDLE} Dim err = job.Wait(propertyIDS, results)
Similar to the response that my colleague gave in the thread "VixHost_Connect Problem", the issue that there is a version mismatch issue. Error code 6 is 'not supported'. You're having an ... See more...
Similar to the response that my colleague gave in the thread "VixHost_Connect Problem", the issue that there is a version mismatch issue. Error code 6 is 'not supported'. You're having an exception when you call GetErrorText() because when Connect() failed, not all of the required libraries were loaded, so VIX is having difficulties looking up the error string. We're looking into ways to make sure that this doesn't happen in future releases. You should be able to get this to work by explicitly passing 1 as the first argument to Connect(). Just to be clear, only functions from the version 1.0 of the VIX API are supported with VMware Server.
Some of the issues are probably caused by using the 1.1 API with the 1.0 server. The constant VIX_API_VERSION has been bumped, and server doesn't deal well with the '2' from 1.1 instead of the '... See more...
Some of the issues are probably caused by using the 1.1 API with the 1.0 server. The constant VIX_API_VERSION has been bumped, and server doesn't deal well with the '2' from 1.1 instead of the '1' it expects. Passing in a '1' might solve many of your problems. However, that doesn't make a lot of sense that the different compilers have different results, so the other possibility is a C runt-time mismatch. The Vix library expects a mutil-threaded, non-debug CRT. If you're letting Visual Studio set up the project, it may be setting you to use a debug CRT, and the threading model could also be incorrect. Unfortunately, if you mix CRT versions, you tend to get ugly crashes. And errcode 6 is 'not supported'. This is probably because you're trying to use the version 2 API with a version 1 back end. If you're working with server 1.03, you can stay with the Vix 1.0 that shipped with it.
I would like to also mention this is a 32bit environment. This forum needs an edit post function.
This post has a few questions. What is error code 6 when trying to connect?[/b] I get this error returned in everything C, C#, VB, VBScript/WSH, Perl Why am I having these excepti... See more...
This post has a few questions. What is error code 6 when trying to connect?[/b] I get this error returned in everything C, C#, VB, VBScript/WSH, Perl Why am I having these exceptions in VixCom for GetErrorText?[/b] Why do my programs crash when compiled with DevC++ and VC+2005 but run fine with VC+6[/b] (except error 6 returned)[b]?[/b] Is this a bug in VixCom/Vix?[/b] Has anyone had any luck with VixCom or Vix on VMWare Server?[/b] If yes, can you please post your code or a link to a project source?[/b] Language is not a problem as long as it uses VIX. The other APIs do not support some of the functionality I am seeking. Environment:[/b] WinXPSP2 VMWare Server 1.0.3 (even though it has been tried on older versions and different machines) Vix API 1.1 Tried in various languages (C#, VB, VBScript, C) [u]Visual C Sharp (C#)[/u][/b] C Sharp (C#) Code[/b] Source at http://www.buriproject.info/vix/c%20sharp%20GetErrorText.7z using System; using System.Collections.Generic; using System.Text; using VixCOM; namespace VIXTest { class Program { static void Main(string[] args) { VixCOM.VixLib lib = new VixCOM.VixLib(); Console.WriteLine("Connecting..."); VixCOM.IJob job = lib.Connect(VixCOM.Constants.VIX_API_VERSION, VixCOM.Constants.VIX_SERVICEPROVIDER_VMWARE_SERVER, "", 0, "", "", 0, null, null); object[] data = \{ VixCOM.Constants.VIX_PROPERTY_JOB_RESULT_HANDLE }; object results = null; ulong err = job.Wait((VixCOM.Constants.VIX_PROPERTY_JOB_RESULT_HANDLE), ref results); if (lib.ErrorIndicatesFailure(err)) { ushort errCode = lib.ErrorCode(err); string errMsg; errMsg = lib.GetErrorText(err, null); Console.WriteLine("Error: " + errCode.ToString() + " : " + errMsg); } exit(true); } static void exit() { exit(false); } static void exit(bool prompt) { if (prompt) { Console.Write("Press Any Key To Exit"); Console.ReadKey(); } System.Environment.Exit(-1); } } } C Sharp(C#) Error ScreenShot[/b] http://www.buriproject.info/vix/c%20sharp%20GetErrorText.png Error Text[/b] System.Runtime.InteropServices.COMException was unhandled Message="The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))" Source="Interop.VixCOM" ErrorCode=-2147417851 StackTrace: at VixCOM.VixLibClass.GetErrorText(UInt64 err, String locale) at VIXTest.Program.Main(String[] args) in C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\VIXTest\VIXTest\Program.cs:line 23 at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() [u]Visual Basic (VB)[/u][/b] VB Code[/b] Source at http://www.buriproject.info/vix/vb%20GetErrorText.7z Public Class Form1 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Dim VixLibA As New VixCOM.VixLib Dim job = VixLibA.Connect(VixCOM.Constants.VIX_API_VERSION, VixCOM.Constants.VIX_SERVICEPROVIDER_VMWARE_SERVER, Nothing, Nothing, Nothing, Nothing, 0, Nothing, Nothing) Dim results = Nothing Dim err = job.Wait((VixCOM.Constants.VIX_PROPERTY_JOB_RESULT_HANDLE), results) If VixLibA.ErrorIndicatesFailure(err) Then Dim errMsg = VixLibA.GetErrorText(err, Nothing) MsgBox("Error: " & err.ToString() & " : " & errMsg) End If End Sub End Class VB Error ScreenShot[/b] http://www.buriproject.info/vix/vb%20GetErrorText.png VB Error Text[/b] System.AccessViolationException was unhandled Message="Attempted to read or write protected memory. This is often an indication that other memory is corrupt." Source="Interop.VixCOM" StackTrace: at VixCOM.VixLibClass.GetErrorText(UInt64 err, String locale) at VixCom_Test.Form1.Form1_Load(Object sender, EventArgs e) in C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\VixCom Test\VixCom Test\Form1.vb:line 10 at System.EventHandler.Invoke(Object sender, EventArgs e) at System.Windows.Forms.Form.OnLoad(EventArgs e) at System.Windows.Forms.Form.OnCreateControl() at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl() at System.Windows.Forms.Control.WmShowWindow(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ContainerControl.WndProc(Message& m) at System.Windows.Forms.Form.WmShowWindow(Message& m) at System.Windows.Forms.Form.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.SafeNativeMethods.ShowWindow(HandleRef hWnd, Int32 nCmdShow) at System.Windows.Forms.Control.SetVisibleCore(Boolean value) at System.Windows.Forms.Form.SetVisibleCore(Boolean value) at System.Windows.Forms.Control.set_Visible(Boolean value) at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.Run(ApplicationContext context) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun() at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel() at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine) at VixCom_Test.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81 at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart()
it does appear to work fine with VC+6 but not VC+ 2005 or DevC++
I have this exact problem with any api. I am running the latest VMWare Server 1.0.3 and the VIX 1.1 API. Using DEV-C++, the Perl interface and the Com interface all crash on me. On Com and P... See more...
I have this exact problem with any api. I am running the latest VMWare Server 1.0.3 and the VIX 1.1 API. Using DEV-C++, the Perl interface and the Com interface all crash on me. On Com and Perl it crashes when getting the error codes. The error returned after connect is 6 (cant translate to err msg because the API crashes) It does not matter the connection strings used or ports The sample codes all compile fine but crash on execution after the connect. /* \---- BEGIN CODE SNIPPET \---- */ #include <stdio.h> #include <stdlib.h> #include "vix.h" #define CONNTYPE VIX_SERVICEPROVIDER_VMWARE_SERVER #define HOSTNAME "" #define HOSTPORT 0 #define USERNAME "" #define PASSWORD "" #define VMPOWEROPTIONS VIX_VMPOWEROP_NORMAL /* Global variables. */ static char *progName; //////////////////////////////////////////////////////////////////////////////// static void usage() { fprintf(stderr, "Usage: %s 1) { vmxPath = argv[1]; fprintf(stderr, "received: %s \n", argv[1]); } else { usage(); exit(EXIT_FAILURE); } jobHandle = VixHost_Connect(VIX_API_VERSION, CONNTYPE, HOSTNAME, // *hostName, HOSTPORT, // hostPort, USERNAME, // *userName, PASSWORD, // *password, 0, // options, VIX_INVALID_HANDLE, // propertyListHandle, NULL, // *callbackProc, NULL); // *clientData); return 0; } /* \---- END CODE SNIPPET \---- */ This crashes in the same manner
Thanks, I will surely try it next tuesday, when I get back to work. Thanks again
Here is a VI Perl Script to configure DRS. Please provide feedback (either positive or negative) if you find it useful. Note that we are planning a DRS workshop in the next few weeks to expl... See more...
Here is a VI Perl Script to configure DRS. Please provide feedback (either positive or negative) if you find it useful. Note that we are planning a DRS workshop in the next few weeks to explain how many common tasks can be scripted. Usage: drsConfig.pl list or edit DRS settings for a cluster --server ] Automation level \[--enable] Enable DRS \[--disable] Disable DRS
Hi Mark, This is a brand new forum. We actually just subdivided the API/SDK discussion into several forums, so that it would be easier to find and answer questions on each different. So, tha... See more...
Hi Mark, This is a brand new forum. We actually just subdivided the API/SDK discussion into several forums, so that it would be easier to find and answer questions on each different. So, thanks for taking the plunge and writing first, and rest assured that we're watching and answering. Let me start by just throwing a workaround your way for a client library to use against Server 1.0.x on Linux-64: Use the VIX libraries that are installed with Server 1.0.3. They are the latest and greatest. The server-1 libraries that are installed with the standalone VIX API 1.1 are exactly the same. (Only the Workstation client libraries are new in that distribution.) That should get you past the installer's lockout of installing the 32-bit libraries on a 64-bit host. Now, remember that VIX API support of Server 1.0 is beta/experimental, which is part of the reason why it doesn't include 64-bit libraries -- we just didn't have them yet in that product generation. Sorry, running the 32-bit client libraries on a 64-bit linux host is not a supported/tested configuration. You're right, the seg fault is probably due to the glibc mismatch. As you're clearly aware, you could get around this by installing an older gcc. You could also get around this by linking directly to the .so, but as mentioned that does not exist in a 64-bit flavor. I think you could build your client app 32-bit, and link to the .so. On the Windows side, can you be more specific about what your'e seeing? We've tested those client libraries with both VS .net 2003 and 2005, but we don't know of any change that should break backwards compatibility to VS6. (Note: The Workstation 6 IDE integration feature for Visual Studio \*does* require 2005, but that's a totally separate issue, nothing to do with VIX API.) Hope this helps... --Matt
I am running 32bit VMWare Server 1.0.3 on x86_64 Fedora Core 4 successfully. I have also been successfully running my Vix code successfully using the 1.0 SDK. I downloaded both the i386 Vix 1... See more...
I am running 32bit VMWare Server 1.0.3 on x86_64 Fedora Core 4 successfully. I have also been successfully running my Vix code successfully using the 1.0 SDK. I downloaded both the i386 Vix 1.1 SDK and the x86_64 Vix 1.1 SDK. First I tried installing the i386 package assuming that as the server was 32bit I should be using the 32bit API as was the case with the 1.0 version of the SDK, but the script refused to install and told me I should be using the x86_64 SDK. So I installed that and changed my Makefile to link to the new libVixAllProducts.a as suggested by the Release Notes. The linking worked, but the first call to Vix_GetErrorText resulted in a seg fault. The code ran successfully with the 32bit 1.0 SDK on this machine. Assuming the seg fault may be due to the fact that FC4 comes with glibc 2.3, and this might be causing problems, I thought I'd link to the VMWare Server libvix.so directly, but that file does not exist in the SDK 1.1 x86_64 download. The libvix.so for Workstation is present. Is this an oversight, or is the x86_64 SDK not supported for VMware Server? I also don't understand why glibc 2.2 is a dependency for linking libVixAllProducts.a. If you are running a reasonably recent Linux distribution, then it is going to have later versions of glibc. So far I haven't been able to find a glibc 2.2 RPM for FC4 x86_64 I've also tried building my application on i386 FC5, but as that's even later, then finding a glibc 2.2 RPM for that is even harder; the linking with libVixAllProducts.a fails. This SDK DOES have the 32bit libvix.so for VMWare Server. I also tried building my code on Windows with the 1.1 SDK, but that now requires MS Visual Studio 2005, whereas SDK 1.0 worked fine with Visual Studio 6 (which is what I use). I cannot find anywhere in the SDK documentation this change in dependency. All in all, upgrading to the Vix 1.1 SDK has been VERY frustrating. Hopefully someone can offer some suggestions. I'm hoping even more that someone will actually read this considering this is the first post in this forum. TIA, Mark.
I was wondering if among the programmers in this forum, if there is someone that could freely share a command line program that could set the DRS to manual or to automatic or even to semi-automat... See more...
I was wondering if among the programmers in this forum, if there is someone that could freely share a command line program that could set the DRS to manual or to automatic or even to semi-automatic. Thanks
Yes, your earlier code was also releasing the jobHandle twice as it exited, as well as calling VixHost_Disconnect() twice. You're also leaking a jobHandle from the VixHost_Connect() (which ess... See more...
Yes, your earlier code was also releasing the jobHandle twice as it exited, as well as calling VixHost_Disconnect() twice. You're also leaking a jobHandle from the VixHost_Connect() (which essentially means a memory leak). And I'd suggest catching the return value of the VixJob_Wait() after the VixHost_FindItems().
so this is getting a bit funny: I tried removing the Vix_ReleaseHandel(jobHandle) in VixDiscoveryProc() but I was still getting segfaults. this seems to be happening in main, as if it tries to ex... See more...
so this is getting a bit funny: I tried removing the Vix_ReleaseHandel(jobHandle) in VixDiscoveryProc() but I was still getting segfaults. this seems to be happening in main, as if it tries to execute abort no matter what. if I return(-1) then all is good. below is the compelete program which works without any segfaults on 32bit. on the 64bit machine I could only get this code to run if I use VMware-vix-1.0.3 and -m32 when compiling. below is the full listing of the code: #include "stdio.h" #include "string.h" #include "vix.h" static VixHandle hostHandle = VIX_INVALID_HANDLE; static VixHandle jobHandle = VIX_INVALID_HANDLE; void VixDiscoveryProc(VixHandle jobHandle, VixEventType eventType, VixHandle moreEventInfo, void *clientData) { VixError err = VIX_OK; VixHandle vmHandle = VIX_INVALID_HANDLE; char *url = NULL; // Check callback event; ignore progress reports. if (VIX_EVENTTYPE_FIND_ITEM != eventType) { return; } // Found a virtual machine. err = Vix_GetProperties(moreEventInfo, VIX_PROPERTY_FOUND_ITEM_LOCATION, &url, VIX_PROPERTY_NONE); if (VIX_OK != err) { // Handle the error... goto abort; abort: printf("Aborting in discover\n"); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); } printf("\nFound virtual machine: %s\n", url); } int main() { VixError err; // Connect to specified host. jobHandle = VixHost_Connect(VIX_API_VERSION, VIX_SERVICEPROVIDER_VMWARE_SERVER, "vmserver", //serverName 902, // hostPort "root", // userName "password", // password, 0, // options VIX_INVALID_HANDLE, // propertyListHandle NULL, // callbackProc NULL); // clientData err = VixJob_Wait(jobHandle, VIX_PROPERTY_JOB_RESULT_HANDLE, &hostHandle, VIX_PROPERTY_NONE); if (VIX_OK != err) { // Handle the error... printf("An error occurred\n"); goto abort; } printf("\nLooking for running virtual machines"); jobHandle = VixHost_FindItems(hostHandle, VIX_FIND_RUNNING_VMS, VIX_INVALID_HANDLE, // searchCriteria -1, // timeout VixDiscoveryProc, NULL); VixJob_Wait(jobHandle, VIX_PROPERTY_NONE); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); return(0); abort: printf("Aborting in main\n"); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); return(-1); }
Yeah, I was afraid you'd copied that bit of docs -- it had a nasty but subtle bug in the jobHandle refcounting. The call to Vix_ReleaseHandle(jobHandle) in the VixDiscoveryProc() is bogus, and p... See more...
Yeah, I was afraid you'd copied that bit of docs -- it had a nasty but subtle bug in the jobHandle refcounting. The call to Vix_ReleaseHandle(jobHandle) in the VixDiscoveryProc() is bogus, and probably causing your crash (its overly decreffing that handle). Remove that line, and see if things get happier. VMware server supports just once snapshot, and Vix enforces that. The latest docs are at http://pubs.vmware.com/vix-api/ReferenceGuide/ The functional reference does refer to things only available in the latest release, but each function should specify which release it works with.
Hi, well thank you for taking the time to look into all this. Great work indeed and we all miss things one time or another. I have 1 more questions(there is always 1 more, right?) would I be a... See more...
Hi, well thank you for taking the time to look into all this. Great work indeed and we all miss things one time or another. I have 1 more questions(there is always 1 more, right?) would I be able to take multiple snapshots with the vix api against a vmware server product giving the snapshots different names or would it always take 1 snapshot overwriting the existing snapshots below is the full listing of the code which causes the segfault, it pretty much came out of the docs. I haven't started doing anything complex yet. #include "stdio.h" #include "string.h" #include "vix.h" static VixHandle hostHandle = VIX_INVALID_HANDLE; static VixHandle jobHandle = VIX_INVALID_HANDLE; void VixDiscoveryProc(VixHandle jobHandle, VixEventType eventType, VixHandle moreEventInfo, void *clientData) { VixError err = VIX_OK; VixHandle vmHandle = VIX_INVALID_HANDLE; char *url = NULL; // Check callback event; ignore progress reports. if (VIX_EVENTTYPE_FIND_ITEM != eventType) { return; } // Found a virtual machine. err = Vix_GetProperties(moreEventInfo, VIX_PROPERTY_FOUND_ITEM_LOCATION, &url, VIX_PROPERTY_NONE); if (VIX_OK != err) { // Handle the error... goto abort; } printf("\nFound virtual machine: %s\n", url); abort: Vix_ReleaseHandle(jobHandle); Vix_FreeBuffer(url); } int main() { VixError err; // Connect to specified host. jobHandle = VixHost_Connect(VIX_API_VERSION, VIX_SERVICEPROVIDER_VMWARE_SERVER, "vmserver1", // hostName 902, // hostPort "root", // userName "password", // password, 0, // options VIX_INVALID_HANDLE, // propertyListHandle NULL, // callbackProc NULL); // clientData err = VixJob_Wait(jobHandle, VIX_PROPERTY_JOB_RESULT_HANDLE, &hostHandle, VIX_PROPERTY_NONE); if (VIX_OK != err) { // Handle the error... goto abort; } Vix_ReleaseHandle(jobHandle); printf("\nLooking for running virtual machines"); jobHandle = VixHost_FindItems(hostHandle, VIX_FIND_RUNNING_VMS, VIX_INVALID_HANDLE, // searchCriteria -1, // timeout VixDiscoveryProc, NULL); VixJob_Wait(jobHandle, VIX_PROPERTY_NONE); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); abort: printf("Aborting\n"); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); }
Can you post your complete code, include the discovery procedure? The online docs are the most up-to-date, and we did recently clean up several problems in the sample code (including possibly ... See more...
Can you post your complete code, include the discovery procedure? The online docs are the most up-to-date, and we did recently clean up several problems in the sample code (including possibly the inconsistency you spotted, where the docs used Vix_INVALID_HANDLE -- this was a doc bug.) Thanks for pointing out the case typo in the Simple docs -- that slipped by everyone til now.
I tried both VMware-vix-1.0.3 and VMware-vix-1.1.0 on a 32bit machine. I am still getting segfault half way through the "finditems" loop. strace makes it look like it was on a poll on the tempor... See more...
I tried both VMware-vix-1.0.3 and VMware-vix-1.1.0 on a 32bit machine. I am still getting segfault half way through the "finditems" loop. strace makes it look like it was on a poll on the temporarily file created. is this a known issue or do you suspect it has to do with my environment? There are a few cases where the documentation was not accurate when it included example code. also the documentation for VMware::Vix::Simple has a typo, one line says "use VMware::Vix::Simple" and the other says "use VMWare::Vix::Simple".
There's no native support for 64 bit linux in vmware server, and we only tested 32 bit. 1.1 does have compatiblity, but still only 32 bit for vmware server. The API should be consistant wit... See more...
There's no native support for 64 bit linux in vmware server, and we only tested 32 bit. 1.1 does have compatiblity, but still only 32 bit for vmware server. The API should be consistant with names. Functions start with Vix, constants with VIX. The latest docs should be correct and on the web.
I initially installed vix-1.1.0 release, which claimed to be compatible with server. it had a 64bit version under ws-2 and I tried to use that initially and it did not work so I installed the vix... See more...
I initially installed vix-1.1.0 release, which claimed to be compatible with server. it had a 64bit version under ws-2 and I tried to use that initially and it did not work so I installed the vix1.0.3 release and with -m32 things sort of work. I am going to try 1.1.0 with -m32 and if all fails I will have to use a 32bit machine. Do you know of any plans to have 64bit support for vix with server? Also, do you know if the API is going to get standardized in case and conventions. some calls use VIX and other use Vix. the docs seem to be out of date on the case isssue. Thanks. I will post what I find.