Cobol, il y a tant de choses à dire…

Cobol, un langage toujours efficace !

6 janvier 2016

N'oublions pas la situation des années 1950/1960, où de nombreux constructeurs informatiques proposaient chacun leur ordinateur, avec son propre langage d'assemblage... et donc de la difficulté d'écrire un programme "unique", exploitable sur l'ensemble du parc. Fortran et Cobol, langages compilés de haut niveau, permettent alors de se concentrer sur l'applicatif, en effaçant la difficulté de la transposition.

Cobol, dont la structure s'oriente vers le traitement des fichiers, est fondé sur le traitement séquentiel de masse avec des logiques, qui sont toujours d’actualités. Aucun langage récent n’offre plus de fonctionnalités pour les applications liées à des fichiers volumineux. Son évolution est limitée par la transformation des fichiers en base de données et le pré-traitement SQL. Arrivent également les "écrans" (5250 et 5280) et la nécessité de traiter du "caractère" en aller-retour.

Les écrans "graphiques" de l'Apple II rendent totalement obsolète la gestion ancienne des écrans (mode caractère) et toute la quincaillerie informatique de l'époque. La problématique de séparation interface-traitement est déjà présente dans les années 1970 chez IBM, avec Cobol et d'autres langages ( définition d’écran avec SDA sur AS/400)... élément que l’on retrouve aujourd’hui chez Microsoft avec Forms et WPF, en mode graphique (Blend).

Ce qui manque aujourd’hui dans le langage Cobol c’est la facilité de raccorder un programme aux interfaces graphiques modernes et la capacité de traiter directement des bases de données OBDC, SQL et autres. L’évolution vers le Cobol Objet a ajouté beaucoup de « verbiage » au détriment de l’efficacité.

Les propriétaires modernes des compilateurs Cobol (Microfocus et Fujitsu) n’ont fait que porter sous les divers IDE du marché et n’ont pas mis en œuvre la modernisation, pourtant nécessaire, des interfaces graphiques et du traitement des fichiers en Base de données.

Aujourd’hui Microsoft supporte à travers C#6 et VB.Net tous les éléments d’une programmation moderne. Cobol reste pour XML certainement le meilleur instrument. Link et Blend, avec quelques aménagements, pourraient doper le langage Cobol de Microfocus.

Au fond, la diversité des langages actuels n’a pas tellement fait progresser le monde de l’applicatif…les investissements dans ce domaine sont énormes, alors qu’une remise en forme du passé, notamment des langages de haut niveau, tel Cobol, aurait permis de conserver des programmeurs à la tête bien faîte !

Jean-Berty HENNEL

Programmez N° 190

Cobol fait partie des dinosaures de l’informatique. Son origine remonte à la fin des années 1950 ! Dès l’origine, il était dédié à la programmation d’applications de gestion. Depuis la première version en 1959, il n’a cessé d’évoluer et fut rapidement standardisé et normalisé. La dernière version est Cobol 2014. Le langage est même 20e au classement TIOBE ! Cobol n’est pas un langage aussi mort que ce que l’on pourrait croire. Il demeure le langage historique, et incontournable de la finance/banque/assurance, et des administrations publiques. Une compétence Cobol peut-elle vous servir ? Faut-il se former ? Qui sont les acteurs majeurs du monde Cobol ? Comment évoluent les outils ? Faisons le point.

Dualité de l’informatique, de COBOL à Facebook

Programmez du 5 janvier 2016

Alex Huart

L’Informatique, celle avec un « I » majuscule, est un univers hétérogène et complexe où cohabitent des familles de technologies très différentes les unes des autres. Des grands mainframes à Twitter, comment assurer un équilibre serein ? Pourquoi aujourd’hui, dans la balance décisionnelle, des applications pour smartphone peuvent-elles être en concurrence avec des systèmes-socles vieux de plus de 30 ans parfois ? Les raisons existent, certes. Mais quid des conséquences ?

« Grosses machines » vs buzz words

Sans conteste, il existe désormais une différence d’exposition, et donc d’appréciation, entre l’informatique « dure » et les nouvelles technologies de l’information. D’un côté les grands systèmes, les langages historiques comme COBOL ou PL/I qui assurent la production quotidienne, et, en face, les NTIC, Facebook et autres applications mobiles. Sans compter les « big data », « Internet des objets », « transformation numérique »… autant de termes à la mode qui viennent ajouter une couche d’opacité à un univers déjà dense et, pour beaucoup, incompréhensible.

Or, le constat est là : les NTIC sont plus faciles d’accès, et quand on ne fait pas partie des buzz words, il est difficile d’exister. Les raisons d’un tel déséquilibre tiennent le plus souvent au besoin impérieux de profits immédiats : les objectifs court-termistes sont devenus la règle. Les DSI éprouvent aujourd’hui des difficultés à faire remonter les problématiques plus profondes. Même les CEO ont du mal à s’intéresser à leurs systèmes legacy, et tout le monde voudrait que ces systèmes fonctionnent et évoluent tout seuls.

Pourtant, opposer informatique « dure » et informatique « à sensation » n’a pas de sens. Est-il véritablement nécessaire de rappeler que l’une ne va pas sans l’autre ? Car les NTIC ne sont en réalité que la partie émergée de l’iceberg.

Un match déséquilibré… et dangereux

Persister dans cette opposition inique est dangereux à plusieurs titres.

D’une part pour des raisons structurelles : les Ressources Humaines ne sont pas en mesure d’absorber les conséquences de cette lutte insensée. Les difficultés de recrutement dans l’informatique dure sont déjà une réalité, et elles vont s’aggraver. Les technologies anciennes n’intéressent plus les jeunes ingénieurs. Ils sont nombreux à commencer leurs études avec l’idée de ne se consacrer qu’au développement d’applications pour le dernier smartphone.

D’autre part, pour l’image auprès des marchés. Rappelons-nous des entreprises qui n’ont pas su se préparer au bug de l’an 2000 : elles l’ont payé cher. Car oublier les systèmes legacy c’est faire preuve d’un manque certain de compréhension des enjeux. Repousser encore le remaniement des fondations de son SI est donc un mauvais message. De plus, ces problématiques se retrouvent basculées vers le DSI, qui doit alors gérer cette « patate chaude » et supporter par la même occasion responsabilités et pression. Et celles-ci sont bien évidemment à la hauteur des enjeux, c’est à dire très élevées.

Moderniser son infrastructure, ce n’est pas recréer un mainframe sous Linux pour faire des économies et placer son espérance dans un meilleur COBOL en 2025. A quoi sert un langage dont les nouvelles générations de développeurs ne veulent pas ?

Revoir les priorités

Il est aujourd’hui nécessaire de prendre du recul sur les NTIC, Twitter, Facebook et consorts, pour se saisir des problématiques de fond que cette culture de l’immédiateté et de la « mode-rnité » efface dans les cercles décisionnaires. Les dirigeants ne peuvent plus prendre des décisions déraisonnables se basant sur une informatique évanescente. Il ne s’agit évidemment pas d’adopter une position passéiste : ce serait suicidaire. Non. La solution, à la fois la plus raisonnable mais aussi la plus pertinente stratégiquement et économiquement, est de faire cohabiter les deux environnements en intelligence.

Pour actualiser « la surface », c’est à dire adopter les nouvelles technologies, il faut pouvoir utiliser l’existant sans le redévelopper, le migrer à l’identique sur une plateforme moderne, pour l’exécuter à moindre coût et ajouter directement de nouvelles fonctions à l’existant en utilisant un langage contemporain.

Comprendre la complexité et la criticité que véhiculent les applications et systèmes obsolescents ne suffit pas à préparer le futur. Il faut agir dans la bonne direction.