DEBUG_AMGR_ENABLE_RETRY_ON_COMPACT

Bij een klant kwam men in de loop van de dag er achter dat bepaalde taken op de server niet werkte. Wij hebben diverse monitoring op de servers bij storingen aan server taken, processen, schijfruimte zodat wij tijdig worden gewaarschuwd. Dit was echter  een versie 9.0.1 omgeving waar een compact van een database middels DBMT ongelukkig samen viel met de refresh van de Agent Manager. Ook al wordt deze versie al enige tijd niet meer ondersteund, het probleem lijkt zich op nieuwe versies ook voor te kunnen doen. LO53401: AGENT MANAGER IS BLOCKED WHEN A SCHEDULED AGENT RUN WHILE THE COMPACT TASK IS RUNNING APAR status: Closed as program error. Error description: Scheduled agent will not run again if AMGR attempts to run it while compact task is processing database. Steps to reproduce: 1. Created a scheduled agent which should run every 10 minutes 2. Created a program document with a compact task running or run the compact -c manually. 3. When the agent want to start running while the compact task is running, there is an error message in console domino: “AMgr: Unable to load agent document for ‘Test1’ in ‘mail\ykioso.nsf’ :Database is being compacted; compact must finish before use.” “Database compactor process shutdown” Local fix: Restart the agent manager or set compact task to run just before amgr cache is reset. Problem summary: A programming error was found and will be corrected in a future release. Problem conclusion: A programming error was found and will be corrected in a future release. Comments: This APAR is associated with SPR# KMUR63DF3V. SPR# KMUR63DF3V Fix introduces an ini DEBUG_AMGR_ENABLE_RETRY_ON_COMPACT to allow an agent to run on a time interval once database compact is complete. Previously when a database was being compacted and an attempt was made to load a scheduled agent it would fail and the agent would be marked to not run again unless the user restarted the agent manager or the agent cache refreshed. This fix introduces a notes.ini variable to allow the agent in question to be retried on it’s subsequent time interval. lees meer…

Lees verder ...

IBM Notes/Domino 10.0.1 is uit

IBM Notes/Domino 10.0.1 is uit. Wat is er (o.a.) nieuw in deze versie: IBM Notes for Windows™ Panagenda MarvelClient Essentials IBM Notes 10.0.1 for macOS Supporting Mojave (with embedded IBM Java™ binaries) IBM Domino AppDev Pack 1.0 IBM Domino AppDev Pack Identity and Access Management Service with OAuth — Preview IBM Verse® On-Premises 1.0.6 https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/8/897/ENUS218-538/index.html&request_locale=en lees meer…

Lees verder ...

DEBUG_REPL_TOLERATE_ERRORS

Wanneer in een cluster problemen zijn ontstaan met DOAS kan het voorkomen dat een postbus (of andere database) bijlagen die opgeslagen zijn als NLO bestanden niet meer kan vinden. Dat probleem zal opgelost moeten worden door de NLO bestanden uit een back-up terug te zetten. Tot die tijd zal het repliceren van de database niet mogelijk zijn omdat de replicator foutmeldingen geeft als 05-01-2018 10:36:02 The database E:\Domino\data\mail\xxxx.nsf attempted to access a missing file: F:\DAOS\0148\71B8CB2B87D602E3F83AA3897F5D8A23E3979A020001E900.nlo: File does not exist Bij meer dan vier fouten staakt de replicator het repliceren en daardoor zal de database niet meer gerepliceert worden tot de fouten zijn opgelost. Om replicatie toch af te dwingen kan de beheerder het commando SET CONFIG DEBUG_REPL_TOLERATE_ERRORS=103 op de server console uitvoeren. Op het internet vond ik eerder de waarde 2C8, maar die werkt in dit geval niet. De waardes die ingevuld kunnen worden zijn de (hex) foutcodes die ook op de server console terug komen. Repliceren gaat vervolgens wel, ondanks de foutmeldingen die voorbij komen. Documenten met fouten worden overgeslagen, dus de fout is hiermee niet opgelost! Workaround Wanneer het niet mogelijk is om de NLO bestanden te herstellen zijn er twee opties: Geef het commando ‘load fixup -j -d mail\xxxx.nsf’ op de server console om de documenten met missende  NLO bestanden te verwijderen. Documenten (berichten) zijn daarmee weg, maar er wordt geen deletion stub aangemaakt. Daardoor kan het document uit een andere replica van de database opnieuw gerepliceerd worden. Moet er natuurlijk wel een goede replica zijn! Lege NLO bestanden aanmaken. Natuurlijk is ook dat geen oplossing, want de bijlagen zijn weg, echter de replicatie taak “ziet” de bestanden staan en gaat daardoor zonder foutmelding de documenten repliceren. Om optie twee te automatiseren zou een script gemaakt kunnen worden om met de lijst van missende NLO bestanden lege bestanden aan te maken. Een lijst met missende NLO bestanden kan verkregen worden door het volgende commando: tell daosmgr listnlo -o mymailobjects.txt MISSING mymail.nsf. Vervolgens kan deze lijst gebruikt worden voor het aanmaken van lege NLO bestanden.   lees meer…

Lees verder ...