Publicité

Affichage des résultats du sondage: Aimez-vous COBOL ?

Votants
113. Vous ne pouvez pas participer à ce sondage.
  • Je fait encore du COBOL et j'aime ça

    20 17,70%
  • J'ai fait du COBOL dans le passé et j'ai aimé

    17 15,04%
  • J'ai déjà fait du COBOL mais c'était une expérience horrible

    10 8,85%
  • Si on m'oblige à faire du COBOL je préfère encore me suicider

    13 11,50%
  • Si mon Patron me demande de faire du COBOL je démissionne

    22 19,47%
  • Autre avis (précisez)

    13 11,50%
  • Sans opinion

    18 15,93%
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 36 sur 36
  1. #21
    Membre actif
    Profil pro
    Inscrit en
    avril 2004
    Messages
    159
    Détails du profil
    Informations personnelles :
    Localisation : France, Bas Rhin (Alsace)

    Informations forums :
    Inscription : avril 2004
    Messages : 159
    Points : 156
    Points
    156

    Par défaut

    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 ....

  2. #22
    Expert Confirmé
    Homme Profil pro Hédhili Jaïdane
    Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    juin 2007
    Messages
    1 882
    Détails du profil
    Informations personnelles :
    Nom : Homme Hédhili Jaïdane
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : juin 2007
    Messages : 1 882
    Points : 3 435
    Points
    3 435

    Par défaut

    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.

  3. #23
    Invité régulier
    Inscrit en
    février 2009
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : février 2009
    Messages : 6
    Points : 5
    Points
    5

    Par défaut

    Citation Envoyé par entreprise38 Voir le message
    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 :
    1
    2
    3
    4
    5
    HAI
    CAN HAS STDIO?
    VISIBLE "HAI WORLD!"
    KTHXBYE

  4. #24
    Membre expérimenté Avatar de Homer-ac
    Profil pro
    Inscrit en
    octobre 2007
    Messages
    449
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 449
    Points : 557
    Points
    557

    Par défaut

    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).

  5. #25
    Expert Confirmé
    Homme Profil pro Hédhili Jaïdane
    Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    juin 2007
    Messages
    1 882
    Détails du profil
    Informations personnelles :
    Nom : Homme Hédhili Jaïdane
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : juin 2007
    Messages : 1 882
    Points : 3 435
    Points
    3 435

    Par défaut

    Citation Envoyé par Homer-ac Voir le message
    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.

  6. #26
    Membre habitué Avatar de gd_dev
    Homme Profil pro Giuseppe Damiani
    Développeur Web
    Inscrit en
    décembre 2003
    Messages
    79
    Détails du profil
    Informations personnelles :
    Nom : Homme Giuseppe Damiani
    Âge : 42
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Service public

    Informations forums :
    Inscription : décembre 2003
    Messages : 79
    Points : 118
    Points
    118

    Par défaut

    Citation Envoyé par Homer-ac Voir le message
    ... 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.

  7. #27
    Membre confirmé
    Femme Profil pro
    Architecte technique
    Inscrit en
    janvier 2008
    Messages
    156
    Détails du profil
    Informations personnelles :
    Sexe : Femme

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2008
    Messages : 156
    Points : 266
    Points
    266

    Par défaut

    Citation Envoyé par gd_dev Voir le message
    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

    Citation Envoyé par gd_dev Voir le message
    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?
    Citation Envoyé par gd_dev Voir le message
    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...

  8. #28
    Membre habitué Avatar de h472009
    Homme Profil pro Issam OUKILI
    Ingénieur qualité méthodes
    Inscrit en
    août 2009
    Messages
    86
    Détails du profil
    Informations personnelles :
    Nom : Homme Issam OUKILI
    Âge : 30
    Localisation : Maroc

    Informations professionnelles :
    Activité : Ingénieur qualité méthodes
    Secteur : Service public

    Informations forums :
    Inscription : août 2009
    Messages : 86
    Points : 112
    Points
    112

    Par défaut

    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

  9. #29
    Membre habitué Avatar de thaundeadboss
    Homme Profil pro
    Développeur COBOL & JAVA
    Inscrit en
    février 2007
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Maroc

    Informations professionnelles :
    Activité : Développeur COBOL & JAVA
    Secteur : Finance

    Informations forums :
    Inscription : février 2007
    Messages : 200
    Points : 148
    Points
    148

    Par défaut

    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.
    Celui qui n'est pas occupé à naitre, est occupé à mourir (Chapeau Bas Bob Dylan)

  10. #30
    Expert Confirmé Sénior
    Avatar de smyley
    Inscrit en
    juin 2003
    Messages
    6 270
    Détails du profil
    Informations forums :
    Inscription : juin 2003
    Messages : 6 270
    Points : 7 783
    Points
    7 783

    Par défaut

    Citation Envoyé par h472009 Voir le message
    et l'exemple le plus concret c'est le traitement des fichiers sequentiels/indexés
    tu aurai un exemple de code ?

  11. #31
    Nouveau Membre du Club
    Homme Profil pro
    Dévelopeur Cobol, + Swing en amateur
    Inscrit en
    novembre 2007
    Messages
    58
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Dévelopeur Cobol, + Swing en amateur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 58
    Points : 28
    Points
    28

    Par défaut quelle architecture info dans SI bancaire

    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 ?

  12. #32
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 114
    Points
    114

    Par défaut

    Citation Envoyé par CobolProgrammator Voir le message
    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

  13. #33
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 114
    Points
    114

    Par défaut

    Citation Envoyé par smyley Voir le message
    tu aurai un exemple de code ?
    Exemple de fichier séquentiel :

    Dans la FILE-CONTROL de l'ENVIRONMENT SECTION
    Code :
    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 :
    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 :
    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 :
    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 :
    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 :
    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 :
    01  FS-FICHIER-VSAM  PIC 9(02).
    Dans la PROCEDURE DIVISION
    Code :
    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,

  14. #34
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 114
    Points
    114

    Par défaut

    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,

  15. #35
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 173
    Points : 10 473
    Points
    10 473

    Par défaut

    Citation Envoyé par Skylyn Voir le message
    (.../...)
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  16. #36
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 114
    Points
    114

    Par défaut

    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,

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •