The Domino 12 Update Certification is now available for 8.5 Certified Administrators

HCL software Academy has changed the requirements for the Domino V12 Update Certification exam.

This certification exam is for individuals who can provide proof of one of the IBM Domino Certifications below:

  • IBM Certified System Administrator – Notes and Domino 8.5
  • IBM Certified Advanced System Administrator – Notes and Domino 8.5
  • IBM Certified System Administrator – Notes and Domino 9
  • IBM Certified Advanced System Administrator – Notes and Domino 9

From LotusScript to ChatGpt and vice versa

My developer colleague, Fabio di Paola, has done some experimenting with ChatGPT and he successfully used it with LotusScript.

He published an article, in Italian, on our blog, here.

To save you the hassle of translating, here it is in English:’s ChatGpt is kind of the main topic of the last few months, we’ve all tried to use it and we’re thinking about how to use it in real cases. Precisely in the light of these considerations, the first question we asked ourselves was “but will I be able to use it within a Domino application?”

The answer is Yes , it can be done : we are investigating it these days and the first results are positive ; It’s true that sometimes, from theory to practice, surprises are always discovered and therefore the last word is never said, but here I feel optimistic. LotusScript can query ChatGpt and receive its response.

OpenAi has released APIs to connect to ChatGpt but, at least for now, they are limited to Python and node.js . In addition several communities have already published code libraries to connect to ChatGpt from other languages. It’s hard to think that something like this will ever be done for LotusScript .

But going to see how the calls are made and trying to experiment on the ChatGpt playground you can understand the mechanisms that underlie the calls to ChatGpt.

The first thing needed, regardless of the code used, is the API key for authentication: this is obtained by registering on the site and then going to the details of your account under ApiKeys It is a string of 51 characters which must then be passed
to every call.

At this point I started building a first prototype in LotusScript, the main parts are two:

  • The NotesHTTPRequest class to send the request and get the response
  • The construction of the Json to be sent and then the parsing of the return Json

For the NotesHttpRequest there is little to say, just remember that the API key must be managed as a header of the request.

For the Json part there are obviously various possibilities to build it and then to parse it, obviously the important thing is to follow the ChatGpt rules: here too, using the playground you can easily understand how to build it, which parameters to pass and how.

A typical example is this:

"model": "text-davinci-003",
"prompt": "Ask here the question.",
"temperature": 0,
"max_tokens": 100,
"top_p": 1,
"frequency_penalty": 0,
"presence_penalty": 0,
"stop": ["\n"]

Also to parse the response there are several possibilities, you can use the NotesJSONNavigator class in LotusScript or a library already present on the net like this one /JSON+LotusScript+Classes in OpenNTF.

At the end of all what I got is a form in which to enter the question with a button that sends it, parses the answer and writes the answer itself in a field below, all using only LotusScript :

I add a curiosity: among the questions I asked ChatGpt I asked if he knows LotusScript (with an affirmative answer) and then I asked if he could write me the LotusScript code to send requests to ChatGpt. Again the answer was yes but the code he gave me had several errors.

I replied pointing out the various errors and corrections were proposed to me which were equally incorrect. As far as I understand at the moment ChatGpt doesn’t “learn” from its mistakes, so it’s possible that asking it the same questions again will result in the same errors.

Problem with Prometheus in Sametime monitoring dashboard

I set up the monitoring dashboard in Sametime, using the provided JSON files; in case you don’t know how to do that, you enable it running this command

docker-compose -f docker-compose.yml -f docker-compose-monitoring.yml up -d

Today I discovered that my Prometheus container kept crashing, and in the logs I found lines like these:

corrupted block 01GQT2R33ASC29W57NF4WEZKP3: open data/01GQT2R33ASC29W57NF4WEZKP3/chunks: no such file or directory;
 corrupted block 01GQW0HNMW76WDHNY6T8CMEVQ0: open data/01GQW0HNMW76WDHNY6T8CMEVQ0/chunks: no such file or directory;
 corrupted block 01GQGDRDRKSS062T1762WACX5H: open data/01GQGDRDRKSS062T1762WACX5H/chunks: no such file or directory;
 corrupted block 01GQJBHXKJW38754FR7CZGTWZN: open data/01GQJBHXKJW38754FR7CZGTWZN/chunks: no such file or directory;
 corrupted block 01GQM9BGT78HDQXM2EZ2BP5P8S: open data/01GQM9BGT78HDQXM2EZ2BP5P8S/chunks: no such file or directory;
 corrupted block 01GQP75073Q7FRW2MEGE1T5869: open data/01GQP75073Q7FRW2MEGE1T5869/chunks: no such file or directory;
 corrupted block 01GQR4YKN8XJS7FY30VYR24VTG: open data/01GQR4YKN8XJS7FY30VYR24VTG/chunks: no such file or directory"

In fact looking at the directory structure under /tmp/prometheus, the default directory where Prometheus store files I found this:

The solution was to delete the directories that didn’t have a “chunks” subdirectory and restart the Prometheus container. The dashboard started working again.

I will be speaking at Engage 2023

Also this year, Theo Heselmans made me the honor of accepting my submission 🙂

I will be speaking with my dear friend Marianna Tomasatti, another Italian HCL Business Partner.

Our session is: Ad01. Useful hacks for Domino Administrators

It will be Wednesday, April 26 from 13:30 to 14:30 in room C. – Husly Lounge

You can find all the awesome sessions of Engage 2023 here

It will be a pleasure for me to speak again at this great event. Engage is the new Lotusphere! And it will be great to meet again many friends from all over the world.

Hope to see many of you there!

Solved – Problems displaying images in Sametime when allowing users to upload their picture in Verse

After digging a bit into the issue I reported in my previous post, I found out that this is not a bug of Sametime.
The problem lies in my customer network topology. As in many other customers I work with, they have some servers on the intranet, and some others on the internet, in this specific case the Domino server that is the LDAP server is on an internal domain ( .lan ) while the Sametime server is on a public domain ( .it ).

This is not a problem for Sametime, all you need to do is use some “extra_host” settings in docker-compose.yml and it works

The problem is that the URL generated by Verse when people upload their pictures is https:// pointing to the Domino server and the Sametime proxy does not like self signed certificates. In fact if I manually change it to use http:// rather than https:// in the person document, then the user picture is displayed correctly

I do not believe I can have the Verse development team change the way they generate the URL and use http:// so with this kind of network topology I have to find a workaround, else the problem will remain.

Thanks to my friend Erik Schwalb from HCL, who got in touch with me and told me that in his setup, where all the servers are in public domains using proper certificates this works fine.

How to make Sametime 12 Meetings work on Android

With the customer where I installed Sametime 12 we had an issue with Meetings using an Android device. From a Android phone a user could not join a meeting or create a new one. With iOS devices, this problem did not happen. We tested on Sametime 12.0.FP1 and Sametime 12.0.1

We opened a Case and in the end HCL Support found the solution, you have to add to the file .env this line

Problems displaying images in Sametime when allowing users to upload their picture in Verse

I have installed Sametime 12.0.1 integrated with Verse. The users now upload their pictures from the Verse UI but this breaks the display of images in Sametime.

The reason is simple: In the Sametime 12 documentation is clearly written that when using images from a web server the file type MUST be jpg or gif

Business card photos must meet the following requirements:
Photos must be less than 45K in size. Photos 10K or less are recommended.
Photo file types .jpg and .gif are supported.
Photos to be used in business card for mobile or web clients they must be in the format of a URL, such as hosted from a web server or HCL Connections Profiles server.

So the users for which I manually define the Photo URL field everything works fine

But for users who upload the picture from Verse the Photo URL is something like this

This type of URL cannot be read correctly by Sametime as an image and the result is that user’s picture are not displayed in Sametime, both in the clients and in the meetings

The only workaround I can think of is to disable the possibility for the users to change the image from Verse and use a proper URL that points to a web server ( I use the same Domino server that does LDAP ). This will cause probably some dissatisfaction for the users and some work for the Admins who have to collect the pictures and put them in a single place, but is the only way to avoid this problem as far as I know.

Sametime 12.0.1 – CPU requirements for MongoDB 6.0

I have installed ST 12.0.1 for a customer using Docker, and initially I wanted to use MongoDB 6.0; installation was fine but MongoDB would not start.

The error thrown was this: Job for mongod.service failed because a fatal signal was delivered to the control process. See “systemctl status mongod.service” and “journalctl -xe” for details.

A quick search on the web gave me the reason of this:

MongoDB requires the following minimum x86_64 microarchitectures:

  • For Intel x86_64 , MongoDB requires one of:
  • a Sandy Bridge or later Core processor, or
  • a Tiger Lake or later Celeron or Pentium processor.
  • For AMD x86_64 , MongoDB requires:
  • a Bulldozer or later processor.

My customer server had a Xeon Gold 5120 which is below the required specs for Mongodb, and that was causing the error.

The only thing I could do was uninstall MongoDB 6.0 and install MongoDB 4.4, which starts without any issue.

So if you plan to use MongoDB 6.0 pay attention to the CPU type you have .

P.S. I never had this before, I run my test servers on a AMD Ryzen 9 3900X 12-Core Processor machine, which is more than enough 🙂