Domino and the future
I know what you’re thinking, not another blog article about Domino’s future. Well no. This is about Domino dealing with future dates and what happens if there’s a blip with your OS’s date Friday, we had the unfortunate situation of one of our servers briefly believing it was operating in 2020. For the fraction of a second the server blipped, seven databases were accessed, including names.nsf. From this point forward the server believed these databases were operating in 2020. Although dates were correctly being set, all new and edited documents inherited the same last modified date of July 25th 2020 corrupting their replication history. Although the cluster replicator immediately pushed the changes across, it continued to report that it was unable to deal with dates so far in the future. IBM helpfully has a tech note covering such an eventuality. Don’t bother searching for it because it rather helpfully tells…
NASA | Earthrise: The 45th Anniversary
Great video showing how the iconic ‘Earthrise’ photo was captured. Featuring the live audio feed from the cabin as the shot was taken
Record Store Day
I wrote a blog article on my music blog about my first visit to a record shop on ‘Record Store Day‘
Unable to reliably deploy XPages using XSCD
We’re late to the XPages game and it’s only in the last few weeks I’ve felt confident enough to push XPages into our system’s templates. I only allow new Domino tech to be deployed when I’m confident that the technology works because we run on a very constrained 32-bit Solaris Domino install. I was ready to use XPages on 8.5.2 but we ran into issues pushing out a XPage Single Copy Design to websites. I tried using standard Domino single copy design templates but whenever we updated an XPage we received various errors. So I waited until 8.5.3 as this version was meant to fix our issue with XSCD. Although we can now push our XSCD’s through our templates, unfortunately moving to XSCD has not solved our issue. We are still unable to reliably deploy changes to XPages to all servers in our cluster without receiving the error: HTTP…
Dojo Date Picker – setting the date format
We’ve just implemented a Dojo Date picker to replace an old calendar tool we were using. In testing, the date picker correctly defaulted to the European date format of dd/mm/yyyy. However, all this testing was on PCs. Testing the same code on my Mac in Safari, the date format has switched to US format. My Mac is setup as a UK machine with UK date format, but it’s still defaulted to incorrect date format. As we’re a University with many international staff and students, assuming that their computers will be set to European format would not be sensible and as the date is being stored in Domino and Oracle we need control over the date formats to ensure the correct date objects are created. Luckily there’s a very simple solution. If you’re using html markup and the dojo parser to generate the date picker, you simply have to add: constraints={datePattern:’dd/MM/yy’}…
Agents ignoring Readers Fields in 8.5.3
We’ve just upgraded a server to 8.5.3. We have an agent that runs as a ‘web user’ but has ‘full admin rights’. The agent basically reads a view with documents that have readers fields and assembles them for display to the user. The agent needs to grab info from a protected database so has ‘full administration rights’. Previously the documents were read with the ‘users’ access permissions. So readers fields were obeyed. Various versions of this code has run this way for 10 years. Under 8.5.3 this is not the case. The readers fields are being ignored. Has anyone else experienced this issue?
XPages Single Copy Design
I’m posting this on behalf of my colleague David Harding (@dharding) who’s been investigating XPages Single Copy Design. I think it’s best I leave it to Dave to explain: We are looking to roll out XPages Single Copy Design to several thousand databases. So far, we have not been able to find a recommended practice for rolling out the XPages Single Copy Design flag and template path to all of these databases. Documentation on the Lotus Notes and Domino Application Development wiki (http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Single_Copy_XPage_Design#Does+employing+SCXD+typically+have+a+positive+or+negative+affect+on+speed+of+performance%3F) suggests that setting the options in the template should propagate to databases that inherit from that template. Quote from page: “Is it true that selecting or de-selecting SCXD in a template does not propagate to applications already created with that template? This is not the case. If a template is set to use a SCXD database and an application is created from this template then the new…
DAOS – Does LZ1 compression apply to web uploads?
We’re in the process of planning our move to DAOS and we’re confused about whether or not to use LZ1 compression. I’m wondering if anyone can help clarify how compression works for web content. In our environment, we have no Notes clients, everything is web-based. All the recommendations I’ve read say that we should switch on LZ1 compression. However, when we switch on compression for web uploads, our test files appear to be compressed using Huffman and not LZ1. So when we upload an existing file, we end up with two files in the DAOS vault as the compression types are different. Should this be happening? Or have we missed some obvious configuration option that ensure web uploads are compressed as LZ1?
Problems with Google Search Appliance and Domino’s compressed HTTP output
If you use Domino’s HTTP GZIP compression, you may have issues with your Google Search Appliance reporting: Malformed HTTP header: empty content It appears that the Google box will tell Domino that it accepts compressed content in the HTTP headers even though it is unable to process the content. Luckily I found an easy solution on the Google Search Appliance support forum. The solution is to add headers to the Google Box’s http requests. Open the GSA admin interface. Select ‘Crawl and Index‘ -> ‘HTTP Headers‘ In the ‘Additional HTTP Headers for Crawler’ enter: Accept-Encoding: *;q=0
$Dir on Solaris
If you are one of the few Solaris users and use the ‘Dir$’ function to read directories in your administrative routines to process databases in a directory. Be aware that it doesn’t work for databases over 2GBs in size. They’re omitted from list. We PMRed it. But it’s already been closed. Apparently it’s a code limitation and won’t be getting fixed. I expect it will be all that 32-bit Solaris code we’re still having to use. Don’t you just love having your hardware tied down by software?