Je me permets de commenter. Je suis développeur Java/JEE depuis 5ans, et chez un client dont le mainframe et le cobol sont sacro saint. Où les mythes du style "cobol c'est + mieux que vos jouets en java" sont fortement ancrés dans la tête des décideurs…
Il y a quelque points à aborder ici.
1) Il n'existe pas de benchmark opposant cobol à d'autres langages. Toutes les affirmations sur la célérité du cobol sont des paroles en l'air venant de manager dont le but est de justifier les facturations d'IBM.
De mon expérience personnelle, je peux affirmer qu'il n'y aucune raison pour qu'un programme cobol traite un fichier plus rapidement qu'un autre écrit en C ou Java. Deuxièmement, en ce qui concerne les accès transactionnels (TP), ils sont incroyablement peut performant en comparaison des serveurs d'application, notamment à cause des allocations mémoires aux couts stratosphérique.
A l'heure des google, facebook, twitter… cela fait pale figure. Quand on sait que derrière facebook il y a plusieurs "jouets" opensource comme Hadoop qui permettent de gérer des péta-octets de données. Tout ce petit monde est écrit en C/Java et ça fonctionne plutôt bien vous ne trouvez pas ? J'ai également en tête une société qui a mise au point un logiciel de trading, en java, capable de traiter 6 millions de transaction par seconde sur une "vulgaire" machine x86 de quelques milliers d'euros.
2) L'emprise des mainframe est problématique. Les entreprises françaises publiques comme privées sont pieds et poings liés à une société américaine (IBM). Bonjour la stratégie économique …
3) Convertir ligne à ligne des programmes écrits en COBOL dans un autre langage n'est pas du tout la bonne approche. La transcription de langage est à mon avis une catastrophe. La bonne approche est d'écrire un émulateur, une et une seule fois permettant de faire fonctionner l'ensemble des programmes cobol sur une plateforme pérenne. Cela a été fait pour la JVM. En effet on peut maintenant faire tourner des programmes cobol dans une JVM… et mieux que ça, on peut les déployer dans un Cloud. C'est à dire que l'on remplace le mainframe IBM qui coute des millions d'euros par des instances EC2. Les IHM restent en CICS 3270.
[^] # Re: Mauvaise approche
Posté par bugsan . En réponse à la dépêche Le COBOL est mort, vive le COBOL. Évalué à 0.
Oups j'ai parlé d'émulateur alors que la solution dont je parle est un compilateur Cobol=>bytecode. Aux temps pour moi ^
# Mauvaise approche
Posté par bugsan . En réponse à la dépêche Le COBOL est mort, vive le COBOL. Évalué à 0.
Bonjour,
Je me permets de commenter. Je suis développeur Java/JEE depuis 5ans, et chez un client dont le mainframe et le cobol sont sacro saint. Où les mythes du style "cobol c'est + mieux que vos jouets en java" sont fortement ancrés dans la tête des décideurs…
Il y a quelque points à aborder ici.
1) Il n'existe pas de benchmark opposant cobol à d'autres langages. Toutes les affirmations sur la célérité du cobol sont des paroles en l'air venant de manager dont le but est de justifier les facturations d'IBM.
De mon expérience personnelle, je peux affirmer qu'il n'y aucune raison pour qu'un programme cobol traite un fichier plus rapidement qu'un autre écrit en C ou Java. Deuxièmement, en ce qui concerne les accès transactionnels (TP), ils sont incroyablement peut performant en comparaison des serveurs d'application, notamment à cause des allocations mémoires aux couts stratosphérique.
A l'heure des google, facebook, twitter… cela fait pale figure. Quand on sait que derrière facebook il y a plusieurs "jouets" opensource comme Hadoop qui permettent de gérer des péta-octets de données. Tout ce petit monde est écrit en C/Java et ça fonctionne plutôt bien vous ne trouvez pas ? J'ai également en tête une société qui a mise au point un logiciel de trading, en java, capable de traiter 6 millions de transaction par seconde sur une "vulgaire" machine x86 de quelques milliers d'euros.
2) L'emprise des mainframe est problématique. Les entreprises françaises publiques comme privées sont pieds et poings liés à une société américaine (IBM). Bonjour la stratégie économique …
3) Convertir ligne à ligne des programmes écrits en COBOL dans un autre langage n'est pas du tout la bonne approche. La transcription de langage est à mon avis une catastrophe. La bonne approche est d'écrire un émulateur, une et une seule fois permettant de faire fonctionner l'ensemble des programmes cobol sur une plateforme pérenne. Cela a été fait pour la JVM. En effet on peut maintenant faire tourner des programmes cobol dans une JVM… et mieux que ça, on peut les déployer dans un Cloud. C'est à dire que l'on remplace le mainframe IBM qui coute des millions d'euros par des instances EC2. Les IHM restent en CICS 3270.