If you want to enable this feature go to this link
MySphere Posts
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
- 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). - Using operating system commands, delete the corrupt replica file.
- Using the Lotus Notes client, open the “good” replica located on the other clustered server.
- Create a new replica on the server where the “bad” replica was deleted.
Select File -> Replication -> New Replica. - Complete the replication.
- Stop the Cluster Directory task on the server where the new replica was created by running the console command “tell CLDBDIR quit”
- Restart Cluster Directory task by running the command “load CLDBDIR”
- Verify database replica is on clustered server: Open Cluster Directory database and select the view, Databases by Replica ID
- Verify that each replica copy of the same NSF file has the same Replica ID value.