Beiträge von CarstenH

Definiere bitte mal "Schließen":

- Schließen des letzten aktiven Fensters der DB?
- Schließen aller derzeit aktiven Fenster der DB?
- Schließen des Handle im Script wenn sie im gleichen Script (z.B. Agent) geöffnet wurde?

Wurde der Server inclusive Javaconsole gestartet? Dann könnte eine Datei namens .jsc_lock der Grund sein. Diese wird beim Crash nicht gelöscht und verhindert den Serverstart.

Ansonsten sind meist hängende Dienste nach dem Crash der Grund die erst durch NSD oder einen Serverneustart beendet werden.

Da die gesamte Mail via Agent erzeugt wird:

- zum Test mal eine Mail per NC an den DWA-User schicken (bitte mit korrekten Usern, also Arbeitsumgebung sollte auch zur Mail-DB und zum OPwner passen) und prüfen ob der DWA dann die Quittung schickt
- Vielleicht weiterhin mal die Zustellbestätigung statt der Empfangsbestätigung mitschicken und kontrollieren
- Sind bei der Agent-Mail wirklich alle Felder korrekt gefüllt? Steht z.B. im Absender und Empfänger die Domäne mit drin? Eine Mail ohne Domänenangaben ist ungültig...auch wenn der Router sie normalerweise weiterleitet weil er annimmt daß es die Eigene ist.

Das Problem hatte ich bei einer R4->R5 Umstellung eines Kunden anfangs auch.

Ursache: R4 ist die letzte Version, die noch als 16-bit Version für das damalige Windows 3.x geschrieben wurde. Unter Windows 3.x hatte das Systemdatum noch kein "echtes" Sommerzeitflag und auch die Windows-Zeitzone war eher eine DOS-basierte Krücke. R4 war ein Multiplattformclient (OS/2, Mac, Win, Unix) und von daher mußte die Zeitzone stabil über alle Versionen sein auch wenn das Betriebssystem das nicht konnte. Das hatte den Effekt, das sowohl Notes als auch das System eine Zeitzoneneinstellung hatten. Änderte man im Notes die Zeitzone dann änderte Notes das für Windows mit. Genauso verhält es sich bei R4 mit der Sommerzeit. Diese ist wie eine zusätzliche Zeitzone.

Wenn man in Notes unter R4 die Sommerzeit aktivierte, wurde im Windows die Zeit vorgestellt. Hatte man die Sommerzeit aber zentral für alle User schon eingestellt wollten viele Firmen nicht dem jeweiligen Windows (und damit dem User) das überlassen sondern es wurden simpel alle Uhren zum Stichtag nach vorn gedreht (und im Winter retour). Das heißt, weder Notes noch Windows liefen wirklich auf Mitteleuropäischer Sommerzeit (CEDT) sondern weiterhin auf Mitteleuropäischer Zeit (CET).

Seit R5 (32bit und Windows 95 bis XP) gibt es die vielen Plattformen nicht mehr und die Betriebssystemhersteller haben auch dazugelernt, die 32bit-Systeme haben bei jeder Zeit auch die Zeitzone hinterlegt. Es ist jetzt also sinngemäß nicht simpel "16:51" sondern "16:51 CEDT".

So, wer bis hierher alles verstanden hat ahnt was kommt. Notes ist seit jeher international ausgelegt, d.h. wenn ich eine Einladung aus London bekomme, die ein Londoner angenommen für morgen 08:00 GMT vor Ort geplant hat, dann zeigt mein Client mir diese Zeit nicht als GMT im Kalender an sondern er zeigt es in meiner Zeitzone, aus 8:00 GMT wird 10:00 CEDT. Dazu steht in jedem Datumsfeld die Zeitzone. Angezeigt wird diese Zeitzone jedoch nur, wenn sich die ursprüngliche unterscheidet.

Da eure R4-Clients anscheinend mit CET gearbeitet haben, eure jetzigen Windowsxxx aber CEDT aktiv haben erkennt Notes das und rechnet für die Bildschirmanzeige alle Zeiten um. Das ist per Design so gewollt und nicht abstellbar. Genaugenommen die Strafe dafür daß man unter R4 die Zeitzonen falsch hatte

Wie kommt man aus dem Dilemma?

Nicht so einfach. Problem ist nämlich, daß man jetzt nicht simpel alle Zeiten per Agent -1 oder +1 machen kann oder die Zeitzone pro Feld ändert. Vielmehr ist ja seit der Umstellung schon gearbeitet worden und damit existieren jetzt korrekte (die nach der Umstellung) und falsche Zeiten (aus R4). Ich habe für den damaligen Kunden einen relativ aufwendigen Agenten geschrieben, der anhand bestimmter Kriterien die falschen von den echten Zeiten herausgesucht und in den Kalendern korrigiert hat. Das Programmieren und Testen hatte etliche Tücken ... aber last but not least haben wirs geschafft. Ich habe damals sehr viel über bestimmte Felder und Einstellungen und deren Zusammenspiel in Client/Server/Betriebssystem gelernt.

Wenn das ReplyTo überhaupt existiert ist das schonmal kein gutes Zeichen, da dann Absender und Antwortadresse sich unterscheiden (und einige Mailclients, darunter auch einige DWA/IWA Versionen) sich nicht korrekt entscheiden können an welche Adresse nun das ReturnReceipt gesendet werden soll.

Hast du schonmal per Mailverfolgung bzw. im Routerlog geschaut ob nicht doch eine Mail zum Zeitpunkt des Öffnens generiert wurde? Man kann auch notfalls den Router kurz stoppen, die Mail im DWA öffnen und dann in den mail.box(en) des Servers schauen ob die Empfangsbestätigung drin liegt. Wenn sich der Feldwert ändert dann wurde auch m.E. auch eine Mail generiert die ja irgendwo auftauchen muß. Eventuell sind auch in einer der beteiligten Mailboxen Regeln hinterlegt denen die Empfangsbestätigung zum Opfer fällt.

@Elements dürfte in deinem Fall das @Count ersetzen können.

Ich hab auch nix andres behauptet *g* Lies simpel nochmal was ich geschrieben hab ;=)

Welche Serverversion (oder genauer: welches DWA Mail-Template und zugehöriges Form-Template) wird verwendet?

Habs grad mal auf einem 5er und 6er Server getestet und funktionierte problemlos. Schau mal bitte nach den Owner-Feldern der beteiligten Mail-DB's, dem Absender und ggf. ReplyTo. Wenns möglich ist schau mit Hilfe der Mailverfolgung ob die Empfangsbestätigung nicht vielleicht doch versendet wurde, nur nicht dahin wo du sie erwartest.

Zitat

Nutzt Du SSL ? Wenn ja solltest Du Single oder Multi-Auth. benutzen, da Du dann das Kennwort schon verschlüsselt übertragen lassen kannst. Das geht bei Disabled nicht.

Ist so leider nicht korrekt, selbstverständlich kann man für die Authentifizierung via "Basic Authentication" (so nennt man die herkömmliche Form wenn Session Authentication disabled ist) SSL verwenden. Man muß lediglich dafür sorgen, daß die URL für die die Authentifizierung gewünscht wird, bereits auf https verweist ;=)

Eingebettete Teilmasken werden weder von RenderTo... noch von ComputeWithForm berücksichtigt. Im Falle von ComputeWithForm konnte ich mir so helfen, daß ich in das Formfeld einfach nacheinander alle TM-Namen eingetragen und jeweils ComputeWithForm aufgerufen habe und die eigentliche Maske erst zum Schluß wieder eingetragen und natürlich nochmals CWF aufgerufen habe. Danach waren alle Felder aller TM und der Maske korrekt berechnet. Bei RenderToRT... könnte man ggf. ähnlich verfahren, nur wird das Zusammenbasteln des Gesamtergebnisses bedeutend aufwendiger. Insofern würde ich wahrscheinlich besser auf die Verwendung von eingebetteten Elementen wie TM verzichten.

Entweder man legt das Feld per Scipt an oder man legt ein Dummyfeld vom Typ Author mit an das dann vom Formelagenten als Kopiervorlage für das neue Feld verwendet wird.

Bei Befüllen ist darauf zu achten, daß Notes-Namen immer in kanonischer Form in das Feld eingetragen werden (z.B. CN=Hans Meiser/OU=Notes/O=Organisation/C=DE), nicht-kanonische Inhalte werden als Text und damit als Gruppen interpretiert, die dann sicher nicht existieren.

Die Dominokomponente verwendet diese Einstellung wenn Servlets über die Java-Servlet-API-Schnittstelle "HttpSession" angeprochen werden. Nach Ablauf des Timeouts wird die Session (also die offengehaltene Verbindung) beendet. Das hat nichts mit iNotes oder der Benutzeranmeldung (Sitzungsauthentifizierung) zu tun.

Wenn eine defekte Mail-DB der Grund ist dann taucht das Problem aber nicht ausschließlich beim Router auf. Anzeichen dafür wären dann abwechselnde Crashs in bestimmten Abständen zum Serverstart von Tasks wie Indexer (update), Scheduler (sched), Agentmanager (amgr) oder Compact (und weitere die auf die DB zugreifen).

Gegenfrage: warum MUSS es eine Umgebungsvariable sein?

Bitte sag mir daß ich mich verlesen hab...JEDER darf jetzt ALLE Dokumente im Directory ändern??? Laßt ihr nachts eure Haustür offen stehen und die Scheiben in den Autos unten? Dann hätte ich gerne mal die Adresse...

Spaß beseite! Das maximale Recht für Nutzer im DD (names) sollte auf Autor gestellt sein. Weiterhin sollte dazu dieser Eintrag mit einer Restriktion für alle belegt sein (also z.B. */Notes/DE = Author) und nicht -Default- und AUF KEINEN FALL Anonymous!!! Da kann jetzt JEDER ohne daß es jemals nachvollziehbar wäre per Browser den gesamten Server so lahmlegen daß er ohne Backup nie mehr hochkommt oder sich einfach alle Rechte auf ALLES holen! Mach das bitte rückgängig!

Damit Paßwortwechsel via Web funktioniert kontrolliere folgendes:
- Benutzer hat Author-Rechte im DD
- Benutzer ist mind. Editor in seiner Mail-DB
- Benutzer ist Owner seiner Mail-DB (Profildokument unter Vorgaben)
- Benutzer ist Owner seines Personendokuments im DD
- ACL des DD: Maximaler Internet Names- & Kennwortzugriff auf Author (oder maximal Editor, falls Webadmin benutzt wird)
- ACL der Mail-DB : Maximaler Internet Names- & Kennwortzugriff auf Editor
- In seltenen Fällen ist es notwendig, dem Nutzer in seiner Mail-DB das Recht auf Designer oder Manager zu setzen (aber zuvor mit Editor testen, das andre ist letzte Wahl)

Richtextfelder sind bei meinen bisherigen Anwendungen insofern nie ein Problem gewesen weil man sie einfach nicht braucht wenn die gesamte Formatierung im Word/Acrobat vorgenommen wird.

Die Variante über das UI diese Felder auszulesen würde bei mir ebenfalls ausfallen, da meist eine Automatisierung (z.B. über Distiller etc.) auf einem Server gwünscht war (Massenausdrucke) und im Backend keine UI-Befehle funktionieren. Auch ist Copy/Paste via Frontend nicht so günstig weil z.B. bereits eine neue Mail, die während des Vorgangs eingeht und eine Meldung hochpoppen läßt zum massiven Problem werden kann. Kann man zwar auch unterdrücken aber wollts nur erwähnt haben ;=)

ich meinte jegliche replikation allgemein und das schließt cluster mit ein. wenn die datenbanken nirgendwo eine weitere replik besitzen dann sollte man mal testen ob das löschen sämtlicher deletionstubs eine besserung bringt, weil diese zumindest in den replizierten umgebungen bei profildokumenten ein hauptproblem darstellen. ob und was an den profildokumenten nicht stimmt läßt sich ggf. auch feststellen wenn man sich diese dokumente mal genauer anschaut (notespeek aus der sandbox eignet sich dazu).

Nun...es gibt kein mir bekanntes Buch "Agenten für Einsteiger" da der kalte Krieg schon länger her ist ;=) Scherz :=)

Also ich würde an deiner Stelle entweder jemanden beauftragen das für dich zu übernehmen oder, wie an anderer Stelle im Forum schonmal empfohlen wurde, du lädst dir einen von uns Trainern zu einem 1-2 tägigen Workshop über Notesprogrammierung und Agenten ein und als ein Kursbeispiel wird z.B. dieser Agent entwickelt. Dann wäre nicht nur das Problem gelöst sondern den nächsten Agenten kannst dann schon alleine angehen.

Das klingt nach (versehentlich) gelöschten Dokumenten oder Designelementen im Domino Directory. Schau dir diese DB mal genau an, ob noch alle Ansichten und wichtige Dokumente wie Server- und Personendokumente noch da sind.

Der Test DWS ist stark an das entsprechende Seminar angelegt, der Workflowteil beschäftigt sich sehr intensiv mit @Formelsprache insbesondere Mailrouting (@Mailsend...), Maskenereignissen und -eigenschaften (automatisch Mailsenden) und reservierten Feldern (z.B. Mailoptions).
Der Securityteil ist grundsätzlich ähnlich wie bei den Admintests, zusätzlich kommen aber spezielle Dinge wie Feldverschlüsselung und Sicherheitseinstellungen von Designelementen zur Sprache.

Der Test DAA ist leider nicht ganz so eng an das gleichnamige Seminar angelegt, meine Seminarteilnehmer haben sich bei diesem Test meist nur dadurch helfen können, daß ich im Kurs etwas abgewichen und auf spezielle Dinge aus dem Test hingewiesen habe die im eigentlichen Kurs so gar nicht vorkamen. Bei diesem Test gehts querbeet durch nette Sachen wie Volltextindex (z.B. welche Anhangtypen können mit welchen Optionen indiziert werden), (Programmier-)Sprachen (z.B. Designelement XYZ wurde verwendet, in welchen Clients [Notes, Browser] funktioniert es anschließend auch?) bis hin zu Fehlersituationen wo die Ursache erraten werden muß, was ohne echte Praxis meist eher wirklich nur Raten ist...

Der Script-Kurs ist für diese Tests absolut nutzlos, Web Development nur bedingt sinnvoll aber wenigstens nicht komplett nutzlos.

Die Frage nach dem LEI verstehe ich nicht ganz, soweit ich mich erinnere war in keinem Dominotest eine diesbezügliche Frage dabei (und ich habe die Tests sehr oft gesehen, da ich diese auch im Testcenter beaufsichtigt habe).

Die optimale Vorbereitung ist aus meiner Erfahrung von der Auffassungsgabe abhängig. Teilnehmer mit guter und sehr guter Auffassungsgabe sollten den Test gleich im Anschluß an den Kurs machen (Erfolgsquote bei meinen Teilnehmern weit über 90%), bei geringerer Gabe bzw. Null Praxiswissen hat sich eine Pause von 1-2 Tagen danach einmal Kursbuch von vorne nach hinten durchblättern und jede Übung nochmal wiederholen und alles Lesen und anschließend (am selben oder nächsten Tag) den Test machen. Je länger der Kurs zurücklag umsomehr sanken die Erfolgsquoten. Innerhalb 1 Woche ists am sinnvollsten.

Viele von uns Trainern bieten auch spezielle Vorbereitungsworkshops an, die man ggf. mit aktuellen (Problem)Themen erweitern kann.