Neueste Beiträge

Seiten: [1] 2 3 ... 10
1
Hallo,

ich möchte hier einen Vorfall und dessen Lösung beschreiben, wie er letztens bei unserem Domino-Server betrieben auf einer IBM i (vorm. AS400) aufgetreten ist.

Laut Log beendete der Server, Version 12.0.2 FP 5 seine Tätigkeit um 20.28, als gerade das tägliche DBMT lief. Zu der Zeit lief auch die Sicherung über das IBM Sicherungstool BRMS. Diese Sicherung wurde infolge dessen auch nicht beendet.

Am nächsten Tag um 6:39 wurde der Server manuell wieder gestartet und lief nach ca. 5 Minuten auf den Fehler:
comp = 11, fnc = 82, tracePt = 10200002049 Unexpected internal error returned to logger: 0x20492010
 Thread=[338165:19190:00002-00000003]
PANIC: Unexpected internal error returned to logger: 0x20492010


Es wurde noch eine Mail-DB, die gerade recovered wurde genannt. Dann Stillstand.
Als erstes wurde die genannte Mail-DB weggesichert und entfernt, da wir schon einmal ein Problem mit einer defekten und sehr großen Datenbank hatten (da hat sich einer in kurzen Intervallen Videos von mehreren Überwachungskameras schicken lassen und die Mail-DB wuchs schnell auf über 120GB an).
Das hat aber keine Abhilfe geschaffen. Eine Google-Suche empfahl, das Transaction-Logging zu deaktivieren (Eintrag in notes.ini TransLog_Status=1 -> 0), was jedoch dazu führte, dass der Domino-Server mit dem DAOS nicht mehr umgehen konnte oder wollte. (The DAOS catalog cannot be updated.: Transactional Logging must be enabled for this function.)

Daraufhin wurde das Transaction-Logging wieder aktiviert und die Fehlermeldung kam, wie zu erwarten war, abermals.
Beim Durchschauen vom console.log fiel uns aber auf, dass es offenbar wirklich ein Problem mit dem Logging gab. In einem Forumsbeitrag wurde für einen Windows-Server geraten, die Rechte zu prüfen und ggf. den Inhalt des ganzen Logging-Verzeichnisses zu löschen.
Nach dem wir die Dateien in /Data/TransLog gesichert hatten, wurde das Directory geleert und der Server neu gestartet.
Dieser quitierte die Aktion mit einer Meldung (PANIC: About to reformat logs and Dirty Databases found, restart again to continue format.) und startete sich neu.
Danach wurde das Transaction-Log neu erstellt und der Recovery-Manager werkelte den Rest des Tages (ab ca. 10:00 bis 18:00) an den Datenbanken.
Aber der Server startete wieder und konnte langsam, nach dem die Mail-DBs recovered wurden wieder den Betrieb aufnehmen.
Am Abend wurde der Server nochmal durchgestartet und es gab keine Probleme mehr.

Wichtig für uns war, dass der Server wieder funktionierte, da tagsdarauf das Update auf Domino 14.5 mit FP1 anstand.
Diess Update wurde mittlerweile erfolgreich durchgeführt.

Ich hoffe, dass dieser Bericht nützlich ist.
Günter Bretterebner
2
Hi Tode,

Danke Dir für Deine Antwort, das hatte ich schon probiert, leider ohne Erfolg. Habe eine komplett leere Gruppe erstellt und diese hinterlegt, gleiches Verhalten.   : /
3
Danke. eXTRa hatte ich zwar gesehen, dachte aber es ist eine 3rd Party Geschichte. Dann gucke ich da mal rein.

Seltsam ist, dass ich beim DRV zwar ein Schema zu dem XML der gesendeten Daten finde, nichts aber zudem Antwortdateien.

Fun Fact. Im XSD gibt es eine Regex für die Validierung der Sozialversicherungsnummer. Lt. DRV kann das Datum z.B. auch der 99.02.99 sein. 🫢
4
Hallo Ulrich

Soweit ich weiß, basiert das XML-Schema für die Leistungsklassifikation für die berufliche Rehabilitation (LBR) auf dem sogenannten "eXTRa-Standard" (Dezember 2015).

Auf die Schnelle konnte ich nur die Schnittstellenspezifikationen finden: https://www.extra-standard.de/verfahren-nutzen/registrierte-verfahren/standard-titel

Darin ist auch ein Verfahren beschrieben, um Testdaten über einen Web-Service abzufragen (Abschnitt 2.6). Dort werden auch alle Antwort-Codes aufgeführt, die von der DRV im Fehler- bzw. Warnungsfall zurückgeschickt werden.

Hoffentlich hilft Dir das weiter.

Beste Grüße aus Stuttgart,
Pantelis
5
Entwicklung / Brauche mal eure Hilfe beim Thema Deutsche Rentenversicherung und LBR
« Letzter Beitrag von eknori am 19.11.25 - 07:44:03  »
Ich bearbeite gerade für einen Kunden das Thema LBR und hänge da etwas fest. Evtl. ist ja hier jemand von der Deutschen Rentenversicherung anwesend und kann helfen.
Die Mails von der DRV kann ich leider nicht lesen, weil die konsequent verschlüsselt senden, und mir der Schlüssel fehlt. Daher gestaltet sich die Kommunikation etwas problematisch.

Worum geht es:

Über eine Notes Anwendung übermittelt ein Kunde XML Daten mit entsprechenden LBR Codes an die DRV. Das scheint zu funktionieren ( zumindest teilweise ).
Die DRV validiert die Daten und stellt ihrerseits XML Daten mit den Responsecodes und ggfs. erkannten Fehlern zur Verfügung. Diese können bei der DRV heruntergeladen werden.

Soweit das, was mir bekannt ist, und ich im Code sehen kann. Dummerweise habe ich keinen Zugriff auf den Server, der die Daten sendet und die Antworten empfängt. Daher kann ich nicht beurteilen, ob hier alles OK ist.

Hier ist der Kunde bereits dabei, mir die notwendigen Berechtigungen zu beschaffen.

In der Zwischenzeit wollte ich schon einmal Code zur Verarbeitung der AntwortFiles (XML) erstellen. Leider habe ich aber keine Beispiele, und finde auch sonst nirgendwo brauchbare Informationen zum Aufbau dieser Dateien. Ist das überhaupt noch XML oder kommt das mitlerweile als JSON zurück? who knows ?? Sehr viele Unbekannte in der Rechnung ...

Daher meine Fragen und Bitte.

Schickt irgendwer LBR Meldungen an die DRV? Kann auch über ein anderes Tool als Notes sein.
Kann mir jemand anonymisierte Daten ( Antwortfiles) zur Verfügung stellen?
Weiss jemand, ob es analog zur DATEV ein Portal gibt, wo man den Prozess in einer Sandbox testen kann? Wenn ja, welche Klimmzüge muss ich machen, um da ran zu kommen?

Und nein, der Kunde kann die Fragen nicht beantworten, weil auch er lediglich verschlüsselte Mails erhält und diese nicht entschlüsseln kann. Eine Kontaktaufnahme per Telefon ist bei der DRV leider nahezu unmöglich.

6
Hi Leute,

auf alle in 2024 geplanten HCL Domino Online-Schulungen gibt es jetzt 20% Rabatt!

Beste Grüße,
Manfred
7
Offtopic / Antw:Momentum verpasst
« Letzter Beitrag von jBubbleBoy am 11.11.25 - 10:35:49  »
Aus meinem Bekanntenkreis habe ich schon so etwas gehört: Früher gab’s bis zu 200 Bewerber, heute sind es vielleicht noch zwei oder drei. Und die Wünsche der Generation Z im IT-Bereich würde ich wie folgt zusammenfassen: Etwas mit KI, im Homeoffice und am liebsten eine 4-Tage-Woche, wegen Work-Life-Balance (natürlich gilt das nicht für alle). Tatsache ist, dass KI derzeit die treibende Kraft in der Entwicklung ist. Daher kann ich gut nachvollziehen, dass HCL Notes/Domino KI-Funktionen in sein Produkt integriert – auch wenn ich persönlich den praktischen Nutzen eher gering einschätze, aber man muss damit werben. Der Fachkräftemangel führt zudem dazu, dass individuelle Lösungen zunehmend in den Hintergrund treten und stattdessen verstärkt auf Standardlösungen in Cloud-Systemen gesetzt wird.

In Spiegel Online erschien ein schöner Artikel mit dem Titel „Ein Job fürs Leben, das ist vorbei“. Diese Artikel passt auch gut in die IT-Welt, denn die Entwicklungszyklen werden immer kürzer und alles verändert sich rasant. Und Ehrlich gesagt ist der Einstieg in neue Technologien mithilfe von KI noch nie so einfach wie heute, unruhig werde ich erst wenn tatsächlich AGI (menschenähnliche Intelligenz) entwickelt wird. Doch das ist Zukunftsmusik, denn in die Zukunft blicken oder gar vorherzusagen, ist schlicht unmöglich und das war vor 20 Jahren nicht anders ::)
8
Administration & Userprobleme / OIDC Fehlermeldung in idpcat.nsf
« Letzter Beitrag von shiraz am 10.11.25 - 16:52:13  »
Hallo,

hat jemand SAML oder OIDC auf Domino 14.5 mit O365 zum Laufen gebracht?
Sagt Euch diese Fehlermeldung was?


9
Offtopic / Antw:Momentum verpasst
« Letzter Beitrag von heini_schwammerl am 08.11.25 - 13:48:25  »
Man kann den Notes Client verteufeln und es gibt auch gute Gründe das zu tun, aber ohne ihn wäre das Produkt aus meiner Sicht schon längst komplett verstorben.

Man hat ja nie versucht den klassischen Client aufzuhübschen und damit das übergestülpte Eclipse wieder redundant zu machen. Das Ergebnis wäre vielleicht ein deutlich verschlankter Notes Client gewesen, der dann etwas aufgehübscht als Basis für Neues hätte dienen können.

So kompliziert sind die Designelemente nun auch nicht dass man die auf Basis von HTML / CSS, Javascript und mit ein wenig Lotusscript als proprietärer Zombie nicht auf Low Code Komponenten hätte umstellen können. Dann noch ein ordentliches Handling von Richtext / Mime und das hätte aus meiner Sicht schon etwas werden können.
 
Hat man dann erstmal alle Komponenten browserfähig gäbe es auch einen sanften Umstieg weg vom dicken Client hin zu einer reinen Web Plattform. Versucht hat man das ja, indem man den Classic Client in den Browser verfrachtet hat, nur behält dieser dann halt sämtliche Limitierungen des klassischen Clients bei. Und der Versuch mit dem Restyler war dann aus meiner Sicht auch eher zu kurz gedacht.

Letztendlich muss jeder selber entscheiden wie er mit der Plattform weitermachen wird. Von HCL erwarte ich diesbezüglich nicht viel, aber wenn man ehrlich ist gab es die letzten 18 Jahre schon keinen Rückenwind mehr.

Alles jammern hilft nichts. Die letzten Änderungen am Lizenzmodell wie die Komplettumstellung auf ein Mietmodell wird die Entscheidung für oder gegen die Plattform vielleicht noch einmal beschleunigen.
Aus meiner Sicht macht HCL hier einen strategischen Fehler, pushed allerdings kurzfristig vielleicht noch einmal die Umsätze. Bei uns sind ja damit auch die günstigeren "Nur Mai Und Kalender" Lizenzen weggefallen.
Grüße

Henning

10
Suuuper! 1000 Dank für die schnelle Hilfe!!!
count=-1 war "the missing piece" und ja, das tut! Sehr cool.

Den überfüssigen "Rest" (wie die Pfeile etc) kriege ich mit dem PHP-requester locker ausgefiltert.

Danke auch für den 2. Link ... allerdings scheint V7 noch einiges nicht unterstützt zu haben, z.B. ReadViewEntries, denn das alles in XML oder JSON zu kriegen wär' natürlich schon toll und würde die Daten-Extraktion erleichtern.
Seiten: [1] 2 3 ... 10
Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz