I don't have answers to all your questions, but the solution that has worked for me, always, is recompiling all LotusScript. We are facing the same issue, too, with a multilingual application of ours. This application inherits its design from a template, and every time the application's design is refreshed from the template, manually or by the nightly task, we start getting ECL alerts, the LotusScript libraries fail with "Error loading USE or USELSX module", the scheduled agents get disabled or the agent code do not get updated. After the design refresh, whenever a docuemnt is launched, the details section of the ECL alert displays the following 'Program signed by: -No Signature-'; 'On: - not known-'. I have been investigating this issue for quite some time now, and have a few leads but no definitive answer to this issue. Based on all the information that I have been able to collect, here is what I have found.
1. $POID: On design refresh, all LotusScript Libraries, agents and database script design elements are updated with a notes item. To the best of my knowledge, this item is added to the aforementioned design elements only; the remaining design elements of the application are not updated with this item.
According to Thomas Gumz, this item stands for "previous note OID and is used to keep track of design refresh handling". And according to Julie Kadashevich, "The behavior for which this field is used is explained in the Agent FAQ in the article called "Troubleshooting agents". Look under explanation of template design update (something is disableing my agent). It is NOT the last time THIS note the was updated. It is the last time a related note was updated."
I am not exactly clear on what Julie meant by "a related note was updated". Does she means that if a Form referencing a scriptlibrary is updated, then the date time stamp in $POID would be updated, too?
The particular section that Julie mentions is thus.
Something is disabling my agent
The Design Update task is a system process that updates database design from a database template. This task’s goal is to keep the database and the template in synch. When either the database or the template have been changed, and the user did not select the "Do not update" design property for specific design elements, the Design Update task updates the database to match the template. This sometimes causes problems for agents, typically described as “something is turning off my enabled agents in the middle of the night!"
This happens because the user has made a significant change in the agent in the database. By significant change, we mean something other than enable/disable status of the agent or the name of the server on which the agent is scheduled to run. The most common change that causes this problem is the change to the schedule of the agent, but it also could be a change to the agent code or some other part of the agent design.
Prior to Notes/Domino 6, the Design Update task recognized changes in the database as well as the template. In Notes/Domino 6, Design Update now keeps track of changes only in the template. This lets you make changes to the database and keep them, unless the template itself had some significant changes. Changes you make to the template take precedence (because typically the changes in the template indicate bug fixes or some other administrative change). If the template is used to update the database, agents revert to the versions in the template, which typically are disabled.
You can suppress the agent design update by selecting the option "Do not allow design refresh/replace to modify" in the Agent Properties box.
It is necessary to disable the agent because when the agent is updated from the template, the agent from the template (including the signature in the template) replaces the agent in the user database. The agent is disabled to force the user to sign it and thus, to make it run with the appropriate security rights. (Otherwise, the mail would come from Lotus Notes Template Developers among other undesirable things.) Because the user ID file does not exist on the server, it is not possible to re-sign the agent with the user ID automatically. The only ID that is available on the server is the server ID, but having the agent run under the server ID is also undesirable.
2. The technote 'LotusScript Performance Problems After Upgrade to Notes Domino 6' - - Reference # 1176211 includes, amongst other things, the below paragraph.
New functionality in Notes 6.x provides for a new agent security model in relation to script libraries. In Notes 5.x, signatures of script libraries were not individually reviewed when the agent was loaded and all script libraries ran under the authority of the user who signed the agent. In Notes 6.x, signatures of script libraries are separately loaded and each script library runs under the authority of the signer of the script library.
3. The technote '"Error in Agent" or "Error Loading USE or USELSX" Running Out-of-Office Agent After Upgrading to Domino 6.x' - - Reference # 1178007 includes, amongst other things, the below paragraph.
Agent security rights in Domino 6.0 were revised to be more robust. This issue occurs when the signer of the script library does not have the correct rights to execute on the Domino server, and/or the script library has not been signed in Notes/Domino 6.x.
4. The technote 'Refreshing design does not update LotusScript agents after recompiling' - - Reference # 1179112 includes, amongst other things, the below paragraph.
In Lotus Domino, after recompiling all LotusScript agents in the master template, refreshing or replacing the design does not work and the design does not update. For example, the administrator updates the design in one database that uses the master template. The script libraries are refreshed but not the agents. This causes update problems and requires the administrator to recompile all scripts in the database.
NOTE: In a simple scenario, if you make changes to a library in the template file and then recompile all scripts and then refresh the design in the target database, even though the agents won't be refreshed, they will acknowledge the library changes. In a large application with several complex libraries and agents, this is not the case.
This issue was reported to Quality Engineering as SPR# ICAO64DJ72 and was fixed in Notes/Domino release 6.5.5.
Excerpt from the Lotus Notes and Domino Release 6.5.5 MR fix list (available at http://www.ibm.com/developerworks/lotus
SPR# ICAO64DJ72 - If a user recompiled all LotusScript in a template (.ntf), then refreshed the design in a database that inherited from that template, the agents in the database (.nsf) did not get updated. With these fixes, script library routines do not keep executing beyond the time limit, and the agents do get updated.
If you haven't yet upgraded, the only workaround is to sign all design elements in the template after recompiling them. Then refreshing the design of the target database will update all agents as well as the script libraries
Based on the above information, the numbered list below describes what I think is happening. This is the most logical conclusion that I could reach. Please correct me, if anybody thinks otherwise.
1. As described by Julie, during the design refresh process, the signature of agents (and all the other design elements ) are overwritten with the signature in the template.
2. Now, based on the ECL alert, it seems that, after the design refresh, the Lotus Notes client evaluates that the creator of the code is unknown, hence it displays '-No Signature-' in the 'Program signed by:' field.
3. And, as mentioned above, in release 6 "signatures of script libraries are separately loaded and each script library runs under the authority of the signer of the script library".
4. Consequently, when the code is executed and since the singer is "unknown" and would not have the appropriate access to execute the code we are prompted with the 'Error loading USE or USELSX module' error message.
5. Therefore, recompiling all the LotusScript or opening and saving the design elements re-signs it with the correct ID. This results in everything working again.
Thus after all this meandering discussion my recommendation to you is to recompile all LotusScript in your release template after you have refreshed it from the development template. This should fix the 'Error loading USE or USELSX module' error.