Discussion :

[bonano]

Bonjour,

Je voi que chacun parmis vous, essay de defondre son langage qui utilise, sans savoir vraiment est ce le meilleur. A mon avis, il faut voir, surtout, par rapport au traitement qu'on souhaite faire et au aussi au type de données à traiter. L'ideal c'est d'avoir une architecture dans laquelle on peut utiliser et exploiter les avantages de chaque langage. Pour mon cas je suis accro à java, et en ce moment je fait de java et cobol dans une banque (tous ce qui est interface graphique, navigation et affichage en java et le métier (regles de gestion en cobol) . Mais c'est vrai faire que de cobol je ne pourrai pas le supporter. C'est donc cool de développer sous RAD 7 en java et Interroger mainframe à partir de java.

Mais biensure java c'est le top ....

[Hédhili Jaïdane]

Bonjour.

Je pense que l'essentiel a été dit. Je n'ai rien à rajouter. D'aucuns me diraient que ce n'est pas parce que n'ai rien à dire que je dois la fermer. Ceux qui savent l'ont bien dit à ceux qui ne savent pas.

J'ai voté "Autres" pour la simple raison qu'à part quelques infidélités avec Assembleur, Fortran, RPG et Basic, j'ai de tout temps programmé en Cobol sur mainframe, S36, S38, AS/400 (iSeries) et PC et que si hier, aujourd'hui et demain on me demandait de programmer dans un autre langage autre que Cobol je laisserais tomber le projet ou même complètement le client. Il est vrai que je suis en fin de carrière, l'apprentissage et l'utilisation d'un autre langage me seront fastidieuses et laborieuses pour atteindre le même niveau de maîtrise que j'ai avec Cobol ou que j'ai eu naguère avec Fortran.

A part ma période mainframe, j'ai programmé, comme tant d'autres, en Cobol dans des PME et non dans des grandes entreprises. C'est pour dire que Cobol n'est pas synonyme d'entreprises financières.

N'en déplaise à certains allergiques, je continue à programmer en Cobol, oui je programme toujours, et à former des jeunes à l'utilisation et la maîtrise de ce langage.

En passant, c'est le RPG qui est naturellement utilisé sur AS/400 (iSeries) et non le Cobol.

[Degourth]

Bon, après, je suis de la "jeune génération" hein. Sûr que les futurs p'tits geeks de dans 25 ans se moqueront de mon amour pour Java et C#, prétextant que c'est moche et moins facile à lire que leur SMS.Net, langage numéro un de l'an 2035.

pourquoi attendre 2035 ?

http://lolcode.com/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
HAI
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE

[Homer-ac]

Juste par curiosité personnelle Hédhili, as tu eu l'occasion de comparer les performances de COBOL ILE et RPG (et/ou autres) sur AS/400 ? J'ai vu du RPG (ex GAP si c'est la même filiation) il y a bien lontemps sur les systèmes IBM DOS, et peut être au début de MVS, et complètement perdu de vue depuis (pas un mal d'ailleurs, langage trop redoutablement positionnel à mon goût, mais ça a peut être évolué ?. A ma connaisance, RPG a disparu des MVS quand s'est généralisé la notion de réentrance des programmes (pour les programmes CICS en particuliers). Mais je fais peut-être erreurs ? En tous cas je n'ai aucune idée des performances d'un programme RPG.

nb. J'ai aussi voté pour 'autres raisons'. Celles évoquées par Hédhili Jaïdane tout d'abord, mais auusi parce que :
- Si je le laisse derrière moi dans une société un programme COBOL Ansi 85, j'ai la certitude qu'il restera exécutable sans correctifs si on installe une nouvelle version du compilateur (sans citer de noms, au fait, j'ai encore une nouvelle fois une proposition de MAJ de JAVA (6 V15) sur mon portable ! Je n'en dirai pas autant d'autres langages plus 'modernes'). Au pire, en cas de maintenance évolutive, il restera encore longtemps des gens capables de prendre en charge.
- Je peux sans doute encore faire plus performant en Assembleur. Mais si je fais attention à ma programmation COBOL, le bénéfice sera assez à la marge et il y aura moins, voire pas du tout sur cerains sites z/OS, de candidats à la maintenance.
- Enfin on peut programmer en pire ou meilleur avec tout langage. Si on a le choix des armes, autant choisir celle que l'on manie le mieux par expérience (le rejoins une fois encore Hédhili sur ce point).

[Hédhili Jaïdane]

Juste par curiosité personnelle Hédhili, as tu eu l'occasion de comparer les performances de COBOL ILE et RPG (et/ou autres) sur AS/400 ? J'ai vu du RPG (ex GAP si c'est la même filiation) il y a bien lontemps sur les systèmes IBM DOS, et peut être au début de MVS, et complètement perdu de vue depuis (pas un mal d'ailleurs, langage trop redoutablement positionnel à mon goût, mais ça a peut être évolué ?. A ma connaisance, RPG a disparu des MVS quand s'est généralisé la notion de réentrance des programmes (pour les programmes CICS en particuliers). Mais je fais peut-être erreurs ? En tous cas je n'ai aucune idée des performances d'un programme RPG....

Bonjour.
En fait j'ai fait du RPG, juste après les mainframes (Cobol, Fortran et Assembleur) pendant un an ou un an et demi parce que j'intervenais sur des machines 3/10, 3/15 et 34 et que l'on ne pouvait pas faire autrement.

D'un côté sa rigidité dans la codification (positionnel, cycle, indicateurs, etc...) ne m'encourageais pas à l'utiliser parce que simplement chose nouvelle pour moi ayant toutes les facilités de Cobol.

Mais d'un autre côté les possibilités qu'il offrait pour faire des traitements batch ou interactifs en quelques instructions et son cycle de base, la gestion des ruptures, des récapitulatifs ont fait que je l'ai utilisé, aussi curieux que cela puisse paraître, en même temps que Cobol.

Les performances du RPG et Cobol ont toujours été similaires avec des avantages tantôt pour l'un tantôt pour l'autre aussi bien sur le S/36 que sur l'AS/400 : nombre d'indicateurs, longueur des noms de variables, taille totales des clés, nombre de zones constituant les clés, et bien d'autres différences qui sont disparues avec les versions ILE. Bien sûr uniquement sur AS/400, il n'y a pas de ILE sur S/36 même si dernier existe en tant qu'environnement de développement et d'exécution sur l'AS/400 même dans ses nouvelles versions (iSeries, System i).

Sur l'AS/400, le RPG a évolué vers le RPG IV (4) ou ILE RPG et offre aujourd'hui la possibilité du codage en FREE tout en gardant tout ce que ses prédécesseurs offraient. Il y a eu cependant une rupture de compatibilité des sources, mais on avait un convertisseur pour ça, chose qu'on avait pas eue en Cobol. Des incompatibilités similaires des sources se trouveront entre les versions OPM et ILE, mais là c'est toute une autre paire de manches.

Tout ce qui peut se programmer ou s'utiliser sur l'AS/400 peut se faire indifféremment dans les deux langages : compatibilités des outils, des techniques de gestion des écrans, de la base de données, etc...sauf le tri interne (dont j'aimerais pas en parler, mais Cobol l'a gardé).

Ce que IBM offre aujourd'hui sur les iSeries et System i (héritiers de l'AS/400) en matière de l'environnement ILE se trouve aussi bien en RPG qu'en Cobol

Certains de nos membres sont très compétents en RPG, ils pourront mieux en parler et le comparer au Cobol qu'ils connaissent aussi bien.

[gd_dev]

... C'est une erreur je pense de croire que COBOL perdure parce que les banques ou assurances rechignent aux coûts de transposition. ..
.... Ne vous trompez pas, les banquiers comme les cies d'assurances sont des financiers et quand ils investissent dans, par exemple pour les plus importants, au moins 2 z/series et tous les produits qui sont nécessaires pour les exploiter, ils en veulent pour leur argent.

Je n'ai pas d'apriorique quand à Cobol ou a tout autre langage d'habilleur, mais à mon avis les grand décideurs sont des moutons comme tous le monde. 99% de mes copains banquier ou assureur utilise l'AS/400 avec le programme XYZ alors moi aussi.

Et la migration de plus de 10 ans donnée d'une base de données qui ne prenait pas en charge les type de données d'aujourd'hui et le tout lié avec une application qui a quand même plus de 10 ans de vie, donc pratiquement 0 bug aujourd'hui. A mon avis ce n'est pas rien. Surtout, que cette nouvelle application n'apporterais rien de plus sur le plan fonctionnel ou autre. Alors pourquoi changer?

La réponse à cette question pourrait venir prochainement si plus personne n'apprend le COBOL.

[xfanx]

Je n'ai pas d'apriorique quand à Cobol ou a tout autre langage d'habilleur, mais à mon avis les grand décideurs sont des moutons comme tous le monde. 99% de mes copains banquier ou assureur utilise l'AS/400 avec le programme XYZ alors moi aussi.

Oo un banquier ou un assureur utilisera plutot un Z/OS, voir 2 pour les PRA comme le dit Homer-ac
j'imagine mal toute la production de ma boite (une banque, et j'entends ici par production toutes les fonctions Backoffice bien sur, pas le Front ) tourner sur un AS/400 ni toute autre machine qu'un Z/os

Et la migration de plus de 10 ans donnée d'une base de données qui ne prenait pas en charge les type de données d'aujourd'hui

a bon? nous sommes à 90% Cobol sous DB2 UDB V8. c'est quoi les types de données d'aujourd'hui dont tu parles?

et le tout lié avec une application qui a quand même plus de 10 ans de vie, donc pratiquement 0 bug aujourd'hui. A mon avis ce n'est pas rien. Surtout, que cette nouvelle application n'apporterais rien de plus sur le plan fonctionnel ou autre. Alors pourquoi changer?

oui, oui largement plus de 10 ans même.. les process développés dans les années 80 sont encore tres présent. et pourquoi les refaire? ils fonctionnent et répondent aux besoins.

Quant à Cobol, en tant que language, je ne comprends pas trop les reproches qui lui sont fait. Ce language est l'idéal pour toute application de gestion.Sous Z/os, comme le dit aussi Homer-ac, hormis l'assembleur c'est le language le plus performant.

c'est sur que si on veut faire du Front en cobol, de jolies pages web ..etc c'est assez suicidaire d'imaginer l'utiliser.

ce langage n'est pas plus mauvais qu'un autre, il faut simplement l'utiliser pour ce qu'il sait faire le mieux. la gestion. a contrario , je trouverais assez suicidaire de faire de la gestion en java voir en C/C++ d'ailleurs .

Chaque langage a ses avantages et ses inconveniants; Dans ma boite, toutes les parties visibles par l'utilisateurs (pages Web) sont en java sous Websphere sous unix/sun mais tout les moteurs fonctionnels sont sous Z/os et en cobol. Pour deux raisons bien simple. La réutilisation et la centralisation des regles fonctionnelles à un seul endroit et la puissance de calcul et la rapidité qu'apporte un Z/os.

personnellement je suis support technique dans ma boite; je suis donc amené à développer des outils pour nos MOE. je n'ai aucun apriori sur aucun langage. je peux en faire un ou une partie en assembleur ou C parceque cobol n'a pas les fonctions nécessaires sans que ça ne me pose le moindre problèmes d'appartenance; mais je privilégierai toujours la maintenabilité et la simplicité et la, j'ai pas trouvé mieux que Cobol.

quand je lis tous ce fil, c'est limite si je sens pas que je devrais avoir honte d'utiliser encore Cobol. Franchement, oui c'est pas un langage particulièrement sexy, mais il fait parfaitement bien ce pour quoi il a été conçu et dans une banque ou une assurance pour du backoffice c'est largement suffisant. je vois pas l'interret pour ue société d'investir dans une Rolls alors qu'une 106 suffirait ; c'est pas l'informatique qui génère de l'argent c'est le flux financier.
et puis ce n'est qu'un langage. on pourra toujours imaginer le meilleurs langage possible pour une application, si elle est mal pensée, mal conçue ça sera toujours une grosse daube; Le métier d'informaticien ne se résume pas à la connaissance et la maitrise d'un langage plutôt qu'un autre il me semble...

[h472009]

Peut etre les fun des nouveaux languages avec une syntaxe (C like) diront que Cobol est archaique, mais je vous assure (est c'est selon mon expérience) qu'il permet de faire des choses formidables en des secondes que les langages evolué si il pourront le faire il prendront des heures et des heures (et l'exemple le plus concret c'est le traitement des fichiers sequentiels/indexés), et c'est parmi les chhoses qui font effrayer les grands organismes (banques/assurances) de migrer vers d'autres technologies plus évolués.

En tout les cas pour une entreprise, peut importe la technologie, nouvelle ou vieille, tant que elle est fiable et maintenable

[thaundeadboss]

Etant nouvelement recruté dans une banque.
je suis amené à faire du cobol (que je trouve moche et compliqué d'ailleurs).
je me demande ou pourrais je trouver des tutoriaux en francais pour ce langage.
et merci d'avance.

[smyley]

et l'exemple le plus concret c'est le traitement des fichiers sequentiels/indexés

tu aurai un exemple de code ?

[CobolProgrammator]

bonsoir tout le monde, thread passionnant pour moi !
passons à la pratique, je voudrais des FAITS : pour ceux qui travaillent ou connaissent le service informatique d'une banque, pouvez vous me décrire l'architecture de votre SI ? je voudrais faire un tour des solutions retenues, pour aller de la base de données jusqu aux écrans des guichetiers ou du back-office, et les points forts et faibles de cette solution

Je donne l'exemple : moi, je travaille pour une banque, nous avons développé notre propre logiciel en Ideal-Datacom (c'est un IDE mainframe comprenant un langage très très proche de Cobol, et un Sgbd), avec juste une couche de Java pour l interface graphique. Les batch (plusieurs milliers par jour) sont sous jcl, donc toujours mainframe IBM; il y a aussi de l infocentre (BO), de la GED, mais le gros du système est donc mainframe. Avantage, c est très robuste et on est très rapides dans nos maintenances ou nouveaux développements. Les temps de réaction des transactions sont de l ordre du 1/4 de seconde. Inconvénient = ça rebute les débutants de travailler sur mainframe, et le look final des écrans même revampés ne fait pas super high-tech.

En fait je voudrais voir si une tendance se dégage, et s'il y en a (qui ?) qui sont passés au full nouvelles technos.

ps -> peut être ça mérite un nouveau thread ?

[Skylyn]

En fait je voudrais voir si une tendance se dégage, et s'il y en a (qui ?) qui sont passés au full nouvelles technos.

Full nouvelles technos non, moi je bosse en Mainframe/MVS/Cobol/JCL/DB2 etc...

Juste des passerelles JAVA pour les interactions avec le site internet

[Skylyn]

tu aurai un exemple de code ?

Exemple de fichier séquentiel :

Dans la FILE-CONTROL de l'ENVIRONMENT SECTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT FICHIER-SAM ASSIGN TO FICHIER-SAM
ORGANIZATION IS SEQUENTIAL
FILE STATUS IS FS-FICHIER-SAM.

Dans la DATA DIVISION => FILE SECTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
FD  FICHIER-SAM
     BLOCK CONTAINS 0 RECORDS
     DATA RECORD IS ENREG-FICHIER.
01  ENREG-FICHIER PIC X({longueur de l'enreg}).

Dans la WORKING-STORAGE SECTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
01  FS-FICHIER-SAM  PIC 9(02).
01  STATUT-FICHIER  PIC 9(1) VALUE 0.
  88  NON-FIN-FICHIER VALUE 0.
  88  FIN-FICHIER VALUE 1.

Dans la PROCEDURE DIVISION, pour le traitement de fichier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
OPEN INPUT FICHIER-SAM.
{ traitement du statut fichier }
READ FICHIER-SAM  AT END SET FIN-FICHIER TO TRUE.
{ traitement du statut fichier }
CLOSE FICHIER-SAM.
{ traitement du statut fichier }

___________________________________________________


Pour le cas d'un fichier indexé :

Dans la FILE-CONTROL de l'ENVIRONMENT SECTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT FICHIER-VSAM ASSIGN TO FICHIER-VSAM
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
FILE STATUS IS FS-FICHIER-VSAM.

Dans la DATA DIVISION => FILE SECTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
FD  FICHIER-VSAM
     RECORD KEY IS CLE-FICHIER.
01  CLE-FICHIER PIC X({longueur de l'enreg}).
      ou
01  CLE-FICHIER.
  05  PARTIE-CLE PIC X({longueur}).
  { autant de 05 que de parties de clé (tu peux même y mettre des FILLER) }

Dans la WORKING-STORAGE SECTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

01  FS-FICHIER-VSAM  PIC 9(02).

Dans la PROCEDURE DIVISION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
READ FICHIER-VSAM
  INVALID KEY
    { traitement clé non trouvée }
  NOT INVALID KEY
    { traitement clé trouvée }
END-READ.

Voilà

_____________________________________
_____________________________________
Skylyn,

[Skylyn]

D'ailleurs, je reviens sur des remarques que j'ai pu apercevoir sur ce thread

Je trouve Java super pour ce qu'il fait mais quand il s'agit de traiter un nombre incalculable d'informations en un minimum de temps, c'est pas Tomcat ou JBoss qui va permettre l'exécution.

Comparons avec un serveur Mainframe.

Les résultats sont contre toute attente. COBOL/Mainframe forme un meilleur couple pour la gestion de milliards de données en un minimum de temps.

Rien que la procédure de Batchs et de Jobs permet de réaliser des programmes périodiques, redémarrables et beaucoup plus fiables que Java.

En Cobol, c'est pas compliqué, ça marche... ou pas... y'a pas d'exceptions qui disent oui ça a marché mais en fait non...

PS : je ne crache sur aucun langage, je fais partie de ces "petits geeks de 25 ans" (26 en fait) mais j'adore Cobol malgré mes précédentes expériences en tant que développeur Web PHP5/Symfony2.

_________________________________
_________________________________
Skylyn,

[el_slapper]

(.../...)
Les résultats sont contre toute attente. COBOL/Mainframe forme un meilleur couple pour la gestion de milliards de données en un minimum de temps.

Rien que la procédure de Batchs et de Jobs permet de réaliser des programmes périodiques, redémarrables et beaucoup plus fiables que Java.

En Cobol, c'est pas compliqué, ça marche... ou pas... y'a pas d'exceptions qui disent oui ça a marché mais en fait non...

PS : je ne crache sur aucun langage, je fais partie de ces "petits geeks de 25 ans" (26 en fait) mais j'adore Cobol malgré mes précédentes expériences en tant que développeur Web PHP5/Symfony2.(.../...)

Je l'ai déjà dit ailleurs, mais Cobol est un langage de niche, très puissant sur sa niche.....et très faible dès qu'il en sort.

Opposer Cobol et Java, c'est contre-productif : Cobol est un complément fort utile à Java pour les traitements fonctionnels massifs.

[Skylyn]

Je ne dis pas le contraire là dessus mais pour ce qui est du traitement de masse, il faut plus faire confiance à des applicatifs COBOL que des applicatifs Java ou autre qui nécessitent une surveillance quasi permanente du serveur ou autre...

En COBOL, l'avantage c'est que les mises à jour sont très espacées et donc les applicatifs plus fiables.

En Java, on sort des runtime à tours de bras, et parfois, certaines fonctionnalités (en dehors de la rétro-compatibilité entre les versions) deviennent de plus en plus souvent obsolètes.

Un applicatif en COBOL réglé comme une horloge sera moins souvent maintenu qu'un applicatif Java qui devra probablement être mis à jour à chaque évolution du langage.

COBOL ne connait pas d'évolutions systématiques et brutales comme ont pu connaître PHP etc...

De plus, je le redis, COBOL est plus direct pour le traitement, ça marche ou pas.

___________________________
___________________________
Skylyn,