FR 2721159 A1 19951215 FR 9506153 A 19950519 INTERFACE DE COMMUNICATION PAR MODEM DANS UN SYSTEME DE TRAITEMENT DE DONNEES Domaine technique: La présente invention se rapporte en général à un procédé et à un système pour procurer des échanges de données entre des systèmes de traitement de données et en particulier à un procédé et à un système pour procurer des communications par modem entre des systèmes de traitement de données. Encore plus particulièrement, la présente invention se rapporte à un procédé et à un système pour procurer des communications par modem entre des applications multiples dans des systèmes de traitement de données différents. Art antérieur: Un modem est un dispositif utilisé pour transmettre des données entre des systèmes de traitement de données tels que des ordinateurs, des postes de travail et autres dispositifs périphériques interconnectés au moyen de lignes de communication classiques qui supportent des transmissions analogiques. Les Modems transforment (modulent) les données numériques d'un dispositif numérique, tel qu'un ordinateur, sous une forme analogique appropriée pour la transmission sur des lignes de communication classiques. Un modem reçoit également un signal analogique et reconstitue (démodule) le signal analogique sous sa forme originale. Les Modems se présentent sous un certain nombre de formes et de types différents. Différents Modems présentent des vitesses de transmission différentes et ils peuvent être reliés de façon externe ou interne à un système de traitement de données. Les Modems peuvent comprendre un certain nombre de caractéristiques telles que l'appel automatique, la détection de vitesse automatique du modem qui est appelé, et la commutation automatique à la vitesse du modem qui est appelé, la détection et la correction d'erreur, la compression de données, et les techniques de modulation multiples. Avec l'apparition de OS/2, l'exécution simultanée de programmes multiples est devenue un point particulier d'attention des développeurs de programme. "OS/2" est une marque déposée de International Business Machines Corporation, situé à Armonk, New York. De telles applications dans un système de traitement de données peuvent rassembler des données provenant d'autres systèmes de traitement de données à l'intérieur d'un réseau. Quelquefois un utilisateur, utilisant un système de traitement de données présentant des applications multiples s'exécutant simultanément sur un site, peut souhaiter obtenir des données d'un autre système de traitement de données présentant des applications multiples s'exécutant simultanément sur un second site en utilisant un modem. Dans une telle situation, il serait avantageux d'avoir un procédé et un système pour procurer des communications de données entre des applications multiples s'exécutant simultanément sur différents systèmes de traitement de données. RESUME DE L'INVENTION C'est de ce fait un but de la présente invention de procurer un procédé et un système pour fournir des échanges de données entre des systèmes de traitement de données. C'est un autre but de la présente invention de procurer un procédé et un système pour fournir des communications par modem entre des systèmes de traitement de données. C'est encore un autre but de la présente invention de procurer un procédé et un système pour fournir des communications par modem entre des applications multiples dans des systèmes de traitement de données différents. Les buts précédents sont obtenus de la façon qui est décrite à présent. La présente invention comprend un appareil pour procurer des communications entre deux systèmes de traitement de données. La présente invention comprend un premier système de traitement de données, un second système de traitement de données, et une ligne de communication reliant les premier et second systèmes de traitement de données. Une première interface située sur le premier système de traitement de données et une seconde interface située sur le second système de traitement de données sont également comprises, dans lesquelles la première interface comprend un moyen pour établir une liaison entre la première et la seconde interface, un moyen pour établir une session pour chaque application sur le premier système de traitement de données demandant une communication avec une application sur le second système de traitement de données et dans lequel la première et la seconde interface comprend un moyen pour contrôler les communications entre les applications qui ont une session établie. Dans mode de réalisation préféré, si la liaison est arrêtée, les sessions ne sont pas arrêtées. Au lieu de cela, la liaison est réétablie automatiquement ou en réponse à un événement quelconque. La liaison peut être arrêtée intentionnellement audit ! f temps de liaison ou pour relier les autres systèmes de traitement de données tout en conservant les sessions établies. Ce qui précède, de même que des buts supplémentaires, particularités et avantages de la présente invention seront mis en évidence dans la description écrite détaillée suivante. BREVE DESCRIPTION DES ILLUSTRATIONS Les particularités novatrices considérées comme caractéristiques de l'invention sont mises en évidence dans les revendications annexées. Cependant, l'invention en elle-même de même qu'un mode d'utilisation préféré, d'autres buts et avantages de celle-ci, seront mieux compris par référence à la description détaillée suivante d'un mode de réalisation à titre d'exemple, lorsque lus en liaison avec les illustrations annexées, dans lesquelles: La figure 1 décrit un système de traitement de données sous la forme d'un ordinateur personnel dans lequel la présente invention qui peut être utilisée, est décrite. La figure 2 est un schéma synoptique d'un système d'ordinateur personnel illustrant les différents composants du système d'ordinateur personnel conformément à la présente invention. La figure 3 décrit un schéma synoptique des composants logiciels utilisés pour transmettre les données entre des applications multiples sur une ligne de communication conformément avec un mode de réalisation préféré de la présente invention. La figure 4 est un schéma synoptique d'une interface décrite sur la figure 3. La figure 5 décrit une structure de communication en conformité avec un mode de réalisation préféré de la présente invention. La figure 6 décrit une structure de données à bloc de commande de réseau par modem. La figure 7 décrit une structure de données qui est un en-tête. La figure 8 décrit une structure de transaction utilisée pour mettre en file d'attente les transactions. La figure 9 est une structure de données utilisée pour garder la trace des sessions actives, et Les figures 10 à 21 sont des organigrammes des processus utilisés pour procurer des sessions multiples sur une ligne de communication conformément à un mode de réalisation préféré de la présente invention. DESCRIPTION DETAILLEE DU MODE DE REALISATION PREFERE En se référant à présent aux figures, et en particulier à la figure 1, il est décrit un système de traitement de données, un système 10 d'ordinateur personnel, dans lequel la présente invention peut être utilisée. Comme représenté, le système d'ordinateur personnel 10 comprend un certain nombre de composants, qui sont interconnectés ensemble. Plus particulièrement, une unité de système 12 est reliée à et peut commander un moniteur en option 14 (tel qu'un dispositif d'affichage vidéo classique). Une unité de système 12 peut également être reliée en option à des dispositifs d'entrée tels qu'un clavier de PC 16 ou une souris 18. La souris 18 comprend des boutons droit et gauche (non représentés). Le bouton gauche est généralement utilisé comme bouton de sélection principale et en variante est appelé le premier bouton de souris ou bouton de souris 1. Le bouton de droite est utilisé, de façon caractéristique, pour sélectionner des fonctions auxiliaires comme cela sera expliqué plus loin. Le bouton de souris droit est appelé en variante second bouton de souris ou bouton de souris 2. Un dispositif de sortie optionnel, tel que l'imprimante 20, peut également être relié à l'unité de système 12. Enfin, l'unité de système 12 peut comprendre un dispositif de mémorisation de masse ou plus, tel que le lecteur de disquette 22. Comme cela est décrit ci-dessous, l'unité de système 12 répond aux dispositifs d'entrée, tels que le clavier de PC 16, la souris 18 ou les interfaces de mise en réseau local. En outre, les dispositifs d'entrée/sortie (E/S), tels qu'un lecteur de disquette souple 22, un dispositif d'affichage 14, une imprimante , et un système de communication de réseau local sont reliés à l'unité de système 12 d'une façon bien connue. Bien sûr, les personnes expérimentées dans la technique sont conscientes que d'autres composants classiques peuvent également être reliés à l'unité de système 12 pour interagir avec eux. Conformément à la présente invention, le système d'ordinateur personnel 10 comprend un processeur de système qui est interconnecté à une mémoire vive (RAM), une mémoire morte (ROM), et une pluralité de dispositifs d'entrée/sortie. Dans une utilisation normale, le système d'ordinateur personnel peut être conçu pour fournir une puissance de calcul indépendante à un petit groupe d'utilisateurs en tant que serveur ou à un seul utilisateur et est d'un prix peu élevé pour qu'il puisse être acheté par des utilisateurs individuels ou des petites entreprises. En fonctionnement, le processeur du système fonctionne avec un système d'exploitation tel que le système d'exploitation d'IBM OS/2 ou le DOS. OS/2 est une marque déposée d'International Business Machines Corporation. Ce type de système d'exploitation comprend une interface (BIOS) de systèmes de base d'entrée/sortie entre les dispositifs d'entrée/sortie et le système d'exploitation. Le BIOS qui peut être mémorisé dans une mémoire morte sur une carte mère ou une carte de type fond de panier, comprend des sous-programmes de diagnostics qui sont inclus dans une section d'autotest à la mise sous tension appelée POST. Avant d'établir la relation entre la structure ci-dessus et la présente invention, un résumé du fonctionnement général du système d'ordinateur personnel 10 peut mériter d'être passé en revue. En se référant à la figure 2, il est représenté un schéma synoptique d'un système d'ordinateur personnel 10 illustrant les divers composants du système d'ordinateur personnel 10 conformément à la présente invention. La figure 2 illustre en outre les composants de la carte de type fond de panier 11 et la liaison de la carte de type fond de panier 11 aux connecteurs d'entrée/sortie 46a à 46d et autres circuits du système d'ordinateur personnel 10. L'unité de traitement central du système (UC) 26 est reliée à la carte de type fond de panier 11 et est constituée d'un microprocesseur qui est relié par un bus local d'unité centrale à haute vitesse 24 par l'intermédiaire d'une unité de synchronisation contrôlée par bus 38 à une unité de commande de mémoire 50 qui est en outre reliée à une mémoire vive volatile 58 (RAM). Alors que tout microprocesseur approprié peut être utilisé pour l'unité centrale 26, un microprocesseur approprié est le microprocesseur Pentium, qui est commercialisé par Intel Corporation. "Pentium" est une marque déposée d'Intel Corporation. Alors que la présente invention est décrite ci-dessous en faisant une référence particulière au schéma synoptique de système de la figure 2, on doit comprendre au vu de la description qui suit, qu'il est envisagé que l'appareil et les procédés conformes à la présente invention puissent être utilisés avec d'autres configurations de circuit de la carte de type fond de panier. Par exemple, le processeur du système pourrait être un microprocesseur Intel 80286, 80386 ou 80486. Ces microprocesseurs particuliers peuvent fonctionner dans un mode d'adressage réel ou dans un mode d'adressage protégé. Chaque mode procure un processus d'adressage pour accéder à différentes zones de la mémoire du microprocesseur. En revenant à présent à la figure 2, le bus local d'unité centrale 24 (comprenant des composants de données, d'adresse et de commande) procure la liaison à l'unité centrale 26, à un coprocesseur mathématique optionnel 27, à un contrôleur d'antémémoire 28, et à une antémémoire 30. Une mémoire tampon 32 est également reliée au bus local d'unité centrale 24. La mémoire tampon 32 est elle-même reliée à un bus système 34 à vitesse inférieure (comparé au bus local d'unité centrale), comprenant également des composants d'adresse, de données et de commande. Le bus de système 34 s'étend entre la mémoire tampon 32 et une autre mémoire tampon 36. Le bus de système 34 est en outre relié à une commande de bus et à une unité de synchronisation 38 et une unité d'accès direct mémoire (DMA) 40. L'unité d'accès direct mémoire est constituée d'une unité d'arbitrage centrale 48 et d'un contrôleur d'accès direct mémoire 41. La mémoire tampon 36 procure une interface entre le bus du système 34 et un bus à caractéristique optionnelle tel que le bus Micro Channel 44. "Micro Channel" est une marque déposée de International Business Machines Corporation. Une pluralité de connecteurs d'entrée/sortie 46a à 46d sont reliés au bus 44 pour recevoir les cartes d'adaptation de Micro Channel qui peuvent être en outre reliées à un dispositif d'entrée/sortie ou à une mémoire. Dans l'exemple décrit, le connecteur d'entrée/sortie 46a comporte une unité de disque dur qui lui est reliée, le connecteur d'entrée/sortie 46b comporte un lecteur de CD/ROM qui lui est relié, et le connecteur d'entrée/sortie 46c comporte une mémoire morte sur une carte d'adaptation qui lui est reliée. Un modem peut être relié à un connecteur d'entrée/sortie. Un bus de commande d'arbitrage 42 relie le contrôleur d'accès direct mémoire 41 et une unité d'arbitrage centrale 48 aux connecteurs d'entrée/sortie 46 et à l'adaptateur de disquette 82. Une unité de commande mémoire 50 est également reliée au bus de système 34 et est constituée d'un contrôleur de mémoire 52, d'un multiplexeur d'adresse 54, et d'une mémoire tampon de données 56. L'unité de commande mémoire 50 est en outre reliée à une mémoire vive telle que représentée par le module de mémoire vive 58. Le contrôleur de mémoire 52 comprend la logique pour transposer les adresses depuis et vers l'unité centrale 26 dans des zones particulières de la mémoire vive 58. Alors que le système d'ordinateur personnel 10 est représenté avec un module de mémoire vive de base de 1 mégaoctet, il peut être compris que de la mémoire supplémentaire peut être interconnectée comme représenté sur la figure 2 par les modules mémoire optionnels 60 à 64. Une autre mémoire tampon 66 est reliée entre le bus de système 34 et un bus d'entrée/sortie de type fond de panier 68. Le bus d'entrée/sortie de type fond de panier 68 comprend des composants d'adresse, de données et de commande respectivement. Divers adaptateurs d'entrée/sortie et autres composants périphériques tels que l'adaptateur d'affichage 70 (qui est utilisé pour attaquer un dispositif d'affichage optionnel 14) sont reliés le long du bus de fond type de panier 68, ainsi qu'une horloge 72, une mémoire vive non volatile 74 (appelée ci-après "NVRAM"), une adaptateur RS232 76, un adaptateur parallèle 78, une pluralité de temporisateurs 80, un adaptateur de disquette 82, un contrôleur de clavier de PC/souris 84, et une mémoire morte (ROM) 86. La mémoire morte 86 comprend le BIOS qui procure les communications transparentes pour les utilisateurs entre beaucoup de dispositifs d'entrée/sortie. L'horloge 72 est utilisée pour les calculs d'heure du jour. La NVRAM 74 est utilisée pour mémoriser des données de configuration du système. C'est-à-dire que la NVRAM contient des valeurs qui décrivent la configuration actuelle du système. Par exemple, la NVRAM 74 contient des informations qui décrivent la capacité d'un disque fixe ou d'une disquette, le type du dispositif d'affichage, la quantité de mémoire, etc.. La NVRAM 74 contient des données d'une importance particulière qui sont utilisées pour décrire la configuration de la console du système, c'est-à-dire si un clavier de PC est relié au contrôleur de clavier/souris 84, si un contrôleur d'affichage est disponible ou si le terminal ASCII est relié à l'adaptateur RS232 76. En outre, ces données sont mémorisées dans la NVRAM 74 à chaque fois qu'un programme de configuration particulier est exécuté. Le but du programme de configuration est de mémoriser les valeurs caractérisant la configuration de ce système dans la NVRAM 76, celle-ci étant sauvegardée lorsque l'alimentation du système est supprimée. Les accès A et B sont reliés au contrôleur de clavier/souris 84. Ces accès sont utilisés pour relier un clavier de PC (par opposition à un terminal ASCII) et une souris au système PC. Un connecteur RS232 est relié à l'unité d'adaptation RS232 76. Un terminal ASCII optionnel peut être relié au système par l'intermédiaire de ce connecteur. Plus particulièrement, le système d'ordinateur personnel 10 peut être réalisé en utilisant tout ordinateur approprié tel que l'ordinateur IBM PS/2 ou un ordinateur IBM RISC SYSTEM/6000, tous deux étant des produits d'International Business Machines Corporation, situé à Armonk, New York. "RISC SYSTEM/6000" est une marque déposée d'International Business Machines Corporation et "PS/2" est une marque déposée d'International Business Machines Corporation. Conformément à un mode de réalisation préféré de la présente invention, OS/2 est le système d'exploitation pour lequel l'interface de modem est réalisée. Les personnes expérimentées dans la technique se rendront compte que la présente invention peut être réalisée avec d'autres systèmes d'exploitation multitâche. OS/2 procure la possibilité d'exécuter des programmes simultanément dans un environnement protégé. Ce système d'exploitation définit le modèle utilisé pour partager les ressources du système dans un système de traitement de données. Le modèle comprend une hiérarchie d'objets multitâche appelés sessions, processus, et enchaînements. Une session est l'unité pour le partage du dispositif d'entrée/sortie. Les processus constituent l'unité de partage des ressources telles que la mémoire, les fichiers, les indicateurs, les caractères d'indicateur, et les enchaînements. Un processus est analogue à un programme. Un enchaînement est l'unité de base d'exécution. Un seul processus peut comprendre des enchaînements multiples qui s'exécutent simultanément dans celui-ci. Un indicateur est une entité utilisée pour commander les accès aux ressources du système. Les processus peuvent être verrouillés sur une ressource avec des indicateurs si le processus suit des conventions de programmation spécifiés. On peut trouver plus d'informations sur OS/2 dans un texte intitulé The Design of 0S/2 par Deitel et Kogan, publié par Addison-Wesley Publishing Company 1992. En faisant maintenant référence à la figure 3, un schéma synoptique de composants logiciels utilisé pour transmettre des données entre des applications multiples sur une ligne de communication, telle qu'une ligne téléphonique, est décrit conformément à un mode de réalisation préféré de la présente invention. Le système de traitement de données 300 comprend des applications A et E et une interface 302. Le système de traitement de données 304 contient les applications B, C, D et l'interface 306. Les systèmes de traitement de données 300 et 304 sont reliés l'un à l'autre par l'intermédiaire des Modems 301 et 303 et de la ligne de communication 308. Une ligne de communication peut être par exemple, un câble série reliant les systèmes de traitement de données ou un réseau commuté, tel que le réseau de télécommunication commuté. Dans un réseau de télécommunication commuté, les données peuvent être transmises au travers de ce réseau sous diverses formes. Les données peuvent par exemple, commencer sous forme d'un signal analogique et, arrivées à un certain point, être converties en un signal numérique pour une transmission ultérieure. Un réseau de télécommunication commuté peut comprendre également des liaisons de communication sans fil ou des liaisons à micro-onde pour transmettre des données au travers du réseau commuté. De façon caractéristique, pour que l'application A reçoive ou envoie des données aux applications B à D, l'application A doit initialiser une session avec l'une des applications et terminer tous les échanges de données avec l'application avant de commencer un échange de données avec une autre application dans le système de traitement de données 304. Avec la présente invention, des sessions multiples peuvent être présentes en même temps. Par exemple, en plus de l'application A qui exécute une session avec l'application D, l'application E pourrait communiquer avec l'application C dans une autre session sur la même ligne de communication. La présente invention procure la possibilité pour une application A de communiquer avec les applications B, C et D en même temps. L'application A appellera chacune des applications en utilisant une fonction d'appel synchrone, telle que MNCall. Cette fonction particulière est décrite plus en détail ci-dessous. Après que toutes les applications aient été appelées et qu'une session ait été établie, les données peuvent être envoyées entre l'application A et les applications B, C et D d'une manière similaire à un "partage du temps", qui est une technique utilisée pour partager les ressources dans un environnement multitâche. A un certain point, l'application A peut arrêter les communications avec une des applications ou plus dans le système de traitement de données 304. En outre, E peut communiquer avec D en même temps. En se référant maintenant à la figure 4, un schéma synoptique d'une interface, telle que l'interface 302 ou 306 sur la figure 3A, est décrite conformément à un mode de réalisation préféré de la présente invention. L'interface 302 comprend une plate-forme d'outil adaptatif (ATP) 312 qui est disponible chez International Business Machines Corporation. L'ATP 312 reçoit des ordres et des demandes de données depuis une application, telle que l'application A sur la figure 3. L'ATP 312 utilise le module de réseau 314 ou le module MN 316 pour transférer des données vers un autre système de traitement de données. Le module de réseau 314 est utilisé lorsque le système de traitement de données est relié à un réseau. Le module de réseau à modem MN est utilisé pour communiquer avec un autre système de traitement de données qui n'est pas relié à un réseau. Comme on peut le voir, le module MN expédie les données sur la ligne de communication 308. La présente invention permet l'utilisation de sessions multiples. Une "session" est une liaison logique entre des applications par l'intermédiaire d'une liaison physique, telle qu'une ligne de communication, comme la ligne de communication 308. Les communications dans ces sessions sont manipulées en transférant des blocs de données avec des en-têtes par l'intermédiaire de la ligne de communication. L'utilisation de sessions est similaire à celle d'un système à réseau d'ordinateur. Conformément avec un mode de réalisation préféré de la présente invention, les sessions établies par les interfaces ne sont pas arrêtées si les communications physiques procurées par une ligne de communication sont perdues ou déconnectées. Par exemple, si un système de traitement de données raccroche la ligne de communication, la session entre les applications dans les systèmes de traitement de données n'est pas arrêtées. Au contraire, lorsqu'une application désire envoyer des données à une autre application dans la session, la présente invention prévoit que la connexion ou liaison par l'intermédiaire de la ligne de communication soit réétablie, et envoie alors les données à l'autre application. En outre, une temporisation peut être établie, telle qu'après une quantité choisie d'inactivité, le traitement de données se déconnecte lui-même de la ligne de communication. Comme auparavant, lorsqu'une application désire envoyer des données à une autre application partageant la session, la présente invention réétablit une connexion au moyen de la ligne de communication et envoie alors les données. Tout ceci se produit sans mettre fin à la session logique en cours. Cette particularité procure à l'utilisateur un procédé pour réduire les taxes sur une ligne de communication à longue distance sans avoir à réétablir une session à chaque fois que des données doivent être expédiées à partir d'une application d'un système de traitement de données à une autre application sur un autre système de traitement de données. Le rétablissement de la connexion peut être préétabli par un fichier de configuration de telle sorte qu'un système de traitement de données essaiera toujours de réétablir la connexion, ou que des informations puissent être échangées de telle manière que l'un ou l'autre des systèmes de traitement de données puissent rétablir la connexion. En se référant maintenant à la figure 5, une structure de données de configuration de communication est décrite conformément avec un mode de réalisation préféré de la présente invention. La structure de données 500, également appelée COMMCFG, contient des paramètres associés à un accès COM, tel que le débit en baud, la parité, etc.. Sur la figure 6, la structure de données 600 constitue le bloc de commande de réseau par modem. Cette structure de données est utilisée par la présente invention pour mémoriser les informations d'une session. Sur la figure 7, la structure de données 700 est un en-tête qui est utilisé par l'API de réseau par modem lorsqu'on envoie des données sur l'accès COM. La structure de données 800 sur la figure 8 est une structure de transaction, MNTRANSACT, qui est utilisée par les API de réseau par modem pour mettre en file d'attente les transactions. La structure de données 900, sur la figure 9, est utilisée pour garder une trace des sessions actives. Ces structures de données des figures 5 à 9 sont sous forme de langage C et sont utilisées par diverses procédures sur les figures ci-dessous pour valider l'utilisation des sessions multiples de la ligne de communication. Les organigrammes suivants illustrent les fonctions utilisées pour réaliser l'échange de données multisession entre des sessions multiples sur une ligne de communication analogique standard unique, telle qu'une ligne téléphonique. AsyncOpenPort est une fonction utilisée pour établir des paramètres associés avec l'accès COM, par exemple le débit en baud, la parité, etc.. Cette fonction nécessite un pointeur sur la structure COMMCFG. La fonction prend les informations trouvées dans cette structure et sauvegarde une copie générale pour une utilisation ultérieure. La fonction ouvre également l'accès COM en établissant les paramètres trouvés dans la structure COMMCFG. En outre, cette fonction renvoie les erreurs à l'appelant. En se référant à la figure 10, un organigramme du processus suivi par une fonctionAsyncOpenPort, est illustré conformément avec un mode de réalisation préféré de la présente invention. La fonction établit le paramètre associé avec l'accès COM, comme illustré au pavé 1001. Ensuite, la fonction obtient un pointeur sur la structure COMMCFG, comme décrit au pavé 1003. La fonction sauvegarde une copie générale des informations, comme illustré au pavé 1005. La fonction ouvre alors l'accès COM en établissant les paramètres tels qu'ils sont trouvés dans la structure COMMCFG elle-même décrite dans le pavé 1009. AsyncClosePort est une fonction utilisée pour fermer l'accès COM et effacer toute donnée associée avec l'accès donné. Aucun paramètre n'est associé à cette fonction. En se référant à la figure 11, un organigramme du processus suivi par la fonction AsyncClosePort est illustré conformément à un mode de réalisation préféré de la présente invention. La fonction referme l'accès COM, comme illustré au pavé 1101. Ensuite, les données associées à l'accès COM sont effacées, comme décrit au pavé 1103. L'effacement des données conduit à la libération de la mémoire et des mémoires tampon utilisées pour mémoriser les données associées à l'accès COM. AsyncCall est une fonction utilisée pour envoyer des ordres au modem. Ces ordres envoyés au modem sont ceux qui sont nécessaires pour numéroter le numéro défini dans la structure COMMCFG. La fonction AsyncCall ne comprend aucun paramètre d'entrée. Au lieu de cela, on utilise des informations provenant de la structure de données de communication globale. En se référant maintenant à la figure 12, un organigramme du processus utilisé par la fonction AsyncCall est illustré conformément à un mode de réalisation préféré de la présente invention. La fonction détermine si la connexion est une connexion directe, comme illustré au pavé 1201. Si une connexion directe est absente, la fonction obtient les signaux d'entrée du modem de l'accès COM, comme décrit au pavé 1203. Ensuite, la fonction détermine si l'indicateur de détection de porteuse (DCD) est établi, comme illustré au pavé 1205. L'établissement de l'indicateur de détection de porteuse indique que le modem est relié. Si la réponse à cette détermination est non, la fonction envoie alors des ordres au modem nécessaires pour numéroter le numéro, comme décrit au pavé 1207. Ensuite, la fonction lit l'accès COM et recherche l'état de connexion du modem, comme illustré au pavé 1209. La fonction se termine après que l'état soit renvoyé à l'appelant, comme décrit au pavé 1211. En se référant à nouveau au pavé 1201, si une liaison directe est présente, la fonction renvoie une indication du fait que l'appel a été effectué avec succès, comme illustré au pavé 1213. En se référant à nouveau au pavé 1205, si l'indicateur de détection de porteuse est établi, la fonction renvoie également une indication comme quoi l'appel a été effectué avec succès, comme illustré au pavé 1213. La fonction AsyncHangup est utilisée pour amener le modem à raccrocher l'appel. Cette fonction particulière n'a pas de paramètre. Les informations sont obtenues de la structure de configuration de communication globale mise en mémoire. En se référant maintenant à la figure 13, un organigramme de haut niveau du processus utilisé par la fonction AsyncHangup est illustré conformément à un mode de réalisation préféré de la présente invention. La fonction commence par déterminer si une connexion directe existe, comme illustré au pavé 1301. Si une connexion directe est absente, la fonction obtient alors les signaux d'entrée du modem de l'accès COM, comme décrit au pavé 1303. Ensuite, la fonction détermine si l'indicateur de détection de porteuse est établi, comme illustré au pavé 1305. Si l'indicateur de détection de porteuse n'est pas établi, la fonction envoie des ordres pour faire raccrocher le modem, comme décrit au pavé 1307. En se référant à nouveau au pavé 1301, si la connexion est une connexion directe, le processus renvoie une indication comme quoi le raccroché a été effectué avec succès, comme illustré au pavé 1309. En revenant au pavé 1305, si l'indicateur de détection de porteuse n'est pas établi, le processus renvoie une indication du fait que le raccroché a été fait avec succès, comme illustré au pavé 1309. La fonction d'ouverture, MNOPEN (PMNCD pMNCD), efface le bloc de commande de réseau par modem (MNCB) et génère un indicateur d'événement. un "indicateur d'événement" est utilisé en tant que variable partagée pour synchroniser des processus simultanés en indiquant si une action a été terminée ou si un événement s'est produit. En se référant à la figure 14, un organigramme d'un processus utilisé par une fonction d'ouverture est illustré conformément à un mode de réalisation préféré de la présente invention. La fonction d'ouverture initialise le bloc de commande à zéro, comme illustré au pavé 1401. La fonction génère alors un indicateur d'événement qui doit être associé à la session, comme décrit au pavé 1403. La fonction se termine après que l'état soit retourné à l'appelant, comme illustré au pavé 1405. La fonction de fermeture, MNCLOSE (PMNCB pMNCB), ferme l'indicateur d'événement. PMNCB est le type de structure et PMNCB est le nom pour ce type. Par référence à la figure 15, un organigramme du processus utilisé par la fonction de fermeture est illustré conformément à un mode de réalisation préféré de la présente invention. La fonction commence par fermer l'indicateur d'événement, comme illustré au pavé 1501. Ensuite, le processus se termine en renvoyant l'état à l'appelant, comme décrit au pavé 1503. Un API d'écoute, MNListen (PMNCB pMNCB), interrompt l'appelant jusqu'à ce qu'appel soit reçu, que l'ordre soit annulé par un autre enchaînement, ou si une erreur sérieuse est détectée. Lorsqu'on utilise l'API d'écoute, le nom de l'écoutant doit être spécifié dans le champ nom du MNCB pointé par le paramètre pMNCB. En se référant à présent à la figure 16, un organigramme du processus utilisé par l'API d'écoute est illustré conformément au mode de réalisation préféré de la présente invention. Le processus commence par réinitialiser l'indicateur d'événement associé, comme illustré au pavé 1601. Le processus remplit une structure de transaction, MN_TRANSACT, comme illustré au pavé 1603. Ensuite, le processus établit le champ d'ordre de transaction pour indiquer une écoute comme illustré au pavé 1605. Le processus établit ensuite le champ d'action de transaction pour indiquer une réception comme décrit au pavé 1609. La structure de transaction est ajoutée à la liste de transaction, comme illustré au pavé 1609. Ensuite, le processus bloque l'indicateur d'événement associé, comme décrit au pavé 1611. Bloquer un indicateur d'événement associé signifie que la transaction associée à l'indicateur d'événement attendra qu'un événement se produise, pendant lequel l'événement sera indiqué par l'indicateur d'événement. Plus simplement, la transaction attend que l'indicateur d'événement soit "libéré". Le processus détermine alors si l'état de la transaction signifie une annulation, comme illustré au pavé 1613. Si l'état de la transaction ne signifie pas une annulation, le processus établit alors le numéro de session distante au numéro de session de l'expéditeur, comme décrit au pavé 1615. Le processus obtient alors le numéro de session locale suivant et recherche la liste de liaison pour s'assurer que le numéro de session local n'est pas en train d'être utilisé, comme illustré au pavé 1617. Le processus établit le numéro de session local au numéro de session disponible suivant trouvé, comme décrit au pavé 1619. Ensuite, la structure de session est alors complétée par les numéros de session locale et distante, comme illustré au pavé 1621. Le processus ajoute la structure de session à une liste de liaison, comme décrit au pavé 1623. La liste de liaison est une liste de liaison comme indiqué par les structures de session de la liste. Ensuite, le processus indique une réponse d'ordre, comme illustré au pavé 1625. L'état de transaction est établi par le processus pour indiquer un succès, comme décrit au pavé 1627. Après cela, le processus établit le champ d'action de transaction pour indiquer une expédition, comme illustré au pavé 1629. Ensuite, une écriture est initiée par le processus qui expédie l'indicateur d'événement d'enchaînement d'écriture, comme décrit au pavé 1631. L'expédition d'un indicateur est effectuée pour indiquer qu'un événement s'est produit pour initialiser une action, telle qu'une opération d'écriture par l'enchaînement associé à l'indicateur d'événement. Le processus établit alors l'état du bloc de commande de réseau par modem pour indiquer un succès, comme illustré au pavé 1633. Le processus se termine en renvoyant l'état à l'appelant comme décrit au pavé 1635. En se référant à nouveau au pavé 1613, si l'état de la transaction signifie une annulation, le processus supprime alors la transaction de la liste de transaction, comme illustré au pavé 1637. Le processus se termine alors en renvoyant une indication comme quoi une erreur s'est produite et que l'ordre API a été annulé, comme décrit au pavé 1639. L'API d'appel, MNCall (PMNCB pMNCB, PUCHAR CalledName), est utilisé pour établir une session avec le nom spécifié par le paramètre CalledName. Cet ordre d'API d'appel contactera l'API AsyncCall pour établir une liaison et ensuite envoyer la demande vers l'extérieur par l'intermédiaire de la ligne COM. En se référant aux figures 17A et 17B, un organigramme du processus utilisé par l'API d'appel est illustré conformément à un mode de réalisation préféré de la présente invention. Les appels API sont également connus sous le nom de procédures. Le processus commence par la détermination du fait que la longueur du nom appelé, Called Name, est plus grand qu'une limite préétablie quelconque, comme illustré au pavé 1701. Si la longueur du nom appelé n'est pas supérieure à la limite, le processus appelle alors la fonction AsyncCall pour établir un appel si nécessaire, comme illustré au pavé 1703. Un appel n'est pas nécessaire lorsqu'une connexion directe est utilisée. Le processus obtient alors le numéro de session locale suivant et effectue une recherche dans la liste de liaison pour s'assurer que le numéro de session locale n'est pas utilisé, comme illustré au pavé 1705. Le processus établit le numéro de session locale au prochain numéro de session locale disponible, comme décrit au pavé 1707. Le processus réinitialise l'indicateur d'événement associé à cette session, comme illustré au pavé 1709. Ensuite, une structure de transaction, MN_TRANSACT, est complétée par le processus, comme décrit au pavé 1711. Le processus établit le champ d'ordre de transaction pour indiquer une connexion, comme illustré au pavé 1713. Ensuite, le processus établit le champ d'action de transaction pour indiquer une expédition, comme décrit au pavé 1715. Le champ de données de transaction est établi par le processus avec le paramètre CalledName, comme illustré au pavé 1717. Ensuite, le processus établit le champ de taille de données de transaction, DataSize, à la longueur de chaîne du paramètre de nom appelé, comme décrit au pavé 1719. La structure de transaction est ajoutée à la liste de transaction comme illustré au pavé 1721. Le processus initialise une écriture en expédiant l'indicateur d'événement d'enchaînement d'écriture, comme décrit au pavé 1723. Un blocage de l'indicateur d'événement associé est effectué, comme illustré au pavé 1725. Ensuite, la détermination du fait que l'état de transaction dans le champ d'état de transaction indique une annulation est faite, comme décrit au pavé 1727. Si la réponse à cette détermination est non, le processus détermine alors si l'état de transaction indique un succès, comme illustré au pavé 1729. Si l'état de transaction n'indique pas un succès, le processus établit alors l'état pour indiquer l'état de la transaction, tel que décrit au pavé 1731. Après cela, le processus supprime la transaction de la liste de transaction, comme illustré au pavé 1733. Le processus se termine alors après avoir renvoyé l'état à l'appelant, comme décrit au pavé 1737. En se référant à nouveau au pavé 1729, si l'état de la transaction indique un succès, le processus établit le numéro de session distante au numéro de session de l'expéditeur, comme illustré au pavé 1739. Le processus complète alors une structure de session avec les numéros de session locale et distante, comme illustré au pavé 1741. Le processus se termine alors après avoir ajouté la structure de session à la liste de liaison, comme décrit au pavé 1743. En se référant à nouveau au pavé 1727, si l'état de la transaction indique une annulation, le processus supprime la transaction de la liste de transaction comme décrit au pavé 1745. Le processus se termine alors après avoir renvoyé une indication comme quoi la transaction a été annulée, comme illustré au pavé 1747. En se référant à nouveau au pavé 1701, si la longueur du nom appelé est supérieur à la limite, le processus se termine alors après avoir retourné une erreur indiquant que le nom est trop long, comme décrit au pavé 1749. La fonction d'expédition, MNSend (PMNCB pMNCB, PVOID Buffer, ULONG Bytes), envoie un bloc de données vers la connexion spécifiée par le paramètre PMNCB. En se référant à la figure 18, un organigramme du processus utilisé par la fonction d'expédition est illustré conformément à un mode de réalisation préféré de la présente invention. Le processus commence par rechercher dans la ligne de connexion un numéro de session locale correspondant au numéro de session locale du paramètre PMNCB, comme illustré au pavé 1801. Le processus détermine alors s'il existe une concordance, comme décrit au pavé 1803. S'il existe une concordance, le processus réinitialise l'indicateur d'événement associé à cette transaction, comme illustré au pavé 1805. Puis, le processus complète une structure de transaction, MNTRANSACT, comme décrit au pavé 1807. Après cela, le processus établit le champ d'ordre de transaction pour indiquer une expédition, comme illustré au pavé 1809. Le processus établit alors le champ d'action de transaction pour indiquer une expédition, comme indiqué au pavé 1811. Ensuite, le champ de données de transaction est établi avec le paramètre de mémoire tampon, comme illustré au pavé 1813. Le champ de taille de données de transaction, DataSize, est alors établi avec les paramètres d'octets, comme décrit au pavé 1815. La structure de transaction est ajoutée à la liste de transaction, comme illustré au pavé 1817. Ensuite, le processus initialise une écriture en expédiant l'indicateur d'enchaînement d'écriture, comme décrit au pavé 1819. Le processus bloque alors l'indicateur d'événement associé, comme illustré au pavé 1821. Le champ d'état est établi pour indiquer l'état de la transaction, comme décrit au pavé 1823. Puis, la transaction est supprimée de la liste de transaction, comme illustré au pavé 1825. Le processus se termine alors après avoir renvoyé l'état à l'appelant, comme décrit au pavé 1827. En se référant à nouveau au pavé 1803, si une concordance n'est pas trouvée, le processus se termine alors après avoir renvoyé une erreur de session invalide, comme décrit au pavé 1829. La fonction de réception, MNReceive (PMNCB pMNCB, PVOID Buffer, ULONG Bytes), soit un bloc de données depuis la connexion spécifiée par le paramètre pMNCB. En se référant à présent aux figures 19A et 19B, un organigramme du processus utilisé par la fonction de réception est illustré conformément à un mode de réalisation préféré de la présente invention. Le processus commence par rechercher dans la liste de liaison, un numéro de session locale correspondant au numéro de session locale trouvé dans le paramètre pMNCM, comme illustré au pavé 1901. Une détermination est faite pour savoir si une concordance est présente, comme décrit au pavé 1903. Si une concordance est présente, le processus réinitialise alors l'indicateur d'événement associé à cette session, comme illustré au pavé 1905. Le processus complète alors une structure de transaction, MN_TRANSACT, comme décrit au pavé 1907. Le champ d'ordre de transaction est établi pour indiquer une réception, comme illustré au pavé 1909. Ensuite, le processus établit le champ d'action de transaction pour indiquer une réception, comme décrit au pavé 1911. Le champ de données de transaction est établi avec le paramètre de mémoire tampon, comme illustré au pavé 1913. Puis, le processus établit le champ DataSize de transaction avec le paramètre d'octets, comme décrit au pavé 1915. Après cela, la structure de transaction est ajoutée à la liste de transaction, comme illustré au pavé 1917. Le processus bloque alors l'indicateur d'événement associé, comme décrit au pavé 1919. Le processus détermine alors si l'état de la transaction dans le champ d'état de transaction indique une annulation, comme illustré au pavé 1921. Si l'état de transaction n'indique pas une annulation, le processus indique alors une réponse d'ordre, comme décrit au pavé 1923. Le processus établit alors le champ d'état de transaction afin d'indiquer un succès, comme illustré au pavé 1925. Le processus établit le champ d'état de transaction pour indiquer un succès, comme décrit au pavé 1927. Puis, le champ d'action de transaction est établi pour indiquer une expédition, comme illustré au pavé 1939. Le processus initialise une écriture en expédiant l'indicateur d'événement d'enchaînement d'écriture, comme décrit au pavé 1931. Le processus se termine alors après avoir renvoyé l'indication d'un succès à l'appelant, comme illustré au pavé 1933. En se référant à nouveau au pavé 1921, si l'état de transaction indique une annulation, le processus supprime alors la transaction de la liste de transaction, comme décrit au pavé 1935. Le processus se termine alors après avoir renvoyé une indication comme quoi la transaction a été annulée, comme illustré au pavé 1937. En se référant à nouveau au pavé 1903, si une concordance est absente, le processus se termine alors après avoir renvoyé une erreur de session invalide à l'appelant, comme décrit au pavé 1939. La fonction de raccroché, MNHangup (PMNCB pMNCB), raccrochera une session établie. En se référant maintenant aux figures 21A et 21B, un organigramme d'un processus utilisant la fonction de raccroché est illustré conformément à un mode de réalisation préféré de la présente invention. La fonction de raccroché commence par une recherche dans la liste de connexion d'un numéro de session locale correspondant au numéro de session locale figurant dans le paramètre pMNCB, comme illustré au pavé 2001. Une détermination du fait qu'une concordance est présente, est faite, comme décrit au pavé 2003. La présence d'une concordance résulte en la suppression de l'élément de connexion de la ligne de connexion, comme illustré au pavé 2005. L'indicateur d'événement associé est réinitialisé, comme décrit au pavé 2007. Après cela, le processus complète une structure de transaction, comme illustré au pavé 2009. Le champ d'ordre de transaction est établi pour indiquer un raccroché, comme décrit au pavé 2011. Puis, le champ d'action de transaction est établi pour indiquer une expédition, comme illustré au pavé 2013. Ensuite, le processus ajoute la structure de transaction à la liste de transaction comme décrit au pavé 2015. Une écriture est initialisée par le processus en expédiant l'indicateur d'événement d'enchaînement d'écriture comme cela est illustré au pavé 2017. Puis, le processus recherche dans la liste de transaction un pMNCB présentant un numéro de session locale correspondant, comme décrit au pavé 2019. Une détermination est faite pour savoir si un numéro de session locale correspondant est présent, comme décrit au pavé 2021. L'absence d'un numéro de session locale correspondant résulte en le processus bloquant l'indicateur associé comme illustré au pavé 2023. Puis, le processus établit alors le champ d'état de transaction pour indiquer l'état de la transaction, comme décrit au pavé 2025. La transaction est supprimée de la liste de transaction, comme illustré au pavé 2027. Le processus se termine alors après avoir renvoyé l'état à l'appelant comme décrit au pavé 2029. En se référant à nouveau au pavé 2021, si un numéro de session locale correspondant est présent, le processus établit alors l'état pour indiquer une annulation, comme illustré au pavé 2031. Le processus se termine alors après avoir expédié l'indicateur d'événement associé, comme décrit en 2033. En se référant à nouveau au pavé 2003, si une correspondance n'est pas trouvée pendant la recherche dans la liste de liaison d'un numéro de session locale correspondant au numéro de session locale du paramètre pMNCB, alors le processus se termine après avoir renvoyé une erreur de session invalide à l'appelant, cosme illustré au pavé 2035. L'ordre d'annulation, MNCancel (PMNCB pMNCB) essaie de localiser l'ordre et d'avertir le propriétaire de l'ordre avec un état d'annulation d'ordre. En se référant maintenant à la figure 21, un organigramme d'un processus utilisant l'ordre annulé est illustré conformément à un mode de réalisation préféré de la présente invention. Le processus commence par rechercher dans la liste de transaction le pMNCB, comme illustré au pavé 2101. Une détermination du fait que le pMNCB est présent, est faite, comme décrit au pavé 2103. L'absence du pMNCB, conduit au renvoi de l'état à l'appelant, comme illustré au pavé 2105. En se référant à nouveau au pavé 2103, si la réponse à ce pavé de décision est oui, le processus établit alors l'état pour indiquer une annulation, comme décrit au pavé 2107. Ensuite, une détermination du fait que l'action indique une expédition en attente est faite, comme illustré au pavé 2105. Si la réponse est oui, le processus s'arrête alors. Si la réponse à cette détermination est non, le processus s'arrête après avoir expédié l'indicateur d'événement associé, comme décrit au pavé 2111. Les données sont réellement lues et écrites en utilisant un enchaînement de lecture et un enchaînement d'écriture conformes à un mode de réalisation préféré de la présente invention. La réalisation d'un enchaînement de lecture et d'écriture peut être trouvée sous forme de codes dans l'appendice. Le code est écrit en langage C. Le processus décrit sur les figures peut être réalisé par les personnes ayant une expérience normale de la technique dans le système de traitement de données décrit sur les figures 1 et 2. Les processus de la présente invention peuvent être également réalisés dans un dispositif de mémorisation de programme qui peut être lu par un système de traitement de données, dans lequel le dispositif de mémorisation de programme code les instructions exécutables du système de traitement de données en effectuant un codage pour les processus de la présente invention. Le dispositif de mémorisation de programme peut prendre diverses formes y compris, par exemple, mais non limité à ceuxci, celle d'une unité de disque dur, d'un disque souple, d'un disque optique, d'une mémoire morte, et d'une EPROM, qui sont connus des personnes expérimentées dans la technique. Les processus mémorisés sur un dispositif de mémorisation de programme sont en sommeil jusqu'à ce qu'ils soient activés en utilisant le dispositif de mémorisation de programme avec le système de traitement de données. Par exemple, un disque dur contenant des instructions exécutables de système de traitement de données concernant la présente invention, peut être relié à un système de traitement de données, un disque souple contenant des instruction exécutables de système de traitement de données concernant la présente invention peut être inséré dans une unité de disque souple dans le système de traitement de données, ou une mémoire morte contenant les instruction exécutables de système de traitement de données concernant la présente invention peut être connectée au système de traitement de données par l'intermédiaire d'une carte ou d'un adaptateur connecté à un connecteur d'entrée/sortie. REVENDICATIONS 1. Procédé pour procurer des communications entre des applications, dans lequel une application appelante est située sur un premier système de traitement de données et une pluralité d'applications sont situées sur un second système de traitement de données, le procédé comprenant les étapes consistant à: recevoir une demande de l'application appelante pour communiquer avec la pluralité des applications, qui s'exécutent simultanément sur le second système de traitement de données, établir une connexion sur une ligne de communication entre les premier et second systèmes de traitemtn de données, établir une session entre l'application appelante et chaque application parmi la pluralité d'applications, et procurer une communication entre l'application appelante et chacune dans la pluralité d'applications en utilisant la ligne de communication sans nécessiter un arrêt de la session. 2. Procédé selon la revendication 1, dans lequel l'étape consistant à établir une connexion entre les premier et second systèmes de traitement de données comprend l'établissement d'une connexion entre les premier et second systèmes de traitement de données, dans lesquels la ligne de communication est un câble série. 3. Procédé selon la revendication 1, dans lequel l'étape consistant à établir une connexion entre le premier et second systèmes de traitement de données comprend l'établissement d'une connexion entre les premier et second systèmes de traitement de données, dans lesquels la ligne de communication est un réseau de télécommunication commuté. 4. Procédé selon la revendication 1, comprenant en outre l'arrêt d'une connexion sans arrêter une session en réponse à un ordre d'arrêt de connexion. 5. Procédé selon la revendication 1, comprenant en outre l'arrêt de la connexion en réponse à une absence de communication sur la ligne de communication entre les premier et second systèmes de traitement de données. 6. Procédé selon la revendication 5, comprenant en outre le rétablissement de la connexion en réponse à l'application appelante essayant d'expédier des données sur l'une de la pluralité d'applications sur le second système de traitement de données. 7. Dispositif pour procurer des communications entre deux systèmes de traitement de données comprenant: un premier système de traitement de données, un second système de traitement de données, une ligne de communication reliant les premier et second systèmes de traitement de données, une première interface localisée sur le premier système de traitement de données, et une seconde interface localisée sur le second système de traitement de données, dans lequel la première interface comprend un moyen pour établir une connexion entre les première et seconde interfaces, un moyen pour établir une session pour chaque application sur le premier système de traitement de données qui demande une mise en communication avec une application sur le second système de traitement de données et dans lequel les première et seconde interfaces comprennent un moyen pour contrôler la communication entre les applications qui comportent une session établie. 8. Dispositif selon la revendication 7, dans lequel lesdites première et seconde interfaces comprennent un moyen de temporisation qui arrête la connexion si la communication sur la ligne de communication est absente pendant une durée prédéterminée et dans lequel les sessions établies ne sont pas arrêtées en réponse à un arrêt de la connexion. 9. Dispositif selon la revendication 7, dans lequel lesdites première et seconde interfaces comprennent un moyen pour rétablir la connexion en réponse à une application située sur le premier système de traitement de données et essayant de communiquer avec une application sur le second système de traitement de données. 10. Dispositif selon les revendications 7, 8 ou 9, dans lequel la ligne de communication est un cable série. 11. Dispositif selon l'une quelconque des revendications 7 à 9, dans lequel la ligne de communication est un réseau de télécommunication commute. 12. Dispositif selon l'une quelconque des revendications 7 à 11 destiné à procurer des communications entre les applications, dans lequel une application appelante est localisée sur un premier système de traitement de données et une pluralité d'applications sont localisées sur un second système de traitement de données, le dispositif comprenant: un moyen de réception pour recevoir une demande de l'une application appelante pour communiquer avec au moins une parmi une pluralité d'applications, qui s'exécutent simultanément sur le second système de traitement de données, un premier moyen d'établissement pour établir une connexion sur une ligne de communication entre les premier et second systèmes de traitement de données, un second moyen d'établissement pour établir une session entre l'application appelante et chaque application contenue dans la pluralité d'applications, et un moyen de communication procurant une communication entre l'application appelante et chacune parmi une pluralité d'applications utilisant la ligne de communication sans nécessiter l'arrét d'une session, dans lequel les communications sont pocurées efficacement entre les applications. 13. Dispositif selon l'une quelconque des revendications 7 à 12 pouv nt être utilisé comme un dispositif de mémorisation qui peut-être lu par ledit système de traitement de données et codant des instructions exécutables de système de traitement de données pour procurer des communications entre les applications, dans lequel une application appelante est localisée sur ledit premier système de traitement de données et une pluralité d'applications sont localisées sur ledit second système de traitement de données, le dispositif de mémorisation de programme comprenant, en outre une unité de disque dur, ou une disquette souple. 14. Dispositif selon la revendication 13, dans lequel une mémoire morte est utilisée avec l'un ou les deux systèmes de traitement de données.