Sehr gerne
Wenn man nicht selbst schon solcherlei Datenverbindungen / Interfaces programmiert hat, ist es mit Sicherheit schwer, die Problemstellungen nachzuvollziehen, die sich dabei auftun. Man denkt sich: das ist wie ein Stromkabel, einmal eingesteckt muss das blöde Ding doch einfach funktionieren
M.E. hat Herr Knöpfel hier beste Arbeit geleistet, dadurch, dass man eben abgestimmt auf die eigenen Daten-Abos und Bedürfnisse, die Erkennung des "Datenunterbruchs" sowie die Reaktion darauf (bis hin, was dann als erstes nachgeladen wird) selbst beeinflussen kann.
Dafür mögen die nötigen Optionen verwirrend sein; am Ende finde ich es aber besser, dass sich "mein" Datensauger RTT/IB nicht selber Datenabbruchs-Szenarien zusammen-phantasiert, sondern dass ich das Ding genau einstellen - und wenn sich die Rahmenbedingungen ändern - neu justieren kann, ohne den Hersteller bemühen zu müssen!
Und dadurch, dass das Problem über einen Neu-Start gelöst wurde, schützt einem RTT/IB auch davor, dass sich der Unterbruch einmal durch einen Windows- oder Programmfehler ergeben könnte, bei dem sich eine solch wichtige Software im eigenen Speicher-Dschungel "verirrt". Diese Lösung mag auf den ersten Blick zusätzlich verwirren. Aber es ist der best-mögliche "Fluchtplan" aus allen Situationen, egal welcher Ursache!
=> Auf Millionen-schweren Mainframes werden wichtige Adresspaces, Tasks und Daemons bis heute ins "Internet-Zeitalter" hinein auf genau dieser Weise programmiert. Es geht um grösst- mögliche Sicherheit, die aus einem Programm selbst heraus möglich ist (also solange nicht noch zusätzliche Monitoring- und Automationsprogramme dazukommen, um die Sicherheit Richtung High-Availability weiter zu erhöhen).
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Bernd« (4. März 2015, 22:30)