DE19845043C1 - Verfahren und dessen Verwendung sowie Datenverarbeitungsvorrichtung zum Abgleichen von in verschiedenen Anwenderdateien gespeicherten Daten - Google Patents
Verfahren und dessen Verwendung sowie Datenverarbeitungsvorrichtung zum Abgleichen von in verschiedenen Anwenderdateien gespeicherten DatenInfo
- Publication number
- DE19845043C1 DE19845043C1 DE19845043A DE19845043A DE19845043C1 DE 19845043 C1 DE19845043 C1 DE 19845043C1 DE 19845043 A DE19845043 A DE 19845043A DE 19845043 A DE19845043 A DE 19845043A DE 19845043 C1 DE19845043 C1 DE 19845043C1
- Authority
- DE
- Germany
- Prior art keywords
- file
- data
- user
- parameter
- directory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Beschrieben wird ein Verfahren und eine Datenverarbeitungsanlage zum Datenabgleich zwischen mindestens zwei Anwenderdateien (D1, D2). Die Anwenderdateien (D1, D2) betreffen zumindest teilweise dieselben Objekte und haben gemeinsame Kenngrößen. Eine Abgleichsteuerung (M) verwaltet zu gemeinsamen Objekten die abzugleichenden Kenngrößen in einer Verzeichnisdatei (D4). Die Abgleichsteuerung (M) erfaßt in bestimmten Zeitabständen die Änderungen und Neueinträge in jeder Anwenderdatei (D1, D2), trägt diese objektbezogen in die Verzeichnisdatei (D4) ein und gibt sie an die jeweils andere Anwenderdatei (D1, D2) weiter.
Description
Die Erfindung betrifft ein Verfahren und dessen Verwendung zum Abgleichen von
Daten, die in mindestens zwei Anwenderdateien gespeichert und
gegebenenfalls abgeändert werden. Ferner betrifft die Erfin
dung eine entsprechende Datenverarbeitungsvorrichtung.
Verschiedene Datenverarbeitungsanlagen eines Unternehmens,
verwenden häufig dieselben Daten. Zum Beispiel Personaldaten
wie Namen und Personalnummer eines Mitarbeiters des Unterneh
mens werden außer von der Personalabteilung auch von der
Buchhaltung oder der Telefonabteilung des Unternehmens benö
tigt. Dabei tritt das Problem auf, die Daten, z. B. die Ruf
nummer, unter der ein Mitarbeiter erreichbar ist, an die
jeweilige Datenverarbeitungsanlage der zuständigen Abteilung
weiterzugeben, die diese Daten benötigen. Die Weitergabe
solcher Daten ist jedoch nur möglich, wenn die Datenverarbei
tungsanlagen eine einheitliche Schnittstelle für den Daten
austausch besitzen. In der Regel ist eine solche Schnitt
stelle nicht vorhanden. Dies gilt insbesondere dann, wenn die
Abteilungen des Unternehmens Programme unterschiedlicher
Hersteller verwenden.
Beim Stand der Technik erfolgt die Weitergabe der Daten
manuell. Das bedeutet, daß ein in einer Abteilung beschäftig
ter Mitarbeiter, der z. B. die Personalnummer eines zu verwal
tenden Mitarbeiters benötigt, bei der Personalabteilung
nachfragt und die Personalnummer in den Datenbestand seiner
Abteilung einträgt. Diese Vorgehensweise ist umständlich und
birgt auch die Gefahr von Fehleingaben. Ferner wird die
Abteilung nicht automatisch von einer Änderung der Personal
nummer, z. B. nach einer Änderung des Arbeitsverhältnisses
eines Mitarbeiters, informiert.
Beispielsweise ist aus der deutschen Offenlegungsschrift
DE 196 07 149 A1 ein Verfahren zum Abgleich von Dateikopien
in verteilten Systemen bekannt, bei dem Änderungen an einer
Dateikopie jeweils in einer der jeweiligen Dateikopie zuge
ordneten Protokolldatei gespeichert werden. Zum Abgleich der
jeweiligen Dateikopien werden die einzelnen Protokolldateien
miteinander verglichen, wobei Änderungsoperationen für die
Dateikopien in einer festgelegten Reihenfolge ausgeführt
werden.
Des weiteren werden in dem Artikel "Datenkonsistenz in ver
teilten Systemen", JABLONSKI, S., Dr. u. RUF, T., in DE-Z In
formationstechnik it 33 (1991) 4, Seiten 175-184, weitere
Verfahren zum Abgleich von Dateikopien in verteilten Systemen
beschrieben.
Ein weiterer Ansatz zur Lösung des Problems des Datenab
gleichs ist bei Programmen zur Bearbeitung von elektronischer
Post, d. h. von Emails, bekannt: Die verschiedenen Email-
Programme, die von Mitarbeitern eines Unternehmens verwendet
werden, tragen die Email-Adressen der Mitarbeiter, die das
jeweilige Email-Programm benutzen, in ein gemeinsames Email-
Verzeichnis ein. Ein Zusatzprogramm paßt das Format der
Verzeichniseinträge so an, daß jedes Email-Programm die
Verzeichniseinträge, die von jeweils anderen Email-Programmen
stammen, lesen kann. Dies entspricht jedoch keinem Datenab
gleich zwischen Anwenderdateien, die von verschiedenen Anwen
dungsprogrammen bearbeitet werden, denn das Zusatzprogramm
arbeitet geänderte Daten nicht in die Anwenderdateien ein.
Aufgabe der Erfindung ist es, ein Verfahren sowie eine Ver
wendung des Verfahrens und eine Datenverarbeitungsvorrichtung
für den automatischen Datenabgleich zwischen verschiedenen
Anwendungsdateien zur Verfügung zu stellen, bei dem Änderun
gen an Anwendungsdateien und/oder Anwendungsprogramme, die
die Anwendungsdateien bearbeiten, nicht vorgenommen werden
müssen.
Die Erfindung löst die Aufgabe durch die Merkmale des Patent
anspruches 1 bzw. 15. Vorteilhafte Weiterbildungen sind in
den Unteransprüchen angegeben.
Gemäß der Erfindung wird eine Vielzahl von Objekten, z. B. die
Mitarbeiter eines Unternehmens, in mindestens zwei Anwender
dateien beschrieben. Eine erste Anwenderdatei kann z. B. eine
Personal-Anwenderdatei sein, in der die Personaldaten aller
Mitarbeiter des Unternehmens gespeichert sind. Eine zweite
Anwenderdatei kann z. B. eine Telefon-Anwenderdatei sein, die
Daten der Mitarbeiter enthält, denen eine Rufnummer in einer
Nebenstellenanlage des Unternehmens zugewiesen ist.
Jede Anwenderdatei wird von einer Anwendersteuerung verwal
tet. Die jeweilige Anwendersteuerung hat keinen direkten
Zugriff auf die jeweils andere Anwenderdatei. Die Erfindung
ermöglicht einen Datenabgleich zwischen den unterschiedlichen
Anwenderdateien, auch wenn die Anwendersteuerungen von
unterschiedlichen Herstellern stammen. Hervorzuheben ist
ferner, daß an den Anwendersteuerungen keine Änderungen
vorgenommen werden. Die Anwenderdateien betreffen zumindest
teilweise dieselben Objekte, z. B. alle Mitarbeiter mit einer
eigenen Rufnummer, und verwenden gemeinsame Kenngrößen, z. B.
eine Personalnummer. Jede Anwenderdatei enthält je Objekt
mindestens eine Objektkenngröße, die eine Eigenschaft des
Objektes beschreibt, z. B. den Namen eines Mitarbeiters.
Ferner gibt eine Datumskenngröße in jeder Anwenderdatei den
Zeitpunkt der letzten Änderung oder der Neueintragung einer
Objektkenngröße an.
Erfindungsgemäß erfaßt eine Abgleichsteuerung in vorgegebenen
Zeitabständen die Änderungen oder Neueintragungen in
mindestens einer Anwenderdatei. Der Zugriff auf die
Anwenderdatei kann z. B. über eine Schnittstelle erfolgen, die
die jeweilige Anwendersteuerung zur Verfügung stellt. Denkbar
ist auch, daß die Abgleichsteuerung direkt auf die Anwender
datei zugreift. Vorzugsweise werden nur die Änderungen oder
Neueintragungen erfaßt, die seit dem letzten Datenabgleich
erfolgt sind.
Die Abgleichsteuerung trägt die geänderten Werte und die
Neueintragungen objektbezogen in eine Verzeichnisdatei ein.
In dieser Verzeichnisdatei werden alle Objekte aufgeführt,
von denen mindestens eine Objektkenngröße zwischen zwei oder
mehr Anwenderdateien abzugleichen sind. Darüber hinaus kann
die Verzeichnisdatei Objekte enthalten, die nur in der
Verzeichnisdatei vorkommen, z. B. zum Testen der
Abgleichsteuerung. Ebenso kann die Verzeichnisdatei
Objektkenngrößen enthalten, die nur in der Verzeichnisdatei
vorkommen und z. B. von der Abgleichsteuerung verwendet
werden.
Die Abgleichsteuerung informiert in ebenfalls vorgegebenen
Zeitabständen die jeweils anderen Anwenderdateien über die
Änderungen bzw. Neueintragungen. Dabei kann die Abgleich
steuerung z. B. eine von der Anwendersteuerung zur Verfügung
gestellte Schnittstelle benutzen oder auch direkt auf die
Anwenderdatei zugreifen.
Die Zeitabstände, in denen Änderungen erfaßt bzw. an Anwen
derdateien weitergegeben werden, sind beliebig wählbar. Es
können auch bestimmte Zeitpunkte festgelegt werden. Das
Erfassen von Änderungen, das Eintragen der Änderungen in die
Verzeichnisdatei und die Weitergabe an die Anwenderdateien
kann zu jeweils beliebigen Zeitpunkten bzw. in beliebigen
Zeitabständen erfolgen.
Die Verwendung der Verzeichnisdatei zum Zwischenspeichern der
geänderten Objektkenngrößen stellt sicher, daß Änderungen
nicht verloren gehen, wenn sie nicht unmittelbar an eine
Anwenderdatei weitergegeben werden können. Bei einem Ausfall
der betreffenden Datenverarbeitungsanlage, der die Anwender
datei zugeordnet ist, arbeitet das erfindungsgemäße Verfahren
weiterhin ohne Beeinträchtigung.
Ferner werden die Daten eines Objektes in der Verzeichnisda
tei erst dann gelöscht, wenn die Daten des Objektes in allen
Anwenderdateien gelöscht sind oder anwendungsspezifisch
behandelt wurden. Scheidet ein Mitarbeiter z. B. aus dem
Unternehmen aus, werden zunächst seine Daten aus der
Personal-Anwenderdatei gelöscht oder als zu löschende Daten
gekennzeichnet. Die Abgleichsteuerung erfaßt diese Änderung
und informiert die Anwendersteuerung, die die Telefon-
Anwenderdatei verwaltet. Die Anwendersteuerung der Telefon-
Anwenderdatei führt alle notwendigen Schritte aus, die beim
Ausscheiden eines Mitarbeiters anfallen, und löscht
ihrerseits die in ihr bezüglich dieses Mitarbeiters
gespeicherten Daten. Nachdem die Abgleichsteuerung auch diese
Änderung in der Telefon-Anwenderdatei erfaßt hat, werden die
Daten dieses Mitarbeiters aus der Verzeichnisdatei gelöscht.
Die Verzeichnisdatei ist gemäß einem Ausführungsbeispiel
matrixartig aufgebaut. Für jedes Objekt wird eine Datenzeile
verwendet und die Kenngrößen sind spaltenartig angeordnet.
Bei dieser Weiterbildung werden alle Kenngrößen, die ein
Objekt beschreiben und die zwischen den verschiedenen Anwen
derdateien abgeglichen werden, in einer Datenzeile zusammen
gefaßt, wodurch der Zugriff auf die Kenngrößen, die zu einem
Objekt gehören, erleichtert wird. Eine solche Datenzeile wird
nachfolgend als Gesamtdatenzeile bezeichnet.
In einer vorteilhaften Weiterbildung wird die Gesamtdatenzei
le zum Zweck des Datenabgleichs um den Wert eines
Referenzzählers erweitert. Der Wert des Referenzzählers gibt
an, in wievielen Anwenderdateien Daten zu dem betreffenden
Objekt vorhanden sind. Der Wert des Referenzzählers wird um 1
erhöht, wenn in einer Anwenderdatei ein Neueintrag für das
betreffende Objekt vorgenommen wird. Entsprechend wird der
Wert des Referenzzählers um 1 erniedrigt, wenn die Abfrage
ergibt, daß die Daten zu dem betreffenden Objekt in einer
Anwenderdatei gelöscht worden sind.
Es kann z. B. festgelegt werden, daß der Referenzzähler der
Gesamtdatenzeile eines Objektes den Wert 1 hat, wenn aus den
Anwenderdateien alle Daten des betreffenden Objektes gelöscht
worden sind und nur noch in der Verzeichnisdatei Daten zu dem
betreffenden Objekt vorhanden sind. In diesem Fall löscht die
Abgleichsteuerung die Gesamtdatenzeile aus der Verzeichnisda
tei. Durch Verwendung des Referenzzählers werden zusätzliche
Abfragen seitens der Abgleichsteuerung an die Steuerungen der
Anwenderdateien, ob in der Anwenderdatei noch Daten zu dem
betreffenden Objekt gespeichert sind, vermieden.
Die Gesamtdatenzeile ist in einer Weiterbildung ferner um den
Wert einer Statuskenngröße ergänzt. Der Wert dieser Status
kenngröße gibt an, daß die Daten eines Objektes in einer
bestimmten Anwenderdatei, z. B. der Personal-Anwenderdatei,
gelöscht worden sind. Die Abgleichsteuerung informiert in
diesem Fall alle weiteren Anwenderdateien darüber, daß die
Daten eines Mitarbeiters, der aus dem Unternehmen ausgeschie
den ist, aus der Personal-Anwenderdatei gelöscht wurden.
Nachdem die Daten des Mitarbeiters aus der Telefon-Anwender
datei gelöscht sind, kann auch die Gesamtdatenzeile mit den
Daten des Mitarbeiters aus der Verzeichnisdatei gelöscht
werden. Umgekehrt führt ein Löschen der Daten eines Mitarbei
ters aus der Telefon-Anwenderdatei, z. B. nach einem Wechsel
zu einer anderen Abteilung des Unternehmens, zu einem Löschen
des Wertes der Rufnummer aus der Gesamtdatenzeile, welche die
Daten des Mitarbeiters enthält. Die Abgleichsteuerung
informiert anschließend die Personal-Anwenderdatei darüber,
daß der Wert der entsprechenden Objektkenngröße, in diesem
Fall also die Rufnummer, in der Gesamtdatenzeile gelöscht
worden ist.
Damit die Abgleichsteuerung eine Anwenderdatei über Neuein
tragungen informieren kann, enthält die Gesamtdatenzeile
objektbezogen als Kenngröße eine Einrichtungszeit, die an
gibt, wann die betreffende Gesamtdatenzeile in die Verzeich
nisdatei eingefügt worden ist. Diese Einrichtungszeit wird
von der Abgleichsteuerung dazu benutzt, um festzustellen,
welche Gesamtdatenzeilen seit dem letzten Datenabgleich in
die Verzeichnisdatei eingefügt worden sind und welche Daten
dementsprechend in die Anwendungsdateien einzutragen sind.
Besonders vorteilhaft ist es, wenn die Verzeichnisdatei je
Gesamtdatenzeile zusätzlich eine Kenngröße enthält, die den
Zeitpunkt angibt, wann geänderte Objekte in die Verzeichnis
datei übernommen worden sind. Dies ermöglicht es der Ab
gleichsteuerung festzustellen, welche Gesamtdatenzeilen sich
seit dem letzten Datenabgleich geändert haben. Damit läßt
sich die von der Verzeichnisdatei zur Anwenderdatei zu über
mittelnde Datenmenge reduzieren.
Die zu übertragende Datenmenge wird weiter reduziert, wenn
einer Anwenderdatei nur die Änderungen übermittelt werden,
die von der jeweils anderen Anwenderdatei stammen. Hierzu
kann die Verzeichnisdatei z. B. für jede Gesamtdatenzeile in
einer Kenngröße den Herkunftsort, d. h. eine Bezeichnung der
Anwenderdatei, der letzten Änderung festhalten.
Weiterhin ist es vorteilhaft, den Zeitpunkt des letzten
Datenabgleichs in einer Datei zu speichern. Damit steht der
Zeitpunkt des letzten Datenabgleichs auch nach einem Ausfall
der Datenverarbeitungsanlage, auf der ein Programm zum
Datenabgleich abgearbeitet wird, zur Verfügung.
Denkbar ist, daß der Rechner, der ein Programm zur Abgleich
steuerung abarbeitet und die Verzeichnisdatei zu unterschied
lichen Datenverarbeitungsanlagen gehören. Der Zugriff auf die
Verzeichnisdatei kann in diesem Fall über eine Netzwerkver
bindung erfolgen. Diese Alternative bietet sich z. B. dann
an, wenn die Datenverarbeitungsanlage, der die Verzeichnisda
tei zugeordnet ist, besondere Möglichkeiten der Datensiche
rung oder besonders größe Datenspeicher bietet.
In einer Weiterbildung erfolgt die Verwendung von Programmen
gemäß dem bekannten X.500-Standard der ITU (International
Telecommunication Union) als Basis für die Verzeichnisdatei.
Der X.500-Standard definiert ein Datenmodell und Verfahren
für den Zugriff auf Verzeichnisdateien. Programme, die gemäß
den durch den X.500-Standard festgelegten Verfahren arbeiten,
und Verzeichnisdateien, die gemäß diesem Standard aufgebaut
sind, können über mehrere Datenverarbeitungsanlagen verteilt
sein. Diese Datenverarbeitungsanlagen sind ihrerseits an ein
Netzwerk angeschlossen. Diese Weiterbildung des
erfindungsgemäßen Verfahrens ermöglicht z. B. die Verwaltung
sehr großer Verzeichnisdateien.
Die Verzeichnisdatei kann ferner auch als Telefonverzeichnis
verwendet werden, in dem einem weiteren Anwendungsprogramm
ein nur lesender Zugriff auf die Daten der Verzeichnisdatei
gestattet wird. Dieses Anwendungsprogramm verwaltet keine
eigene Anwendungsdatei und braucht demzufolge nicht am Daten
abgleich beteiligt zu sein.
Um die Abgleichsteuerung testen zu können, ist bei einem
zweiten Ausführungsbeispiel vorgesehen in der Verzeichnisda
tei gespeicherte Objektkenngrößen mit einem weiteren Programm
zu ändern. Ein solches Programm braucht ebenfalls nicht am
Datenabgleich beteiligt zu sein.
Gemäß einem weiteren Aspekt der Erfindung wird ein Datenver
arbeitungssystem nach Anspruch 15 angegeben, das den Abgleich
von Daten, die in unterschiedlichen Anwenderdateien gespei
chert sind, realisiert.
Nachfolgend wird ein Beispiel der Erfindung anhand der Zeich
nung näher erläutert. Darin zeigen:
Fig. 1 schematisch den Aufbau eines Datenverarbeitungs
systems eines Unternehmens,
Fig. 2a eine Personal-Anwenderdatei,
Fig. 2b eine Telefon-Anwenderdatei,
Fig. 2c eine Verzeichnisdatei,
Fig. 3 schematisch den Aufbau einer Steuereinrichtung für
den Datenabgleich,
Fig. 4 Verfahrensschritte S10 bis S32 bis zum Beginn der
Auswertung einer Antwortdatei,
Fig. 5 Verfahrensschritte S40 bis S62 für die Auswertung
der übrigen Zeilen der Antwortdatei,
Fig. 6 Verfahrensschritte S70 bis S92 zum Löschen von
Gesamtdatenzeilen aus der Verzeichnisdatei, und
Fig. 7 die Verfahrensschritte S100 bis S116, die sich an
die Schritte S70 bis S92 anschließen.
Fig. 1 zeigt als Ausführungsbeispiel der Erfindung ein
Datenverarbeitungssystem 10, bestehend aus drei Datenverar
beitungsanlagen A1, A2, A3. Die erste Datenverarbeitungsan
lage A1 wird von den Mitarbeitern einer Personalabteilung
benutzt. Zur Datenverarbeitungsanlage A1 gehören mehrere
Rechner, die über ein Netzwerk mit einem Rechner R1, der
ebenfalls zur Datenverarbeitungsanlage A1 gehört, verbunden
sind. Der Rechner R1 arbeitet ein Programm P1 ab, mit dem
eine Personal-Anwenderdatei D1 bearbeitet wird. Die Personal-
Anwenderdatei D1 enthält zu jedem Mitarbeiter des Unterneh
mens Objektkenngrößen, wie z. B. Namen, Personalnummer und
eine Rufnummer.
Die zweite Datenverarbeitungsanlage A2 wird von einer Tele
fonabteilung des Unternehmens genutzt. Aufgabe der Telefonab
teilung ist u. a. die Vergabe von Rufnummern einer Nebenstel
lenanlage des Unternehmens an die Mitarbeiter. Eine Telefon-
Anwenderdatei D2, die auf einem Rechner R2 der Datenverarbei
tungsanlage A2 gespeichert ist, enthält für alle Mitarbeiter
des Unternehmens, denen eine Rufnummer zugewiesen wurde u. a.
ebenfalls Objektkenngrößen, wie z. B. der Namen, die Personal
nummer und die Rufnummer. Auf dem Rechner R2 läuft ein weite
res Programm P2, mit dem die Telefon-Anwenderdatei D2 bear
beitet wird.
Die dritte Datenverarbeitungsanlage A3 wird für den Datenab
gleich zwischen den Datenverarbeitungsanlagen A1 und A2
eingesetzt. Ein direkter Datenaustausch zwischen den Daten
verarbeitungsanlagen A1 und A2 ist nicht möglich, weil die
Programme P1 und P2 zur Bearbeitung der Personal-Anwenderda
tei D1 bzw. der Telefon-Anwenderdatei D2 unterschiedliche
Datenformate verwenden. Dies gilt insbesondere dann, wenn die
beiden Programme P1 und P2 von verschiedenen Herstellern
stammen. Bei einem direkten Datenaustausch zwischen den
Anwendungsdateien steigt die Anzahl von Abgleichsteuerungen
quadratisch mit der Anzahl der Anwendungsdateien.
Zur Datenverarbeitungsanlage A3 gehören ein Rechner R3 mit
einer Steuereinrichtung M, eine Konfigurationsdatei D3 und
eine Verzeichnisdatei D4. Die Steuereinrichtung M tauscht
über eine erste Verbindung C1 Daten mit dem Programm P1 und
über eine zweite Verbindung C2 mit dem Programm P2 aus. Durch
die Konfigurationsdatei D3 wird festgelegt, daß die Objekt
kenngrößen Namen und Personalnummer, die von einem Mitarbei
ter der Personalabteilung mit Hilfe des Programms P1 erfaßt
wurden, an das Programm P2 übermittelt werden. Dementspre
chend legt die Konfigurationsdatei D3 fest, daß der Wert der
Objektkenngröße TN, d. h. die Rufnummer, den die Telefonabtei
lung an einen Mitarbeiter vergeben hat, an das Programm P1
übermittelt wird. In der Verzeichnisdatei D4 werden für jeden
Mitarbeiter alle auszutauschenden Daten gespeichert.
Fig. 2a zeigt den Aufbau der Personal-Anwenderdatei D1. In
diesem Beispiel ist die Personal-Anwenderdatei D1 als Liste
von Personaldatenzeilen aufgebaut, von denen in Fig. 2a drei
Personaldatenzeilen z1 bis z3 dargestellt sind. Die Liste
enthält Spalten s1 bis s13 für die nachfolgend beschriebenen
Kenngrößen. Die Personal-Anwenderdatei D1 enthält für jeden
Mitarbeiter des Unternehmens eine Personaldatenzeile
entsprechend den in Fig. 1 gezeigten Personaldatenzeilen z1
bis z3.
Die erste und zweite Spalte s1 und s2 enthalten für jede
Personaldatenzeile z1 bis z3 eine Objektkenngröße SN bzw. GN,
die auf eine Zeichenkette mit dem Nachnamen bzw. den Vornamen
eines Mitarbeiters des Unternehmens verweist. In der dritten
Spalte s3 befindet sich eine Objektkenngröße PC, mit der die
Postleitzahl des Mitarbeiters festgelegt ist.
Der Wert einer Kenngröße HUS (Hicom User) in der vierten
Spalte s4 legt fest, ob dem Mitarbeiter, zu dem die Daten
zeile z1 bis z3 gehört, über ein eigenes Endgerät der Neben
stellenanlage erreichbar ist. Falls der Mitarbeiter über ein
eigenes Endgerät erreichbar ist, wird der Wert der Kenngröße
HUS auf den Wert YES gesetzt andernfalls auf NO. Die fünfte
Spalte s5 enthält für jede Personaldatenzeile z1 bis z3 eine
Objektkenngröße TN, deren Wert die Rufnummer festlegt, unter
der der Mitarbeiter erreichbar ist.
Die sechste Spalte s6 enthält eine Objektkenngröße OU
(Organisation Unit). Der Wert dieser Objektkenngröße enthält
eine Bezeichnung einer Abteilung des Unternehmens, in der der
Mitarbeiter tätig ist. Für Mitarbeiter der Vertriebsabteilung
wird z. B. der Objektkenngröße OU der Wert SALES zugewiesen.
Die Spalte s7 enthält eine erste Kenngröße UID (User Identi
fication), deren Wert die Personalnummer des Mitarbeiters
angibt. Der Wert der Kenngröße UID kennzeichnet zugleich auch
jede Personaldatenzeile z1 bis z3, weil es in der Personal-
Anwenderdatei für jeden Mitarbeiter genau eine Personaldaten
zeile z1 bis z3 gibt.
Der Wert einer Objektkenngröße GS in der achten Spalte s8
legt eine Gehaltsstufe des Mitarbeiters fest, und in der
neunten Spalte s9 befindet sich für jede Personaldatenzeile
z1 bis z3 eine Datumskenngröße BD mit dem Geburtsdatum des
Mitarbeiters. Die Spalte s10 schließlich enthält eine Kenn
größe MT (Modification Time), deren Wert dem Zeitpunkt der
letzten Änderung eines Wertes der Kenngröße in den Spalten s1
bis s9 entspricht.
Fig. 2b zeigt den Aufbau der Telefon-Anwenderdatei D2. Die
Telefon-Anwenderdatei D2 ist als Liste von Telefondatenzeilen
mit den Spalten s20 bis s27 aufgebaut. Im folgenden wird der
Aufbau einer Telefondatenzeile z4 erläutert. In der ersten
Spalte s20 der Telefondatenzeile z4 steht der Wert einer
Kenngröße DMS-ID (DMS-ID = 100), die automatisch vom Programm
P2 vergeben wird, sobald eine Telefondatenzeile z4 in die
Telefon-Anwenderdatei D2 eingefügt wird. Der Kenngröße DMS-ID
in jeder Telefondatenzeile z4 wird ein eindeutiger Wert
zugewiesen. In der zweiten Spalte s21 steht der Wert einer
zweiten Objektkenngröße SN, die auf eine Zeichenkette mit dem
Nachnamen des Mitarbeiters verweist (z. B. SN = Liebig). Die
dritte Spalte s22 mit einer zweiten Objektkenngröße GN ent
hält eine Zeichenkette, die auf den Vornamen des Mitarbeiters
verweist (GN = Max). Die vierte und fünfte Spalte s23 bzw.
s24 mit Informationsfeldern TX1 und TX2, enthalten erläu
ternde Texte.
Die sechste Spalte s25 enthält die Objektkenngröße TX3 (z. B.
TX3 = 123), deren Wert auf den Wert der ersten Kenngröße UID
(UID = 123) gesetzt wird. Der Betrag der zweiten Objektkenn
größe TN (TN = 46404) in der siebten Spalte s26 definiert die
Rufnummer, die die Telefonabteilung dem Mitarbeiter, dessen
Personalnummer der Wert der Objektkenngröße TX3 der Tele
fondatenzeile z4 festlegt, zugewiesen hat. Die achte Spalte
s27 enthält eine Datumskenngröße MOD-TIME, deren Wert dem
Zeitpunkt entspricht, zu dem ein Wert der Kenngrößen in den
Spalten s20 bis s26 geändert wurde.
Fig. 2c zeigt den Aufbau der Verzeichnisdatei D4, die als
Liste von Gesamtdatenzeilen z5 bis z7 aufgebaut ist. Jede
Gesamtdatenzeile z5 bis z7 enthält Spalten s30 bis s41, mit
nachfolgend anhand der Gesamtdatenzeile z6 erläuterten Kenn
größen. Die erste Spalte s30 enthält eine dritte Objektkenn
größe SN, deren Wert (SN = Liebig) gleich dem Wert der ersten
Objektkenngröße SN der Personaldatenzeile z2 und gleich dem
Wert der zweiten Objektkenngröße SN der Telefondatenzeile z4
ist. Analog steht in der zweiten Spalte s31 eine dritte
Objektkenngröße SN, deren Wert auf eine Zeichenkette mit dem
Vornamen des Mitarbeiters verweist (GN = Max). Der Wert
dieser dritten Objektkenngröße SN ist gleich dem Wert der
ersten und zweiten Objektkenngröße SN in der Spalte s2 der
Personaldatenzeile z2 bzw. in der Spalte s22 der Telefonda
tenzeile z4.
Die dritte Spalte s32 enthält eine zweite Objektkenngröße
UID, deren Wert der Personalnummer des Mitarbeiters ent
spricht (UID = 124). Der Wert dieser Objektkenngröße ist
gleich dem Wert der ersten Objektkenngröße UID in der Spalte
s7 der Personaldatenzeile z2 und gleich dem Wert der Objekt
kenngröße TX3 der Telefondatenzeile z4.
Die vierte Spalte s33 enthält eine zweite Objektkenngröße HUS
(HUS = YES), deren Wert der ersten Objektkenngröße HUS der
Personaldatenzeile z2 entspricht. Die fünfte Spalte s34
enthält eine Kenngröße DMS (DMS = 100). Der Wert der Kenn
größe DMS ist gleich dem Wert der Kenngröße DMS-ID der Tele
fondatenzeile z4 in der Telefon-Anwenderdatei D2. Die sechste
Spalte s25 der Gesamtdatenzeile 26 enthält eine zweite
Objektkenngröße TN, deren Wert der Rufnummer des Mitarbeiters
entspricht. Der Wert der zweiten Objektkenngröße TN besteht
aus der Rufnummer der Nebenstelle, die von der Telefonabtei
lung vergeben wurde und deren Wert in der Spalte s26 der
Telefondatenzeile z4 steht, ergänzt um eine Vorwahlinformati
on "+4989722".
Die siebte Spalte s36 enthält eine zweite Objektkenngröße OU,
deren Wert auf eine Zeichenfolge mit der Bezeichnung der
Abteilung, in der der Mitarbeiter tätig ist, verweist (OU =
SALES). Der Wert dieser zweiten Objektkenngröße OU in der
Gesamtdatenzeile z6 ist gleich dem Wert der ersten Objekt
kenngröße OU in der Personaldatenzeile z2.
Die Spalte s37 enthält für jede Gesamtdatenzeile den Wert
einer Steuerkenngröße STS (Status). Der Wert dieser Steuer
kenngröße STS wird von der Steuereinrichtung M auf den Wert
DEL gesetzt, wenn die Personaldatenzeile z1 bis z3 eines
Mitarbeiters aus der Personal-Anwenderdatei D1 gelöscht
wurde. Beim nächsten Datenabgleich der Telefon-Anwenderdatei
D2 mit der Verzeichnisdatei D4, wird der Datenverarbeitungs
anlage A2 der Telefonabteilung der Wert der Kenngröße DMS
übermittelt, die auf eine Gesamtdatenzeile z5 bis z7 ver
weist, deren Steuerkenngröße STS den Wert DEL hat. Die Daten
verarbeitungsanlage A2 der Telefonabteilung löscht anschlie
ßend diejenige Telefondatenzeile aus der Telefon-Anwenderda
tei D2, deren Wert der Kenngröße DMS-ID gleich dem übermit
telten Wert ist.
Die Spalte s38 enthält eine Datumskenngröße CRT (Creation
Time), deren Wert den Zeitpunkt angibt, zu dem die Gesamtda
tenzeile in die Verzeichnisdatei eingefügt wurde. Die Spalte
s39 enthält eine Datumskenngröße MDT (Modification Time),
deren Wert den Zeitpunkt der letzten Änderung eines Wertes
der Kenngrößen in den Spalten s30 bis s37 einer Gesamtdaten
zeile z5 bis z7 angibt.
Die Spalte s40 enthält eine Kenngröße MN (Modifier Name),
deren Wert eine Zeichenkette mit einer Bezeichnung des Urhe
bers der letzten Änderung enthält. Werte in den Spalten s30
bis s33, s36, s37 der Gesamtdatenzeile z6 werden von der
Steuereinrichtung M nur geändert, wenn ein Wert der Kenngrö
ßen in den Spalten s1, s2, s4, s6 oder s7 der Personaldaten
zeile z2 geändert wurde. In diesem Fall setzt die Steuerein
richtung den Wert der Kenngröße MN auf den Wert PD-ADMIN.
Eine Änderung des Wertes in der Spalte s34 bzw. s35 der
Gesamtdatenzeile z6 erfolgt nur, wenn zuvor ein Wert der
Kenngröße DMS-ID bzw. TN in der Telefondatenzeile z4 geändert
wurde. In diesem Fall setzt die Steuereinrichtung M den Wert
der Kenngröße MN auf den Wert DMS-ADMIN. Bei einem Datenab
gleich der Telefon-Anwenderdatei D2 mit der Verzeichnisdatei
D4, werden nur Gesamtdatenzeilen z5 bis z7 berücksichtigt,
bei denen Werte der Kenngrößen in den Spalten s30 s33, s36
oder s37 geändert wurde.
Der Betrag eines Referenzzählers RCU (Reference Counter) in
der Spalte 41 wird auf den Wert "2" gesetzt, wenn nur den
Kenngrößen in den Spalten s30 bis s33, s36 oder nur den
Kenngrößen in den Spalten s34, s35 Werte zugewiesen wurden.
Das heißt, die Steuereinrichtung M hat nur Daten der
Personal-Anwenderdatei D1 oder nur der Telefon-
Anwenderdatei D2 in die Verzeichnisdatei D4 übernommen. Der
Betrag des Referenzzählers RCU hat den Wert "3", wenn allen
Kenngrößen in den Spalten s30 bis s36 Werte zugewiesen
wurden. Das heißt, die Steuereinrichtung M hat aus der
Personal-Anwenderdatei D1 und der Telefon-Anwenderdatei Daten
in die Verzeichnisdatei D4 übernommen.
Der Wert des Referenzzählers RCU wird beim Löschen einer
Gesamtdatenzeile z5 bis z7 aus der Verzeichnisdatei D4
ausgewertet. Die Steuereinrichtung M löscht nur Gesamtdaten
zeilen z5 bis z7 aus der Verzeichnisdatei, deren Steuerkenn
größe STS den Wert DEL und deren Referenzzähler den Wert "1"
hat. Zum Beispiel wird die Gesamtdatenzeile z6 aus der Ver
zeichnisdatei D4 erst gelöscht, wenn sowohl die Telefondaten
zeile z4 aus der Telefon-Anwenderdatei D2 als auch die Perso
naldatenzeile z2 aus der Personal-Anwenderdatei gelöscht
wurden.
Anhand der Fig. 3 werden die Module 12 bis 26 der Steuerein
richtung M beschrieben, die für den Datenaustausch zwischen
der Verzeichnisdatei D4 und der Telefon-Anwenderdatei D2
benötigt werden. Für den Datenaustausch zwischen der Perso
nal-Anwenderdatei D1 und der Verzeichnisdatei D4 werden
jeweils entsprechende, an die Datenformate angepaßte Module,
die hier nicht näher erläutert werden, verwendet. Ein Steuer
modul 26 legt den Ablauf des Datenabgleichs zwischen der
Personal-Anwenderdatei D1 und der Telefon-Anwenderdatei D2
fest. Bei den nachfolgenden Erläuterungen wird davon ausge
gangen, daß die Datenverarbeitungsanlage der Telefonabteilung
eine sogenannte XIE-Schnittstelle für den Datenaustausch zur
Verfügung stellt. Über diese XIE-Schnittstelle werden Tele
fondatenzeilen z4 der Telefon-Anwenderdatei D2 angefordert,
Werte von Kenngrößen in Telefondatenzeilen z4 geändert und
Telefondatenzeilen z4 aus der Telefon-Anwenderdatei D2 ge
löscht.
Ein erstes Eingabemodul 12 fordert vom Rechner R2 alle Tele
fondatenzeilen z4 an, deren Kenngröße MOD-TIME in der Spalte
s27 größer ist als der Zeitpunkt der letzten Datenanforde
rung. Die Datenverarbeitungsanlage A2 übermittelt eine Ant
wortdatei upload.rsp an den Rechner R3. Die Antwortdatei
upload.rsp enthält Zeilen mit allgemeinen Informationen,
Kommentarzeilen und Datenzeilen.
Ein erster Umwandler 16 wertet die Antwortdatei upload.rsp
zeilenweise aus und schreibt die Datenzeilen in eine Datei
dmsdir.dxf. In diesem Ausführungsbeispiel wird angenommen,
daß die Datenzeilen, im folgenden als Metadatenzeilen be
zeichnet, im sogenannten HDMS-Format (Hicom Domain Management
Service), vorliegen. Dieses HDMS-Format wird auch von der
XIE-Schnittstelle benutzt. Die Daten, die von der Datenverar
beitungsanlage (A1) der Personalabteilung an den Rechner R3
übermittelt wurden, werden von einem weiteren Umwandler, hier
nicht dargestellt, in das HDMS-Format übertragen. Für die
Darstellung der Werte der Kenngrößen wird der sogenannte
ASCII-Zeichensatz verwendet. Damit ist es möglich, die Datei
dmsdir.dxf mit einem beliebigen Textbearbeitungsprogramm zu
lesen. Dies erleichtert u. a. die Fehlerdiagnose.
Die Metadatenzeile enthält die Werte der Kenngrößen der
Telefondatenzeile z4 und einer Kenngröße AKTION, deren Wert
auf eine Zeichenfolge INSERT, UPDATE oder DELETE verweist.
Auf die Zeichenfolge INSERT wird verwiesen, wenn die Tele
fondatenzeile z4 in die Telefon-Anwenderdatei D2 eingefügt
wurde. Auf die Zeichenfolge UPDATE wird verwiesen, wenn der
Wert einer Kenngröße in den Spalten s20 bis s26 der Tele
fondatenzeile z4 geändert wurde. Wurde die Telefondatenzeile
aus der Telefon-Anwenderdatei D2 entfernt, wird auf die
Zeichenfolge DELETE verwiesen.
Die Metadatenzeilen werden anschließend von einem Analysa
tor 18 ausgewertet. Der Analysator 18 nimmt aus der Metada
tenzeile die Werte der Kenngrößen, die in die Gesamtdatenzei
le z5 bis z7 übernommen werden. In diesem Beispiel sind dies
die Werte zu den Kenngrößen DMS-ID und der zweiten Objekt
kenngröße TN der Telefondatenzeile z4. Der Analysator 18 legt
ferner die Werte für die Kenngrößen CRT bzw. MDT, MN und STS
fest.
Wurde eine Telefondatenzeile z4 in die Telefon-Anwenderdatei
D2 eingefügt, wird der Wert der Kenngröße CRT auf die aktuel
le Zeit gesetzt. Der Kenngröße MDT wird die aktuelle Zeit
zugewiesen, wenn der Wert der Kenngröße DMS-ID oder der Wert
der zweiten Objektkenngröße TN der Telefondatenzeile z4
geändert oder die Telefondatenzeile z4 aus der Telefon-Anwen
derdatei gelöscht wurde. Für den Wert der Kenngröße MN wird
die Zeichenfolge DMS-ADMIN festgelegt.
Bei neu eingefügten Telefondatenzeilen z4 erhöht ein Kon
trollmodul 20 den Wert des Referenzzählers RCU derjenigen
Gesamtdatenzeile z5 bis z7 um 1, deren Wert der Telefondaten
zeilenkenngröße DMS gleich dem Wert der Kenngröße DMS-ID ist.
Wurde eine Telefondatenzeile z4 aus der Telefon-Anwenderdatei
D2 gelöscht, verringert das Kontrollmodul 20 den Wert des
Referenzzählers RCU um 1. Die Steuereinrichtung M löscht eine
Gesamtdatenzeile z5 bis z7 aus der Verzeichnisdatei D4 unter
der Bedingung, daß die Kenngröße STS der Gesamtdatenzeile z5
bis z7 den Wert DEL hat und der Referenzzählers RCU derselben
Gesamtzeile z5 bis z7 den Wert "1" hat. In diesem Ausfüh
rungsbeispiel wird der Wert der Kenngröße STS einer Gesamtda
tenzeile z5 bis z7 auf den Wert DEL gesetzt, wenn die Perso
naldatenzeile, deren Wert der ersten Objektkenngröße UID
gleich dem Wert der zweiten Objektkenngröße UID der Gesamtda
tenzeile z5 bis z7 ist, aus der Personal-Anwenderdatei D1
gelöscht wurde.
Ein erstes Ausgabemodul 22 liest die Metadatenzeilen aus der
Datei dmsdir.dxf und prüft den Aufbau dieser Metadatenzeile.
Danach wird die Gesamtdatenzeile z5 bis z7 in der Verzeich
nisdatei D4 gesucht, deren Kenngröße DMS den in der Metada
tenzeile angegebenen Wert für die Kenngröße DMS-ID hat.
Anschließend wird der Wert der dritten Objektkenngröße TN der
Gesamtdatenzeile auf den in der Metadatenzeile angegebenen
Wert gesetzt.
Ein zweites Eingabemodul 24 liest aus der Verzeichnisdatei D4
alle Gesamtdatenzeilen z5 bis z7, bei denen sich Werte in den
Spalten s30 bis s37 seit dem letzten Datenabgleich der Tele
fon-Anwenderdatei D2 mit der Verzeichnisdatei D4 geändert
haben. Diese Gesamtdatenzeilen z5 bis z7 werden in eine Datei
dirdms.dxf geschrieben. Aus den Datenzeilen dieser Datei
dirdms.dxf bildet ein zweiter Umwandler 25 eine Datei
dnload.req. Die Datei dnload.req wird von einem zweiten
Ausgabemodul 14 an den Rechner R2 übermittelt.
Anhand der Fig. 4 bis 7 wird das Verfahren zum Datenab
gleich der Verzeichnisdatei D4 mit den Daten der Telefon-
Anwenderdatei D2 mit Hilfe eines Flußdiagramms weiter erläu
tert. Die Schritte S10 bis S52 bilden eine Programmfunktion
export.dms und die Schritte S70 bis S116 eine Programmfunkti
on import.x500. Das Steuermodul 26 ruft zunächst die Pro
grammfunktion export.dms und, falls die Programmfunktion
export.dms ohne Fehlermeldung beendet wurde, anschließend die
Programmfunktion import.x500.
Fig. 4 zeigt die Ablaufschritte S10 bis S32 der Programm
funktion export.dms. Im Schritt S10 wird eine Datei
lastsyncdms gelesen, die aus einer einzigen Zeile besteht.
Diese Zeile enthält eine Zeitangabe mit dem Zeitpunkt des
letzten Datenabgleichs der Verzeichnisdatei D4 mit Daten der
Telefon-Anwenderdatei D2. Im Schritt S12 wird die Konfigura
tionsdatei D3 eingelesen. Die Konfigurationsdatei D3 enthält
u. a. eine Zeile mit der Adresse des Rechners R2 der Datenver
arbeitungsanlage A2 der Telefonabteilung.
Der Zeitpunkt, zu dem der Datenabgleich der Verzeichnisdatei
D4 mit der Telefon-Anwenderdatei D2 beginnt, wird in einer
Datei tmptimedms zwischengespeichert (Schritt S14). Nach
fehlerfreiem Datenabgleich der Verzeichnisdatei D4 mit der
Telefon-Anwenderdatei D2, wird der Inhalt dieser Datei
tmptimedms in die Datei lastsyncdms kopiert (Schritt S44 in
Fig. 5).
Im Ablaufschritt S16 werden über die XIE-Schnittstelle der
Datenverarbeitungsanlage A2 die Werte aller Telefondatenzei
len z4 angefordert, deren Wert der Datumskenngröße MOD-TIME
größer ist als der in der Datei lastsyncdms angegebene Wert.
Dies sind alle Telefondatenzeilen z4, bei denen mindestens
ein Wert in den Spalten s20 bis s26 verändert wurde. Der
Rechner R3 schickt über die Verbindung C2 an den Rechner R2
eine Datei upload.req, die einen entsprechenden Befehl ent
hält.
Nachdem der Rechner R2 eine Antwortdatei mit HDMS-Datenzeilen
an den Rechner R3 übermittelt hat, werden im Schritt S20 die
Antwortdatei upload.rsp und im Schritt S22 die Datei
dmsdir.dxf geöffnet. Im Verfahrensschritt S24 wird die Zeile
der Datei upload.rsp gelesen. Falls es sich bei dieser Zeile
nicht um eine sogenannte Einleitungszeile handelt (Abfrage
S28) wird im Schritt S30 eine Fehlermeldung ausgegeben. In
eine Speicherzelle RC (Return Code) wird der Wert "2" ge
schrieben (Schritt S32). Die Adresse der Speicherzelle RC ist
auch dem Steuermodul 26 bekannt. Das Steuermodul 26 liest den
in der Speicherzelle RC abgelegten Wert und wertet ihn aus.
Das Steuermodul 26 erkennt anhand des Wertes "2" in der
Speicherzelle RC, daß während des Ablaufs der Funktion ex
port.dms ein Fehler aufgetreten ist. Im Fehlerfall wird z. B.
der Inhalt der Datei tmptimedms nicht in die Datei
lastsyncdms kopiert.
Hat die Abfrage S26 ergeben, daß es sich bei der eingelesenen
Zeile um die Einleitungszeile handelt, wird diese Zeile
ignoriert. Die Bearbeitung wird über die Verzweigung V1 mit
dem Ablaufschritt S40 in Fig. 5 fortgesetzt.
Fig. 5 zeigt die Verfahrensschritte S40 bis S62, mit denen
weitere Zeilen der Antwortdatei upload.rsp ausgewertet wer
den. Im Schritt S40 wird die nächste Zeile der Antwortdatei
upload.rsp gelesen. Besteht diese Zeile aus der Zeichenfolge
#0;0 (Abfrage S42), bedeutet dies, daß seit dem letzten
Datenabgleich der Verzeichnisdatei D4 mit der Telefon-Anwen
derdatei D2 in den Telefondatenzeilen z4 keine Werte verän
dert wurden. In diesem Fall wird im Schritt S44 der Inhalt
der Datei tmptimedms in die Datei lastsyncdms geschrieben. In
die Speicherzelle RC wird der Wert 3 geschrieben und zum
Steuermodul 26 zurückgesprungen. Da in der Telefon-Anwender
datei D2 keine Daten verändert wurden, ruft das Steuermodul
26 auch nicht die Programmfunktion import.x500 auf, d. h. der
Datenabgleich der Verzeichnisdatei D4 mit der Telefon-Anwen
derdatei D2 ist abgeschlossen.
Enthält die eingelesene Zeile die Zeichenfolge #1-1 (Abfrage
S48) bedeutet dies, daß die Datenverarbeitungsanlage A2 die
Anfrage nicht bearbeiten konnte. In diesem Fall wird im
Schritt S50 eine Fehlermeldung ausgegeben, in die Speicher
zelle RC der Wert "2" geschrieben (Schritt S52) und die
Programmfunktion export.dms beendet. Andernfalls handelt es
sich bei der eingelesenen Zeile um eine HDMS-Datenzeile, die
im Schritt S54 in die Datei dmsdir.dxf geschrieben wird.
Anschließend wird in der Abfrage S56 geprüft, ob die Antwort
datei upload.rsp weitere Zeilen enthält. Ist dies der Fall,
wird zum Ablaufschritt S40 verzweigt. Nach Auswerten der
letzten Zeile der Antwortdatei upload.rsp wird im Schritt S58
zunächst die Datei upload.rsp und im Schritt S60 die Datei
dmsdir.dxf geschlossen. Der Speicherzelle RC wird der Wert
"0" zugewiesen und die Programmfunktion export.dms beendet.
Anhand des Wertes "0" der Speicherzelle RC erkennt das Steu
ermodul 26, daß die Datei dmsdir.dxf Datenzeilen enthält und
ruft die Programmfunktion import.x500 auf.
Die Fig. 6 zeigt die Verfahrensschritte S70 bis S92 der
Programmfunktion import.x500. Nach dem Aufruf der Programm
funktion import.x500 durch das Steuermodul 26 wird im Schritt
S70 die Konfigurationsdatei D3 eingelesen. Die Konfigurati
onsdatei D3 enthält u. a. einen Eintrag mit Bezeichnungen
derjenigen Kenngrößen der Telefondatenzeilen z4, deren Werte
in diejenige Gesamtdatenzeile z5 bis z7 übernommen werden,
deren Wert der Telefondatenzeilenkenngröße DMS gleich dem
Wert der Kenngröße DM-ID ist.
Im Schritt S74 wird die Datei dmsdir.dxf, die die Metadaten
zeilen enthält, geöffnet. Diese Metadatenzeilen enthalten
zusätzlich zu den Werten der Kenngrößen der Telefondatenzei
len z4, eine Kenngröße AKTION, deren Wert auf eine Zeichen
folge INSERT, UPDATE oder DELETE verweist. Die nachfolgenden
Schritte beschreiben nur diejenigen Verfahrensschritte, die
durchlaufen werden, falls der Wert der Kenngröße AKTION auf
die Zeichenfolge DELETE verweist, d. h. daß die Telefondaten
zeile z4 aus der Telefon-Anwenderdatei entfernt wurde.
Im Ablaufschritt S76 wird die erste Zeile aus der Datei
dmsdir.dxf gelesen und als aktuelle Metadatenzeile genommen.
Falls die Abfrage S78 ergibt, daß die betreffende Telefonda
tenzeile z4 in der Telefon-Anwenderdatei D2 geändert (AKTION
= UPDATE) oder die betreffende Telefondatenzeile z4 in die
Telefon-Anwenderdatei D2 eingefügt wurde (AKTION = INSERT),
wird die Bearbeitung mit weiteren, hier nicht erläuterten
Verfahrensschritten fortgesetzt. Im Ja-Zweig wird im Schritt
S80 aus der aktuelle Metadatenzeile der Wert der Kenngröße
DMS-ID bestimmt und im Schritt S82 aus der Verzeichnisdatei
D4 eine Gesamtdatenzeile z5 bis z7 als aktuelle Gesamtdaten
zeile genommen, deren Wert der Kenngröße DMS gleich dem Wert
der Kenngröße DMS-ID ist.
Im Verfahrensschritt S84 werden die Werte des Referenzzählers
RCU und der Steuerkenngröße STS der aktuellen Gesamtdatenzei
le ermittelt. Falls die Abfrage S86 ergibt, daß der Wert des
Referenzzählers RCU gleich "1" und der Wert der Kenngröße STS
gleich "DEL" ist, wird die aktuelle Gesamtdatenzeile aus der
Verzeichnisdatei D4 gelöscht. Die Beziehung STS = DEL bedeu
tet, daß die zugehörige Personaldatenzeile bereits aus der
Personal-Anwenderdatei D1 entfernt wurde. Das Ergebnis
RCU = 1 gibt an, daß sowohl die zugehörige Personaldatenzeile
aus der Personal-Anwenderdatei D1 als auch die zugehörige
Telefondatenzeile aus der Telefon-Anwenderdatei D2 gelöscht
wurden.
Falls die Abfrage S90 ergibt, daß die Datei dmsdir.dxf wei
tere Zeilen enthält, wird die nächste Zeile eingelesen, als
aktuelle Metadatenzeile genommen und zur Abfrage S78 ver
zweigt. Andernfalls wird die Bearbeitung über die Verzweigung
V4 mit Ablaufschritt S114 in Fig. 7 fortgesetzt.
Fig. 7 zeigt die Schritte S100 bis S116 der Programmfunktion
import.x500. Mit Schritt S100 wird der Nein-Zweig der Abfrage
S86 fortgesetzt. In dem Schritt S100 wird eine Lösch-Liste
mit Bezeichnungen derjenigen Kenngrößen zusammengestellt,
deren Werte aus der Gesamtdatenzeile z5 bis z7 gelöscht
werden. In diesem Beispiel sind dies die Werte zu den Kenn
größen DMS und TN. Die Lösch-Liste besteht demnach aus der
Zeichenfolge "DMS TN".
Im Schritt S102 wird der Wert der Objektkenngröße HUS auf
"NO" gesetzt. Damit wird verhindert, daß beim nächsten Daten
abgleich der Telefon-Anwenderdatei D2 mit der Verzeichnisda
tei D4 diese Gesamtdatenzeile berücksichtigt wird. Der Wert
des Referenzzählers RCU wird im Verfahrensschritt S104 um den
Wert 1 erniedrigt. Falls die anschließende Überprüfung
(Abfrage S106) ergibt, daß die Lösch-Liste nicht leer ist,
d. h. die aktuelle Gesamtdatenzeile noch Kenngrößen hat, deren
Werte zu löschen sind, werden im Schritt S108 die Werte der
Kenngrößen, deren Bezeichnungen die Lösch-Liste enthält,
gelöscht. Andernfalls wird in der Abfrage S110 überprüft, ob
die Datei dmsdir.dxf eine weitere Datenzeile enthält. Ist
dies der Fall wird die nächste Zeile aus der Datei dmsdir.dxf
eingelesen, als aktuelle Metadatenzeile genommen und die
Verzweigung V2 zur Abfrage S78 verzweigt.
Nachdem die letzte Zeile der Datei dmsdir.dxf bearbeitet
wurde (Nein-Zweig der Abfrage S110), wird im Schritt S114 der
Inhalt der Datei tmptimedms in die Datei lastsyncdms ge
schrieben. In die Speicherzelle RC wird der Wert "0" ge
schrieben (Schritt S116) und die Programmfunktion import.x500
beendet.
Claims (21)
1. Verfahren zum Abgleichen von Daten, die in mindestens zwei
Anwenderdateien (D1, D2) gespeichert und gegebenenfalls
abgeändert werden,
bei dem die Anwenderdateien (D1, D2) eine Vielzahl von Objek ten anhand von Kenngrößen beschreiben,
jede Anwenderdatei (D1, D2) von einer Anwendersteuerung (P1, P2) verwaltet wird, wobei die jeweilige Anwendersteuerung (P1, P2) keinen direkten Zugriff auf die jeweils andere Anwenderdatei (D1, D2) hat,
beide Anwenderdateien (D1, D2) zumindest teilweise dieselben Objekte betreffen und gemeinsame Kenngrößen verwenden,
eine Abgleichsteuerung (M) die Verwaltung von Daten in einer Verzeichnisdatei (D4) steuert,
die Verzeichnisdatei (D4) zu gemeinsamen Objekten Objektkenn größen (TN) speichert, die den beiden Anwenderdateien (D1, D2) gemeinsam sind und unterschiedliche Werte annehmen kön nen, wobei jede Anwenderdatei (D1, D2) und die Verzeichnis datei (D4) eine das Objekt identifizierende Schlüsselkenn größe (UID, TX3) enthält,
jede Anwenderdatei je Objekt mindestens eine Objektkenngröße (TN) enthält, die eine Eigenschaft des Objektes charakteri siert,
jede Anwenderdatei je Objekt eine Datumskenngröße (MT, MOD-TIME) enthält, die den Zeitpunkt der letzten Änderung oder der Neueintragung der Objektkenngröße angibt,
die Abgleichsteuerung (M) in vorgegebenen Zeitabständen die aktuellen Änderungen und/oder Neueintragungen in jeder Anwen derdatei (D1, D2) erfaßt und die Werte gemeinsamer Objekt kenngrößen (SN, GN, TN) in die Verzeichnisdatei objektbezogen einträgt,
die Abgleichsteuerung in vorgegebenen Zeitabständen die jeweils andere Anwenderdatei (D1, D2) über diese Änderung bzw. Neueintragung informiert und die geänderte Objektkenn größe übergibt,
und bei dem die Daten eines Objektes in der Verzeichnisdatei (D4) gelöscht werden, wenn die Daten des Objektes in allen Anwenderdateien (D1, D2) gelöscht sind.
bei dem die Anwenderdateien (D1, D2) eine Vielzahl von Objek ten anhand von Kenngrößen beschreiben,
jede Anwenderdatei (D1, D2) von einer Anwendersteuerung (P1, P2) verwaltet wird, wobei die jeweilige Anwendersteuerung (P1, P2) keinen direkten Zugriff auf die jeweils andere Anwenderdatei (D1, D2) hat,
beide Anwenderdateien (D1, D2) zumindest teilweise dieselben Objekte betreffen und gemeinsame Kenngrößen verwenden,
eine Abgleichsteuerung (M) die Verwaltung von Daten in einer Verzeichnisdatei (D4) steuert,
die Verzeichnisdatei (D4) zu gemeinsamen Objekten Objektkenn größen (TN) speichert, die den beiden Anwenderdateien (D1, D2) gemeinsam sind und unterschiedliche Werte annehmen kön nen, wobei jede Anwenderdatei (D1, D2) und die Verzeichnis datei (D4) eine das Objekt identifizierende Schlüsselkenn größe (UID, TX3) enthält,
jede Anwenderdatei je Objekt mindestens eine Objektkenngröße (TN) enthält, die eine Eigenschaft des Objektes charakteri siert,
jede Anwenderdatei je Objekt eine Datumskenngröße (MT, MOD-TIME) enthält, die den Zeitpunkt der letzten Änderung oder der Neueintragung der Objektkenngröße angibt,
die Abgleichsteuerung (M) in vorgegebenen Zeitabständen die aktuellen Änderungen und/oder Neueintragungen in jeder Anwen derdatei (D1, D2) erfaßt und die Werte gemeinsamer Objekt kenngrößen (SN, GN, TN) in die Verzeichnisdatei objektbezogen einträgt,
die Abgleichsteuerung in vorgegebenen Zeitabständen die jeweils andere Anwenderdatei (D1, D2) über diese Änderung bzw. Neueintragung informiert und die geänderte Objektkenn größe übergibt,
und bei dem die Daten eines Objektes in der Verzeichnisdatei (D4) gelöscht werden, wenn die Daten des Objektes in allen Anwenderdateien (D1, D2) gelöscht sind.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die
Anwenderdateien (D1, D2) und die Verzeichnisdatei (D4) ma
trixartig aufgebaut sind, wobei je Objekt eine Datenzeile
(z1-z7) verwendet wird und die Daten für Kenngrößen spal
tenartig (s1-s41) angeordnet werden.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet,
daß die Verzeichnisdatei (D4) je Datenzeile (z5-z7) den
Wert eines Referenzzählers (RCU) enthält, der angibt, in
wievielen Anwenderdateien (D1, D2) Daten zu dem betreffenden
Objekt vorhanden sind.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß der
Referenzzähler (RCU) um 1 erhöht wird, wenn bei der Abfrage
einer Anwenderdatei (D1, D2) eine Neueintragung für das
betreffende Objekt festgestellt wird.
5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet,
daß der Referenzzähler (RCU) um 1 erniedrigt wird, wenn
festgestellt wird, daß in einer Anwenderdatei (D1, D2) die
Daten zu dem betreffenden Objekt gelöscht worden sind.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch
gekennzeichnet, daß die Verzeichnisdatei (D4) objektbezogen
als Kenngröße eine Einrichtungszeit (CRT) enthält, die an
gibt, wann die betreffende Datenzeile (z5, z7) erstmalig in
der Verzeichnisdatei (D4) angelegt worden ist.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch
gekennzeichnet, daß die Verzeichnisdatei (D4) als Kenngröße
den Änderungszeitpunkt (MDT) je Datenzeile (z5-z7) enthält,
der angibt, wann geänderte Objektkenngrößen (TN) in die
Verzeichnisdatei (D4) übernommen wurden.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch
gekennzeichnet, daß die Verzeichnisdatei (D4) als Kenngröße
den Herkunftsort (MN) je Datenzeile (z5-z7) enthält, der
angibt, aus welcher Anwenderdatei (D1, D2) die zuletzt geän
derten Daten herkommen.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch
gekennzeichnet, daß der Zeitpunkt des letzten Datenabgleichs
in einer Datei abgespeichert wird.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch
gekennzeichnet, daß der Zugriff auf die Verzeichnisdatei (D4)
gemäß einem durch den X.500-Standard definierten Verfahren
erfolgt.
11. Verwendung des Verfahrens nach einem der Ansprüche 1 bis
10, für eine Personal-Anwenderdatei (D1) mit Personaldaten
einer Personalabteilung, wobei die Objekte Mitarbeiter eines
Unternehmens sind.
12. Verwendung nach Anspruch 11, dadurch gekennzeichnet, daß
als Objektkenngröße der Nachname (SN), der Vorname (GN), die
Adresse (PC), die Telefonnummer (TN), Unternehmensabteilung
(OU), die Gehaltsstufe (GS) und/oder das Geburtsdatum (BD)
verwendet werden.
13. Verwendung nach Anspruch 11 oder 12, dadurch gekenn
zeichnet, daß in einer Telefon-Anwenderdatei (D2) als zweite
Anwenderdatei Telefondaten gespeichert werden, wobei die
Objekte Mitarbeiter des Unternehmens sind.
14. Verwendung nach Anspruch 13, dadurch gekennzeichnet, daß
als Objektkenngröße der Nachname (SN), der Vorname (GN), eine
Tätigkeitsbezeichnung (TX1), die Telefonnummer (TN) und/oder
die Abteilung (TX2) verwendet werden.
15. Datenverarbeitungsvorrichtung zum Abgleichen von Daten,
die in mindestens zwei Anwenderdateien (D1, D2) gespeichert
und gegebenenfalls abgeändert werden,
bei dem die Anwenderdateien (D1, D2) eine Vielzahl von Objek ten anhand von Kenngrößen beschreiben,
jede Anwenderdatei (D1, D2) von einer Anwendersteuerung (P1, P2) verwaltet wird, wobei die jeweilige Anwendersteuerung (P1, P2) keinen direkten Zugriff auf die jeweils andere Anwenderdatei (D1, D2) hat,
beide Anwenderdateien (D1, D2) zumindest teilweise dieselben Objekte betreffen und gemeinsame Kenngrößen verwenden,
eine Abgleichsteuerung (M) die Verwaltung von Daten in einer Verzeichnisdatei (D4) steuert,
die Verzeichnisdatei (D4) zu gemeinsamen Objekten Objektkenn größen (TN) speichert, die den beiden Anwenderdateien (D1, D2) gemeinsam sind und unterschiedliche Werte annehmen kön nen, wobei jede Anwenderdatei (D1, D2) und die Verzeichnis datei (D4) eine das Objekt identifizierende Schlüsselkenn größe (UID, TX3) enthält,
jede Anwenderdatei je Objekt mindestens eine Objektkenngröße (TN) enthält, die eine Eigenschaft des Objektes charakteri siert,
jede Anwenderdatei je Objekt eine Datumskenngröße (MT, MOD-TIME) enthält, die den Zeitpunkt der letzten Änderung oder der Neueintragung der Objektkenngröße angibt,
die Abgleichsteuerung (M) in vorgegebenen Zeitabständen die aktuellen Änderungen und/oder Neueintragungen in jeder Anwen derdatei (D1, D2) erfaßt und die Werte gemeinsamer Objekt kenngrößen (SN, GN, TN) in die Verzeichnisdatei objektbezogen einträgt,
die Abgleichsteuerung in vorgegebenen Zeitabständen die jeweils andere Anwenderdatei (D1, D2) über diese Änderung bzw. Neueintragung informiert und die geänderte Objektkenn größe übergibt,
und bei dem die Daten eines Objektes in der Verzeichnisdatei (D4) gelöscht werden, wenn die Daten des Objektes in allen Anwenderdateien (D1, D2) gelöscht sind.
bei dem die Anwenderdateien (D1, D2) eine Vielzahl von Objek ten anhand von Kenngrößen beschreiben,
jede Anwenderdatei (D1, D2) von einer Anwendersteuerung (P1, P2) verwaltet wird, wobei die jeweilige Anwendersteuerung (P1, P2) keinen direkten Zugriff auf die jeweils andere Anwenderdatei (D1, D2) hat,
beide Anwenderdateien (D1, D2) zumindest teilweise dieselben Objekte betreffen und gemeinsame Kenngrößen verwenden,
eine Abgleichsteuerung (M) die Verwaltung von Daten in einer Verzeichnisdatei (D4) steuert,
die Verzeichnisdatei (D4) zu gemeinsamen Objekten Objektkenn größen (TN) speichert, die den beiden Anwenderdateien (D1, D2) gemeinsam sind und unterschiedliche Werte annehmen kön nen, wobei jede Anwenderdatei (D1, D2) und die Verzeichnis datei (D4) eine das Objekt identifizierende Schlüsselkenn größe (UID, TX3) enthält,
jede Anwenderdatei je Objekt mindestens eine Objektkenngröße (TN) enthält, die eine Eigenschaft des Objektes charakteri siert,
jede Anwenderdatei je Objekt eine Datumskenngröße (MT, MOD-TIME) enthält, die den Zeitpunkt der letzten Änderung oder der Neueintragung der Objektkenngröße angibt,
die Abgleichsteuerung (M) in vorgegebenen Zeitabständen die aktuellen Änderungen und/oder Neueintragungen in jeder Anwen derdatei (D1, D2) erfaßt und die Werte gemeinsamer Objekt kenngrößen (SN, GN, TN) in die Verzeichnisdatei objektbezogen einträgt,
die Abgleichsteuerung in vorgegebenen Zeitabständen die jeweils andere Anwenderdatei (D1, D2) über diese Änderung bzw. Neueintragung informiert und die geänderte Objektkenn größe übergibt,
und bei dem die Daten eines Objektes in der Verzeichnisdatei (D4) gelöscht werden, wenn die Daten des Objektes in allen Anwenderdateien (D1, D2) gelöscht sind.
16. Datenverarbeitungsvorrichtung nach Anspruch 15, dadurch
gekennzeichnet, daß die Anwenderdateien (D1, D2) und die Ver
zeichnisdatei (D4) matrixartig aufgebaut sind, wobei je
Objekt eine Datenzeile (z1-z7) verwendet wird und die Daten
für Kenngrößen spaltenartig (s1-s41) angeordnet werden.
17. Datenverarbeitungsvorrichtung nach Anspruch 15 oder 16,
dadurch gekennzeichnet, daß die Verzeichnisdatei (D4) je
Datenzeile (z5-z7) den Wert eines Referenzzählers (RCU)
enthält, der angibt, in wievielen Anwenderdateien (D1, D2)
Daten zu dem betreffenden Objekt vorhanden sind.
18. Datenverarbeitungsvorrichtung nach einem der Ansprüche 15
bis 17, dadurch gekennzeichnet, daß die Verzeichnisdatei (D4)
objektbezogen als Kenngröße eine Einrichtungszeit (CRT)
enthält, die angibt, wann die betreffende Datenzeile (z5, z7)
erstmalig in der Verzeichnisdatei (D4) angelegt worden ist.
19. Datenverarbeitungsvorrichtung nach einem der Ansprüche 15
bis 18, dadurch gekennzeichnet, daß die Verzeichnisdatei (D4)
als Kenngröße den Änderungszeitpunkt (MDT) je Datenzeile
(z5-z7) enthält, der angibt, wann geänderte Objektkenngrö
ßen (TN) in die Verzeichnisdatei (D4) übernommen wurden.
20. Datenverarbeitungsvorrichtung nach einem der Ansprüche 15
bis 19, dadurch gekennzeichnet, daß die Verzeichnisdatei (D4)
als Kenngröße den Herkunftsort (MN) je Datenzeile (z5-z7)
enthält, der angibt, aus welcher Anwenderdatei (D1, D2) die
zuletzt geänderten Daten herkommen.
21. Datenverarbeitungsvorrichtung nach einem der Ansprüche 15
bis 20, dadurch gekennzeichnet, daß der Zugriff auf die Ver
zeichnisdatei (D4) gemäß einem durch den X.500-Standard defi
nierten Verfahren erfolgt.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19845043A DE19845043C1 (de) | 1998-09-30 | 1998-09-30 | Verfahren und dessen Verwendung sowie Datenverarbeitungsvorrichtung zum Abgleichen von in verschiedenen Anwenderdateien gespeicherten Daten |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19845043A DE19845043C1 (de) | 1998-09-30 | 1998-09-30 | Verfahren und dessen Verwendung sowie Datenverarbeitungsvorrichtung zum Abgleichen von in verschiedenen Anwenderdateien gespeicherten Daten |
Publications (1)
Publication Number | Publication Date |
---|---|
DE19845043C1 true DE19845043C1 (de) | 2000-03-30 |
Family
ID=7882934
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19845043A Expired - Fee Related DE19845043C1 (de) | 1998-09-30 | 1998-09-30 | Verfahren und dessen Verwendung sowie Datenverarbeitungsvorrichtung zum Abgleichen von in verschiedenen Anwenderdateien gespeicherten Daten |
Country Status (1)
Country | Link |
---|---|
DE (1) | DE19845043C1 (de) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10058391A1 (de) * | 2000-11-24 | 2002-06-13 | Siemens Ag | Objektbearbeitungssystem mit einem Objektmodell |
DE10250644B4 (de) * | 2002-10-30 | 2006-08-10 | Siemens Ag | Austausch und Abgleich von Daten zwischen Applikationen |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19607149A1 (de) * | 1996-02-26 | 1997-08-28 | Siemens Ag | Verfahren zum rechnergestützten Abgleich mehrerer, in mindestens einem Rechner gespeicherten Dateikopien einer gespeicherten Datei |
-
1998
- 1998-09-30 DE DE19845043A patent/DE19845043C1/de not_active Expired - Fee Related
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19607149A1 (de) * | 1996-02-26 | 1997-08-28 | Siemens Ag | Verfahren zum rechnergestützten Abgleich mehrerer, in mindestens einem Rechner gespeicherten Dateikopien einer gespeicherten Datei |
Non-Patent Citations (1)
Title |
---|
JABLONSKI, S., Dr., u. RUF, T.:"Datenkonsistenz in verteilten Systemen", in:DE-Z.: Informations- technik it 33, 1991, 4, S. 175-189 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10058391A1 (de) * | 2000-11-24 | 2002-06-13 | Siemens Ag | Objektbearbeitungssystem mit einem Objektmodell |
DE10058391C2 (de) * | 2000-11-24 | 2003-06-18 | Siemens Ag | Vorrichtung zur Objektbearbeitung |
US8275809B2 (en) | 2000-11-24 | 2012-09-25 | Siemens Aktiengesellschaft | Object processing system using an object model |
DE10250644B4 (de) * | 2002-10-30 | 2006-08-10 | Siemens Ag | Austausch und Abgleich von Daten zwischen Applikationen |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0525432B1 (de) | Verfahren zur Änderung von Systemkonfigurationsdatensätzen in einem Fernmeldevermittlungssystem | |
DE4125389C1 (de) | ||
EP1151399B1 (de) | Integration heterogener Datenbank-Systeme | |
DE68925957T2 (de) | Fernmeldedatenbankzugriffsverfahren | |
DE69229453T2 (de) | Verfahren und Anordnung zum Zugriff auf eine relationelle Datenbank, ohne eine objektorientierte Umgebung verlassen zu müssen | |
DE69830020T2 (de) | Vorrichtung und Verfahren zur Aufrechterhaltung der integrierten Datenübereinstimmung zwischen mehreren Datenbanken | |
DE69736748T2 (de) | Editierumgebung für objektmodelle und verfahren zu deren anwendung | |
DE102007062986A1 (de) | Verfahren und Einrichtung zur Client-Server-Kommunikation gemäß dem Standardprotokoll OPC UA | |
DE69127399T2 (de) | Verfahren zur automatischen Löschung vorübergehender Dokumentverbindungen in einem Datenverarbeitungssystem | |
DE1499182A1 (de) | Elektrische Datenverarbeitungsanlage | |
EP0959588A2 (de) | Netzelement mit einer Steuerungseinrichtung und Steuerungsverfahren | |
EP1225511A1 (de) | Verfahren und system zur akten-verwaltung in verteilten umgebungen | |
EP1005215B1 (de) | Verfahren und Vorrichtung zum Editieren von Konfigurationsdaten für Telekommunikationssysteme | |
DE19845043C1 (de) | Verfahren und dessen Verwendung sowie Datenverarbeitungsvorrichtung zum Abgleichen von in verschiedenen Anwenderdateien gespeicherten Daten | |
EP1005216A2 (de) | Verfahren und Vorrichtung zur Validierung von Konfigurationsdaten für Telekommunikationssysteme | |
EP1235123A2 (de) | Addon-Mechanismus für ein Steuerungssystem basierend auf einem Typdatenfeld | |
EP0548398A1 (de) | Verfahren zur Verwaltung von Programmen und Daten sowie Computersystem zur Durchführung des Verfahrens | |
DE69929209T2 (de) | Verfahren und system zur verwaltung von teilnehmerfunktionen | |
EP1099172A1 (de) | Verfahren, anordnung und satz mehrerer anordnungen zur behebung mindestens einer inkonsistenz in einer datenbankmenge, die eine datenbank sowie mindestens eine kopiedatenbank der datenbank aufweist | |
DE3032615C2 (de) | ||
EP4102378A1 (de) | Verfahren zur neuorganisation und/oder transformation von daten | |
EP1191458B1 (de) | Bidirektionale Verknüpfung eines Datenbanksystems mit einem Datenverzeichnis | |
WO2004072850A2 (de) | Verfahren und vorrichtung zum modifizieren von modular aufgebauten nachrichten | |
DE10017608B4 (de) | Verfahren zur Durchführung von Operationen in einem Datenbanksystem | |
DE19720464C1 (de) | Verfahren zum Bearbeiten von Datensätzen und Datenverarbeitungsanlage zur Durchführung der Verfahren |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8100 | Publication of the examined application without publication of unexamined application | ||
D1 | Grant (no unexamined application published) patent law 81 | ||
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |