Support 1a

[Support 1a]

That’s correct. Novell changed the way the registry entries worked in 6.5 SP1 so that TPH’s could be registered under HKEY_LOCAL_MACHINE.

Here’s the contents of a .reg file from my machine:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWARENovellGroupWiseClientThird Party]
"DLL1"="C:\PROGRA~1\Advansys\Formativ\TokenBlocker.dll"

Here’s a link to Novell’s documentation where they discuss the required registry entries, along with the change they made for SP1. Scroll down to the ‘ TPH Interface Requirements’:

http://developer.novell.com/ndk/doc/gwtoken/gwtokens/data/a6eyuta.html

I hope this helps.

Advansys Support

[Support 1a]

It turns out that, in at least the 6.5.5 client, the DisplayProfile token is not broken.

The defect actually lies in the Formativ GroupWise.DisplayProfile() command. When Novell duplicated the bug, they accidently used the incorrect syntax for the document ID. They today realised this and found the command does actually work. This led us back to our wrapping, which we found to be incorrect. We have fixed this in Formativ. The fix will be available in the next maintenance release.

In the meantime, you can work around the bug by using ThrowToken as shown here:

iSyntax = "DisplayProfile(""GWHQ.MOSMAN.MOSMAN Library:1686.1"")"
groupwise.throwtoken(iSyntax, iReturnVal)

I hope this helps.

Advansys Support

[Support 1a]

The information has been resent.

Regards,

Advansys Support

[Support 1a]

Thanks MA.

This is a difficult area to work with, and a major ommision in the Object API. The link above contains much of the collective knowledge in this area. I hope it helps.

Advansys Support

[Support 1a]

Thanks for letting the community know about the workaround you came up with.

Regards,

Advansys Support

[Support 1a]

Thanks MA!

Advansys Support

[Support 1a]

Thanks for the update. Good luck with your rollout.

Advansys Support

[Support 1a]

We’ve never seen, nor heard any reports of a problem like this. As you mentioned, simply deleting a field definition should remove the field value from message objects that have a value defined – nothing ‘bad’ should happen.

Despite the fact you are using Formativ, you are actually using the native GroupWise Object API here. Formativ doesn’t provide any additional ‘wrappers’ or functionaility in this regard. When you access something like GroupWise.Account in Formativ, you are using a native, unmodified Object API object. Without wishing to appear evasive, I am extremely confident any issue in this regard is not related to Formativ. It is almost certainly an Object API issue, or an issue with the GW agents being used.

Which version of GroupWise are you using? As MA alluded to, some earlier versions of GroupWise didn’t handle the management of custom fields particulary well. Nothing destructive that I am aware of, but it was certainly problematic to delete field definitions, etc. It may be worthwhile upgrading to the latest services packs, etc, for the version you are running.

I can’t really provide you with any other advice, other then try increasing the size and traffic on your development system and try again. I would also ensure your live system is fully patched and completely ‘healthy’ before adding the field definition again.

Advansys Support

[Support 1a]

I don’t know when the bug first appeared. (I doubt even Novell could tell me that). You would probably need to experient to see if you could find a version where the token worked.

You may be able to get more information from Novell’s developer support forum.

Advansys Support

[Support 1a]

Unfortunately we can’t locate it in our support account. It may have been trapped by a spam filter, or has otherwise been misplaced. Could you please resend and we’ll take a look.

Could you please also send a separate email to support@advansyscorp.com to let us know you have sent the information.

Regards,

Advansys Support

[Support 1a]

Novell have confirmed this as a bug and have assigned it defect # 145301.

They were unable to say when it might be fixed, but indicated it probably would only make it into a post 6.5.6 FTF release. It may make it into GW7 SP1, but SP2 is probably more likely.

I’ll post more here when I hear anything from them.

Advansys Support

[Support 1a]

You may also want to contact the development partners shown at http://www.advansyscorp.com/formativ_partners_developers.htm if you have not already done so.

Regards,

Advansys Support

[Support 1a]

Thanks MA.

Advansys Support

[Support 1a]

Hello LP,

No, I’ve not heard anything back from Novell. I’ve just sent an email asking for a status update.

Unfotrtunately I am not aware of any workarounds to this aparent token bug.

I’ll let you know what I find out.

Regards,

Advansys Support

[Support 1a]

The Object API (used to add entries to Address books) is the most likely culprit here. This is all client side, so I don’t expect any impact on the server’s memory.

As mentioned by Support 2, adding more than 300 or so entries results in severe slowdowns, and as you are seeing, extensive memory use. Adding 15000 entries will certainly tax the system.

I think some of these issue may have been addressed in GroupWise 7.

Advansys Support

[Author]

Replies