Author: <span>kenio.carvalho</span>

With the launch of Domino Upgrade Pack 1 Domino Designers need to know how to use REST and JSON.

I found a good tutorial about REST. It is a starting point.

This year i made several certifications and all goals achieved.

My certifications this year:

LOT-801  – IBM Lotus Domino 8.0 Application Development Update
LOT-851  – IBM Lotus Domino 8.5 Application Development Update
000-038           – IBM Tivoli Identity Manager V5.1 Fundamentals
LOT-910  – IBM WebSphere Portal 7.0 Deployment and Administration Update
000-377    – IBM WebSphere Application Server Network Deployment V7.0, Core Administration
LOT-913  – Developing WebSite Using IBM Lotus Web Content Management 7.0

The last certification was today LOT-913  with 100%. It was my first 100% on IBM Tests.

 the Traveler server is experiencing a high CPU situation for an extended time, here are some actions to take which should resolve this issue

From TN 1568658

An extended high CPU on a Traveler server can be caused by several issues.  

Here is an approach to resolve this issue:

1)  Make sure you have the latest Fix Packs for both Traveler and Domino installed as several known issues have been addressed in the Fix Packs.  

The latest Traveler Fix Pack can be found here.

The latest Domino Fix Pack can be found here.

2) Verify the number of HTTP threads based on the number of devices using the Traveler server.  The steps to check this are documented here.

3)  Run a Traveler database defragmentation which will clean up and reduce the database size.  This will run automatically after installing the latest Traveler fix pack.  If it has been over a month since the last defrag has been done, running this again will be helpful.   It is recommended to run a defrag monthly.

How to defrag the database is documented here.

4) If you have followed the 3 steps above, but the issue continues, you could be experiencing a known Domino Server issue related to the DelayQueue function.  This is documented in SPR RSSN8HPLKX / APAR LO63480.  

To identify this problem (on Traveler 8.5.2.4), issue the cmd: show stat traveler.delay*  

If the output displays the following 2 lines, then you have encountered this defect:

Traveler.DelayQueue.Count.WrongOrder.DiscDelQ =      
Traveler.DelayQueue.Count.WrongOrder.StateController =

The Domino fix for this issue is included in Domino 8.5.2.4 or later, which can be found using the link in step 1 above.
NOTE: This fix is already included in Domino Server 8.5.3 and higher releases.

When AdminP processes a password change in Lotus Notes/Lotus Domino, the old password is cached by the server for two days. What if this cache period is too long or too short ? Can the cache period ever be modified?

Yes, the cache period can be modified by setting the following parameter in the server’s notes.ini file:
HTTP_Pwd_Change_Cache_Hours.

Use the following format:

HTTP_Pwd_Change_Cache_Hours=x
(where x is the number of hours of caching time for the old password)

During the cache period, both old and new passwords are valid, assuming the change has replicated to the server being accessed.

In addition, the Security Settings Document –> Password Management –> “Allow users to change Internet password over HTTP” field must be set to Yes.

The information above is from TN1084395

There is no native failover support for scheduled agents in Domino. I know this issue i think since i start to work as a Domino Administrator 12 years ago.

From TN 109833034

This issue has been reported to Lotus Quality Engineering in the form of an enhancement request; however, there are currently no plans to address it.

Basically, scheduled agents run only on the server on which they are scheduled to run.  If Server A is clustered with Server B and Server A goes down, any scheduled agents on Server A are not going to run on Server B, even though they are clustered.

One way around this is to code the agents so that they poll the other server for availability.  If the server is available, they do not run; if it is not available, they do run.  It is important to note that this workaround is not supported by Lotus.

An optional workaround is:

1.  Create a single agent (AgentCore) with the core processing code you need and set the trigger to “Agent list selection”.
2.  Create a second agent (AgentTriggerPrimary) with code that calls the AgentCore agent.  Schedule this agent to run on the Primary Cluster Server.
3.  Create a third agent (AgentTriggerBackup) with code that checks to see if the Primary Cluster Server is available.  If it is not, it calls the AgentCore agent, otherwise it exits.  Schedule this agent to run on the Failover Cluster Server.

This kind of problem is old but you can use new tools to solve the problem.

Yesterday, in one of our applications a lot of old documents  reappear like ghosts.  According the TN 1098733 the problem is caused by:

1. The purge interval  is more frequent than the replication schedule.
If a document is deleted and the deletion stub is purged before replication, the other replica copy does not have the information that the document has been deleted and replicates the document just like a new document.

2. A document was modified on one database replica after it was deleted on another replica copy.
If a document gets modified on one replica copy of the database after it was deleted from another replica, the modified date on the existing document is newer and would overwrite the deletion stub (there is no replication conflict with deletion stubs, the document just reappears).

3. A document was modified more often than the deleted document
If a document gets modified more often on a replica copy than of the database with the deleted document, it will come back after replication even if it was deleted after the last modification. This is because the sequence number (number of modifications) takes precedence over the modified date – and since there can’t be a conflict with a deletion stub it reappears after next replication.

But in Domino Administrator you don’t have any   tool to help. Its where the ScanEZ, a powerful tool, can help to solve this kind of problem.

Go to this link and see a good article about the tool and how ScanEZ was used in this scenario.  

For more information about ScanEZ go to this link

Este tipo de problema é antigo mas existem ferramentas novas para ajudar a resolver o problema.

Ontem, uma de nossas aplicações, muitos documentos aqntigos reapareceram como “fantasmas”

Usei o ScanEz para achar quais documentos estavam com problemas e solulcioná-lo rápidamente, excluindo tais documentos.

Domino installer does not start and goes to command prompt immediately.

Domino requires the following packages to be installed. They can be located on the RHEL6 distribution disks or installed via RPM.

glibc-2.12-1.7.el6.i686
libgcc-4.4.4-13.el6.i686
libstdc++-4.4.4-13.el6.i686

The packages listed above are sufficient to install Domino in silent and console modes.
To run GUI Domino installer, you will need additional xWindows packages:

libXtst-1.0.99.2-3.el6.i686
libXmu-1.0.5-1.el6.i686
libXp-1.0.0-15.1.el6.i686

To run GUI setup you will need two more packages:
libXft-2.1.13-4.1.el6.i686.rpm
libXi-1.3-3.el6.i686.rpm

Installing the packages above plus any dependencies will allow the installer to run.

 The information above is from the TN 1455332

From TN 1228354. This is the last option

1. Ensure that the corrupt replica is not in use by any user or server.
   On the Domino server hosting the corrupted database, enter the following command: “dbcache flush” (command may require entering two or three time to release the database).
2. Using operating system commands, delete the corrupt replica file.
3. Using the Lotus Notes client, open the “good” replica located on the other clustered server.
4. Create a new replica on the server where the “bad” replica was deleted.
   Select File -> Replication -> New Replica.
5. Complete the replication.
6. Stop the Cluster Directory task on the server where the new replica was created by running the console command “tell CLDBDIR quit”
7. Restart Cluster Directory task by running the command “load CLDBDIR”
8. Verify database replica is on clustered server: Open Cluster Directory database and select the view, Databases by Replica ID
9. Verify that each replica copy of the same NSF file has the same Replica ID value.

Today  i an agent stop to working . The cause was the wrong signature but in this case was not access rights

The TN 1099178 explain the problem:

In order for “After new mail has arrived” triggered agents to run on Notes/Domino Servers, the following must be true:

1.        The signer of the agent (the last person to save or enable the agent) must have their mail file located on the same server as where the agent will run.  The server determines this by taking the name of the last person to save the agent, performing a person lookup into the Domino Directory and retrieving the Mail Server from that user’s Person document.  If the Mail Server in the Person document is different than the current server, the agent will not run.  If the person is not found in the directory, the agent will not run.  This person lookup is performed every time the agent loads to run.  Remember, if the User ID is hierarchical, the user name in the Person document must also be hierarchical.  This is stored in the field “FullName” in the Person document.

2.        Historical Detail: In Notes R4, if the agent is a Formula agent (as opposed to a Simple Action or Script agent), then there is an additional requirement that the agent be saved as a R4 type agent, rather than an R3/R4 Compatible agent (which is the default).  An agent will save as a R4 agent when a feature that is exclusive to R4 is used within the agent.

Note:   This limitation no longer applies to formula agents created or saved in R5.  R5 does not save agents in the R3/R4 compatible format.  Existing agents that are still in the R3/R4 compatible agent format will still not run under R5 until they are resaved using an R5 client.

Workarounds for the Mail Server Lookup caveat in Requirement #1 above

In Notes 4.5x and later:

You can add a parameter to the NOTES.INI file that disables this mail lookup check.  The NOTES.INI parameter must be set on the server where the agent is to be run.  The parameter is:  

AMgr_DisableMailLookup=1

Historical Detail: In 4.5x releases prior to 4.5.3 and in release 4.6, if the above INI parameter is set to 0, then it still acts as if it is set to 1.  So, in those Notes releases if you want to re-enable the mail lookup, the INI parameter must be removed entirely.

Note:  This parameter does not prevent the following warning when saving the agent; however, the agent still runs:

“Unable to determine the execution access privileges for this agent on ; agent may not run.”