INECO

Intranet & Network Consultancy

Adres:

Mooieweg 184
6836AL Arnhem
Nederland

E-Mail:

info@ineco.nl

Homepage:

ineco.nl

IBAN:

NL61RABO0128076690

BTW-ID.:

NL001860090B08

KvK:

09093129

Contactpersoon:

Marcel Rothuizen

Telefoon:

+31653353140

Tag: Lotus Notes Specialist

  • Over mij

    Over mij

    INECO staat voor Intranet & Network Consultancy. Ik ben Marcel Rothuizen en heb INECO in 1996 opgericht in Arnhem.

    ICT loopt als een rode draad door mijn loopbaan. HCL Notes en HCL Domino zijn daarbij vanaf het begin een belangrijk onderdeel van mijn werk geweest. In de loop der jaren heb ik honderden applicaties ontwikkeld, beheerd en verbeterd en met uiteenlopende Domino-omgevingen gewerkt

    HCL Notes en HCL Domino zijn inmiddels al een paar keer van naam veranderd: van Lotus Notes en Lotus Domino naar IBM Notes en IBM Domino en uiteindelijk naar HCL Notes en HCL Domino. De naam mag dan veranderen, mijn kennis van het platform is gebleven.

    Als het iets met HCL Notes of Domino te maken heeft, is de kans groot dat ik je kan helpen.

    Naast mijn specialistische kennis van HCL Notes en HCL Domino heb ik brede ervaring met andere ICT- en ontwikkeltechnologieën, waaronder C#, Visual Basic, PHP, CSS, HTML, Java, JavaScript en Python.

    Ook op het gebied van Agile en Scrum heb ik ruime ervaring. Ik ben gecertificeerd als Professional Scrum Master II (PSM II) en Professional Scrum Product Owner I (PSPO I).

    Mijn uitgangspunt is eenvoudig: goede kwaliteit leveren voor een redelijk bedrag, zonder onnodige fratsen of poeha.

    Meer weten over mijn ervaring, expertise en werkzaamheden? Bekijk dan mijn cv van Marcel Rothuizen – ICT Consultant / HCL Domino Consultant.

    Zoek je een Lotus Notes-ontwikkelaar, IBM Notes-ontwikkelaar, HCL Notes-ontwikkelaar of HCL Domino-beheerder?
    Dan ben je hier nog steeds aan het juiste adres.

    Lotus mag dan al jaren uit de naam verdwenen zijn, de applicaties en kennis zijn dat zeker niet.

    Waarom de naam INECO?

    De naam INECO ontstond in 1995, toen het begrip intranet sterk in opkomst was.

    Veel van mijn werkzaamheden bestonden in die tijd uit het opzetten van intranetten, internetverbindingen en netwerken voor bedrijven. Daarom ontstond de naam INECO, als samenvoeging van de eerste letters van INtranet, NEtwork en COnsultancy.

    INECO bestaat inmiddels al ruim 30 jaar, maar de naam is gebleven.

    De merknaam INECO en het INECO-logo zijn gedeponeerd onder nummer 0966575 bij het Benelux-Bureau voor de Intellectuele Eigendom.

    HCL Software

    INECO is HCL Software Reseller. Het verkopen van software en licenties is echter niet mijn belangrijkste activiteit.

    Ik adviseer klanten waar nodig over de aanschaf en implementatie van HCL Software en kan helpen met de ontwikkeling, inrichting en het beheer van HCL Notes- en HCL Domino-omgevingen.

    De focus ligt daarbij op wat voor jouw organisatie daadwerkelijk nodig is, niet op het verkopen van zoveel mogelijk licenties.

    Documenten

    De algemene voorwaarden van INECO kunt u hier vinden:
    Algemene voorwaarden INECO (2026-1).

    Meer over mijn professionele achtergrond en actuele activiteiten vind je op mijn LinkedIn-profiel:
    https://www.linkedin.com/in/mrothuizen/

    , , , , , , , , , , , , , , , ,

  • Volgnummer probleempje in IBM Notes

    Een klant had een raar probleem. Een database waar documenten een volgnummer kregen bij het aanmaken, bleek ineens dubbele nummers te krijgen.
    Waar de nummering eerder nog iets in de 18 miljoen was, begon het ineens weer met 16.877.210. En dat herhaalde zich een paar keer.
    Na inspectie van de code bleek de teller bijgehouden te worden in een document. Niet ongebruikelijk, de code klopte ook, en werkte nog steeds goed.
    Maar deze database had ook een replica. Ondanks dat de teller slechts in een database werd gebruikt leek Notes bij het repliceren toch telkens overtuigd dat de replica met het oudere teller document nieuwer was dan de bron database, die wel degelijk nieuwer was.

    Na controle van het replica id hadden we het over het volgnummer dat Notes gebruikt om samen met de datum te bepalen welk document in een replica nieuwer is.
    Een collega Notes specialist die goed met cijfers is zag direct wat het was: de nummering in het volgnummer (sequence number) kan bestaan uit maximaal FFFFFF. Dit is gelijk aan 16.777.215, en daarna begint het tellen weer bij 0.

    In ons geval was het nummer in de originele database dus over de FFFFFF heen gegaan, en had daarmee een lager nummer gekregen dan het replica document, waardoor telkens bij het repliceren het oudere document weer terug werd gerepliceerd waardoor ook de teller voor de documenten weer lager was.

    Door een nieuw teller document aan te maken was het probleem weer opgelost, maar dit was wel de eerste keer dat ik dit zag in een Notes database.

    Leuk die theorie, maar waarom staat het volgnummer bij een nieuw document dan op 00000001 (8 posities), wat in mijn ogen aangeeft dat het tot FFFFFFFF (4.294.967.295) kan gaan en niet tot FFFFFF?
    Dat antwoord kan ik helaas (nog) niet geven, maar een korte test met een code loopje gaf uitsluitsel, na 00FFFFFF begon het nummer weer met 00000001. Of dit een bug is of een bewuste keuze durf ik niet te zeggen.

    Even wat uitleg over het sequence number:

    Als database A een document bevat met een bepaalde UNID en database B bevat een document met het zelfde UNID, zal de replicator concluderen dat deze twee documenten replica kopieën van elkaar zijn.
    In dat geval, gaat de replicator verder met het volgnummer en sequentietijd van de twee documenten te onderzoeken.
    Als het volgnummer en de tijd van aanpassing het zelfde zijn voor beide documenten , dan is er volgens de replicator geen actie vereist omdat de documenten gelijk zijn aan elkaar.
    Aan de andere kant, als een van beide, het volgnummer of de tijd van aanpassing, of beide, verschillen tussen de twee documenten, dan moet de replicator beslissen welke recenter is en het oudere document actualiseren met de inhoud van de meest recente versie.

    Als een document is bijgewerkt maar het andere document niet, wordt het sequentienummer van het eerste document groter dan die van het andere document.
    De replicator behandelt deze zaak door het overschrijven van het andere document met de eerste, waardoor de twee databases weer synchroon zijn.

    Universal Note ID (UNID)=
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT00096E86

    Sequence Time =
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT00096E86

    Sequence Number =
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT00096E86

    De overige regels zijn:
    Originator ID (OID) =
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT00096E86

    OID.File =
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT00096E86

    OID.Note =
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT00096E86

    Global Note ID (GNID) =
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT00096E86

    Database ID (GNID.File) =
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT<00096E86

    Note ID (GNID.NoteID) =
    OF162EE8B9:66439054
    ON2BAE1447:A7A43567
    SDC1257F8F:0067AAFF-SN00000001
    DBC1257738:002ED95E
    NT00096E86

    , , , , , ,
↑