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 Daten

Info

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
Application number
DE19845043A
Other languages
English (en)
Inventor
Dietmar Fauth
Andreas Wolf
Shahnar Saravandi-Rad
Heinrich Schmidt
Guenter Stohl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE19845043A priority Critical patent/DE19845043C1/de
Application granted granted Critical
Publication of DE19845043C1 publication Critical patent/DE19845043C1/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers

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.
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.
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.
DE19845043A 1998-09-30 1998-09-30 Verfahren und dessen Verwendung sowie Datenverarbeitungsvorrichtung zum Abgleichen von in verschiedenen Anwenderdateien gespeicherten Daten Expired - Fee Related DE19845043C1 (de)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (1)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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
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
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
DE4324665C2 (de) Verfahren zur Verarbeitung von zwischen mindestens zwei Datenübertragungssystemen zu übertragenden Datensätzen sowie eine Anwendung
EP1191458B1 (de) Bidirektionale Verknüpfung eines Datenbanksystems mit einem Datenverzeichnis
EP1593036A2 (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
DE102004001497B4 (de) Verfahren und Synchronisierungseinrichtung zum Zugriff auf Ereignisdaten in einer Kommunikationsumgebung
EP1109100B1 (de) Verfahren zur Abarbeitung eines Daten-Ladeauftrags in einem Daten ver- und/oder bearbeitenden System

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