Brevet FR2753815A1 — publié le 19980327

Une technique economique pour le stockage et le traitement des DATES pour l'AN 2000 Cette invention présente une solution technique pour répondre de façon efficace et économique à un problème chronique auquel sont confrontées la majorité de petites, moyennes et grandes entreprises: le stockage et le traitement des dates pour l'an 2000 dans les applications et les systèmes informatiques. Il s'agit d'un problème complexe, de porté mondiale, sur lequel sont penchés: des- sociétés de service en informatique, des éditeurs de logiciels ainsi que des constructeurs (comme: IBM). Malgré de nombreux articles qui se succèdent depuis quelques années ainsi que les revendications multiples de certaines sociétés dans les presses professionnelles (comme: 01 Informatique et Le Monde Informatique), on constate aujourd'hui qu'il n'y a toujours pas de solution efficace et économique dans ce domaine. Ce problème est toujours qualifié comme: "le danger qui guette", "le syndrome. de l'an 2000", "le cauchemar de fin de siècle", "la bombe à retardement", "la maladie de l'an 2000", etc. (cf. Le Monde Informatique du 14/6/96 et 01 Informatique du 21/6/96, etc.). L'origine du problème est le format de stockage (réduit en espace disque) des dates sur six digits dans une majorités des applications écrites en L3G/L4G (comme COBOL, FORTRAN, PASCAL, BASIC, etc.) jusqu'à ces dernières années. Les conséquences incontournables de ce format de stockage se trouvent dans l'ensemble des éléments constituant les programmes: les longueurs des zones de travail, la tailles des enregistrements des fichiers et des records bases de données, les tests, les calculs, les tris, les commandes OS dans les JCL, les formats d'affichage ou de saisie des écrans, les formats des fichiers d'impression, etc. Les solutions proposées jusqu'à aujourd'hui sont basées sur des méthodes et des outils d'aide à la maintenance des applications dans l'optique de les faire évoluer vers une gestion des dates étendues en huit digits malgré tous les risques que cela peut comporter. Par conséquent, l'ensemble des éléments précités sont remis en question et soumis à des modifications par intervention humaine sur les codes et par une démarche appliquée au cas par cas voire ligne par ligne. Une charge évaluée à plusieurs milliers d'années/homme au niveau mondial, pour un résultat sans aucune valeur ajouté. Objectifs visés par cette invention La solution proposée permettra de: * Pérenniser les applications touchées par le problème cité bien au delà des années 2000 tout en évitant les charges excessives des solutions classiques. * Elargir le porté des valeurs des données DATE tout en conservant la longueur physique des zones de stockage. * Automatiser la conversion des programmes et éviter les risques due aux interventions manuelles sur les codes. * Eviter l'obllgatlon de modifier: les JCL, les formats des grilles d'écrans, les fichiers de données et les fichiers d'impression. * Autoriser la cohabitation entre des programmes ayant une vision ancienne des données DATE et ceux ayant une vision évoluées de celles-ci. Techniques employées Cette invention est basée sur les étapes et les techniques suivantes: * Introduire un nouveau type de donnée DATE dans la syntaxe des langages classique L3G/L4G. * Dissocier les traitements effectués sur une donnée DATE de son format de stockage physique. * Appliquer une technique de compression permettant à la fois d'élargir le porté des valeurs des données DATE et rester la plus proche aux structures physique des données DATE actuelles. * Appliquer une technique de transcodage dynamique (et externe aux programmes) pour autoriser la cohabitation entre les formats anciens et les formats nouveaux des données DATE. Procédés de realisation Cette invention propose les procédés suivants: (a) Appliquer la technique de compression suivante (Fig. 5, 6) permettant le codage de l'années au delà de l'an 2000, au mois jusqu'à l'an 2069 pour les zones paquets (deux digits sur un caractère) > Si la valeur de l'année est inférieur à 2000: alors, conserver le format de stockage actuel sinon, stocker le digit de gauche en codage HEXA et laisser le digit de droit en codage DECIMAL. Exemple: Année Etendue (2 car.) Paquet (8 bits) "1900" - > "00" 0000 0000 "1955" - > "55" 0101 0101 "1999" - > "99" 1001 1001 "2000" - > "A0" 1010 0000 "2055" - > "E5" 1110 0101 "2069" - > "F9" 1111 0101 Cette technique de compression a l'avantage d'être à la fois évolutive et très proche à la structure de définition des données DATE actuelles. Elle permet d'assurer une transparence ascendante dans certains traitements comme les tris et les tests de comparaison entre les données DATE et les données de type caractère, etc.. (b) Elargir la syntaxe de définition des données dans les langages L3G/L4G par des extensions suivantes: "USAGE IS DATE (ou YYMMDD ou DDMMYY ou YYMM ou MMDD ou ...)", "STORAGE IS COMPRESSED (ou UNCOMPRESSED)". La reconnaissance des données de type DATE permettra d'appliquer automatiquement des règles de gestion adaptées à ces données dans les opérations de calculs, les tests de comparaisons, les transferts et les conversions. (c) Créer un outil d'analyse et de conversion de code programme (Fig. 1, 7) dont la définition est résumée dans le diagramme séquentiel suivant: b Mémoriser l'ensemble des noms de rubriques susceptibles de contenir des données de type DATE à partir d'un fichier de configuration. > Pour chaque rubrique de type DATE mémorisée: sk Trouver les interactions avec d'autres rubriques de type non-DATE. sE Proposer le passage des rubriques trouvées en type DATE. > Mettre à jour le fichier de configuration si nécessaire. Cet outil sera capable de mémoriser les rubriques dates (USAGE IS DATE, etc.) des fichiers à partir d'une librairie (exemple: CopyLib pour les FD/COBOL), puis en fonction de leurs interaction avec d'autre rubriques proposer celles qui sont susceptibles de porter la clause USAGE IS DATE (ou YYMMDD ou DDMMYY ou ...). Par extension, il saura proposer et/ou accepter un format YYMMDD pour une rubrique de travail et un format DDMMYY pour une zone écran (selon une configuration initiale et selon le pays, etc.) (d) Créer un ensemble de fonctions de conversion de données DATE (Fig. 3 et 4) permettant les transformations des données DATE entre les rubriques de longueur et/ou format différent. Exemple: Transformer une donnée de format YYMMDD sur six digits (compressé ou non) vers un format DDMMYY sur huit ou dix digits (année sur quatre digits plus les caractères '/' pour une rubrique d'affichage sur écran). (e) Créer un outil de pré-compilation (Fig. 1, 2, 8) de code programme dont la définition est résumée dans le diagramme séquentiel suivant: > Mémoriser l'ensemble des rubriques déclarée avec USAGE IS DATE, etc. dans le programme. > Pour chaque opération de calcul ou de comparaison effectuée sur une rubrique de type DATE: > Transférer la valeur de la rubrique vers un registre de travail sous le format étendu et non-compressé. > Remplacer la rubrique par le registre concerné dans l'opération. 2 > Pour chaque rubrique de type DATE recevant le résultat d'une opération de calcul: > Remplacer la rubrique par un registre de travail dans l'opération de calcul. > Transférer la valeur de du registre vers la rubrique sous le format correspondant à sa déclaration. Cet outil sera capable de traiter les clauses USAGE IS DATE, etc., et remplacer toutes opérations effectuées sur les rubriques dates soit par des appels aux fonctions de gestion de date, soit par les mêmes opérations sur des rubriques particulières (type: registres de travail) créées et chargées par les valeurs des dates en format étendu (Fig. 3 et 4). Il aura à avertir (par des Warnings) le programmeur sur les opérations ambiguës ou complexes, lui permettant de simplifier les opérations ou utiliser les fonctions appropriées reconnues par le pré-compilateur (ou le compilateur même). Par extension, une rubrique définie avec 'USAGE IS DATE' peut être gérée de façons différentes selon son emplacement. Par exemple, en format YYMMDD dans un enregistrement de fichier, en format DDMMYY dans une grille d'écran (selon configuration de pays), etc. La possibilité de préciser 'USAGE IS YYMMDD' (ou d'autres compositions de YY, MM et DD) permettra d'éviter l'ambiguïté dans certains cas de figure. Le transcodage de l'année entre les formats étendu, non-étendu, compressé et non-compressé se ferra de façon automatique en fonction de type et de la longueur des rubriques. Le codage de l'année sur deux digits sera en mode compressé par défaut, toute en autorisant des données non-compressées en lecture pour la compatibilité ascendante. (f) Appliquer la technique de transcodage suivante dans les fonctions de conversion de DATE pour obtenir de façon unique une valeur de DATE en format étendu à partir d'une valeur DATE en ancien format (non-compressé et non-étendu): > Si année YY est supérieure à la valeur "yy" 9 alors, année YYYY aura la valeur "19" & YY 9 sinon, année YYYY aura la valeur "20" & YY La valeur "yy" étant appliquée selon une configuration évolutive au cours-des années. Exemple: if YY > "10" then YYYY="19" & YY else YYYY="20" & YY. L'application de cette technique de façon dynamique et externe aux programmes permettra la cohabitation entre les formats anciens et les formats nouveaux des données DATE. L'algorithme appliqué peut évoluer chaque année sans besoin de modifier les programmes ou les données des fichiers et permettra de distinguer le siècle avant le chargement des registres de travail pour les calculs, les comparaisons, les échanges avec les rubriques de format étendu, etc. Avantages Les procédés ci-dessus sont applicables, quelque soit la plate-forme matériel ou le langage de programmation L3G/L4G. Ils permettent de pérenniser les applications au moins jusqu'à l'an 2069 avec une charge de travail négligeable par rapport aux solutions connues jusqu'à présent (exemple: 30 minutes par programme de 1000 lignes COBOL au lieu de 2 jours). La charge de réalisation des outils proposés par cette invention sur une plate-forme matériel et pour un langage de programmation reste négligeable par rapport à la charge de création du compilateur même (exemple: 4 mois par rapport à 4 ans) . La démarche appliquée au niveau d'un pré-compilateur au lieu d'un compilateur, permettra d'économiser la charge de réalisation de l'outil pour un même langage sur les plates-formes différentes. REVENDICATIONS (1) Procédé de stockage et de traitement des données DATE pour l'an 2000, caractérisé par les étapes suivantes: (a) Création d'un nouveau type de rubriques dans les langages classiques L3G/L4G, par l'extension de la syntaxe de définition des rubriques: USAGE IS DATE, YYMMDD, etc. (b) Enrichissement de format de stockage des données de type DATE définies suivant l'étape (a), par une technique de compression de ces données sur le même espace de mémorisation et de stockage. (c) Enrichissement des codes programmes suivant les étapes (a) et (b), par la définition de l'outil d'analyse et de conversion du code programme. (d) Dissociation entre les traitements effectués sur des données DATE et leurs formats de stockage suivant les étapes (a) à (c), par la définition de l'outil de pré-compilation et par les fonctions de conversion de DATE. (e) Transcodage automatique des données DATE du format ancien vers le format étendu suivant l'une des étapes (a) à (d), par l'application d'une algorithme externe et évolutive pour déterminer le siècle.