Domino Diva

Server Error Device is Busy In Use

Kim Greenekim@kimgreene.com  

 I received a call from a customer this morning saying noone could access their mail files.  The really strange thing about the situation was that the log.nsf, names.nsf, ... could be opened.  It was just a problem with the mail files.  When users tried to open their mail files, they received the following error message.

"Server Error: Device is Busy/In Use"

The console showed messages like this for mail files the router was trying to deliver mail to:

"Error delivering to servername/domain mail/xxxxxxxxxxxx.nsf; Device is Busy/In Use"

I dumped the server call stacks for all Domino jobs on that server and the job call stacks for any jobs I thought could be suspect.  I looked through the output and didn't find anything suspicious.  Next I invoked the QP0FPTOS api to identify if there were any IFS locks on the objects. The output showed there indeed were IFS locks on the files.  I issued the RLSIFSLCK command against a few mail files.  This did no good, the objects remained locked.  The only time the RLSIFSLCK command cannot release a lock is if it is a directory lock or if there is a save lock. 

This tipped me off to look at the job log for the save job.  This customer takes their Domino servers down every evening, saves the data directories, and then starts the servers after the save is complete.  The save output showed that the first Domino server had been saved fine, however the save job for the second server, the server we were having this issue with, was still active.

Once the save job was ended, the problem went away, no server restart was required.  The mail files are able to be accessed again and the customer is very happy.

Now it's time to get outside and enjoy this beautiful weather since it's the weekend!

• Comments[3]

Impressed with 'Compress database design'

Kim Greenekim@kimgreene.com  

 I am very impressed with the new database property 'compress database design'.  I recently upgraded my test Domino server from 7.0.3 to 8.0.1 and played around with the 'compress database design' database property.  After doing a compact -c on the database to switch it to the new ODS, level 48, I saw this on the console:

Compacted mail/dadminis.nsf, 9472K bytes recovered (54%)

Here is a bit of a precursor to explain my test.  The mail file (dadminis.nsf) was using the Standard Mail 7 template.  It was still at ODS 43 after the upgrade.  The mail file only had 4 documents in it, so it was primarily comprised of design elements.  I set the notes.ini parameter Create_R8_Database=1 and restarted the server.  I did a 'load compact -c mail/dadminis.nsf' at the console, and got the above results, the 54% reduction in file size.

The size of the mail file (still the Standard Mail 7 tempate) went from 18 MB down to 8192 Kb.  Talk about a nice improvement for a base mail file.  Thank you to the Lotus team for this improvement!

Next on my target list is how much the database property 'compress document data' pays off.

• Comments[2]

V6R1 Program Conversion on System i

Kim Greenekim@kimgreene.com  

If you are looking for information related to the program conversion on System i that happens when upgrading to V6R1, you may want to check out some recent articles I wrote.  The intention was to have one article, but it ended up being too big to fit in the space available in the magazine.  The compromise was to split it into the main article included in the magazine and two web exclusives.  Here are links to all three articles:

"Preparing for V6R1, What to Expect During Your Conversion"

"The Impact on Domino"

"Tips for Working With the V6R1 Conversion Tool"

One of the biggest gotchas, IMO, is that the program conversion tool doesn't pick up the Domino libraries by default when estimating how long the program conversion times for libraries will take.  This would be a nasty one for customer to miss, as conversion of the Domino libraries can take over an hour in some worse case scenarios.  Even worse, if the customer doesn't realize that Domino gets converted because the tool doesn't report it by default, they may not find out about the program conversion until they start the Domino servers after the upgrade to V6R1.  Because of the time required to convert the Domino libraries, the server most likely won't start and could produce some strange errors.  This would not be a fun upgrade experience. 

Hopefully you will find these articles helpful in planning any upgrades to V6R1.

• Comments[0]

Misunderstood multi-versioning

Kim Greenekim@kimgreene.com  

 In a conversation with a new customer this afternoon, I heard a common theme come through; multi-versioning is not well understood.  I have had similar conversations with a number of customers over the past few years. The net is that customers do not understand what multi-versioning is and how it can benefit their Domino installations.

Domino on the System i (iSeries, AS/400) has had multi-versioning since releases 6.0.3 and 6.5.0.  This support allows more than one version of Lotus Domino to be installed and running on your iSeries at the same time.  For example, a single iSeries box or iSeries LPAR could have releases 6.5.6, 7.0.2, 7.0.3, and 8.0.1 installed and running. The main areas of confusion I have found related to this support in my conversations with customers are related to these three areas:

1) how it affects the install process

2) how servers are upgraded to the new release after the new code installation

3) do all servers have to be upgraded at the same time

How it affects the install process

I like to use multi-versioning support to, at a minimum, install the new version of Lotus Domino.  With multi-versioning support, I can leave production servers active while installing the new version.  This saves about 1/2 hour of downtime for the customer.  It also allows the customer the flexibility of installing the new code version during production hours, so they are ready to update their Domino servers whenever is convenient for them. 

How do servers get updated after the installation

There is an UPDDOMSVR (Update Domino Server) command that allows you to specify which server you want to take to the new release level.  When you are ready to update a Domino server, simply end the server and issue the UPDDOMSVR command.  The parameters to the command are the name of the Domino server and the release level you would like to upgrade the server to.  It really is that simple.

Do all servers have to be upgraded

This is a very simple answer, no.  You can pick and choose which servers to upgrade.  For example, if a customer has three servers sitting at releast 6.5.6 and they want to upgrade one of the servers to release 7.0.3, they have that flexibility.  Better yet, if a customer wants to check out the new release 8.0.1 that came out yesterday, then can simply install the new code release, configure a test server with this new code release, while leaving their existing servers untouched.

Multi-versioning is really that simple!

• Comments[6]