DE4220698C2 - Verfahren zum Betreiben einer Datenverarbeitungsanlage - Google Patents

Verfahren zum Betreiben einer Datenverarbeitungsanlage

Info

Publication number
DE4220698C2
DE4220698C2 DE4220698A DE4220698A DE4220698C2 DE 4220698 C2 DE4220698 C2 DE 4220698C2 DE 4220698 A DE4220698 A DE 4220698A DE 4220698 A DE4220698 A DE 4220698A DE 4220698 C2 DE4220698 C2 DE 4220698C2
Authority
DE
Germany
Prior art keywords
block
signal
software
global
lsn
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 - Lifetime
Application number
DE4220698A
Other languages
English (en)
Other versions
DE4220698A1 (de
Inventor
Anders Abrahamsson
Lars Holmquist
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE4220698A1 publication Critical patent/DE4220698A1/de
Application granted granted Critical
Publication of DE4220698C2 publication Critical patent/DE4220698C2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44521Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Exchange Systems With Centralized Control (AREA)

Description

Ein Teil der Offenbarung dieser Patentanmeldung enthält Material, welches dem Urheberrechtsschutz unterliegt. Der Inhaber des Urheberrechts hat nichts gegen die Reproduktion mittels Kopieren der Patentanmeldung oder der Patentveröf­ fentlichtung durch irgend jemand, wie diese in dem Patent­ amt, der Amtsakte oder dem Register erscheinen, reserviert sich ansonsten jedoch sämtliche Urheberrechte.
Die Erfindung betrifft ein Verfahren zum Betrieben einer Datenverarbeitungs­ anlage, zum Beispiel die Steuerung eines Telekommunikations-Verbindungssystems. Insbesondere betrifft sie ein Verfahren zur dynamischen Modifizierung von Adres­ sierinformation innerhalb eines derartigen Systems.
Telekommunikations-Vermittlungssysteme, deren Be­ triebsablauf durch gespeicherte Programme gesteuert wird, verwenden im allgemeinen einen oder mehrere Rechner, um die unterschiedlichen Funktionen innerhalb des Systems zu steu­ ern. Bei der Organisation derartiger konventioneller, durch gespeicherte Programme gesteuerter Telekommunikations-Zen­ tralen ist es bekannt, jede Zentrale in einzelne Funktions­ blöcke zu unterteilen, so daß von jedem Block eine begrenzte Anzahl von Funktionen durchgeführt wird. Daher erfordert die Zusammenarbeit zwischen verschiedenen Blöcken die einfachst möglichen Schnittstellen mit so wenig Nachrichten-Übermitt­ lungsschaltungen wie möglich. Die Unterteilung der Software zum Steuern derartiger Zentralen in diskrete Funktionsblöcke führt zu einer häufigen Wechselwirkung zwischen diesen Blöc­ ken über den Austausch von Softwaresignalen, welche den Fluß von sowohl Befehlen als auch Daten innerhalb dieses Systems steuern.
Eine Funktionsblock-orientierte, durch gespeicherte Programme gesteuerte Telekommunikationszentrale ist in dem US-Patent Nr. 3 969 701 für Hundal beschrieben.
Im allgemeinen treten die Probleme, die mit dem Verknüpfen und Laden diskreter Softwaremodule in Computersysteme ver­ bunden sind, auch bei durch gespeicherte Programme gesteuer­ ten Telekommunikationszentralen auf. Zu diesen Problemen gehören solche, die mit dem Speichern der Programm-Module in den Hauptspeicher zusammenhängen, was als Laden bezeichnet wird, und das Kombinieren von Unterprogramm-Modulen zu einem Verbundprogramm, was als Verknüpfen (Linking) bezeichnet wird. Das mit diesem Themen zusammenhängende Grundprinzip ist in einem Artikel mit dem Titel "Linkers and Loaders" beschrieben, Leon Presser und John White, Computing Surveys, Band 4, September 1972.
Das grundsätzliche Konzept umfaßt das Erfordernis, daß ver­ kettende Programm-Module exakte Adressen in sich aufweisen müssen, um auf andere Teile zugehöriger Programm-Module zuzugreifen, die für einen ordnungsgemäßen Betriebsablauf erforderlich sind. Wenn ein bestimmtes Programm-Modul aus dem Speicher entfernt und später erneut geladen wird, so kann es an einem anderen Speicherplatz liegen als an dem, den es bei seinem vorherigen Aufenthalt inne hatte. Daher muß vor dem Laden des Moduls irgendein Mechanismus vorhanden sein, um einen Bezug zu den spezifischen Befehlen innerhalb des Programms zur Verfügung zu stellen, so daß diese Befehle durch die anderen Module des Programms geladen werden kön­ nen.
Zusätzlich werden Programm-Module, die einen Teil des Be­ triebsprogramms der Telekommunikations-Zentrale bilden, häufig geändert oder vergrößert, um zusätzliche Funktionen oder Wirkungen zur Verfügung zu stellen, wodurch die Inter­ aktion mit anderen Programm-Modulen geändert wird. Beim Abändern von Programm-Modulen ist es gewöhnlich erforder­ lich, Teile der Befehle innerhalb dieses Moduls zuzufügen bzw. wegzulassen, um das Ziel der Modifikation zu erreichen. Diese Vorgänge erfordern es, daß die Adressen innerhalb der spezifischen Module und deren individuelle modifizierte Komponenten ordnungsgemäß in Betracht gezogen werden, wenn sie zur Ausführung wiederum in das System geladen werden.
Der Vorgang des Speicherns übersetzter oder kompilierter Programme in den Hauptspeicher eines Rechners für die Aus­ führung ist allgemein als Laden bekannt. Das Laden von Pro­ grammbefehlen in den Hauptspeicher aus anderen, sekundären Speicherquellen oder Orten ist ein notwendiges Erfordernis für die Ausführung der Software. Es haben sich in Folge der Tatsache Probleme ergeben, daß einige Programme zu groß sind, als daß sie vollständig in den Hauptspeicher geladen werden können, und daß es daher erforderlich ist, während der Ausführung Teile des Programms aus dem Speicher auszula­ gern und wieder einzulagern. Auch aus der Tatsache haben sich Probleme ergeben, daß Programme nicht immer in den exakten absoluten Adressenraum zurückgeladen werden bei jeder Ausführung, und daher müssen die Adressen für Symbole innerhalb eines bestimmten Programm-Moduls oder Blockes jedes Mal erneut berechnet werden, wenn der Block ausgeführt wird.
Ein verwandtes Konzept ist als Verknüpfen (Linken) bekannt. Das Verknüpfen umfaßt die Kombination von Unterprogrammen zu einem Verbundprogramm und wurde als ein wertvolles Werkzeug bei modernen Betriebssystemen akzeptiert, in welchen modu­ lare Software einen wesentlichen Teil darstellt. Das Ver­ knüpfen kann theoretisch zu irgendeinem von sieben unter­ schiedlichen Zeitpunkten durchgeführt werden: zur Source­ code-Erzeugungszeit; nach der Code-Erzeugung, jedoch vor dem Kompilieren oder Übersetzen; zur Zeit der Kompilierung oder Übersetzung; nach dem Übersetzen, jedoch vor dem Laden; beim Laden; nach dem Laden, jedoch vor der Ausführung; oder bei der Ausführung. Weit bekannte Systeme wie beispielsweise das IBM System/360 und die UNIVAC 9400 führen ein Verknüpfen nach dem Übersetzen, jedoch vor dem Laden durch. Viele exi­ stierende Systeme führen ebenfalls eine Verknüpfung zum Zeitpunkt des Ladens durch, jedoch begrenzt die Ausführung der Vorgänge zusammen miteinander die Flexibilität, die verfügbar ist, wenn die beiden Vorgänge getrennt ausgeführt werden. Zwar wurde die Möglichkeit des Verknüpfens zur Zeit der Ausführung erkannt, jedoch wurde angenommen, daß diese Vorgehensweise, die als Segmentierung bekannt ist, mit zahl­ reichen Problemen verbunden ist, beispielsweise mit höheren Gemeinkosten und der Anforderung, daß die Hardware und Soft­ ware hoch integriert sein müssen.
Eine Art des Umgehens mit der Verwaltung von Adressierinfor­ mation innerhalb der Komponenten modularer Software besteht in der Bereitstellung einer globalen Signal-Verteilungsta­ belle, die mit den globalen Signalzahlen geladen wird, die bestimmten Arten von Signalen innerhalb der Software zuge­ ordnet sind, zusammen mit den lokalen Signalzahlen korre­ spondierender Jobs innerhalb des betreffenden Moduls, wel­ ches in die Software geladen wird. Dieses ermöglicht es jeder globalen Signalzahl oder externen Differenz, eine globale Signalzahl aufzurufen, so daß diese durch Querver­ weis in der Globalsignalzahl-Verteilungstabelle angegeben ist, um die lokale Signalzahl innerhalb eines bestimmten Softwareblocks aufzufinden, bevor dieses Signal in einen Jobpuffer des Prozessors geladen wird, um an einen anderen Block der Software übertragen zu werden.
Zwar ist ein derartiges Verfahren der Verknüpfung von Vor­ gängen innerhalb einzelner Softwareblöcke und zwischen die­ sen, und der Verkettung von Adressen innerhalb der verschie­ den Software-Module eines Programms effektiv, jedoch weist es bestimmte inhärente Nachteile auf. Einer dieser Nachteile besteht darin, daß nach einer erneuten Ladung eines revi­ dierten Blocks in das System die Überarbeitung von Signalen, die vor der Modifikation des Softwareblocks in den Jobpuffer gebracht wurden, nicht mehr exakt ausgeführt werden kann, da die lokalen Signalzahlen, die dem modifizierten Block zu­ geordnet sind, hätten geändert werden können, als der Block erneut geladen und die Globalsignal-Verteilungstabelle er­ neut beschrieben wurde. Immer dann, wenn ein Modul eines Progamms modifiziert wurde und erneut geladen werden muß, muß daher sämtliche Information innerhalb des Jobpuffers gelöscht und dann erneut geladen werden. Wenn der Inhalt der Globalsignal-Verteilungstabelle in Folge eines Ausladens und erneuten Ladens eines modifizierten Softwareblocks geändert wurde, kann dies zusätzlich zu der versehentlichen Verwen­ dung einer alten lokalen Signalnummer in dem Jobpuffer füh­ ren, was zu der Ausführung einer unrichtigen Befehlsadresse führt, wenn ein anderes Signal dieser lokalen Signalnummer in der neuen Version des erneut geladenen Blocks oder Moduls zugeordnet wurde. Weiterhin empfängt der Software-Benutzer keine Fehlernachricht, wenn dies auftritt, da die Software nicht erkennen kann, daß die Befehlsadresse fehlerhaft ist. Dies kann zu gestörten Ausgangssignalen führen, wenn der Block vollständig ausgeführt werden kann.
Aus dem Buch "OS/2" von Jeffrey I. Krantz, Ann M. Mizell, Robert L. Williams, Verlag: John Wiley & Sons, Inc., USA, 1988, S. 57-81 ist ein Verfahren zum Betreiben einer Datenverarbeitungsanlage bekannt, mit welchem Multitasking- Anwendungen möglich sind, wobei ein Benutzer nur jeweils mit einer Anwendung kommunizieren kann, also Daten eingeben und eine Bildschirmanzeige erhalten kann, während die anderen Anwendungen zwar aktiv sind, jedoch im Hintergrund ablaufen. Das Betriebssystem unterhält ein globales Informationssegment, welches Information enthält, die für das gesamte System Gültigkeit hat; weiterhin gibt es ein lokales Informationssegment, welches für jeden Vorgang in dem System aufrechterhalten wird, und aktualisiert werden kann, wenn es von einer Anmeldung gelesen wird. Über eine Schnittstelle wird einem Vorgang die Möglichkeit eingeräumt, das globale Informationssegment und das lokale Informationssegment zu lesen.
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Betrieben einer Datenverarbeitungsanlage zur Verfügung zu stellen, welches die funktionelle Zusammenarbeit zwischen Elementen der Datenverarbeitungsanlage vereinfacht.
Die Aufgabe wird durch ein Verfahren mit den im Patentanspruch 1 angegebenen Merkmalen gelöst; vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.
Das Verfahren der vorliegenden Erfindung überwindet die voranstehend geschilderten und andere Nachteile und stellt einen erhöhten Pegel an Geschwindigkeit und Verläßlichkeit innerhalb der Datenverarbeitungsanlage dadurch zur Verfügung, daß Adressen innerhalb der Software dynamisch verknüpft werden, während die einzelnen Software-Module ausgeführt werden.
Bei dem Verfahren gemäß der vorliegenden Erfindung kann ein modulares Software- System, beispielsweise eines, welches in einem Telekom­ munikations-Vermittlungssystem verwendet werden kann, so ausgelegt werden, daß das Verbinden von Variablen und Signalen innerhalb der Software bis zu dem Zeitpunkt während der Ausführung verzögert wird, an welchem ein gegebenes Modul tatsächlich ausgeführt wird. Diese Vorgehensweise überwindet frühere Probleme bei modularen Systemen, die es nicht zulie­ ßen, daß Modifikationen individueller Software-Module vor­ genommen wurden, ohne daß es erforderlich war, daß der ge­ samte Satz der Software-Module innerhalb des Softwaresystems erneut vor der Ausführung verknüpft wurde.
Die Erfindung überwindet ebenfalls die Probleme, die mit der Existenz begrenzten Speicherraums in dem Hauptspeicher des Rechnersystems zusammenhängen, der in vielen Fällen zu klein ist, um den gesamten Softwaresatz aufzunehmen. In einer derartigen Situation müssen Software-Module in den Speicher ein- und aus diesem ausgelagert werden, ohne eine Garantie, daß das Software-Modul bei darauf folgenden Ausführungen oder Ladungen an denselben physikalischen Adressenraum ge­ bunden wird. Dies kann zu einer unrichtigen Bezugnahme loka­ ler Adressen innerhalb eines Moduls führen.
Ein Aspekt der vorliegen­ den Erfindung umfaßt die Übertragung von Software-Signalen von einem Block oder Modul eines modularen Softwaresystems auf einen anderen Block durch die Bezugnahme auf eine lokale Signalzahl für jedes Signal, jeden Vorgang oder Job, der innerhalb eines gegebenen Blocks auftritt. Auf derartige lokale Signalzahlen kann in einer globalen Signal- Verteilungstabelle Bezug genommen werden, welche einen Quer­ verweis zwischen globalen Signal- oder Blockzahlen und loka­ len Zahlen angibt, die innerhalb dieses Blocks vorhanden sind. Die lokale Signalzahl und ihre zugeordneten Blockzahl werden in der globalen Signal-Verteilungstabelle gespeichert oder aktualisiert zu dem Zeitpunkt, wenn das Modul geladen oder ausgeführt wird, wodurch die voranstehend angegebenen Probleme vermieden werden.
Ein Aspekt des Verfahrens gemäß der vorliegenden Erfindung umfaßt die Identifizierung, welches Softwaresignal von einem Block an einen anderen übertragen werden soll, und die Übertragung einer globalen Signalnummer, die diesem Softwa­ resignal zugeordnet ist, und einer Blockzahl, die dem Block zugeordnet ist, welcher das Softwaresignal empfangen soll, an ein Register innerhalb des Jobpuffers des Systems, der in der zentralen Verarbeitungseinheit enthalten ist. Sobald sich die Information innerhalb des Jobpuffers befindet, weist sie eine zugeordnete Priorität auf, und wird daraufhin entsprechend dieser Priorität ausgeführt. Erreicht das Si­ gnal die Spitze der Jobpuffer-Warteschlange und wird dann ausgeführt, so wird auf die globale Signal-Verteilungstabel­ le zugegriffen, um die zugeordnete Signalzahl in dem Emp­ fangsmodul oder Empfangsblock zu erhalten. Dies wird durch Kombinieren der globalen Signalzahl mit der Zahl erreicht, die dem empfangenden Block zugeordnet ist. Schließlich zeigt die lokale Signalzahl zu einer Befehlsadresse in dem empfan­ genden Block, welche wiederum zu einem Befehl innerhalb des empfangenen Blocks zeigt, der ausgeführt werden soll.
Zwar mag auf den ersten Blick dieses Verfahren der Adres­ sierung und der Kommunikation ziemlich kompliziert erschei­ nen, jedoch weist es mehrere wichtige Vorteile auf. Es er­ laubt es einem Programm, irgendwo innerhalb des Programm­ speichers des Systems gespeichert zu werden, ohne irgend­ etwas zu beeinflussen, abgesehen von dem Wert, der in dem Referenzspeicherplatz als die Programm-Startadresse für die­ sen Block gespeichert ist. Weiterhin kann eine Programmfolge oder ein Job irgendwo innerhalb eines Softwareblocks ange­ ordnet werden, ohne irgendetwas zu beeinflussen, abgesehen von der Adresse in der Signal-Verteilungstabelle. Alle diese Vorteile führen dazu, daß das Softwaresystem einfacher zu nutzen ist und weniger anfällig für Befehlsfehler ist, die häufig durch den menschlichen Benutzer nicht feststellbar sind.
Die Erfindung wird nachstehend anhand zeichnerisch darge­ stellter Ausführungsbeispiele näher erläutert, aus welchen weitere Vorteile hervorgehen. Es zeigt:
Fig. 1 eine diagrammartige Darstellung der Art und Weise, auf welche Adressierinformation für modulare Soft­ wareblöcke in einem Computerprogramm in einem Re­ ferenzspeicher gespeichert wird;
Fig. 2 eine diagrammartige Darstellung der Art und Weise, auf welche Programmbefehle und zugeordnete Adres­ sierinformation innerhalb modularer Softwareblöcke eines Computerprogramms gespeichert werden;
Fig. 3 eine diagrammartige Darstellung der Art und Weise, auf welche individuelle Jobs innerhalb modularer Softwareblöcke adressiert werden;
Fig. 4 eine diagrammartige Darstellung der Art und Weise, auf welche modularen Softwareblöcken zugeordnete Daten in einem Datenspeicher gespeichert werden;
Fig. 5 eine diagrammartige Darstellung der Art und Weise, auf welche unterschiedliche Programm- und Daten­ adressen innerhalb eines modularen Softwaresystems behandelt werden;
Fig. 6 eine diagrammartige Darstellung der Art und Weise, auf welche Softwaresignale von einem Block modula­ rer Software zu einem anderen Block modularer Software geschickt werden;
Fig. 7 eine diagrammartige Darstellung der Art und Weise, auf welche Softwaresignale, die zeitweilig in ei­ nem Jobpuffer eines zentralen Prozessors festge­ halten werden, durch die Betriebssystem-Software behandelt werden;
Fig. 8 eine diagrammartige Darstellung der Art und Weise, auf welche modulare Softwareblöcke entsprechend dem System gemäß der vorliegenden Erfindung dyna­ misch verknüpft werden; und
Fig. 9 ein Flußdiagramm zur Erläuterung des Betriebsab­ laufs des Verfahrens des Systems gemäß der vorlie­ genden Erfindung.
Die Steuerung einer Telekommunikations-Zentrale kann auf eine Anzahl unterschiedlicher Arten organisiert sein. Wenn das System allerdings in verschiedene Funktionsblöcke unter­ teilt wird, so findet die Zusammenarbeit zwischen den unter­ schiedlichen Blöcken durch den Zentralprozessor des Systems statt. Um die Anordnung und die Identifizierung der ver­ schiedenen Funktionsblöcke innerhalb der Software zu er­ leichtern, wird im allgemeinen jedem Block eine eindeutige Zahl zugeteilt. Eine typische Vermittlung (Zentrale) enthält im allgemeinen zwischen 300 und 500 Funktionsblöcke.
Das Gesamtsystem einer derartigen Datenverarbeitungsanlage weist typischerweise mehrere unterschiedli­ che Speicherbereiche auf, in welchen unterschiedliche Aspek­ te des Software-Steuersystems gespeichert sind. In Fig. 1 sind zwei derartige Bereiche gezeigt, die einen Programm­ speicher (PS) umfassen, der den Code enthält, der die Be­ triebsbefehle oder -Schritte der Software aufweist, die ent­ sprechend der Blockzahl angeordnet sind. Entsprechend wird ein unterschiedlicher Bereich, der als der Referenzspeicher (RS) bekannt ist,. dazu verwendet, bestimmte Adressierparame­ ter zu speichern, die für den Zugriff auf den Programmspei­ cher verwendet werden. Beispielsweise beginnt in Fig. 1 der Abschnitt des Programms, welcher den Block XX in dem Pro­ grammspeicher enthält, an einer Programm-Startadresse (PSA) in dem Programmspeicher, und diese PSA wird als ein diskre­ tes Wort, welches dem Block XX zugeordnet ist, in den Refe­ renzuspeicher geschrieben. Dies bedeutet, daß die Start­ adresse des Programms die Adresse angibt, an welcher der Block in dem Programmspeicher beginnt, und daß die Blockzahl (BN) dazu verwendet wird, dieses Wort in dem Referenzspei­ cher zu adressieren. Daher hat jeder Block im System seinen eigenen Bereich in dem Referenzspeicher, der eine Tabelle aufweist, die als die Referenztabelle bezeichnet wird.
Ein Funktionsblock kann gewöhnlich eine große Anzahl von Tätigkeiten oder "Jobs" durchführen, und jeder Job wird durch Senden eines Signals zu dem geeigneten Block eingelei­ tet. Um das Auffinden eines gewünschten Jobs innerhalb eines gewünschten Blocks zu erleichtern, wird jedem Signal eine individuelle Zahl zugeteilt, welche als die Signalort- und lokale Signalzahl (LSN) bezeichnet wird. Zur Einleitung eines Jobs innerhalb eines bestimmten Blocks sind sowohl eine Blockzahl als auch eine lokale Signalzahl erforderlich, und diese beiden Elemente bilden zusammen etwas, was als ein Softwaresignal bezeichnet wird, normalerweise abgekürzt als BN+LSN.
Wie aus Fig. 2 hervorgeht, ist dort schematisch ein Ab­ schnitt des Programms innerhalb des Programmspeichers darge­ stellt, welcher als Teil des Blockes XX sowohl die Programm­ information als auch eine Signal-Verteilungstabelle (SDT) aufweist. In jede Position der Signal-Verteilungstabelle wird eine diskrete Adresse eingeschrieben. Diese Adresse, die immer relativ zur Programm-Startadresse des Blocks ist, gibt an, wo innerhalb des Programms die unterschiedlichen Jobs beginnen. Dies führt dazu, daß die absolute Adresse eines Jobs die Startadresse des Blocks (PSA) plus die in der Signal-Verteilungstabelle angegebene Adresse umfaßt. Wie aus Fig. 3 hervorgeht, ist dort eine Erläuterung der Adressie­ rung eines bestimmten Jobs innerhalb des Programms darge­ stellt, wobei die Adresse des Anfangs des Blocks, der den gewünschten Job enthält, mit der Adresse kombiniert wird, die in der Signal-Verteilungstabelle angegeben ist, entspre­ chend der lokalen Signalzahl des Jobs, um die bestimmte Adresse innerhalb des Blocks zu ereichen, welcher die Soft­ ware zur Ausführung dieses Jobs enthält.
Um einen bestimmten Job auszuführen, muß die Software in­ nerhalb eines Blocks Daten adressieren können. In Systemen der momentan beschriebenen Art kann ein Block nur seine "eigenen" Daten adressieren, also Daten, auf die er selektiv zugreifen kann. Zur Erläuterung der Art und Weise, auf wel­ che Daten, die sich auf den Betriebsablauf eines programm­ gesteuerten Telekommunikations-Vermittlungssystems der vor­ liegenden Art beziehen, in einem anderen Bereich des Spei­ chers gespeichert werden, der als der Datenspeicher bezeich­ net wird, wird angenommen, daß vier Geräte einer bestimmten Art vorhanden sind, die mit einem Gruppenschalter verbunden sind. Diese Geräte bilden eine Teil eines Blockes X inner­ halb des Systems, dessen Daten bestimmte Information über die vier Geräte enthalten. Weiterhin wird angenommen, daß die folgende Information für jedes der vier Geräte gespei­ chert werden muß:
  • (a) der Zustand des Geräts;
  • (b) wo das Gerät mit dem Gruppenschalter verbunden ist; und
  • (c) der Wert eines Störungszählers, welcher die Beaufsich­ tigungs-Information über das Gerät überwacht.
Daher braucht der Block drei Variable. Aus Fig. 4 läßt sich ersehen, daß anstelle der Identifizierung eines bestimmten Wortes oder einer bestimmten Adresse innerhalb des Daten­ speichers für jedes Gerät, und Speicherung aller drei Varia­ bler, die diesem Gerät entsprechen, an diesem Ort das System die Daten so organisiert hat, daß sämtliche dem Zustand der vier Geräte zugeordnete Daten an einem Ort gruppiert sind, die Verbindung der vier Geräte an einem anderen Ort, und der Störungszähler aller vier Geräte an dem dritten Ort. Diese Orte werden als Variablen-Blöcke bezeichnet. Die jedem ein­ zelnen Gerät zugeordneten bestimmten Daten werden innerhalb dieses Ortes identifiziert.
Das System muß bestimmte Betriebsabläufe durchführen, um die Variable aufzufinden, die es braucht, und führt dies mit Hilfe von zusätzlicher Information durch, welche in dem Referenzspeicher gespeichert ist. Sämtliche Variable eines bestimmten Blocks haben eine Tabelle innerhalb des Referenz­ speichers, welche als die Basis-Adressentabelle bezeichnet wird. Die Funktionen dieser Tabellen schließen das Speichern von Information ein, welche anzeigt, wo in dem Datenspeicher die für einen bestimmten Block erforderlichen Variablen sich befinden. Jeder Variablen innerhalb eines Blockes wird eine Zahl zugeteilt, die als ein Zeiger innerhalb der Basis- Adressentabelle des Blocks verwendet wird. Die Basis-Adres­ sentabelle innerhalb des Referenzspeichers wird mit Hilfe eines Wortes aufgefunden, welches als die Basis-Startadresse (BSA) bezeichnet wird, in der Referenztabelle des Referenz­ speichers angegeben (in derselben Tabelle, die die Programm- Startadresse für diesen bestimmten Block in dem Programm­ speicher enthielt). Das Wort, welches die Speicherposition oder Startadresse des Variablen-Blocks innerhalb des Daten­ speichers angibt, wird als eine Wortadresse (WA) bezeichnet, wie in Fig. 5 erläutert. Daher werden Daten für einen Job innerhalb eines Blockes dadurch gefunden, daß die Basis- Adressentabelle für diesen Block (die an der Basis-Start­ adresse für diesen Block beginnt) ermittelt wird, und dann die Wortadresse innerhalb des Datenspeichers, in welchem sich die Daten befinden, ermittelt wird.
Das voranstehend angegebene Software-Adressierschema führt zu einer Anzahl von Vorteilen. Hierzu gehört die Tatsache, daß ein Programm irgendwo in dem Programmspeicher gespei­ chert werden kann, ohne irgendetwas zu beeinflussen, abge­ sehen von der Programm-Startadressen und dem Referenzspei­ cher. Zusätzlich kann eine einen Job umfassende Programm­ sequenz irgendwo in einem Block angeordnet werden, ohne irgendetwas zu beeinflussen, mit der Ausnahme der Adresse der Signal-Verteilungstabelle dieses Blocks. Zusätzlich ist die Anzahl der Variablen für jeden Block vollständig flexi­ bel, und es wird nur die Größe der Basis-Adressentabelle beeinflußt, die diesem Block zugeordnet ist. Schließlich kann die Anzahl der Geräte einfach erhöht oder verringert werden, da der Variablen-Block zu einem freien Bereich in dem Datenspeicher bewegt werden kann, und nur die Wortadres­ se der Daten beeinflußt wird.
Bei der Verwendung eines Software-Adressiersystems der vor­ anstehend beschriebenen Art ist es häufig erforderlich, ein Signal von einem Software-Block an einen anderen Software­ block zu schicken. Beispielsweise kann ein Überwachungsblock häufige Aktualisierungen der Anzahl von Störungen erfordern, die innerhalb eines Schalters aufgetreten sind, und daher eine häufige Aktualisierung des Wertes des Störungszählers eines bestimmten Blocks. Der anfordernde Block fordert da­ durch Information an, daß er ein Softwaresignal an den Block sendet, von welchem die Information kommen muß. Der Zentral­ prozessor führt die Übertragung derartiger Information da­ durch durch, daß er ein Softwaresignal von dem Überwachungs­ block an den Block schickt, der die Störungszähler enthält (Block X). Die Werte der Zähler werden abgelesen und in einem Softwaresignal an den Überwachungsblock zurückge­ schickt. Bevor die Signalübertragung ausgeführt wird, werden die Werte in den Registerspeicher (RM) gebracht, innerhalb der zentralen Verarbeitungseinheit angeordnet und für eine Standard-Datenübertragung zwischen den Blöcken verwendet. Die globalen Signalzahlen des Signals für den Anforderungs­ block (Block Y) werden in dem Block X innerhalb der Tabelle gespeichert, die als die Signalsendetabelle (SST) bezeichnet wird. Die Blockzahl wird in einem Register gespeichert. In Fig. 6 ist gezeigt, wie ein Signal von dem Block Y, der Daten anfordert, in bezug auf die Signal-Verteilungstabelle des Blocks gesetzt wird und daher zu der Jobadresse inner­ halb des Blocks, der dann ein Softwaresignal (BNR+LSN) in­ nerhalb der Signalsendetabelle dieses Blockes anordnet. Diese Information wird an den Registerspeicher zusammen mit den zugeordneten, angeforderten Daten von dem Datenspeicher geschickt. Dann enthält der Registerspeicher ein Softwaresi­ gnal und dessen zugeordnete Daten, die von dem Block Y ange­ fordert wurden.
Bei dem Betriebssystem eines programmgesteuerten Vermitt­ lungssystems der vorliegenden Art ordnet der Zentralprozes­ sor unterschiedliche Jobs, die durchgeführt werden sollen, in einer Schlange an und nimmt sie in einer ordnungsgemäßen Reihenfolge entsprechend einer Priorität an, die der Aus­ führung dieses Jobs zugeordnet wurde. In Fig. 7 sind mehrere Jobpuffer (JBA-JBD) gezeigt, die unterschiedliche Priori­ tätsgrade für die Ausführung aufweist. Die Puffer für Pro­ gramme zur Handhabung der Verkehrsdichte innerhalb des Ver­ bindungssystems, JBA-JBB, weisen die höchste Priorität auf, wogegen Puffer, die dem Betriebs- und Ladungsprogramm zu­ geordnet sind, nämlich JBC-JBD, die niedrigste Priorität aufweist. Wenn daher die Priorität des bestimmten Jobs auf­ tritt, die der Übertragung der Daten zugeordnet wurde, die von dem Block Y angefordert wurden, von dem Registerspeicher zu dem Block Y, und zwar in den Puffer C, welchem dieser Job zugeordnet wurde, so führt das Betriebssystem die Übertra­ gung durch und schickt die Softwaresignale zusammen mit den Daten von dem Registerspeicher zu dem Block Y, der dies angefordert hat.
In Fig. 8 ist eine schematische Darstellung der Übertragung von Softwaresignalinformation innerhalb eines modularen Softwaresystems gemäß der vorliegenden Erfindung gezeigt. Ein Block modularer Software 51, der als Block A bezeichnet ist, weist mehrere Abschnitte auf, einschließlich eines Programmcode-Auflistungsabschnitts 52, einer Signal-Vertei­ lungstabelle 53 und einer Softwaresignal-Sendetabelle 54. Zusätzlich weist ein Jobpuffer 55 mehrere Register 56 auf, in denen zeitweilig Softwaresignale gespeichert werden, die eine Bearbeitung durch den Zentralprozessor erwarten, die erforderlich ist, um diese Signale beispielsweise einem an­ fordernden Softwareblock zuzuführen. Ein weiterer Software­ block, der Block B61, weist ebenfalls einen Programmcode- Auflistungsabschnitt 62 und eine Signal-Verteilungstabelle 63 auf. Die dargestellte Ausführungsform der Erfindung um­ faßt weiterhin eine globale Signal-Verteilungstabelle 64, innerhalb derer eine Auflistung sämtlicher zentraler Signal­ zahlen für die jeweiligen Signale aufrechterhalten wird, die in jedem Block der in das System geladenen Software enthal­ ten sind.
Wie voranstehend kurz erwähnt wurde, stellt die globale Signal-Verteilungstabelle 64 ein wesentliches Element für die Aufrechterhaltung der Verknüpfungsadressen unter unter­ schiedlichen Software-Modulen dar. Die globale Signal-Ver­ teilungstabelle 64 hält die Querverweise zwischen den globa­ len Signalzahlen, die bestimmten Signalen entsprechen, die von einem Modul oder Block zu einem anderen geschickt wer­ den, und den lokalen Signalzahlen aufrecht, die jedem dieser Signale innerhalb jedes einzelnen Blocks in dem System ent­ sprechen. Wenn ein Softwareblock in das System geladen wird, so wird der Abschnitt der globalen Signal-Verteilungstabelle 64, der diesem Block entspricht, erneut so eingeschrieben, daß er eine lokale Signalzahl für jedes Signal enthält, wel­ ches innerhalb des Software-Blocks enthalten ist. Dies wird konventionellerweise dadurch vorgenommen, daß die globale Signalzahl dieses bestimmten Signals und der Blockzahl des Software-Blocks kombiniert wird, der dieses Signal enthält, über einen exklusiven ODER-Vorgang oder ein anderes Kombina­ tionsverfahren. Wenn daher ein Software-Block aus dem System entfernt wird, geändert oder auf irgendeine Weise vergrö­ ßert, die zu Änderungen der individuellen Signale innerhalb des Blocks führen, so muß dieser Abschnitt der Softwaresi­ gnal-Verteilungstabelle neu geschrieben werden, um den neuen Inhalt von Signalen innerhalb des Blocks wiederzuspiegeln, und eine neue Berechnung lokaler Signalzahlen für jedes dieser Signale innerhalb des Blocks.
Wie in Fig. 8 gezeigt ist, wird ein Softwaresignal S1 von dem Block A51 zu dem Block B61 geschickt. Der Block B61 wird als der empfangende Block bezeichnet, wogegen der Block A51 als der sendenden Block bezeichnet wird. Die Blockzahl des empfangenden Blocks wird als BNR bezeichnet. Das System soll das gewünschte Signal S1 an den empfangenden Block schicken und zuerst die globale Signalzahl für das Signal des S1 dadurch erhalten, daß auf die Signalsendeta­ belle 54 des Blocks A51 zugegriffen wird, über seine Adres­ se, welche die Programm-Startadresse des Blocks A51 (PSAA) umfaßt sowie den Wert des Signalsendezeigers (SSP). Sobald die globale Signalzahl für S1 erhalten wird, wird sie direkt in ein Register 56 innerhalb des Jobpuffers 55 geladen und wartet auf eine Übertragung zu dem Block B entsprechend der Prioritätsvereinbarungen der zentralen Verarbeitungseinheit und der Priorität, die dem betreffenden Signal, welches übertragen wird, zugeordnet ist. Während dieser Zeit wurde die Information in Form der globalen Signalzahl von S1 und der Blockzahl des empfangenden Blocks aufbewahrt. Sobald der Signalübertragungsvorgang einen ausreichenden Prioritäts­ pegel für die Ausführung der Übertragung erreicht hat, greift das System auf die globale Signal-Verteilungstabelle 64 zu, um die lokale Signalzahl von S1 in dem Block B61 zu erhalten. Dies wird dadurch durchgeführt, daß in die globale Signal-Verteilungstabelle 64 mit der Adresse hineingegangen wird, die durch Auswahl der globalen Signalnummer gefunden wurde, und eine exklusive ODER-Operation dieses Wertes mit der Blockzahl BNR durchgeführt wird. Innerhalb dieser Tabel­ le wird an dieser Adresse die lokale Signalnummer für S1 in dem Block B61, dem empfangenden Block, gefunden.
Sobald die lokale Signalzahl für S1 in dem Block B61 erhal­ ten wurde, geht dann das System in den Block B61 dadurch hinein, daß es die Befehlsadresse IA66 innerhalb des Blocks B61 auffindet, in welchen das Signal eingegeben werden soll­ te. Dies wird dadurch durchgeführt, daß von der Signal-Ver­ teilungstabelle 63 des Blockes B61 die Programm-Startadresse des Blockes B61 genommen wird (PSAB) minus der lokalen Si­ gnalzahl innerhalb des Blockes B61, um die Befehlsadresse 66 zu lesen. Sobald die Befehlsadresse 66 erhalten wurde, wird das Signal S1 in dem Block B61 eingegeben, und die Übertra­ gung ist vollständig. Daher beginnt der Befehl, der sich an der IA66 befindet, mit der Ausführung.
Der Betriebsablauf des Verfahrens gemäß der vorliegenden Er­ findung weist eine Anzahl von nützlichen Eigenschaften und Vorteilen gegenüber dem Stand der Technik auf, bei welchem zuerst die lokale Signalzahl von der globa­ len Signal-Verteilungstabelle 64 erhalten wird und dieser Wert in den Jobpuffer 55 eingegeben wird. Nachdem revidierte Softwareblöcke wiederum in das System geladen wurden, kann zuerst die Bearbeitung von Signalen immer noch durchgeführt werden, die in den Jobpuffer vor der Modifizierung und dem erneuten Laden des Blocks geladen wurden. Dies bedeutet, daß die in den Jobpuffer 55 geladenen Informationen, bevor der Block modifiziert wurde, nach der Modifizierung immer noch gültig sind, und daß der Jobpuffer nicht aktualisiert oder gelöscht werden muß, bevor der Block wiederum geladen wird. Wenn Signaleintrittspunkte entfernt wurden und die revidier­ te Version eines empfangenden Blocks, sowie ein Signal in dem Jobpuffer, welches sich auf diesen Punkt bezieht, be­ arbeitet wird, ermittelt darüber hinaus das Betriebssystem einen fehlenden Eintrag in der globalen Signal-Verteilungs­ tabelle 64, anstatt möglicherweise eine fehlerhafte Ausfüh­ rung an einer unrichtigen Befehlsadresse innerhalb des Pro­ gramms zu beginnen. Darüber hinaus können Signaleintritts­ punkte in der revidierten Version des empfangenden Punkts erneut lokalisiert werden, und bei einem erneut aufgefunde­ nen Signal wird sich die lokale Signalzahl und die globale Signal-Verteilungstabelle 64 geändert haben, und die globale Signal-Verteilungstabelle 64 wird mit dieser lokalen Signal­ zahl aktualisiert. Wenn Signale zu diesem Eintrittspunkt in den Jobpuffer verarbeitet wurden, so wird die korrekte loka­ le Signalzahl aus der globalen Singal-Verarbeitungstabelle 64 durch das Betriebssystem erhalten, wodurch mögliche Feh­ ler ausgeschaltet werden.
Eine Tatsache muß in Verbindung mit der Anwendung des Sy­ stems der vorliegenden Erfindung berücksichtigt werden, und dies ist die Tatsache, daß bei der Modifizierung eines Co­ des, der einen Signaleintrittspunkt in einem Block beein­ flußt, berücksichtigt werden muß, daß dann, wenn die Daten­ strukturen modifiziert werden, Aufrufe dieses neuen oder modifizierten Codes alte Parameterwerte erreichen können, beispielsweise Signaldaten, die das Signal in dem Jobpuffer begleiten, welche Adressen und/oder Daten in dem Format der Datenstruktur enthalten, die vor der Modifizierung verwendet wurde. Wenn andererseits der Block zum Zeitpunkt der erneu­ ten Ladung des frisch modifizierten Softwareblocks Rückkehradressen aufweist, so werden die lokalen Signalzahlen auf den Rückkehradressenstapeln, die zwischen der alten und der neuen Version modifiziert wurden, durch das Betriebs­ system aktualisiert.
Wie in Fig. 9 gezeigt wird, einem Flußdiagramm eines Teils des Verfah­ rens gemäß der vorliegenden Erfindung, nämlich des Signal­ sendebefehls im Schritt 17, beginnt ein innerhalb der zen­ tralen Bearbeitungseinheit (CPU) enthaltenes Mikroprogramm mit dem Signalübertragungsvorgang durch Einlesen der globa­ len Signalzahl von S1 von dem SST54 des Blocks A51. Das SSI70 fügt dann Signale in die Warteschlange des Jobpuffers 55 in dem Schritt 71 ein, und schreibt die GSN und die BNR in den Jobpuffer 55 ein. Daraufhin bearbeitet das Betriebs­ system 72 das Signal S1 von dem Block A51 zu dem Block B61 in dem Schritt 72 durch Lesen der globalen Signalzahl des Signals und der BNR von dem Jobpuffer 55, und durch Lesen seiner lokalen Signalzahl in dem Block B61 aus der globalen Signal-Verteilungstabelle 64. Daraufhin wird der IA66-Ein­ trittspunkt in dem Block B61 aus dem SDT63 des Blockes B61 in dem Schritt 73 gelesen, und der sich an diesem Punkt befindende Befehl beginnt mit der Ausführung in dem Schritt 74. Der Vorgang legt das nächste zu bearbeitende Signal in dem Schritt 75 fest, der dann für andere, darauf folgende Signale wiederholt wird, die eine Übertragung zwischen Blöc­ ken innerhalb des Systems erfordern.
Nachstehend ist ein Abschnitt eines Pseudo-Codes angegeben, der zur Implementierung der Programmlogik für das Laden und die Aufrechterhaltung der GSDT verwendet werden kann, wenn ein revidierter Block erneut in das System geladen wird, entsprechend dem erfindungsgemäßen Verfahren. Aus dieser Schil­ derung sollte deutlich werden, wie der tatsächliche Code geschrieben werden würde, um die vorliegende Erfindung zu implementieren.
Es wird daher angenommen, daß der Betriebsablauf des Verfahrens gemäß der vorliegenden Erfindung aus der voranstehen­ den Diskussion deutlich wird. Zwar wurde das Verfahren, das detail­ liert beschrie­ ben wurde, als bevorzugt gekennzeichnet, jedoch ist es selbstverständlich, daß hierin unterschiedliche Änderungen und Modifikationen vorgenommen werden können.

Claims (5)

1. Verfahren zum Betreiben einer Datenverarbeitungsanlage, bei welchem Betriebsprogramme in funktionale Blöcke unterteilt sind, die in einen Hauptspeicher eingelagert und ausgelagert werden, und deren Zusammenarbeit durch einen Zentralprozessor der Datenverarbeitungsanlage gesteuert wird, wobei
  • - jede Tätigkeit eines Blocks (A, B, . . . ) durch Senden eines Signals (S1) zu dem Block eingeleitet wird;
  • - jedem Signal (S1) in einem ersten Block (A) eine lokale Signalzahl (LSN) zugeordnet wird;
  • - die lokale Signalzahl (LSN) in einer globalen Signal- Verteilungstabelle (GSDT, 64) gespeichert wird;
  • - dem Signal (S1) weiterhin eine Blockzahl (BNR) zugeteilt wird, die einen zweiten Block (B) bezeichnet, an welchen das Signal (S1) gesendet werden soll;
  • - aus der lokalen Signalzahl (LSN) und der Blockzahl (BNR) ein Softwaresignal (BNR + LSN) gebildet wird;
  • - dem Softwaresignal (BNR + LSN) eine globale Signalzahl (GSN) zugeordnet wird; und
  • - die globale Signal-Verteilungstabelle (GSDT, 64) zum Zeitpunkt des Ladens eines Blockes aktualisiert wird; und wobei die Übertragung eines Softwaresignals von einem ersten Block (A) zu einem zweiten Block (B) folgende Schritte umfaßt:
  • - Festlegung des Softwaresignals in dem ersten Block (A), das zu dem zweiten Block (B) übertragen werden soll;
  • - Übertragung der dem Softwaresignal zugeordneten globalen Signalzahl (GSN) zusammen mit der Blockzahl (BNR) des zweiten Blocks (B) an ein Register (56) innerhalb eines Jobpuffers (55) des Zentralprozessors;
  • - Zugriff auf die globale Signal-Verteilungstabelle (GSDT, 64), um die lokale Signalzahl (LSN) zu erhalten, welche der globalen Signalzahl (GSN) des Softwaresignals in dem zweiten Block (B) entspricht; und
  • - Übertragung des Softwaresignals an die Adresse in dem zweiten Block (B), welche der lokalen Signalzahl (LSN) entspricht.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt des Zugriffs auf die globale Signal- Verteilungstabelle (GSDT, 64), um die lokale Signalzahl (LSN) des Softwaresignals zu erhalten, unmittelbar vor der Übertragung des Softwaresignals von dem Jobpuffer zu dem zweiten Block (B) durchgeführt wird.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß jeder Block (A, 51) einen Codeabschnitt (52) aufweist, eine Signalverteilungstabelle (SDT, 53) und eine Signalsendetabelle (SST, 54), und daß eine lokale Adresse des Softwaresignals in dem zweiten Block (B, 61) mit dem Softwaresignal unmittelbar vor der Übertragung des Softwaresignals von dem Jobpuffer (55) an den zweiten Block (B, 61) und nach der Ladung des Softwaresignals in den Jobpuffer (57) von dem ersten Block (A, 51) verbunden wird.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß die Übertragung des Softwaresignals von dem Jobpuffer (55) an den zweiten Block (B, 61) folgende Schritte umfaßt:
  • - Bestimmung eines Eingangspunktes einer Befehlsadresse (IA, 66) für das Softwaresignal in dem zweiten Block (B, 61); und
  • - Einleitung der Ausführung an der Befehlsadresse (IA, 66) in dem zweiten Block.
5. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß das Laden des Softwaresignals in den Jobpuffer (55) dadurch durchgeführt wird, daß auf eine globale Signalnummer (GSN) und eine Nummer (BNR), welche dem Softwaresignal zugeordnet ist, von der Signalsendetabelle (SST) aus zugegriffen wird, und die globale Signalnummer (GSN) und eine Nummer (BNR), welche dem zweiten Block (B, 61) zugeordnet ist, in den Jobpuffer (55) eingeschrieben werden.
DE4220698A 1991-07-23 1992-06-24 Verfahren zum Betreiben einer Datenverarbeitungsanlage Expired - Lifetime DE4220698C2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US07/734,456 US5297285A (en) 1991-07-23 1991-07-23 System for dynamically linking modular portions of computer software

Publications (2)

Publication Number Publication Date
DE4220698A1 DE4220698A1 (de) 1993-01-28
DE4220698C2 true DE4220698C2 (de) 1997-05-15

Family

ID=24951767

Family Applications (1)

Application Number Title Priority Date Filing Date
DE4220698A Expired - Lifetime DE4220698C2 (de) 1991-07-23 1992-06-24 Verfahren zum Betreiben einer Datenverarbeitungsanlage

Country Status (4)

Country Link
US (1) US5297285A (de)
DE (1) DE4220698C2 (de)
GB (1) GB2258068B (de)
SE (1) SE514861C2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19704855A1 (de) * 1997-02-10 1998-08-13 Gsf Forschungszentrum Umwelt Verfahren zum Betreiben von Datenverarbeitungsanlagen

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0458495A3 (en) * 1990-05-21 1993-04-14 Texas Instruments Incorporated Apparatus and method for managing versions and configurations of persistent and transient objects
US5396614A (en) * 1992-06-25 1995-03-07 Sun Microsystems, Inc. Method and apparatus for a secure protocol for virtual memory managers that use memory objects
US5339430A (en) * 1992-07-01 1994-08-16 Telefonaktiebolaget L M Ericsson System for dynamic run-time binding of software modules in a computer system
US5410703A (en) * 1992-07-01 1995-04-25 Telefonaktiebolaget L M Ericsson System for changing software during computer operation
US5625845A (en) * 1992-10-13 1997-04-29 International Business Machines Corporation System for facilitating continuous, real-time, unidirectional, and asynchronous intertask and end-device communication in a multimedia data processing system using open architecture data communication modules
GB2272085A (en) * 1992-10-30 1994-05-04 Tao Systems Ltd Data processing system and operating system.
GB2288041A (en) * 1994-03-23 1995-10-04 Ibm Object linking and embedding over a computer network.
WO1995027359A2 (en) * 1994-04-01 1995-10-12 Ericsson Telefon Ab L M Mobility in telecommunication networks
DE19502728A1 (de) * 1995-01-28 1996-08-01 Philips Patentverwaltung Telekommunikationsvorrichtung
US6078945A (en) * 1995-06-21 2000-06-20 Tao Group Limited Operating system for use with computer networks incorporating two or more data processors linked together for parallel processing and incorporating improved dynamic load-sharing techniques
US5682534A (en) * 1995-09-12 1997-10-28 International Business Machines Corporation Transparent local RPC optimization
US6332168B1 (en) 1995-09-28 2001-12-18 International Business Machines Corporation Method of, system for, and computer program product for providing a run time subsystem for run time libraries
US6389483B1 (en) 1995-10-17 2002-05-14 Telefonaktiebolaget L M Ericsson (Publ) System and method for reducing coupling between modules in a telecommunications environment
US6467085B2 (en) 1995-10-17 2002-10-15 Telefonaktiebolaget L M Ericsson (Publ) System and method for reducing coupling in an object-oriented programming environment
US5894574A (en) * 1996-05-03 1999-04-13 Alcatel Usa Sourcing, L.P. Apparatus and method for SIB-based global title translation services
US5896535A (en) * 1996-08-20 1999-04-20 Telefonaktiebolaget L M Ericsson (Publ) Method and system for testing computer system software
JPH1185524A (ja) * 1997-09-05 1999-03-30 Toshiba Corp 情報処理装置及び方法並びに情報処理プログラムを記録した記録媒体
JPH11110194A (ja) * 1997-10-06 1999-04-23 Toshiba Corp 外部ライブラリ関数との結合方法ならびに同方法がプログラムされ記録される記録媒体
US6151709A (en) * 1998-02-13 2000-11-21 Novell, Inc. Processes and apparatuses for uploading instructions to a computer
US6222916B1 (en) 1998-05-22 2001-04-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for introducing and modifying telecommunications services
US6253367B1 (en) 1998-11-18 2001-06-26 Micrografx, Inc. Method and system for transforming dynamic content for use on the internet
DE10134463A1 (de) * 2001-07-16 2003-02-13 Tenovis Gmbh & Co Kg Verfahren zur Speicherung von Software einer TK-Anlage
US7210145B2 (en) * 2001-10-15 2007-04-24 Edss, Inc. Technology for integrated computation and communication; TICC
WO2007123527A1 (en) * 2006-04-20 2007-11-01 Srinivasan Chitoor V Technology for integrated computation and communication; ticc

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3969701A (en) * 1973-04-09 1976-07-13 Telefonaktiebolaget L M Ericsson Function block oriented SPC system
FR2230258A5 (de) * 1973-05-16 1974-12-13 Honeywell Bull Soc Ind
AT342119B (de) * 1973-05-17 1978-03-10 Siemens Ag System mit einer datenverarbeitungsanlage fur die abwicklung von programmen, insbesondere zur steuerung einer fernsprechvermittlungsanlage
US4037215A (en) * 1976-04-30 1977-07-19 International Business Machines Corporation Key controlled address relocation translation system
US4074072A (en) * 1976-05-24 1978-02-14 Bell Telephone Laboratories, Incorporated Multiprocessor control of a partitioned switching network by control communication through the network
US4138738A (en) * 1978-07-24 1979-02-06 Drogichen Daniel P Self-contained relocatable memory subsystem
US4425618A (en) * 1981-11-23 1984-01-10 Bell Telephone Laboratories, Incorporated Method and apparatus for introducing program changes in program-controlled systems
SE439208B (sv) * 1983-09-30 1985-06-03 Ericsson Telefon Ab L M Programminnesstyrd telekommunikationsanleggning
GB8405491D0 (en) * 1984-03-02 1984-04-04 Hemdal G Computers
US4853842A (en) * 1985-09-11 1989-08-01 Texas Instruments Incorporated Computer memory system having persistent objects
US4833604A (en) * 1986-01-13 1989-05-23 International Business Machines Corporation Method for the relocation of linked control blocks
EP0262486B1 (de) * 1986-09-25 1993-11-18 Siemens Aktiengesellschaft Adressenverwaltungseinheit einer Multiprozessor-Zentralsteuereinheit eines Nachrichten-Vermittlungssystems
US4849877A (en) * 1986-12-22 1989-07-18 American Telephone And Telegraph Company Virtual execution of programs on a multiprocessor system
US4791558A (en) * 1987-02-13 1988-12-13 International Business Machines Corporation System and method for generating an object module in a first format and then converting the first format into a format which is loadable into a selected computer
US4980844A (en) * 1988-05-27 1990-12-25 Victor Demjanenko Method and apparatus for diagnosing the state of a machine
US5073852A (en) * 1988-12-16 1991-12-17 Cayman Systems, Inc. Network protocol translator including method and apparatus for reducing interprocess communication and data exchange overhead
US4961141A (en) * 1988-12-16 1990-10-02 International Business Machines Corporation Generating efficient code for a computer with dissimilar register spaces
US5006976A (en) * 1989-02-23 1991-04-09 Fisher Controls International, Inc. Process control terminal
GB2242293A (en) * 1990-01-05 1991-09-25 Apple Computer Apparatus and method for dynamic linking of computer software components

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19704855A1 (de) * 1997-02-10 1998-08-13 Gsf Forschungszentrum Umwelt Verfahren zum Betreiben von Datenverarbeitungsanlagen

Also Published As

Publication number Publication date
SE9202036L (sv) 1993-01-24
GB2258068A (en) 1993-01-27
SE9202036D0 (sv) 1992-07-01
SE514861C2 (sv) 2001-05-07
DE4220698A1 (de) 1993-01-28
GB9212016D0 (en) 1992-07-15
GB2258068B (en) 1996-02-28
US5297285A (en) 1994-03-22

Similar Documents

Publication Publication Date Title
DE4220698C2 (de) Verfahren zum Betreiben einer Datenverarbeitungsanlage
EP0635792B1 (de) Verfahren zur Koordination von parallelen Zugriffen mehrerer Prozessoren auf Resourcenkonfigurationen
DE4011745A1 (de) Taskverfolgungseinrichtung
DE2630323A1 (de) Datenspeichereinrichtung
DE1934365A1 (de) Automatische Programmschaltung bei Computern mit Multiprogrammierung
DE2854397A1 (de) Pufferspeichereinheit fuer ein datenverarbeitungssystem
DE68924719T2 (de) Vorrichtung und Verfahren zur Ausführung eines Unterprogramms in einem Datenverarbeitungssystem mit Blockumschaltung.
DE2054830C3 (de) Informationsverarbeitungsanlage mit Mitteln zum Zugriff zu Speicher-Datenfeldern variabler Länge
DE2801563A1 (de) Dialogprozessor
DE2400064A1 (de) Speicherpruefanordnung und diese verwendendes endgeraetsystem in einem datenverarbeitungssystem
DE4207158A1 (de) Speicher-zugriffssteuerung
DE102006036837A1 (de) Datenspeicherverwaltungsverfahren und -system
DE69133025T2 (de) Multiprozessorsystem
DE68923864T2 (de) Anordnung zur Speicher- und Peripherie-Bausteinauswahl.
DE2101949A1 (de) Verfahren zum Schutz von Datengruppen in einer Multiprocessing-Datenverarbeitungsanlage
DE2856680A1 (de) Befehlspuffer fuer ein datenverarbeitungssystem
DE2350229A1 (de) Datenverarbeitungsanlage, insbesondere als steuereinrichtung fuer fernsprechvermittlungsanlagen
DE2912073A1 (de) Stapelspeicheranordnung zur kurzzeitigen speicherung von informationen bei nichtabsetzbarkeit dieser informationen in einem datenverarbeitungssystem
DE2458286A1 (de) Datenverarbeitungssystem zum verschieben von datenfeldern mit verschiedenen strukturen
EP0632668B1 (de) Verfahren zum Aktualisieren eines Systemprogramms in einer Vermittlungseinrichtung
EP0409330A2 (de) Schaltungsanordnung zum Steuern des Zugriffs auf einen Speicher
EP1235123A2 (de) Addon-Mechanismus für ein Steuerungssystem basierend auf einem Typdatenfeld
DE2507405A1 (de) Verfahren und anordnung zum synchronisieren der tasks in peripheriegeraeten in einer datenverarbeitungsanlage
DE3782546T2 (de) Datenpaketverkuerzungsverfahren und -vorrichtung.
DE10121745A1 (de) Verfahren und Anordnung zu einem Stack mit einem, in Datengruppen mit mehreren Elementen aufgeteilten Speicher

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
D2 Grant after examination
8364 No opposition during term of opposition
R071 Expiry of right
R071 Expiry of right