Design note corrupt?

HCL Domino Domino Forum
1

Hi all,

I have a curious problem. A database we developed for one of our clients stopped running a scheduled agent. The server log indicated the error

Error loading USE or USELSX module: xxx

I checked and saw that the Script Library xxx was saved with a date after the agent was last saved. So, I saved the agent again and received no errors during the recompile. However, the next night, the agent failed to run again, with the same problem logged in the server’s log database.

Trying to run the agent manually displays the following error in a dialog box:

Error processing use list module: Scripted Object

followed by:

Error loading USE or USELSX module: xxx

Apparently, the agent calls all of the functions out of the script library xxx correctly (no missing or mistyped parameters, etc.) or else the compilation would have caught that problem as I was saving the agent. But when I run the code, it fails.

Is it possible that there is some sort of corruption in the design note of the script library? When I look at the design note of the script library, it contains the $ScriptLib item (with my code visible in its text representation) but does not contain the $ScriptLib_O item (with its object code) as do my other LotusScript libraries.

Any help will be appreciated, although I suspect the answer will be to export the source code, delete the original script library and import the source code into a new script library, allowing the Object Code to be recreated.

2

Subject: Design note corrupt???

Haven’t there been some improvements to the LotusScript compiler in 7.0.2 (or 7.0.3)? Any chance you can recompile all LotusScript on a machine with a newer release installed?

Would be a little less tedious than deleting and recreating the, but exporting, deleting and recreating the Script library might be the save path.

3

Subject: RE: Design note corrupt???

Hi Harkpabst,

Thanks for the input - I still never quite trusted the recompile all but luckily for me, this script library is only used in about 10 different places so it was a reasonably easy process to go through. In fact, to bring this issue to a close, I have determined that it was indeed the missing $ScriptLib_O item that was causing the issue.

Learning experience:

When saving an agent (or some other design note) that calls functions from a script library, the compiler only checks the $ScriptLib item to make sure the function signatures are all corrrect but does not attempt to check for the presence of a $ScriptLib_O item (which is probably expected since the parser is not expected to read/interpret the object code). However, when the agent runs, it could care less about the $ScriptLib item - it only wants to see the $ScriptLib_O item. So despite the fact that the agent compiled fine, it could not run because of the missing $ScriptLib_O item.