Hi Daniel - does the cluster in question have a large number of Retention Classes defined?

If you run the JCASScript tool against that cluster, are you able to retrieve the Rentetion Classes successfully?

gstuartemc schrieb: Hi Daniel - does the cluster in question have a large number of Retention Classes defined? If you run the JCASScript tool against that cluster, are you able to retrieve the Rentetion Classes successfully?

Well it doesn't look like I've got too many, but not enough retention classes:

CASScript>rc

No retention classes exist on the primary cluster

CASScript>

So I'm guessing that somewhere in the API someone takes an invalid value for the number of classes (say -1) and uses that for malloc purposes, and since malloc takes unsigned numbers...

But that's just me guessing. How JCASScript can get the retention classes, when the API can't is somewhat fascinating.

Cheers,

-daniel

cluesch schrieb: How JCASScript can get the retention classes, when the API can't is somewhat fascinating.

Actually the answer to that is quite simple.

JCASScript is built against (and shipping with) SDK version 3.2.607, and I'm using 3.2.687 (3.2 Patch 4). If I'm running the programs against JCASScript.jar and its DLLs everything works.

So someone broke the SDK (Same issue also on Solaris 10) when fixing other things. So we'd need another Patch, or the previous (3.2.607) version for downloading.

Problem solved, or at least identified.

Thanks Daniel - I have raised a TestRack defect report and this should be fixed in the next patch release.

As a workaround, please create a Retention Class on the cluster in question.