I’m posting this description both as a warning to others and as a call for help to anyone who may have found a workaround for this:
The problem is centred around the “design” task on the server. If we modify the design of a “schedule” agent in the template (ntf) file, the design task will not upgrade the agent in the database file (nsf) if the schedule is activated.
The only workaround found, so far, is to deactivate the schedule prior to running the design task and reactivate it once the design as been change. we can automated the process … using an agent of course. This is not a very interesting solution in a network with over a 1000 servers running 100s of applications.
At first I had a hard time believing this. ND6 as been on the market for a year and many large organisations are using it. I found it strange that no one would have notice this kind of major bug before. After contacting IBM/Lotus support it was confirm that only a single case (under investigation) was “similar” to ours but that our problem was confirm by the analyst and already reproduce in the IBM labs.
My second reaction was to hope that it was corrected in the current version since my customer are deploying a very early release of ND6, despite warning of potentials troubles in any “.0” product. Unfortunately the problem was reproduce using all currently available versions of ND6, (including 6.0.3 and the just release 6.5.0) .
Subject: Serious bug with the design task not updating agent
Should be great if you give us the code of your agents (Formula, LS, JAVA, launch options, readers access, acl, Security tab in server documents), my clients are running approx. 3500 agents/minutes on their Domino servers, and we do have modification of code, but not an agent was not updated. All agents are using LS libraries or JAVA libraries, not a single code is located in the agent, except sarting code. Some clients are on iSeries, others Linux and some on win NT/2000.
Subject: RE: Serious bug with the design task not updating agent
The nature of the agents is irrelevent. Any schedule agent that is activated will be affected by this bug.
In your example I would suspect that all the changes where made in the libraries, not in the agent code. The libraries, being independent design objects will not be impacted by the bug, only the trigger code will.
It explains some of the changes to the design update task that were implemented based on customer requests. Once you see what changed, it might be easier for you to see how to make it do what you want. The section about Design Update task is called “Something is disableing my agent”.
Subject: RE: Serious bug with the design task not updating agent
What is the change that you are making in the template? Did the date on which that element that you changed got updated? What is the date on the agent in the database? Are the dates in synch between client and server?
The way this works that the first time the update happens, the date when the agent in the TEMPLATE has been changed is stored in the agent in the DATABASE. From there on, if the date in the template changes then it takes precendence. Otherwise, the agent keeps the changes and does not get replaced by the template version. So look at the dates - the answer is there.
Subject: RE: Serious bug with the design task not updating agent
I toltally agree with you. That is exacly how it sould work, but it is not.
Here’s a quick way of reproducing the problem:
1- Create a new template from any design with some “scheduled” agents.
2- Use this template to create a new DB on a ND6 server.
3- Activate one of the “scheduled” agent.
4- With Domino Designer, make some change to the activated agent in the template and save your change. To get a compare element also make a change in a sheduled agent that is not enabled in the NSF.
5- Lauch the design task on the server.
The result will be that the “enabled” agent will not show the changes and the “disabled” one will have been updated properly.