Problems with the .Net SDK for XAM??

Hi JD - those steps look correct and complete.

Have you tried taking the .NET layer out the equation? By that I mean downloading the native C samples for XAM, or using the shXAM community tools to verify the connectivity?

I appreciate that you have used JCenteraVerify but this uses only the native Centera SDK and not the XAM layer.

When you used JCenteraVerify, did you use the same PEA file for authentication that you are using with the .NET samples?

Hi Graham,

I haven't tried shXAM, but XAMVerify works OK. Is this sufficient to prove the XAM layer? I may get time to try shXAM, or a native C sample tonight, but I'm not holding my breath given XAMVerify works.

I'm using the exact same connection string (snia-xam://centera_vim!128.221.200.60?c:\\temp\\xam.pea) and pea file as I'm using with the .Net application. The pea file is the "xamconnect.pea" file for the US2 cluster from the "EMC Centera Online Clusters (Connectivity Information)" webpage.

NB: My development environment is Windows 7. I appreciate that this version wasn't listed as a supported OS, but given XAMVerify works and the SDK is .Net (ie works on Win7) I figure this should be OK.

Graeme

Hi Graeme

Interesting. Windows 7 may have a bearing on this, but I could not say either way as I have not attempted to use it at all. I did experience some issues with Windows Server 2008 being more strict with memory use when I ported the layer from Windows XP, and it could be that Win7 may have gone further in this direction.

XAMVerify should be sufficient to rule out the native SDKas being the issue.

I would like to remove Win7 from the equation - are you able to get hold of a WinXP or Server2008 client that you could try out? Unfortunately I do not have access to a Win7 one to help with this.

Graeme - there is really nothing to be gained by testing it on Vista as it's not really been tried there either. It really needs to be XP or Server (2003 or 2008) if we are to be sure it is not OS issues.

I am actually preparing a new build based on or latest EMC XAM Stack (1.0p2) and addressing a couple of memory management issues that were raised. This should be ready in a day or so.

Fair enough. Unfortunately it will take me a while to set up access to a XP or Win 2008 environment. I can perform the tests under Vista without much effort so I will try that over the next day or two as well. Having said that, Vista and Win7 are similar animals...

Hi Graham,

Getting an XP machine turned out to be easier than I thought. Unfortunately it didn't change the outcome; the .NET XAM SDK still throws the same expections as I outlined at the beginning of this thread.

The XP machine is a 32 bit version of SP2. All of the Centera XAM dlls are in one directory as follows:

• centera_vim.dll (v1.0.103.0)
• fpcore.dll (v 4.0.698.0)
• fpos32.dll (v 3.2.281.0)
• fpparser.dll (v 3.2.48.0)
• fpstreams.dll (v 4.0.698.0)
• fputils.dll (v 4.0.698.)
• fpxml.dll (v 4.0.698.0)
• pai_module.dll (v 3.2.98.0)
• xam.dll (v1.0.103.0)
• xam.lib
• xam_toolkit.dll (v1.0.103.0)
• xam_toolkit.lib

I set the loglevel and logverbosity to 5, but didn't see anything in the logs that looked problematic. I've attached the log files from test 10 (import) and test 12 (multipartwrite).

NB: The definition for LogVerbosity in the .NET SDK (XAMLibrary.cs) is incorrect. The original property definition defines LogVerbosity as a XString. It should be a long.

Graeme

Graeme - the LogVerbosity constant is the name of the field and is correctly defined as a String. The long constant LOG_ALL would represent the "5" that you set. Secondly, the actual value of the field is returned as a Long so I do not see what you are reporting as being incorrect.

For the Import test, I see in the log that you create an XSet and then run the Import test. Had you previously run the Export test? I just tested the code with Create XSet, Export and then Import and all worked fine.

The connection string I used was "snia-xam://centera_vim!128.221.200.60?c:\\peas\\xamconnect.pea", and the PEA file was freshly downloaded from the EDN location.

I am preparing a new release (built and tested using the latest SDK) which includes some Test Harness changes. This will be available later today - can I ask you to pull it down and test with that so that we are on exactly the sampe page?

Graeme - I have just been inspecting the code and the Import and Export code at this point would only work for very small files. I am modifying them as part of the new release.

The Test Harness code is not intended as production or sample quality code, it's really only to demonstrate concepts and get you "up and running" with the concepts of the objects involved.

Graham

I'm not sure what is going on here. It' not the name of the property (Constant.LogVerbosity) that I think is wrong. It's the property definition itself. In the .Net SDK I load off CodePlex earlier this week has the following definition for LogVerbosity property in XAMLibrary.cs

public XString LogVerbosity

{

get { XString value = new XString(); GetField(Constants.LOG_VERBOSITY, value); return value; }

set { SetField(Constants.LOG_VERBOSITY, value); }

}

Hi Graham

Given the evidence I'd have to say that looks like the most likely cause, although I was positive I downloaded the most recent version (at least the one that was on the download page on the codeplex site). Anyway, the important thing is that it seemed to fix the issue to a large degree. I still get a exception when I run the import test (although export works OK). I haven't had time to look more closely at this. It could be that I aren't driving the test properly. If I can't sort it out I'll post another question.

NB: I can report that the SDK appears to work with Windows 7. I realise that running the test harness is far from conclusive , but from what I have seen so far the behaviour under Windows 7 is identical to XP.

Many thanks .... Graeme