Naca 1.2 : support Oracle et Microfocus pour la migration de Cobol vers Java

Posté par (page perso) . Modéré par Florent Zara.
30
16
oct.
2009
Java
Les outils du projet NACA en Open Source sont étendus (support fichiers Microfocus, Oracle, nouveaux verbes Cobol, etc.) dans leur version 1.2 pour rendre toujours plus simple la migration de Cobol sur mainframe vers Java et Linux. Nous avons publié la version 1.2 de notre framework de conversion 100% automatique de Cobol vers Java, développé initialement lors de notre projet NACA de migration des applications Publicitas d'un mainframe IBM vers une (toute petite) ferme de serveurs Intel.

Depuis la mise en Open Source de ces outils, nous avons allègrement dépassé le cap des 1500 téléchargements et connaissons des tests pilotes, voire des migrations avec nos outils déjà largement avancées sur quatre continents : seule l'Afrique nous manque à ce moment.

Tous les détails du projet se trouvent dans les articles déjà publiés sur ce site (voir liens) et des précisions dans la suite de la dépêche. À l'occasion de ces divers projets, nous avons reçu:
  • Des annonces de bugs que nous avons corrigés ;
  • Des contributions externes que nous avons déjà (en partie) intégrées ;
  • Des mandats d'extension de nos outils qui nous ont permis d'en étendre les fonctions génériques avec l'autorisation par le commanditaire de les remettre à disposition de la communauté.
Quelques premiers retours d'expérience après la v1.2 nous ont fait produire une version 1.2.0.1 qui est celle que nous vous recommandons de télécharger, dorénavant depuis Google Code. Les grandes avancées depuis la V1.1 sont :
  • La prise en charge d'Oracle par la combinaison de deux techniques : un transcodage automatique de certains ordres de la syntaxe DB2/UDB d'IBM vers la syntaxe Oracle, associée à une mécanique d'extraction / remplacement des ordres DB2 par des ordres Oracle pour la partie la plus complexe des requêtes SQL. Ceux qui liront le code source verront que le support JDBC par Oracle est très limité, voire médiocre, ce qui nous a obligé à produire beaucoup de code spécifique additionnel pour supplanter les fonctions standards manquantes ;
  • La gestion des formats de fichiers Microfocus pour les fichiers de données, en plus du format propre à NACA. C'est très utile pour intégrer d'autres outils du marché (tris externes, etc...) qui respectent très souvent ce format. Toutes les options de format sont gérées y compris le traitement correct des fins de ligne (CR vs CR LF) dans tous les cas, même si le fichier est traité sur une machine qui attend des fins de ligne inverses de celles où le fichier a été généré ;
  • L'extension des options et structures lexicales supportées pour certains verbes Cobol comme MOVE, INSPECT, etc...
  • La gestion de nouveaux verbes Cobol: POWER, MODULO, SEARCH, NEXT SENTENCE, etc.
  • La gestion des clauses COPY de programmes et données imbriquées ;
  • Gestion d'options de configuration du framework pour en augmenter la flexibilité en fonction de l'environnement du projet ;
  • Beaucoup de nettoyage dans les structures des répertoires et l'organisation / nommage des fichiers afin de supprimer au maximum les spécificités du projet NACA interne initial.
Pour tous les détails précis, voir le fichier ChangeLog inclus dans le paquet de code source, téléchargeable via Google Code, nouveau dépôt officiel pour notre projet (voir lien ci-joint). Si vous êtes fan de technologie, vous pourrez aussi lire les 65 pages de documentation technique, très détaillée sur l'architecture de nos outils que nous avons aussi récemment publiée sur le wiki Google Code.

Tous les retours sont bienvenus ! ;-)
  • # Encore encore

    Posté par (page perso) . Évalué à 6.

    C'est vraiment un superbe projet. Ce n'est pas mon domaine d'activité mais je lis toutes tes dépêches avec gourmandises: les "détails du projet" comme tu dis, ont tellement d'ampleur, qu'on a beau travailler dans d'autres domaines, on apprend plein de trucs. En plus c'est presque un cours de méthodologie. Tu dois être un bon chef de projet...
    Encore encore, d'autre dépêches, s'il te plait!

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Encore encore

      Posté par (page perso) . Évalué à 7.

      J'oubliais:
      ça me sidère qu'une boite libère un tel projet, surtout vu les arguments et le soin avec lequel c'est fait (pour les curieux, c'est dans le 3e lien de la dépêche). On devrait te voter un prix spécial rien que pour ça.
      En attendant je suggère aux modérateurs de te mettre en tête sur la liste des dépêches à primer, ce sera toujours ça.

      C'est peut -être excessif, mais à lire des nouvelles pareilles, comment s'empêcher de penser aux années 90 où on nous moquait, en nous regardant comme des crétins farfelus? toutes ces années passées à convaincre des gens, à leur montrer que le libre c'est mieux ça n'a vraiment pas été inutile.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Encore encore

        Posté par (page perso) . Évalué à 4.

        En attendant je suggère aux modérateurs de te mettre en tête sur la liste des dépêches à primer, ce sera toujours ça.

        Je vais te livrer un secret : la note d'une dépêche entre en jeu dans le choix des dépêches à primer. As-tu cliqué sur "pertinent" ?
    • [^] # Re: Encore encore

      Posté par (page perso) . Évalué à 5.

      Salut zero heure,
      Merci pour les fleurs: j'essaierai de continuer à poster dans la même veine! ;-)
      a+
      didier
  • # Et, ça se passe comment pour l'arithmétique ?

    Posté par . Évalué à 2.

    Quand on a en interface externe (fichier) avec des valeurs en "PACKED-DECIMAL", en "DISPLAY" signé ou pas (avec des PIC 9(13)V99 et des PIC S9(11)V999...) comment le Pascal ou autre langage fait sans passer en flottant (qui n'est pas terrible pour faire des additions et soustractions).
    Il me semble qu'il y a des instructions spécialisées (s390 et autres AS400) faisant toutes les opérations arithmétiques directement sur les chaines décimales ou décimales codée bianire, la question à quand le coprocesseur décimal cablé pour Centrino et Atlon ?
    Peut-on raisonnablement faire un bilan d'entreprise en Pascal ou en C et avoir un Actif égal au Passif ?

    Je me souviens d'une application de gestion qui avait été développée par une boite de service en FORTRAN (ces programmeurs devaient être en inter contrat), le compte de résultats avait tendance à beaucoup énerver les comptables de l'hôpital en question ! Mais c'était il y a quelques 25 ans...

    Pourquoi vouloir abandonner le Cobol (qui était déjà en train de mourir dans les années 70, mais le canard est toujours présent au poste de travail) ? La syntaxe est simple, il faudrait, dans un premier temps, simplement améliorer les possibilités d'édition et proposer (en gardant la compatibilité) des formatages comme en C par exemple, cela réduirait les descriptions de données.

    Cela dit, j'aime assez le Pascal (trop peu utilisé dans l'industrie) ainsi que ADA.
    • [^] # Re: Et, ça se passe comment pour l'arithmétique ?

      Posté par . Évalué à 2.

      bah c'est pas très dur, on garde tous ces types bizarres et on ne convertit rien, c'est à dire qu'on déclare des types de données correspondants et qu'on implémente les opérations nécessaires pour ces nouveaux types, même des opérations de base comme l'addition

      du coup, ça rame, mais ça fait exactement ce qu'on veut et c'est portable partout où il y aura un compilateur Cobol
      • [^] # Re: Et, ça se passe comment pour l'arithmétique ?

        Posté par . Évalué à 3.

        Justement, Ça rame beaucoup pour rien !
        Pour l'instant, donc gardons le Cobol !
        Quand on aura des processeurs d'au moins 96 bits (dont un pour le signe) et les instructions arithmétiques adaptées gérant la position de la virgule éventuelle, tous les langages de programmation pourront le remplacer...

        Après cela, quel DSI prendra le risque de décider de migrer une application stratégique pour son entreprise qui tourne depuis 20 ans. Ce sera un contrat pour des années de bugs !
        C'est pour cela que le cœur des grosse applications reste en Cobol/DB2, on se contente de rhabiller les interfaces Homme/Machine (CICS est remplacé par (ou associé à) une couche WEB.

        Rendez-vous dans 15 ans. Cobol venant de fêter ses 50 ans, il sera peut-être à la retraite.

        @+
        • [^] # Re: Et, ça se passe comment pour l'arithmétique ?

          Posté par (page perso) . Évalué à 2.

          Bonjour Jean,

          Nous avons migré notre application de 4 millions de lignes de Cobol vers Java avec le package NACA que nous avons ensuite mis en open source.

          C'est plus stable, plus rapide ... et 3 millions d'euros moins cher / an. ça vaut le coup, non ?
          didier
          • [^] # Re: Et, ça se passe comment pour l'arithmétique ?

            Posté par (page perso) . Évalué à 2.

            PS: bien sûr, ce ne pas un projet simple. Il faut donc le "buy-in" du management (j'ai eu celui de mon DSI à l'époque car il voulait impérativement ces économies). On n'a rien sans rien, n'est-ce pas ?
            Aujourd'hui, mon DSI est un homme heureux sur le sujet!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.