Folgende Frage hat sich für uns ergeben, Sie schreiben in Ihrem Kommentar:
Abhilfe besteht m. E. darin, dass die SM die Einzeltelegramme entsprechend zusammenstellt (nur DE zu einem EAK, was im Falle EAK relevanter Informationen (Zeitstempel, Intervalldaten, Folgenummern!, ...) ohnehin zwingend ist.
Können Sie uns bitte mitteilen, wo in der TLS diese Vorgehensweise so beschrieben ist?
Sehr geehrter Herr Kniss, ich bedanke mich für die ausführliche Info. Die betroffenen Entwickler werden von mir informiert.
Sehr geehrte Damen und Herren,
bei der Abnahme des IVLS Systems in Frankfurt ist in der KexTLS folgender Effekt aufgetreten:
Der Kunde zieht in einer Streckenstation den Stecker zum Lokalbus ab, so dass das Steuermodul alle DEs als gestört meldet. Diese DE-Fehler werden verteilt über mehrere Langtelegramme über eine KRI an die KexTLS gesendet. Nun kommt es zu dem Effekt, dass nicht immer alle DE-Blöcke von der KexTLS ausgewertet werden.
Es kommt manchmal zu Fehlermeldung der folgenden Art:
Knotennummer:15438994 (60308-146) DE:111 FG:6 Id:1 Typ:1 Länge:2
00000000: 02 0D ..
#5897895534 05.12.2022 10:16:46,310:+0100 (TID:000022) ======================
WARNUNG: KEx-TLS.de.bsvrz.kex.tls.osi7.Eak
DeBlock kann nicht verarbeitet werden, da DE/FG an diesem EAK unbekannt (Osi7-De-Fg: 15438994-111-6 [60308-146-111-6])
EAK: ............................................................................
Eak (Bezeichnung) : IVLS Frankfurt / AQ_KAT_10B EAK8
Knotennummer : 15438994 (Dez) eb9492 (Hex) 60308-146 (LocCode)
Osi2Adresse : 8
Umsetzungsmodul : de.bsvrz.kex.tls.osi7.conversion.EakDefault@1a968a59
Schlüsselwerte (HashKeys): 15438994-199-4
15438994-92-3
15438994-99-6
15438994-93-4
15438994-92-4
........................................................................
De (Bezeichnung) : IVLS Frankfurt / AQ_KAT_10B / FG4-Clusterkanal
De-Typ : DeWzg
De-Kanal-Nummer : 199
Funktionsgruppe : 4
Knotennummer : 15438994 (Dez) eb9492 (Hex) 60308-146 (LocCode)
EA-Kanal : 0
Ist Cluster-Kanal? : Ja
De-Status : ok
Umsetzungsmodul : de.bsvrz.kex.tls.osi7.conversion.he.ivls.ffm.Fg004
ObjektReferenzAufDe: {IvlsFfmKR1.SM20_15438994.EAK8.DeWzg199:DeWzg [0:IVLS Frankfurt / AQ_KAT_10B / FG4-Clusterkanal, ];}
........................................................................
De (Bezeichnung) : IVLS Frankfurt / AQ_KAT_10B / FG3-WZG 1 -- FG3-LED -- 3-zeilig
De-Typ : DeUfd
De-Kanal-Nummer : 92
Funktionsgruppe : 3
Knotennummer : 15438994 (Dez) eb9492 (Hex) 60308-146 (LocCode)
EA-Kanal : 1
Ist Cluster-Kanal? : Nein
De-Status : ok
Umsetzungsmodul : de.bsvrz.kex.tls.osi7.conversion.Fg003Typ061
ObjektReferenzAufDe: {IvlsFfmKR1.SM20_15438994.EAK8.DeUfd92:DeUfd [0:IVLS Frankfurt / AQ_KAT_10B / FG3-WZG 1 -- FG3-LED -- 3-zeilig, ];}
........................................................................
De (Bezeichnung) : IVLS Frankfurt / AQ_KAT_10B / VLT-AQ -- Tür (AQ_KAT_10B)
De-Typ : DeVlt
De-Kanal-Nummer : 99
Funktionsgruppe : 6
Knotennummer : 15438994 (Dez) eb9492 (Hex) 60308-146 (LocCode)
EA-Kanal : 6
Ist Cluster-Kanal? : Nein
De-Status : Fehler
Umsetzungsmodul : de.bsvrz.kex.tls.osi7.conversion.Fg006Typ048
ObjektReferenzAufDe: {IvlsFfmKR1.SM20_15438994.EAK8.DeVlt99:DeVlt [0:IVLS Frankfurt / AQ_KAT_10B / VLT-AQ -- Tür (AQ_KAT_10B), ];}
........................................................................
De (Bezeichnung) : IVLS Frankfurt / AQ_KAT_10B / WZG 2 -- LED (Unten) -- 3-zeilig
De-Typ : DeWzg
De-Kanal-Nummer : 93
Funktionsgruppe : 4
Knotennummer : 15438994 (Dez) eb9492 (Hex) 60308-146 (LocCode)
EA-Kanal : 2
Ist Cluster-Kanal? : Nein
De-Status : ok
Umsetzungsmodul : de.bsvrz.kex.tls.osi7.conversion.he.ivls.ffm.Fg004
ObjektReferenzAufDe: {IvlsFfmKR1.SM20_15438994.EAK8.DeWzg93:DeWzg [0:IVLS Frankfurt / AQ_KAT_10B / WZG 2 -- LED (Unten) -- 3-zeilig, ];}
........................................................................
De (Bezeichnung) : IVLS Frankfurt / AQ_KAT_10B / WZG 1 -- LED (Oben) -- 3-zeilig
De-Typ : DeWzg
De-Kanal-Nummer : 92
Funktionsgruppe : 4
Knotennummer : 15438994 (Dez) eb9492 (Hex) 60308-146 (LocCode)
EA-Kanal : 1
Ist Cluster-Kanal? : Nein
De-Status : ok
Umsetzungsmodul : de.bsvrz.kex.tls.osi7.conversion.he.ivls.ffm.Fg004
ObjektReferenzAufDe: {IvlsFfmKR1.SM20_15438994.EAK8.DeWzg92:DeWzg [0:IVLS Frankfurt / AQ_KAT_10B / WZG 1 -- LED (Oben) -- 3-zeilig, ];}
Die DE-Blöcke die in dieser Ausgabe als OK gekennzeichnet sind, werden scheinbar nicht erkannt und daher nicht ausgewertet.
Die vollständige Fehlermeldung kann dem anhängenden Log-File entnommen werden. Ebenso die Konfiguration der SST (es handelt sich um SST 20, SST_KAT_A, beginnend in Zeile 1004) . Das gesendete Einzeltelegramm wurde mehrfach analysiert und es konnte kein Fehler erkannt werden. Das Komische an der Sache ist, dass wenn ich den Stecker in der SST wieder aufstecke und erneut ziehe, andere DE-Blöcke verworfen werden. Ab und zu werden auch alle DE-Blöcke ausgewertet. Das Ganze ist irgendwie nicht deterministisch.
Ist Ihnen dieser Effekt bekannt und gibt es dafür schon eine Lösung ? Da dieser Effekt die Abnahme verhindert, wäre wir für eine schnelle Antwort dankbar.
Eingesetzte Software:
Danke für die Info, wir werden hier auf die aktuelle Rechteprüfung umsteigen.
Ist der Aufrufparameter -rechtePruefung=alt
gesetzt, sollte das alte Berechtigungskonzept aktiv sein. Leider ist dies jedoch nicht der Fall.
In der beigefügten XML-Datei kb.objekteStUzA2Zugriffsrechte.xml funktionieren unter dem aktuellen DaV so z.B. die Rechte lt. Definition Objekte
nicht mehr.
Der Benutzer kann in diesem Fall also nicht mehr die Betriebsart oder Helligkeit eines AQs einstellen.
Eingesetzte Softwareversionen:
Betriebssystem: SLES 15 SP 4
Docker Basisimage: eclipse-temurin:8
Java:
root@8e1a3f5d577d:/# java -version
openjdk version "1.8.0_322"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
Kernsoftware: 3.18.0, Buildzeitpunkt: 2022-03-09 11:58
Parameter:
Benutzerparameter:
RollenRegionenPaareParameter:
Die Stauverlaufsanalyse verhält sich anders als in Doku beschrieben
Schlagartiges Auflösen des Stauobjektes. Die Länge der Stauobjektes wurde stetig verlängert, bis es Schlagartig aufgelöst wurde.
Erwartet wird ein Abbauen des Stauobjektes.
Laut Doku soll die Länge des Stauobjekt nicht über den nächsten Störfallindikator hinaus verlängert werden.
Dies konnte allerdings im besagten Beispiel beobachtet werden. MAX Länge = 13 km Abstand zum nächsten Störfallindikator ca 5km.
Eingesetzte Softwareversionen:
Für Rückfragen steh Herr Jonas Willert ( jonas.willert(AT)swarco.de ) zur Verfügung.
Trotz entsprechender Einstellung der Archivparameters werden für einige Objekte Datensätze gemäß atg.krSperrzustandBruecke
vom Archiv nicht gesichert.
Live-Daten sind am DaV vorhanden:
Die Archivanfrage wurde wie folgt formuliert:
Ergebnis der Archivanfrage:
Parametrierung Archivierung (atg.archiv)
Parameter ArchivEinstellung (atg.archivEinstellung):
Eingesetzte Archivversion: 5.0.2
Eingesetzte Kernsoftware: 3.18.0
Logfile während der Testabfrage: Archivsystem-0-0.log.txt.zip
Liegt hier das Problem evtl. bei den Archiven, welche Daten für die drei Objekte nachliefern könnten?
Da am DaV des verwendeten Archivs sh.kopp.kr-sh-ars01.archiv1
auch die Live-Daten für alle drei Objekte ankommen hätten wir erwartet, dass diese immer gesichert werden. Zurzeit scheint dies nur bei sh.kopp.krBruecke.wwa.a23.nok
der Fall.
Das CompositeZeitDauer verhält sich im RW 3.5 bei der Initialisierung nicht mehr so wie das Äquivalent aus RW 1.
Nachfolgender Code sorgt beim RW 3.5 dafür, dass nichts im Textfeld der Zeitdauer erscheint:
CompositeZeitDauer zdRw35 = new CompositeZeitDauer(shell, SWT.BORDER, 0l, false);
zdRw35.setZeitDauerInBezugAufAnfangsZeitpunkt(120000l);
Im RW 1 bekommen wir hier folgendes zu sehen:
0 Jahre 0 Monate 0 Tage 0 Stunden 2 Minuten 0 Sekunden 0 Tausendstel
Des Weiteren liefert zdRw35.getZeitDauer()
in diesem Beispiel -1
.
Das nachfolgende Video verdeutlicht das Verhalten:
CompositeZeitDauer__RW1_vs_RW35
Beispielhaft ist eine kleine Anwendung zum Testen angefügt: WidgetZeitdauerTest.java
Zuerst einmal Danke für die Infos.
Zum Einsatz kommt der bereitgestellte Binärbuild V3.5.0 vom 28.05.2020.
Wir schauen uns gerne den aktuellen Development-Branch bzgl. der Menüproblematik an.
Sehe ich es richtig, dass wir uns hier schon bei Version 3.6.0 befinden bzw. wird es empfohlen diesen Stand produktiv einzusetzen?
Auch uns ist bewusst, dass viele Plugins nicht mit einer Neuanmeldung am DaV zurechtkommen. Der bei Verbindungsverlust erscheinende Dialog weckt jedoch beim Endanwender den Eindruck, dass dies möglich sei.
Wird die Verbindung zum Rahmenwerk getrennt, erscheint ein Hinweisdialog. Es kann eine Neuanmeldung durchgeführt werden.
Der Menüaufbau kann hier scheitern, es kommt ggf. zu einem Invalid thread access. Die Menüleiste bleibt in diesem Fall leer.
Nachfolgend die entsprechenden Logs aus dem Rahmenwerk:
!ENTRY org.eclipse.e4.ui.workbench.swt 4 2 2022-07-05 11:40:08.554
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.e4.ui.workbench.swt".
!STACK 0
org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(SWT.java:4723)
at org.eclipse.swt.SWT.error(SWT.java:4638)
at org.eclipse.swt.SWT.error(SWT.java:4609)
at org.eclipse.swt.widgets.Widget.error(Widget.java:432)
at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:352)
at org.eclipse.swt.widgets.Widget.checkParent(Widget.java:290)
at org.eclipse.swt.widgets.Widget.<init>(Widget.java:155)
at org.eclipse.swt.widgets.Menu.<init>(Menu.java:198)
at org.eclipse.swt.widgets.Menu.<init>(Menu.java:138)
at org.eclipse.jface.action.MenuManager.createMenuBar(MenuManager.java:204)
at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer.createWidget(MenuManagerRenderer.java:370)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:1002)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:662)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:768)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:739)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:733)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:717)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.subscribeTopicToBeRendered(PartRenderingEngine.java:161)
at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58)
at org.eclipse.e4.core.di.internal.extensions.EventObjectSupplier$DIEventHandler.handleEvent(EventObjectSupplier.java:92)
at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:205)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:203)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:132)
at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:75)
at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:44)
at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:55)
at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:63)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:424)
at org.eclipse.e4.ui.model.application.ui.impl.UIElementImpl.setToBeRendered(UIElementImpl.java:314)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor.setMainMenu(RwProcessor.java:409)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor.access$1(RwProcessor.java:377)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor$ReconnectVerbindungsListener.lambda$0(RwProcessor.java:128)
at org.eclipse.core.runtime.jobs.Job$1.run(Job.java:164)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
!ENTRY org.eclipse.e4.ui.workbench 4 0 2022-07-05 11:40:08.559
!MESSAGE Exception occurred while rendering: org.eclipse.ui.main.menu=org.eclipse.e4.ui.model.application.ui.menu.impl.MenuImpl@24a4e2c5 (tags: [], contributorURI: null) (widget: null, renderer: org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer@7ac058a0, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null) (label: null, iconURI: null, tooltip: null, mnemonics: null) (enabled: true)
!STACK 0
org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(SWT.java:4723)
at org.eclipse.swt.SWT.error(SWT.java:4638)
at org.eclipse.swt.SWT.error(SWT.java:4609)
at org.eclipse.swt.widgets.Widget.error(Widget.java:432)
at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:352)
at org.eclipse.swt.widgets.Widget.checkParent(Widget.java:290)
at org.eclipse.swt.widgets.Widget.<init>(Widget.java:155)
at org.eclipse.swt.widgets.Menu.<init>(Menu.java:198)
at org.eclipse.swt.widgets.Menu.<init>(Menu.java:138)
at org.eclipse.jface.action.MenuManager.createMenuBar(MenuManager.java:204)
at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer.createWidget(MenuManagerRenderer.java:370)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:1002)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:662)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:768)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:739)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:733)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:717)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.subscribeTopicToBeRendered(PartRenderingEngine.java:161)
at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58)
at org.eclipse.e4.core.di.internal.extensions.EventObjectSupplier$DIEventHandler.handleEvent(EventObjectSupplier.java:92)
at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:205)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:203)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:132)
at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:75)
at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:44)
at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:55)
at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:63)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:424)
at org.eclipse.e4.ui.model.application.ui.impl.UIElementImpl.setToBeRendered(UIElementImpl.java:314)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor.setMainMenu(RwProcessor.java:409)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor.access$1(RwProcessor.java:377)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor$ReconnectVerbindungsListener.lambda$0(RwProcessor.java:128)
at org.eclipse.core.runtime.jobs.Job$1.run(Job.java:164)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
!ENTRY org.eclipse.core.jobs 4 2 2022-07-05 11:40:08.647
!MESSAGE Während "Verbindung herstellen...." ist ein interner Fehler aufgetreten.
!STACK 0
org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(SWT.java:4723)
at org.eclipse.swt.SWT.error(SWT.java:4638)
at org.eclipse.swt.SWT.error(SWT.java:4609)
at org.eclipse.swt.widgets.Widget.error(Widget.java:432)
at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:352)
at org.eclipse.swt.widgets.Control.setRedraw(Control.java:3650)
at org.eclipse.jface.action.StatusLineManager.update(StatusLineManager.java:272)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor.setRwStatusLeiste(RwProcessor.java:435)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor.access$2(RwProcessor.java:415)
at de.bsvrz.buv.rw.rw.ui.internal.RwProcessor$ReconnectVerbindungsListener.lambda$0(RwProcessor.java:131)
at org.eclipse.core.runtime.jobs.Job$1.run(Job.java:164)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Danke für die Info, wir sind uns bewusst dass zur Zeit nur Parameter berücksichtigt werden.
Eine Anforderung die wir sehen ist unter beliebigen Aspekten ResultData mit den Urlasserinformationen aus dem Urlasserdialog zu verorgen, sofern die ensprechenden Felder existieren.
Die Klasse DefaultUrlasserInfoDatenSender übernimmt die Urlasserinformationen nur für ResultData, welche unter dem Aspekt asp.parameterVorgabe versendet werden. Bei allen anderen ResultData, welche nicht unter diesem Aspekt versendet werden, werden keine Urlasserinformationen eingetragen.
Danke für die Info.
Wird in der StartStoppConsole mittels Enter das Applikations-Fenster zu einer selektierten Inkarnation geöffnet, so ist sogleich die selektierte Inkarnation/Applikation nicht mehr erkennbar.
Die Markierung springt zur ersten Inkarnation:
Die Anforderung ist im Rahmen des Kopplungsrechners SH notwendig.
Weitere Infos hierzu erhalten Sie über Herrn Söhnke Bruhn. Den Kontakt leite ich via EMail an Sie weiter.
Die Klasse de.bsvrz.buv.plugin.pua.PuaVerbinder
ist nur in der Lage mit einer PuA des lokalen Konfigurationsverantwortlichen zu arbeiten.
Hängt die PuA jedoch an einer anderen ConfigurationAuthority, so ist das Plugin Protokolle und Auswertungen nicht mehr verwendbar.
Im PuA-Navigator erscheint in diesem Fall nur noch der Hinweis PuA ist nicht verfügbar!
Das Plugin kann leider nur mit einem Standardarchiv, welches am lokalen Konfigurationsverantwortlichen hängt, umgehen.
Der ArchivIterator erzeugt so beim Einsatz verschiedener Archive an einer Anlage eine Meldung der Form:
#000023 10.12.2021 11:03:49,214:+0100 (TID:000073) ###################### FEHLER : Rahmenwerk.de.bsvrz.sys.funclib.bitctrl.modell.util.bmvew.Betriebsmeldungsverwaltung Initiale Archivabfrage Informationskanal fehlerhaft beendet.: de.bsvrz.sys.funclib.bitctrl.archiv.ArchivException: Das Archiv steht nicht zur Verfügung.
Wird eine Betriebsmeldung die lt. Parameter atg.betriebsMeldungsVerwaltungRegel
auf einen InformationsKanal, welcher in einem anderen Archiv gesichert wird publiziert, so steht diese nicht mehr zur Verfügung.
Sehr geehrte Herren, erst einmal vielen Dank für Ihre Mühen.
Wie sieht eine streambasierte Archivabfrage von nachgelieferten Daten aus, bei der nur die Datenzeitpunkte innerhalb eines Zeitbereiches von Interesse sind?
Gibt es hier seitens der Archivabfrage eine effiziente Methode zur Filterung oder muss tatsächlich jeder Datensatz im Nachgang manuell auf Zugehörigkeit zum Zeitbereich ausgewertet werden?