<Desc/Clms Page number 1>
Prévention et détection d'erreurs dans un système de traitement de données L'invention se rapporte à un système de traitement de données transactionnelles et particulièrement à un système ayant des structures complexes de données et de traitement.
Généralement, lorsqu'un système est conçu pour traiter des données transactionnelles il y a lieu de tenir compte de plusieurs aspects importants au traitement. Ceux-ci peuvent comprendre les ventes, bons de commande, comptes, traitement de données client et traitement de paiements. De ce fait certains systèmes de traitement sont assez complexes. Toutefois, certains systèmes ont une complexité additionnelle causée par le fait que chaque transaction individuelle est relativement complexe. Par exemple, c'est le cas lorsqu'une transaction se rapporte à l'achat d'un objet par paiements hebdomadaires étalés, disons sur quarante-deux semaines, et que l'objet doit être livré au client à une date donnée. Dans ce cas, l'achat d'un seul objet donne lieu à quarante-deux messages d'entrée de paiement ajoutés à de nombreux autres signaux d'entrée.
Les structures des bases de données et des mémoires sont généralement et nécessairement assez complexes et il existe une grande interdépendance entre les modules de traitement et les structures de mémoire et de stockage.
<Desc/Clms Page number 2>
Des exemples de l'art antérieur relatif au traitement de données transactionnelles comprennent le brevet anglais No.
GB-B-2 180 380 (Merrill Lynch) et le brevet européen No EP-B1-0 014 312 (IBM). Dans la première description, la manière d'utiliser les liaisons de communication et de traitement des données financières sont des caractéristiques importantes, tandis que la deuxième description décrit en détail les opérations d'exécution de transactions à l'aide d'un terminal. Une de ces opérations est par exemple le stockage d'informations d'identification personnelles et l'attribution de fonctions à des touches de transaction. Quoique les systèmes décrits dans les deux descriptions ont certainement des mérites, ils ne révèlent pas de dispositions qui aident à éviter les erreurs qui apparaissent dans les systèmes transactionnels complexes.
Le brevet anglais No. GB-B-2 202 656 (IBM) décrit un système de réorganisation de la mémoire d'un système à microprocesseur dans lequel un circuit d'adressage et de gestion est construit pour enregistrer et signaler une erreur détectée dans la mémoire pendant le test et pour mettre le circuit de mémoire hors circuit en redirigeant ses adresses. A nouveau, le système décrit dans cette divulgation est sans aucun doute très bénéfique dans les opérations exécutées lorsqu'une erreur est détectée. Elle ne révèle toutefois pas de méthode de prévention de données
<Desc/Clms Page number 3>
erronées, ou de détection de données erronées dans un système complexe de traitement de données transactionnelles ayant un grand nombre de fichiers et de structures de traitement.
L'invention vise à rendre disponible un système de traitement de données transactionnelles comprenant des moyens techniques pour traiter ces problèmes.
Selon l'invention, on propose un système de traitement de données transactionnelles comprenant un réseau local auquel sont raccordés un certain nombre de terminaux d'interfaçage et un système hôte, le système hôte comprenant des processeurs de traitement de données transactionnelles en communication avec un certain nombre de structures de bases de données stockées sur des unités de mémoire, le système hôte comprenant en plus une mémoire de travail dans laquelle des fichiers temporaires peuvent être créés, et dans lequel le processeur du système hôte comprend : des moyens de communication avec un terminal d'interfaçage pour la réception de données transactionnelles et pour écrire les données reçues automatiquement dans la mémoire de travail ;
<Desc/Clms Page number 4>
des moyens de recherche automatique dans une unité de stockage, d'un écran d'affichage d'erreur, l'écran particulier cherché correspondant à la nature des données en cours introduction, l'écran d'affichage d'erreur comprenant des signaux de gestion de pixels pour afficher sur le terminal d'interface un certain nombre de lignes, chaque ligne comprenant une ligne de texte et un champ associé de saisie de données, l'écran comprenant également du texte général indiquant à l'utilisateur que des données doivent être introduites lorsqu'un curseur est situé dans un champ de saisie de données ; des moyens de surveillance des données entrées dans les champs des lignes ; des moyens de génération automatique d'un nombre binaire représentatif de la séquence des saisies dans les champs de saisie de données ;
et des moyens de conversion automatique du nombre binaire en un signal représentant un format dans une base supérieure, et pour écrire le nombre converti dans un champ prédéterminé d'un enregistrement correspondant.
De préférence, le moyen de conversion central comprend des moyens de conversion de binaire en décimal.
<Desc/Clms Page number 5>
Dans une réalisation, le nombre binaire est généré en fonction de la séquence des champs de saisie des données vue par l'utilisateur en réponse aux signaux de gestion des pixels.
Dans une autre réalisation, chaque processeur connecté à une structure de base de données comprend :- des moyens de réception d'un signal de mise à jour de données provenant d'un terminal d'interfaçage ; des moyens de recherche dans la structure de base de données d'un enregistrement correspondant et d'écriture de l'enregistrement vers un fichier tampon créé en mémoire de travail ; des moyens de traitement de l'enregistrement dans le fichier tampon et ensuite de procéder à des opérations de vérification de données stockées dans ces emplacements ; des moyens d'écraser l'ancien enregistrement dans la structure de base de données en écrivant l'enregistrement traité sur l'ancien enregistrement ;
<Desc/Clms Page number 6>
des moyens d'insertion automatique de données de contrôle dans l'enregistrement et parallèlement d'écrire les données ainsi générées dans une structure de base de données de contrôle ; et des moyens d'activer un processus de traitement par lots pour traiter les données de contrôle à des intervalles réguliers.
Idéalement, le processus de traitement par lots des données de contrôle activé, comprend des modules de génération de rapports imprimés.
Dans une autre réalisation encore, le processeur comprend en outre des moyens de mise à jour d'une structure de base de données résumées contenant des données relatives à la mise à jour qui a été faite.
Dans une autre réalisation, le système comprend en plus un processeur de vérification du contenu de fichiers index dans un processus batch, le processeur de vérification comprenant : des moyens pour déterminer le nombre d'enregistrements stockés dans une structure de base de données et de génération automatique d'une table en mémoire de travail, la table ayant une cellule unique associée à chaque
<Desc/Clms Page number 7>
enregistrement de la structure, l'organisation de la table étant celle des emplacements physiques des unités de stockage des enregistrements de la base de données ; des moyens d'envoyer des signaux à un fichier index correspondant pour successivement avoir accès à chaque enregistrement de la structure de base de données ;
et des moyens d'écriture d'un marqueur dans la cellule correspondante de la structure de la table pour indiquer que l'accès à l'enregistrement correspondant a réussi.
De préférence, un nombre binaire est écrit dans chaque cellule, le nombre exprimant le nombre d'accès qui ont eu lieu à l'enregistrement associé.
L'invention sera plus clairement comprise par la description ci-après de certaines mises en oeuvre de l'invention, données exclusivement à titre d'exemple et en se référant aux dessins joints dans lesquels : la fig. 1 est un schéma représentant une partie d'un système de traitement de données transactionnelles illustrant quelques unes des interconnexions du processeur principal et du stockage ainsi que le cheminement des données ;
<Desc/Clms Page number 8>
la fig. 2 est la représentation schématisée d'un processus de marquage d'erreur effectué par le système ; la fig. 3 est la représentation schématisée d'un processus de mise à jour qui évite la corruption de données ; et l fig. 4 est la représentation schématisée de la manière par laquelle un processus de détection d'erreurs d'index est effectué.
Un système de traitement de données transactionnelles 1 est illustré dans la fig. l Le système 1 sert à l'exécution de traitements de données relatives à des transactions par lesquelles un client, en consultation avec un préposé, choisit dans un catalogue des marchandises à acheter. La sélection est enregistrée par le préposé, par voie de communication avec le bureau principal, ces données comprenant une date de livraison demandée et une période d'étalement de paiement. La transaction implique que le client paie chaque semaine pendant une période, dans ce cas jusque quarante-deux semaines, une somme d'argent au préposé. Les marchandises sont alors livrées à la fin de la période de paiement, habituellement avant la Noël.
Le système 1 assure l'enregistrement de commandes, l'enregistrement des paiements hebdomadaires, le traitement de commande des marchandises pour assurer que les marchandises sont achetées et prêtes à temps pour la
<Desc/Clms Page number 9>
livraison, ainsi que pour du marketing permanent. Il y a un degré élevé de traitement de comptes et de paiements et les paiements arrivent de diverses institutions financières de manière différente, sur disquette ou par modem. Il sera donc constaté que le traitement transactionnel est assez complexe. L'invention offre des fonctions techniques qui sous-tendent le traitement des données exécuté pour minimiser les données erronées et de détecter ces erreurs là où elles apparaissent.
L'invention ne s'occupe pas de la nature du traitement des données, mais des processus techniques d'arrière plan qui assurent les résultats techniques d'intégrité accrue des données transactionnelles traitées.
Le système 1 reçoit des données de paiement d'un certain nombre de systèmes d'institutions financières distants, dont trois sont illustrés identifiés par les chiffres 2,3 et 4.
Dans cette réalisation toutes les données de paiement sont transmises par modem. Le système 1 comprend un grand nombre d'interfaces 5 comprenant des terminaux connectés en réseau local. Un système hôte connecté au réseau comprend un processeur de commandes 6 connecté à une base de données de commandes 7, d'une capacité de 4 à 6 Mo. Dès qu'une commande est reçue de l'interface de saisie 5 elle est enregistrée dans un enregistrement de la base de données 7.
<Desc/Clms Page number 10>
Le processeur de commandes 6 est également connecté à une base de données résumée 8 ayant une capacité d'environ 0.5 Mo et une base de données de contrôle 9 ayant une capacité de l'ordre de 2 à 3 Mo. Un fichier tampon 10 et un fichier de contrôle des totaux 11 sont stockés sur disque dur.
Un processeur de paiements 20 du système hôte reçoit les données des systèmes distants 2,3 et 4 et est à son tour connecté à une base de données des paiements 21 ayant une capacité de l'ordre de 3 à 4 Mo. Le processeur de paiements 20 est en outre connecté à une base de données préposé ayant une capacité de 2 à 3 Mo. Le système 1 comprend également un processeur d'achats 25 connecté au processeur de paiements 20 et au processeur de commandes 6. Il y a une base de données clients 27 d'une capacité de l'ordre de 6 à 8 Mo connectée au processeur d'achats 25. Comme schématisé dans le coin supérieur droit de la fig. 1, il y a une série de fichiers index 30 d'une capacité totale d'environ 35 Mo.
Les fichiers index 30 sont utilisés par les divers processeurs pour accéder aux bases de données. Le schéma de la fig. 1 de l'ensemble du système est simplifié en ce sens qu'il y a un grand nombre de processeurs supplémentaires, ainsi que de bases de données et de fichiers. Le but de la fig. 1 est toutefois d'illustrer les processeurs principaux, bases de données et fichiers mémoire qui
<Desc/Clms Page number 11>
exécutent les divers processus techniques de l'invention.
Ces processus sont également exécutés par des processeurs supplémentaires non illustrés.
En se référant à la fig. 2, on illustre le fonctionnement du processeur de commandes 6 à la réception de nouvelles commandes. A l'étape 43, des données sont saisies à l'interface 5 et le processeur 6 à l'étape 44 les écrit dans la mémoire de travail (RAM). Le processeur de commandes 6 (case 45) génère automatiquement un écran d'affichage d'erreur 40 qui est transmis pour affichage à l'interface 5. Le signal transmis à l'interface 5 comprend des pixels de gestion pour afficher un nombre de lignes, chaque ligne comprenant un champ de saisie 42 et une ligne de texte 41. Chaque ligne de texte 41 définit la nature d'une erreur potentielle ou des informations relatives à des erreurs généralement concernant les données en cours de saisie.
Par exemple, une ligne de texte peut spécifier que le nombre de semaines d'étalement de paiement est sujet à vérification, tandis qu'une autre peut signaler que l'adresse du client est incomplète. L'utilisateur est incité à déplacer le curseur de l'interface 5 vers le bas passant successivement par tous les champs de saisie 42 et d'appuyer sur une touche particulière du clavier pour indiquer la quelle, s'il y en a, des lignes de texte 41 s'applique à la séance particulière de saisie. Le processeur de commandes 6 commande l'affichage d'une coche
<Desc/Clms Page number 12>
pour indiquer quelles lignes ont été indiquées.
Cette coche est toutefois comprise par le processeur de commandes 6 dans le traitement ultérieur comme étant un digit binaire "1". Des lignes non cochées sont considérées comme ayant un digit binaire "0". Après avoir reçu toutes les saisies, comme représenté à l'étape 46, le processeur de commandes 6 (case 47) génère un nombre binaire, dans cette réalisation représentant 0000110100 du jeu de champs de saisie 42. A l'étape 48, le nombre binaire est converti en format décimal (quoique alternativement il pourrait être transformé en format hexadécimal) et à l'étape 49, le nombre décimal (dans ce cas 52) est écrit dans l'enregistrement approprié de la base de données.
Le nombre décimal est écrit dans un champ de l'enregistrement de la base de données pour réception d'un indicateur d'erreur, ce champ étant par après relu chaque fois que l'enregistrement de la base de données est ouvert en lecture.
Ce processus technique aide d'abord l'utilisateur à s'assurer de prendre en considération toutes les erreurs de données possibles lors de la séance de saisie et aide donc à éviter la saisie de données erronées. En plus, un enregistrement est créé d'une ou des erreurs ou erreurs potentielles dans les données et cet enregistrement est finalement stocké de façon extrêmement efficace dans l'enregistrement de la commande. Ceci n'économise pas seulement de la mémoire mais permet d'assurer que lorsque
<Desc/Clms Page number 13>
l'utilisateur passe en revue les enregistrements des données, un enregistrement affichant une entrée dans le champ d'erreurs devra être consulté régulièrement.
On se référant maintenant à la fig. 3, on illustre un processus également exécuté par le processeur de commandes 6, mais qui en plus est exécuté par n'importe lequel des autres processeurs connectés à la base de données. Ceux-ci comprennent le processeur de paiements 20, le processeur de livraison 24 et le processeur d'achats 25. La base de données concernée est généralement identifiée par la référence 50 et contient une série d'enregistrements 51. Le déroulement du processus implique la communication avec le fichier tampon 10 en mémoire de travail. Lorsqu'un ou plusieurs enregistrements 51 de la base de données 50 doivent être mis à jour, l'enregistrement concerné est lu (case 52) et écrit (case 53) dans le fichier tampon 10. Le traitement nécessaire est exécuté dans le fichier tampon 54.
Cette opération peut être la modification du nombre de semaines d'étalement de paiement d'un article, un changement d'adresse ou encore une modification des spécifications des marchandises commandées. A l'étape 55, le processeur concerné vérifie les données modifiées par comparaison à des données de référence et par l'affichage d'invites supplémentaires invitant l'utilisateur à confirmer les données entrées. A l'étape 56, le processeur concerné remplace par écrasement l'enregistrement originel
<Desc/Clms Page number 14>
51 de la base de données 50, l'adresse physique de l'enregistrement 51 ayant initialement été stockée dans le fichier tampon 10.
Après les opérations de l'étape 56, le processeur concerné met à jour la base de données résumée 8 (case 57) pour consigner la nature de la mise à jour et l'adresse de l'enregistrement concerné. L'écriture de ces données dans la base de données résumée 8 est exécutée de façon structurée, la base de données 8 disposant de diverses catégories pour divers types de mise à jour.
Un aspect important de ces opération est que le processeur concerné à l'étape 58 insère des données de contrôle supplémentaires comprenant e. a. un cachet horaire dans les données mises à jour et écrit (case 59) les données combinées dans le fichier 9. Sur une période de traitement le fichier de contrôle 9 atteint environ 3 Mo et au point 60 qui peut être exécuté p. e. en fin de semaine, plusieurs processus de traitement par lot sont exécutés. Ces processus comprennent l'édition d'un rapport de contrôle imprimé reprenant toutes les mises à jour qui ont eu lieu pendant la période de traitement. Le processus par lots 60 peut également produire des rapports d'information concernant le traitement des données, destinés à la direction.
Un fichier tampon utilisé de cette façon aide à s'assurer que les données du fichier 50 ne soient pas corrompues et les opérations de vérification exécutées évitent que des données erronées soient écrites dans le
<Desc/Clms Page number 15>
fichier 50. La combinaison des fonctions d'accès aux fichiers résumés 8 et de contrôle 9 est extrêmement importante pour le dépistage de toute erreur survenue et également en mettant à la disposition de la direction les informations concernant la nature des mises à jour. Ceci peut également aider à éviter des mises à jour futures en assurant que les opérations transactionnelles soient exécutées différemment à l'avenir.
Le système hôte de traitement de données transactionnelles 1 comprend un processeur par lots qui, lorsqu'il est activé, vérifie à des intervalles réguliers le contenu des fichiers index 30 utilisés en temps réel pour accéder aux données des bases de données. La fig. 4 illustre le processeur de détection d'erreurs 70 qui transmet des signaux à un fichier index 30 qui accède à une base de données transactionnelle 50 contenant des enregistrements 51.
Avec le temps, le contenu d'un fichier index peut devenir erroné, pouvant ainsi donner lieu à l'envoi au processeur concerné d'une adresse physique erronée d'un enregistrement dans une des bases de données. L'intégrité du fichier index est vérifiée par le processeur de traitement par lots 70 par la création initiale d'une table 71 contenant une série de cellules adressables par le processeur 70. Chaque cellule correspond à un jeu unique d'emplacements physiques sur le disque contenant la base de données, ce jeu d'emplacements correspondant à un
<Desc/Clms Page number 16>
enregistrement précis. Il existe donc un rapport un à un entre les cellules de la table 71 et les emplacements physiques sur le disque des enregistrements 51 de la base de données 50.
Le processeur 70 transmet des signaux au fichier index 30 concerné demandant successivement l'accès à chaque enregistrement de la base de données 50. Chaque enregistrement étant accédé successivement, un 11111 binaire est écrit dans la cellule associée de la table 71. Comme le montre la fig. 4, le processeur 70 est arrivé au point d'avoir essayé d'accéder à tous les enregistrements de 1 à 896 et il y a une entrée pour chacune des cellules associées à la table 71. D'où, la série de"0"dans toutes les cellules suivantes (à partir de la ligne 8). Lors d'un deuxième accès d'un enregistrement, le contenu de la cellule est augmenté de 1 et, dans l'exemple illustré, la sixième cellule de la ligne 4 indique un deuxième accès.
Par contre, la deuxième cellule de la ligne 5 n'a pas d'entrée, indiquant qu'elle n'a pas été accédée. A la fin du processus de détection d'erreurs il sera clair quels enregistrements n'ont pas été accédés et, bien sûr, quels enregistrement ont été accédés deux ou plusieurs fois. Une action appropriée peut alors être considérée pour corriger le fichier index 30. Le processus de détection d'erreur est répété successivement pour chaque fichier index.
<Desc/Clms Page number 17>
On comprendra que l'invention propose un système dont le fonctionnement assure l'intégrité continue des données et le taux d'erreurs est réduit au minimum là où des processus complexes sont mis en oeuvre.
L'invention n'est pas limitée aux réalisations décrites ci-dessus mais peut être variée dans sa construction et ses détails.
<Desc / Clms Page number 1>
Prevention and detection of errors in a data processing system The invention relates to a transactional data processing system and particularly to a system having complex data and processing structures.
Generally, when a system is designed to process transactional data, several important aspects of processing must be taken into account. These may include sales, purchase orders, accounts, customer data processing and payment processing. As a result, some treatment systems are quite complex. However, some systems have additional complexity caused by the fact that each individual transaction is relatively complex. For example, this is the case when a transaction relates to the purchase of an object by weekly payments spread over, say, forty-two weeks, and the object must be delivered to the customer by a given date. In this case, the purchase of a single object gives rise to forty-two payment entry messages added to many other entry signals.
The structures of databases and memories are generally and necessarily quite complex and there is a great interdependence between the processing modules and the memory and storage structures.
<Desc / Clms Page number 2>
Examples of the prior art relating to the processing of transactional data include English Patent No.
GB-B-2 180 380 (Merrill Lynch) and European patent No EP-B1-0 014 312 (IBM). In the first description, the manner of using the communication and financial data processing links are important characteristics, while the second description describes in detail the operations for executing transactions using a terminal. One of these operations is for example the storage of personal identification information and the allocation of functions to transaction keys. Although the systems described in the two descriptions certainly have merits, they do not reveal provisions which help to avoid the errors which appear in complex transactional systems.
British Patent No. GB-B-2 202 656 (IBM) describes a memory reorganization system of a microprocessor system in which an addressing and management circuit is constructed to record and report an error detected in the memory during the test and to deactivate the memory circuit by redirecting its addresses. Again, the system described in this disclosure is undoubtedly very beneficial in the operations executed when an error is detected. However, it does not reveal any method of data prevention
<Desc / Clms Page number 3>
errors, or detection of erroneous data in a complex transactional data processing system having a large number of files and processing structures.
The invention aims to make available a transactional data processing system comprising technical means for dealing with these problems.
According to the invention, a transactional data processing system is proposed comprising a local network to which a number of interfacing terminals are connected and a host system, the host system comprising transactional data processing processors in communication with a certain number of database structures stored on memory units, the host system further comprising a working memory in which temporary files can be created, and in which the processor of the host system comprises: means of communication with a terminal interfacing for the reception of transactional data and for writing the data automatically received in the working memory;
<Desc / Clms Page number 4>
means of automatic search in a storage unit, of an error display screen, the particular screen sought corresponding to the nature of the data being introduced, the error display screen comprising signals pixel management to display on the interface terminal a certain number of lines, each line comprising a line of text and an associated data entry field, the screen also comprising general text indicating to the user that data must be be entered when a cursor is located in a data entry field; means for monitoring the data entered in the fields of the lines; means for automatically generating a binary number representative of the sequence of entries in the data entry fields;
and means for automatically converting the binary number into a signal representing a format in a higher base, and for writing the converted number in a predetermined field of a corresponding record.
Preferably, the central conversion means comprises means for converting from binary to decimal.
<Desc / Clms Page number 5>
In one embodiment, the binary number is generated as a function of the sequence of data entry fields seen by the user in response to the pixel management signals.
In another embodiment, each processor connected to a database structure comprises: - means for receiving a data update signal coming from an interfacing terminal; means for searching the database structure of a corresponding record and writing the record to a buffer file created in working memory; means for processing the recording in the buffer file and then for carrying out operations for verifying data stored in these locations; means for overwriting the old record in the database structure by writing the processed record to the old record;
<Desc / Clms Page number 6>
means for automatically inserting control data into the record and at the same time writing the data thus generated into a control database structure; and means for activating a batch process for processing the control data at regular intervals.
Ideally, the batch processing process for activated control data includes printed report generation modules.
In yet another embodiment, the processor further comprises means for updating a summary database structure containing data relating to the update which has been made.
In another embodiment, the system further comprises a processor for verifying the content of index files in a batch process, the verification processor comprising: means for determining the number of records stored in a database and generation structure automatic of a table in working memory, the table having a single cell associated with each
<Desc / Clms Page number 7>
recording of the structure, the organization of the table being that of the physical locations of the storage units for the records of the database; means for sending signals to a corresponding index file for successively having access to each record of the database structure;
and means for writing a marker in the corresponding cell of the structure of the table to indicate that the access to the corresponding record has been successful.
Preferably, a binary number is written in each cell, the number expressing the number of accesses that took place to the associated record.
The invention will be more clearly understood by the description below of certain implementations of the invention, given exclusively by way of example and with reference to the accompanying drawings in which: FIG. 1 is a diagram representing a part of a transactional data processing system illustrating some of the interconnections of the main processor and the storage as well as the routing of the data;
<Desc / Clms Page number 8>
fig. 2 is the schematic representation of an error marking process performed by the system; fig. 3 is a schematic representation of an updating process which prevents data corruption; and l fig. 4 is a schematic representation of the manner in which an index error detection process is carried out.
A transactional data processing system 1 is illustrated in FIG. l System 1 is used for processing data relating to transactions by which a customer, in consultation with an agent, chooses from a catalog of goods to buy. The selection is recorded by the attendant, by communication with the main office, this data including a requested delivery date and a payment spreading period. The transaction implies that the customer pays weekly for a period, in this case up to forty-two weeks, a sum of money to the attendant. The goods are then delivered at the end of the payment period, usually before Christmas.
System 1 ensures the recording of orders, the recording of weekly payments, the order processing of goods to ensure that the goods are purchased and ready in time for delivery.
<Desc / Clms Page number 9>
delivery, as well as for permanent marketing. There is a high degree of account and payment processing and payments arrive from various financial institutions in different ways, on diskette or by modem. It will therefore be noted that the transaction processing is quite complex. The invention provides technical functions underlying the data processing performed to minimize erroneous data and to detect these errors where they appear.
The invention does not deal with the nature of data processing, but with the technical background processes which ensure the technical results of increased integrity of the transactional data processed.
System 1 receives payment data from a number of remote financial institution systems, three of which are shown identified by the numbers 2,3 and 4.
In this embodiment all the payment data are transmitted by modem. The system 1 comprises a large number of interfaces 5 comprising terminals connected in the local network. A host system connected to the network comprises a command processor 6 connected to a command database 7, with a capacity of 4 to 6 MB. As soon as an order is received from the input interface 5, it is recorded in a record of the database 7.
<Desc / Clms Page number 10>
The command processor 6 is also connected to a summarized database 8 having a capacity of approximately 0.5 MB and a control database 9 having a capacity of the order of 2 to 3 MB. A buffer file 10 and a 11 totals control file are stored on hard drive.
A payment processor 20 of the host system receives data from the remote systems 2, 3 and 4 and is in turn connected to a payment database 21 having a capacity of the order of 3 to 4 MB. The payment processor 20 is further connected to an attendant database having a capacity of 2 to 3 MB. The system 1 also includes a purchasing processor 25 connected to the payment processor 20 and to the command processor 6. There is a database of customer data 27 with a capacity of the order of 6 to 8 MB connected to the purchasing processor 25. As shown in the upper right corner of FIG. 1, there is a series of index files 30 with a total capacity of approximately 35 MB.
The index files 30 are used by the various processors to access the databases. The diagram in fig. 1 of the entire system is simplified in that there are a large number of additional processors, as well as databases and files. The purpose of fig. 1 is however to illustrate the main processors, databases and memory files which
<Desc / Clms Page number 11>
carry out the various technical processes of the invention.
These processes are also executed by additional processors not shown.
Referring to fig. 2, the operation of the command processor 6 is illustrated on receipt of new commands. In step 43, data is entered at the interface 5 and the processor 6 in step 44 writes it to the working memory (RAM). The command processor 6 (box 45) automatically generates an error display screen 40 which is transmitted for display at the interface 5. The signal transmitted at the interface 5 comprises management pixels for displaying a number of lines , each line comprising an entry field 42 and a line of text 41. Each line of text 41 defines the nature of a potential error or information relating to errors generally concerning the data being entered.
For example, one line of text may specify that the number of weeks of payment deferral is subject to verification, while another may indicate that the customer's address is incomplete. The user is encouraged to move the cursor of the interface 5 downwards passing successively through all the input fields 42 and to press a particular key on the keyboard to indicate which, if any, of the lines Text 41 applies to the particular input session. The command processor 6 controls the display of a check mark
<Desc / Clms Page number 12>
to indicate which lines have been indicated.
This check mark is however understood by the command processor 6 in the subsequent processing as being a binary digit "1". Unchecked lines are considered to have a binary digit "0". After having received all the inputs, as shown in step 46, the command processor 6 (box 47) generates a binary number, in this embodiment representing 0000110100 of the set of input fields 42. In step 48, the number binary is converted to decimal format (although alternatively it could be converted to hexadecimal format) and in step 49, the decimal number (in this case 52) is written to the appropriate database record.
The decimal number is written in a field of the record of the database for reception of an indicator of error, this field being afterwards re-read each time that the record of the database is opened for reading.
This technical process first helps the user to ensure that all possible data errors are taken into account during the data entry session and therefore helps to avoid entering incorrect data. In addition, a record is created of one or more errors or potential errors in the data and this record is ultimately stored extremely efficiently in the order record. This not only saves memory but ensures that when
<Desc / Clms Page number 13>
the user reviews the data records, a record displaying an entry in the error field should be consulted regularly.
Referring now to FIG. 3 illustrates a process also executed by the command processor 6, but which in addition is executed by any of the other processors connected to the database. These include the payment processor 20, the delivery processor 24 and the purchasing processor 25. The database concerned is generally identified by the reference 50 and contains a series of records 51. The progress of the process involves the communication with buffer file 10 in working memory. When one or more records 51 of the database 50 have to be updated, the concerned record is read (box 52) and written (box 53) in the buffer file 10. The necessary processing is executed in the buffer file 54.
This operation can be the modification of the number of weeks of staggered payment of an item, a change of address or even a modification of the specifications of the goods ordered. In step 55, the processor concerned verifies the modified data by comparison with reference data and by the display of additional prompts inviting the user to confirm the data entered. In step 56, the processor concerned overwrites the original recording
<Desc / Clms Page number 14>
51 of the database 50, the physical address of the record 51 having initially been stored in the buffer file 10.
After the operations of step 56, the processor concerned updates the summary database 8 (box 57) to record the nature of the update and the address of the recording concerned. The writing of this data in the summarized database 8 is executed in a structured manner, the database 8 having various categories for various types of update.
An important aspect of these operations is that the processor concerned in step 58 inserts additional control data comprising e. at. a time stamp in the updated data and writes (box 59) the combined data in the file 9. Over a processing period the control file 9 reaches approximately 3 MB and at point 60 which can be executed p. e. at the end of the week, several batch processing processes are carried out. These processes include the publication of a printed inspection report showing all the updates that have taken place during the processing period. The batch process 60 can also produce data processing information reports for management.
A buffer file used in this way helps to ensure that the data in file 50 is not corrupted and the verification operations performed prevent erroneous data from being written to the
<Desc / Clms Page number 15>
file 50. The combination of the functions of access to the summary files 8 and of control 9 is extremely important for the detection of any error which has occurred and also by making information concerning the nature of the updates available to management. This can also help avoid future updates by ensuring that transactional operations are executed differently in the future.
The host transactional data processing system 1 comprises a batch processor which, when activated, checks at regular intervals the content of the index files 30 used in real time to access the data of the databases. Fig. 4 illustrates the error detection processor 70 which transmits signals to an index file 30 which accesses a transactional database 50 containing records 51.
Over time, the contents of an index file can become erroneous, which could therefore give rise to the sending to the processor concerned of an erroneous physical address of a record in one of the databases. The integrity of the index file is checked by the batch processor 70 by the initial creation of a table 71 containing a series of cells addressable by the processor 70. Each cell corresponds to a unique set of physical locations on the disk containing the database, this set of locations corresponding to a
<Desc / Clms Page number 16>
precise recording. There is therefore a one-to-one relationship between the cells of the table 71 and the physical locations on the disk of the records 51 of the database 50.
The processor 70 transmits signals to the index file 30 concerned successively requesting access to each record in the database 50. Each record being accessed successively, a binary 11111 is written in the associated cell of the table 71. As shown in the fig. 4, the processor 70 has arrived at the point of having tried to access all the records from 1 to 896 and there is an entry for each of the cells associated with the table 71. Hence, the series of "0" in all the following cells (from line 8). During a second access to a record, the content of the cell is increased by 1 and, in the example illustrated, the sixth cell in line 4 indicates a second access.
However, the second cell on line 5 has no entry, indicating that it has not been accessed. At the end of the error detection process it will be clear which records have not been accessed and, of course, which records have been accessed two or more times. An appropriate action can then be considered to correct the index file 30. The error detection process is repeated successively for each index file.
<Desc / Clms Page number 17>
It will be understood that the invention proposes a system whose operation ensures the continuous integrity of the data and the error rate is reduced to the minimum where complex processes are implemented.
The invention is not limited to the embodiments described above but can be varied in its construction and its details.