Invalid function "<modulename>.configure"

Hi Forum,

I have just upgraded several LL971 modules. They install fine on CS10. They all install fine on CS10.5 except one or two which give me this error on installation:

In the thread log when CS10.5 starts up it gives me this kind of entry:

09:16:26,797 INFO OpenInstalledModuleOSpaces(): Cannot open {'<modulename>'}

09:16:27,043 INFO Dispatcher error: Invalid function "<modulename>.configure".

09:16:27,044 INFO Wed May 20 09:16:27 2015 - 30462 Func='<modulename>.configure' Timing: 0.532 0.531 0.532

Has anyone seen this before and is there a resolution?

Is CS10.5 having a problem opening the ospace (is it unable to read it for example or is it in a corrupted format for CS10.5?) or is it opening the ospace but then having a problem running the configure function (which is normal and not overridden)?

Is there a way I can safely debug the startup phase of CS10.5 to home in on the problem further if necessary?

Any tips welcome.

Regards,

Find more posts tagged with

Comments

SCL

I am surprised by what I have just seen: in CS10 the modules startup in the order specified in the opentext.ini file.

In my CS10.5 SDK environment, I have just observed the modules starting up in what looks like alphabetical order! This may well have something to do with it.

This doesn't seem to have been documented in the quick-start guide for developers. So be careful to ensure your dependencies are fully set up.

I'll be checking those dependencies next.

Regards,

Mark_Sherry

If you search your OS files for the module for modulename do you find anything?

Mark_Sherry

Also, CSIDE uses exactly the same code to load OSpaces and modules as when run as a server, and I believe that code hasn't changed since CS10. The CSIDE start-up script calls the regular llwebstartup.lxe start-up script to do initialization, including module loading.

Jacopo Malnati

I had your exact issue while porting from 9.7.1 to 10.5 some of my modules and it was due to a hidden dependency to a module that it was present in 9.7.1 or 10 but not in 10.5.

Even if the dependency was not explicit and there were no visible orphans pointing to something they should not, the dependency, in terms of code describing the old orphan, was inside the oll.

If you open your oll on a 10 system and dump its code, you can go through it and check for something similar to what I had. Just remove the "hidden" orphan, reimport the code, build it and try it on a 10.5. I had these kind of dependencies because I added and removed orphans on a 9.7.1 builder.

Appu_Nair1

I have run into plenty of instances like Jacopo Malnati explains in regular code port from 971 to 10 (builder) or 971 to 10.5(CSIDE).In many of the cases the editing of the ascii dmp file has saved me .

SCL

Hi All,

Thank you all for your replies.

The way I solved this was loading the module up in SDK CS10 Builder, exporting the module, then importing the module again, then transferring across to Eclipse SDK.

There were hidden references to other modules in the .oll which had since been removed in Builder explicitly, but that had lingered in the .oll.

Cheers,

Sher Clark

Jacopo Malnati

That trick (export-import) worked for me in different occasions, but not always. Now I wonder what kind of dependency had to be manually hunt down and removed from the dump.. unfortunately I do not remember much of that