Didier DURAND a écrit 40 commentaires

Bonjour Julien et Jean-Max,

Merci des appréciations flatteuses sur le projet Naca que j'avais lancé à l'époque puis open sourcé quand la 1ère migration fur terminée.

Je sais que l'approche ligne à ligne peut paraître surprenante voire iconoclaste mais c'est du pragmatisme: on permet une adaptation rapide des développeurs venant du Cobol.

Il y a une vraie demande: c'est pour cela que nous continuons à développer l'approche initiale Naca dans la société Eranea montée pour poursuivre le développements des outils.
Les besoins sont généralement doubles: économie et modernisation.

Et effectivement, la traçabilité (et les stack dumps…) de Java améliore la "transparence" du Cobol initial lors de débordements de tableaux et autres approximations coutumières de certains programmes Cobol. Sans parler du "plaisir" à pouvoir débugger du Cobol transcodé via le debugger Java d'Eclipse.

Nous utilisons ces outils actuellement à la migration (10M lignes de Cobol) d'une privée genevoise de renom. Me contacter pour détails.

PS: on voit aussi beaucoup de sociétés qui veulent passer au Cloud Computing vite mais qui sont bloquées par l'entrave que représente Cobol. Le transcoder vers Java lève l'écueil.

Bons projets de transcodage

A dispo si questions

didier

Bonjour Djano,

Merci pour les encouragements!
De toute façon, on s'éclate bien: le sujet est passionnant et, en cette période économiquement difficile, le sujet intéresse les DSI.
cordialement
d. durand (fondateur d'Eranea)

... à tous ceux qui ont voté pour moi pour me pemettre d'obtenir ce prix: je potasserai le bouquin choisi avec intérêt.
didier

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!

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

Salut zero heure,
Merci pour les fleurs: j'essaierai de continuer à poster dans la même veine! ;-)
a+
didier

Bonjour Yves,

En fait, nous n'avons plus vraiment besoin du transcodeur: nous travaillons maintenant sur le Java qui est le nouveau source officiel de notre application Pub2000 (Le COBOL est à la poubelle)

Comme vous le soulignez, nous avons fait beaucoup d'efforts pour la lisibilité: j'ai publié un exemple concret sur mon blog perso (en cas de besoin, me contacter)

Enfin, nous ne sommes pas éditeurs d'où la démarche d'open sourcing du code pour restituer ce que nous avons reçu du Libre. Par contre, si qqn veut de notre assistance pour son propre projet, nous sommes dotés d'une expertise toute fraîche et bien réelle. Donc, nous ne sommes pas contre qq mandats d'assistance sur les projets similaires d'autres.

salutations
didier

Bonjour Yves,

Je citais le cloud computing pour la croissance horizontale et pas le SAN
cordialement
didier

Bonjour Yves,

On ne peut pas tout faire en même temps.....
Passer d'un mainframe à des serveurs Linux, c'est déjà un bon pas,non ? Maintenant, on peut construire vers le cloud computing depuis cette base.

cordialement
didier

Nous avons utilisé une double redondance:
-un SAN à très haute dispo auquel tous les serveurs du cluster sont accroché
- une redondance horizontale avec des "boîtes" en parallèle (car peu coûteuses) pour pallier les pannes. Ensuite différents dispositifs hw et sw de load-balancing envoient les requêtes vers les serveurs de transaction en "pleine forme".

PS: il semble que le cloud computing (EC2 d'Amazon) et Google avec son million de serveurs vont dans la même direction.

à dispo pour d'autres compléments

didier

Bonjour baud123,

Pour répondre juste à la partie finale: nous avons essayé de virtualiser même les conflits inter-VM (charge des processeurs) nous ont fait revenir en arrière.

De toute façon, mon expérience est que les coûts essentiels dans les archis serveurs
a) sont dans les RH et pas dans le hard: donc pas de réelle nécéssité d'optimiser les coûts HW au dernier centime (contrairement au mainframe...). Il est souvent plus efficace d'un point de vue financier global de mettre en place un serveur de plus que tenter de les empiler (avec les problèmes précités) dans une architecture virtualisée (VMware, Xen, etc...)

b) dans la gestion des OS (nombre d'images d'OS) que dans les boîtes: on passe beaucoup plus souvent des patches que l'on ne prend le tournevis pour changer qch au hw.

Donc, la virtualisation ne serait (toujours selon mon expérience perso...) qu'une optimisation du 2ème ordre. A admettre que ce soit vraiment une optimisation.

Cordialement
didier

Bonjour Djainette,

O peut effectivement s'arrêter en chemin dans la migration et ne migrer que le front-end

Nous avons, dans notre cas, décidé d'aller au bout car il y avait des millions d'euros à économiser chaque année de manière récurrente.
cordialement
didier

Bonjour pwet_,

Vous apportez-vous même la réponse dans la seconde question: nous ne sommes pas moins fiables mais plus fiables car nous avons pu bâtir une redondance active dans le nouveau système que nous n'avions pas dans l'ancien.

De plus, nous avons pu bâtir un centre de disaster recovery que nous n'avions pas avant à cause des coûts mainframe.

Enfin, les pcs nous ont apporté des possibilités de croissance horizontale (par ajout de machines) et de load-balancing (les programmes "lourds" sur des machines dédiés) que nous n'avions pas avant.

Honnêtement, nous expérimentons depuis 15 mois une meilleure architecture que celle que nous avions avant avec le mainframe (dixit notre resp. d'exploitation qui n'était pourtant pas "chaud" pour linux/serveurs au début.

Si jamais, je suis à votre disposition pour d'autres questions.
cordialement
didier

Karmatronic,
Merci!
Elles peuvent entrer en contact avec nous si elles veulent de l'aide ou des conseils
cordialement
didier

Bonjour Volia,

Il faut lire les autres articles que je pointe en entête: nous avons fait ainsi pour aller très vite et économiser chaque année des millions d'euros.

Ces millions d'euros nous permettent maintenant de financer le développement d'une autre version totalement OO et adaptée au nouveaux besoins de notre business

Sans ces économies, cette nouvelle version auraît été très dure à financer....

Concernant les exemple: un peu de patience. Ils vont suivre!...
didier

Bonjour djainette,

on y pense mais il y a encore qq questions en suspend.

didier

Bonjour PRPS,

C'est juste ce que l'on appelle une vraie appication. L'informatique professsionnelle ne se limite pas à des mashups de 100 lignes....

J'écris cela parce que je connais aussi des appllications natives OO encore nettement plus grosse que celle-ci.

Et le but n'est pas d'avoir la plus grosse, c'est juste de répondre aux vrais besoins.

didier

Bonjour,

Oui, nous avons une représentation objet très poussée: chaque instruction est un objet et même chaque partie d'une instruction (condition d'un test) est un objet

cordialement
didier

Si je peux me permettre...

J'ai utilisé transcodage plutôt que compilation car il y a dans "transcodage" l'idée de passer d'un code compréhensible par l'être humain (COBOL) à un autre code compréhensible (Java). Pour moi dans compilation, il y a finalement passage à un code machine incompréhensible par l'homme.

Par ailleurs, comme le niveau sémantique des 2 codes est similaire, je n'ai pas utilisé "traduction" car effectivement comme dit plus haut par IsNotGood, il n'y a pas d'apport sémantique dans le transcodeur. Pas mieux avant qu'après. donc pas de traduction.

Voilà, j'espère que cela tient debout à vos yeux! ;-)
cordialement
didier

Bonjour Benoar,

L'approche MDA était trop complexe: le PIM (Platfom Indépendent Model) était très dur à "retro-enginieré". Nous sommes donc "seulement" passéss d'un PSM (Platform Specific Model) [Cobol] à un autre [Java].

Le PIM , ce sera pour la prochaine fois ! ;-)

Merci pour votre appréciation

Concernant le PS, on regarde toutes les éventualités mais une release OSS "interroge" beaucoup nos juristes. Il faut laisser un peu de temps au temps...

cordialement
didier

Bonjour Windu,

Cela nous a fait aussi plaisir de livrer tous ces détails pour partager les résultats de notre travail.

cordialement
didier

test

Et les distros payantes de Linux type Redhat ? Je taquine...
[De toute façon, LIbre ne veut pas dire gratuit même si c'est le cas 99.9%]

Bonjour Obsidian,

3 points:

1)Le problème de l'obsolesence des technologies se posera toujours

2) nous avons transcrit les écrans en dialogue HTML/CSS.

3) les programmeurs C/C++ se font encore plus rares (à mon regret: cela était mon langage initial) ) de nos jours que les progs Java. En tout cas dans l'industrie.

didier

Bonjour BillPasGates,

Nous ne travaillons pas à la même échelle que Google mais notre nouvelle architecture est devenue une architecture à croissance horizontale: nous avons éclaté des fonctions auparavant rassemblées sur le mainframe sur différentes boîtes. De plus, nous povons aussi facilement ajouter des serveurs comme notre application transactionnelle le demande.

Avant il fallait upgrader tout le mainframe ....avec des factures à 6 ou 7 chiffres!

cordialement
didier