IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

AWS veut-il tuer les mainframes ? Le fournisseur de services de cloud computing veut remplacer les mainframes par des serveurs à grande échelle
Et COBOL par Java

Le , par Bill Fassinou

203PARTAGES

25  0 
Lors de l'édition 2021 de son événement re:Invent, qui s'est tenu du 29 novembre au 3 décembre à Las Vegas au Nevada, AWS a fait une flopée d'annonces, dont une a particulièrement retenu l'attention : le leader mondial des services de cloud computing a présenté "AWS Mainframe Modernization", un nouveau service géré qui permet aux entreprises de migrer leurs charges de travail mainframe vers le cloud. Beaucoup d'acteurs ont applaudi cette annonce et des critiques ont déclaré que AWS Mainframe Modernization pourrait être la réponse au problème des migrations de mainframes ridiculement complexes.

AWS pourrait nuire aux entreprises fournisseurs de mainframes

Même si les mainframes sont encore très présents dans les grands groupes, en particulier dans les banques et les assurances, et continuent d'être la colonne vertébrale d'une immense quantité de transactions, ils sont désormais en voie de disparition. Et AWS semble vouloir accélérer cette tendance. En effet, aujourd'hui, le coût, l'agilité et de nombreux autres facteurs incitent les entreprises à migrer vers des infrastructures modernes, mais un certain nombre de problèmes doivent être traités avant, pendant et après le processus de migration. Il s'agit, entre autres, de la complexité des applications et de leur compatibilité avec le cadre cible proposé.



Tous ces éléments auront une incidence sur les résultats de la migration et sur les opérations commerciales globales d'une entreprise. Comme la gestion des systèmes informatiques hérités tels que les mainframes pose un certain nombre de défis, les responsables informatiques doivent être préparés à faire face à ces problèmes et à ces processus complexes. Ainsi, bien que certaines organisations ressentent le besoin de migrer leurs charges de travail vers une infrastructure moderne, elles peinent à franchir le pas. La réponse du leader mondial des services de cloud computing est "AWS Mainframe Modernization". Le nouveau service offre deux options aux clients.

Certains peuvent vouloir remanier leurs charges de travail mainframe pour les faire fonctionner sur AWS en transformant les applications héritées - probablement écrites en COBOL - en services modernes basés sur Java dans le cloud. Les clients peuvent également conserver leurs applications telles qu'elles sont écrites et réorganiser leurs charges de travail sur AWS en réutilisant le code existant avec un minimum de modifications. AWS Mainframe Modernization promet un pipeline de migration complet, de bout en bout, qui comprend les outils de développement, de test et de déploiement nécessaires à l'automatisation du processus.

« Avec le lancement d'AWS Mainframe Modernization, les clients et les intégrateurs de systèmes peuvent désormais moderniser plus rapidement leurs charges de travail mainframe existantes de manière prévisible et se débarrasser d'une grande partie de la complexité et du travail manuel qu'impliquent les migrations », a déclaré William Platt, directeur général des services de migration chez AWS. Ce service met le fournisseur de services de cloud computing en concurrence avec les fabricants de mainframes et les fournisseurs de logiciels spécialisés, parmi lesquels IBM, Unisys, Bull, NEC et Fujitsu. Le nouveau produit d'AWS pourrait être un bâton dans leurs roues.

Selon Adam Selipsky, PDG de l'entreprise, AWS Mainframe Modernization peut réduire le temps de migration de deux tiers grâce à l'automatisation quasi complète du processus. En partant d'une analyse du mainframe, AWS Mainframe Modernization décide si le "refactoring" ou le "replatforming" est la meilleure solution avant de proposer des options.

Il peut également automatiser la réécriture du code : Selipsky a spécifiquement déclaré qu'il est capable de convertir COBOL en Java tout seul. Cette dernière fonctionnalité ne manquera pas d'enthousiasmer ceux qui veulent utiliser l'apprentissage automatique et ses capacités d'analyse, mais qui n'ont pas le bagage nécessaire pour le faire.

Les produits d'AWS pourraient accélérer la disparition des mainframes

Plus de 50 ans après l'apparition du premier mainframe, le System/360 d'IBM, ces machines imposantes sont encore très présentes dans les secteurs de la banque, de l'assurance et du commerce de détail, grâce à leur capacité à traiter efficacement d'énormes volumes de transactions, et à leur réputation en matière de sécurité et de temps de fonctionnement. Cependant, ces systèmes sont incroyablement coûteux et difficiles à entretenir, et le nombre de personnes qualifiées pour s'occuper de ces logiciels anciens ne cesse de diminuer. Depuis des années, AWS tente d'inciter ses clients à délaisser les mainframes et migrer vers ses centres de données.



Cette fois-ci, l'entreprise affirme avoir construit un moteur d'exécution qui fournit toutes les capacités de calcul, de mémoire et de stockage nécessaires à l'exécution d'applications remaniées et "replatformées", tout en gérant automatiquement l'approvisionnement en capacité, la sécurité, l'équilibrage des charges, la mise à l'échelle et la surveillance de l'état des applications. AWS a assuré que comme tout cela se fait via le cloud public, il n'y a pas de coûts initiaux, et les clients ne paient que pour la quantité de calcul provisionnée.

La banque brésilienne Banco Inter a été l'une des premières organisations à s'inscrire à Mainframe Modernization avec AWS. « En utilisant le runtime géré AWS Mainframe Modernization, nous espérons simplifier nos opérations de traitement des cartes pour une résilience et une évolutivité accrues », a déclaré Guilherme Ximenes, directeur technique chez Banco Inter. « Nous sommes également enthousiasmés par le pipeline DevOps CI/CD qui nous permettra d'accroître l'agilité dont nous avons besoin pour offrir plus rapidement à nos clients de nouvelles capacités de transaction par carte de crédit et de débit ».

Par ailleurs, certains critiques pensent qu'AWS Mainframe Modernization est particulièrement bienvenue dans le monde post-pandémique, qui a vu les mainframes et COBOL revenir dans l'actualité en raison de l'incapacité des vieux mainframes obsolètes à traiter les demandes de chômage. « Les mainframes sont ainsi revenus dans l'esprit du public et l'on s'est rendu compte que tout le monde voulait qu'ils disparaissent, mais que la plupart d'entre eux en dépendent encore », ont-ils déclaré.

Actuellement, AWS Mainframe Modernization est disponible en avant-première dans les régions de l'Est des États-Unis (N. Virginia), de l'Ouest des États-Unis (Oregon), de l'Asie-Pacifique (Sydney), de l'UE (Francfort) et de l'Amérique du Sud (São Paulo), avant d'être étendu à d'autres sites "dans les mois à venir".

Source : AWS

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez du service géré AWS Mainframe Modernization ?
IBM doit-il craindre pour son chiffre d'affaires sur le marché des mainframes ?
Pensez-vous que les mainframes vont effectivement disparaître ou resteront-ils encore longtemps ? Pourquoi ?

Voir aussi

AWS présente une flopée de nouveaux services de bases de données et de ML, et annonce en Preview version RDS Custom pour Microsoft SQL Server et AWS DMS Fleet Advisor

98 % des responsables informatiques envisageraient de migrer des mainframes vers le cloud, même si 96 % d'entre eux considèrent que les applications mainframe sont importantes, selon LzLabs

AWS présente Proton, le service de gestion des conteneurs, pour automatiser le développement et le déploiement des conteneurs et d'applications "serverless"

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de TotoParis
Membre éprouvé https://www.developpez.com
Le 25/12/2021 à 17:14
Citation Envoyé par thamn Voir le message
Mmh, en regardant sur wikipedia, je vois:
Il faudrait changer de référence que ce pitoyable Wikipedia.
Lire ceci par exemple : https://www.ibm.com/support/pages/en...tation-library (c'est juste au hasard !)

Citation Envoyé par thamn Voir le message
- la dernière version du langage COBOL date de 2014
IBM entreprise COBOl : 2019.

Citation Envoyé par thamn Voir le message
- le COBOL ne gère pas la récursivité (??!!!!)
Ah ben sûr que oui, même si c'est pas forcément ancien. Quant à son utilité...

Citation Envoyé par thamn Voir le message
- le COBOL ne gère pas l'allocation dynamique de mémoire
Ah que si même si nativement c'est récent, on pouvait utiliser depuis longtemps les service FREEMAIN et GETMAIN de LANGUAGE ENVIRONMENT : encore faillait-il lire la documentation IBM, démarche rarement suivie, que ce soit par des jeunots à la grande gueule, ou des plus anciens...

Citation Envoyé par thamn Voir le message
- le temps de compilation serait lent
Ah elle est bien bonne celle-là. J'ai jamais lu plus ridicule.

Citation Envoyé par thamn Voir le message
- le langage serait verbeux
En effet, un peu trop. Une expression comme "TOTAL = QUANTITE * PRIX" dans n'importe quel langage, peut s'écrire :
"COMPUTE TOTAL = QUANTITE * PRIX" ou MULTIPLY QUANTITE BY PRIX GIVING TOTAL" : en effet, c'est lourd à écrire.

Citation Envoyé par thamn Voir le message
A cela, je présume que je peux rajouter (même si je n'ai pas vérifié):
Ah ben faudrait un peu vérifier soi-même ou demander à des personnes qui en savent plus que vous.

Citation Envoyé par thamn Voir le message
- que le code exécutable généré est probablement a 1000 lieux de ce que pourrait générer un compilateur "moderne".
Le compilateur IBM est l'un des meilleurs au monde. Son code gère des adressages sur 64 bits, avec une franche et massive évolution du jeu d'instruction assembleur.

Citation Envoyé par thamn Voir le message
- qu’écrire et exécuter des tests en COBOL doit être compliqué
Pas pire qu'en C ou en Java. Sans outillage, comme XPEDITER, c'est en effet difficile, mais pas pire que faire du Python dans on EDI favori.

Citation Envoyé par thamn Voir le message
- je présume aussi que les outils disponible ne doivent pas être super, et pas super accessible non plus
Les outils sont en format terminal à la mode TSO : c'est une interface texte en effet. Sinon XPEDITER, que je connais très bien, est facile d'accès, et très puissant.

Citation Envoyé par thamn Voir le message
- de ce que je peux voir, il semblerait que les compilateurs soient très différents selon la plateforme
C'est un peu logique : les architectures technique sont fort différentes.

Citation Envoyé par thamn Voir le message
- je parle même pas du tooling (outil de formatage? generation de documentation? analyse de code?)
Formatage : en effet, ça manque.
Génération de documentation : idem.
Analyse de code : non, il y a plein d'outils, comme Code Coverage chez Microfocus, Compuware's Xpediter/Code Coverage, et sans doute d'autres.

Citation Envoyé par thamn Voir le message
- je ne parle même pas des aspect de securite, et des bibliothèques disponible
Le système Z/OS est l'un des plus sécurisé qui soit, sinon le plus sécurisé au monde. Aucune plateforme UNIX ou de cette famille ne peut le prétendre (comme la faille SSH l'a montré il y a quelques temps), ou alors au prix d'une armada de dispositifs logiciels et matériels des plus hallucinant (et merci la maintenance de ce "machin" alors).
Quant à Java, la dernière faille avec LOG4J est tout simplement hallucinante.

Citation Envoyé par thamn Voir le message
Bref, ce langage semble aujourd'hui totalement archaïque, encore pire si on compare a ce qu'on fait de plus récent.
Honnêtement, je peux comprendre que ce langage pouvait avoir un intérêt quelconque pour une entreprise il y a 40 ans (intérêt qui probablement relevait de la "portabilité du langage" et sa relative simplicité j'imagine face a d'autre langage plus complexe de l’époque, ça devait rassurer les RHs qui déjà a l’époque ne devaient pas valoir un clou pour ce qui est de comprendre les métiers pour lequel ils recrutent..).
Mais, aujourd'hui, j'ai vraiment du mal a comprendre.
C'est pourtant simple : à une certaine époque, il n'y avait que cela : Mainframe et COBOL, pour les traitements sur de grandes quantités de données.
Unix et ses serveurs, c'était bon pour bricoler dans son garage. Quant aux RH, en effet, ils n'avaient pas il y a 40 ans la même formation que de nos jours.

Citation Envoyé par thamn Voir le message
Je n'ai pas d'attrait particulier pour le Java, mais:
- les outils sont disponibles (documentation, testing, analyse de code), maintenus et continuent d’évoluer
- le langage est utilise par une grosse communauté (c'est le moins qu'on puisse dire ^^)
- le langage continue d’évoluer (dernière version en date d’âpres wikipedia: septembre 2021 et je présume que Java 16 n'est pas apparu il y a 7 ans parce qu'il me semble qu'a l’époque j'ai du utiliser Java 6 ou 7)
- il dispose du minimum vital pour un langage de programmation digne de ce nom (je veux dire, allocation dynamique, et récursivité sont possible, je dis pas que c'est forcement a utiliser mais des fois c'est quand même bien pratique hein).
- vu la relative simplité du COBOL, il semblerait possible d’écrire un transpileur vers un autre langage
Le paradigme Objet n'est pas forcément adapté à l'informatique de gestion pour faire des traitements batch. Depuis bien longtemps déjà l'essentiel du TP se fait via une interface web qui communique avec un Mainframe et du COBOL / DB2 derrière. Il manque juste la possibilité de définir des fonctions (autrement que sous forme de sous-programmes) : ça existe depuis si longtemps dans des langages qui ne sont même plus en vogue, que cela en est frustrant.
12  3 
Avatar de TotoParis
Membre éprouvé https://www.developpez.com
Le 25/12/2021 à 17:49
Un aspect essentiel n'est pas évoqué : les logiciels COBOL "traduits" en JAVA restent les propriété du client, ou c'est AMAZOn qui en devient propriétaire ?
Les données sont transférées chez AMAZON : dans quel pays ?
BNP PARIBAS avait tenté le coup en Inde pour la tenue de compte il y a pas mal d'années : le Gouvernement les a vite remis à leur place...
9  2 
Avatar de walfrat
Membre chevronné https://www.developpez.com
Le 01/01/2022 à 18:55
Bien que j'ai que 32ans j'ai travaillé sur quelques problématiques lié au Cobol à savoir :
  • Voir si je peux faire tourner du COBOL de leur application avec un compilateur Open Source gratuit pour se séparé du propriétaire.
  • Etudier un outil qui propose de migrer du Cobol vers un framework Java concu par leur soins pour que les développeurs CoBOL puissent l'utiliser


Pour le premier cas ma réponse a été que ça ne se fera pas de façon magique et que certaines instructions ne sont clairement pas prise en charge (j'avais eu la réponse en posant la question sur le forum du dit compilateur). EN bref il faudrait un certain effort et vu que ce n'était qu'un étude qu'on m'a fait faire vite je ne pouvais certainement pas m’engage sur la possibilité définitive de faire cela.

Pour le second point :

Je n'ai aucun doute que leur outils de migrations COBOL vers leur framework Java fonctionne cependant la façon dont est fait l'outil est désespérant :
  • Chaque classe Java est dans un classpath séparé, seul les librairies du framework et de base du JRE sont disponible
  • Si tu veux faire des appels entre différentes classes, tu dois construire des hashmap<String,Object> et appelé des procédure à la main. Ces classes doivent être spécifiquement enregistrées comme "procédure"
  • Mon impression global sur cette outil est qu'on a fait un framework qui dépouille Java (ou n'importe quel langage) de toute capacité d'être manipulé comme un langage de développement et a la place pouvoir être utiliser par des "secrétaires". Je comprend l'intérêt ne pas vouloir forcément faire monter pleinement en compétence d'ancien développeur COBOL en Java, pas besoin de connaître Java en profondeur pour faire de la base de données et des formulaires, mais je pense qu'il y avait moyen de faire mieux. Pour moi, si tu veux travailler sur ce framework, tu cherches un boulot gagne pain dont la compétence requise en tant que "développeur" est proche du zéro absolu.
5  0 
Avatar de chaton-garrou
Nouveau membre du Club https://www.developpez.com
Le 27/12/2021 à 10:52
Merci pour la précision de LOG4J, effectivement j'ai été mal informé sur cette faille. (une confusion ne détruit pas le reste des informations)

On parle de Z/OS car le but est de quitter le mainframe d'après ce que laisse supposer l'article avec son titre accrocheur.
En réalité, les offres de migrations ne concerne qu'une partie du SI pour alléger la charge processeur qui est la base de la facturation.
Donc oui les avantages des mainframes est à prendre en compte surtout dans le contexte actuel où les piratages se multiplient.
Concernant la récursivité, je l'ai utilisé il y a deux semaines, j'ai pris un petit warning mais ça fonctionne.
Lors de mes derniers essais (il y a 4 ans en TELON), j'ai remarqué que sur ma machine de travaille, passer le 5em niveau de récursivité d'un paragraphe, le mainframe se perds (mais qui utilise encore le TELON ).
Si on veux une véritable récursivité, il faut créer un programme récursif pas un paragraphe...
en gros je n'en ai pas l'utilité dans mon domaine mais je laisse les curieux voir ça avec big blue: https://www.ibm.com/docs/en/i/7.2?to...ecursive-calls

On ne passe pas non plus une moulinette magique qui convertit le cobol,
si on voit les programmes des années 90...j'ai mal aux yeux et si tu génère ça, ce sera dégueulasse. (je parle en un langage autre, ayant vu des programmes avec + de 200 goto)
Ca demande une refonte avant moulinette + contrôle en sortie.

Mon précédent poste était axé sur "Non on ne va pas stopper tout du jour au lendemain car il n'y aurais pas de gains significatifs",
après je ne suis pas contre la conversion du cobol, je ne suis pas pour non plus...

Maintenant thamn si tu trouve nos informations trop déphasées, je t'invite à contacter l'entreprise la plus au fait des possibilités du cobol, des mainframes et qui fait de la migration aussi... Eh oui, IBM propose aussi de la migration en cloud
Il n'y a pas de match a qui sera le plus performant, le plus beau etc.
Tout les langages ont leurs points forts et leurs utilités, qu'il ai 50 ans n'est pas une faiblesse
5  1 
Avatar de chaton-garrou
Nouveau membre du Club https://www.developpez.com
Le 27/12/2021 à 22:27
Citation Envoyé par thamn Voir le message
et vous me confirmez que sa raison d'exister semble être parce que IBM l'aurait vendu avec ses mainframe, et ce n'est pas a mon humble avis un argument en faveur de ce langage.
Quand on compare avec d'autre langages de la meme epoque, FORTRAN par particulier, en quoi est t-il mieux? Certainement pas en terme de performances..
Historiquement parlant... Je ne peux pas te donner tors que sa force viens d'IBM. A ma connaissance j'entends bien.
De l'autre coté le Fortran me semble plus accès calcul, et pour l'époque, était-il moins évident à appréhender.(Supposition vu que je ne le pratique pas)
Dans le contexte actuel, on trouve ça désuet mais jadis on ne se lançais pas dans l'informatique comme aujourd'hui, les connaissances étaient moins simples à obtenir...

Si un système avec des capacités égales à un mainframe, tournant avec principalement fortran, pour le même prix, avait existé, nous n'aurions peut être pas un déploiement aussi avancer pour le cobol aujourd'hui.
Maintenant c'est un autre sujet sur pourquoi à l'époque l'un était plus utile que l'autre? Là par contre je suis trop jeune pour répondre mais la réponse se trouve surement dans la simplicité du COBOL pour son utilisation. (encore une supposition car franchement, j'ai pas connu les cartes perforées )

Aujourd'hui tu veux lancer un mec dans le cobol, il peut commencer à se débrouiller en 7 jours. Tu veux le rendre un minimum sachant? tu l'envoie 3 mois en formation Algo/mainframe/JCL/SQL/Cobol et tu obtiens un mec qui comprends comment ça tourne derrière, comment la mémoire fonctionne, etc

Quoi qu'il en soit on ne peux pas remplacer un old-gen par un autre old-gen, les novices vont fuir la profession

petit article qui te répondra peut-être plus: https://bytescout.com/blog/cobol-vs-fortran.html
En le lisant je comprends ceci: comparer cobol et fortran revient à comparer un balais et une raclette...
Le mouvement est le même, le but est le même, mais le sujet est différent. L'un nettoie la poussière, l'autre évacue l'eau.
Donc la gestion et le calcul scientifique ont des besoins différents. Cobol est simple procédural et plus maniable, Fortran est puissant, impératif et moins verbeux.
4  0 
Avatar de Escapetiger
Expert éminent https://www.developpez.com
Le 02/01/2022 à 19:45
Citation Envoyé par autran Voir le message
En revanche la problématique sous-jacente n’est que peu adressée dans ce fil. Et cette problématique ce résume de manière très pragmatique par le questionnement suivant : Comment fait une entreprise qui dispose d’un Système d’information développé en Cobol ou Fortran lorsque son sachant part à la retraite ?
A mon sens il y a 3 options :
  • Appeler une SSII qui va lui tondre la laine sur le dos au prétexte que c’est une architecture et un langage de niche
  • Embaucher un jeune sachant (de 55 ans) à prix d’or dont l’entreprise deviendra captive et qui la placera dans 10 ans devant le même problème.
  • Migrer le SI vers un plateforme supporté par le marché
Tout à fait d'accord pour la problématique, il existe normalement la GPEC (Gestion prévisionnelle des emplois et compétences) dans les grosses structures.

Le client final (Entreprises hors SSII/ESN, Administrations) ne veut plus investir dans le legacy alors que dans d'autres secteurs où les compétences s'acquièrent sur un temps long (le nuclèaire, le pétrole, etc.), des actions de mentorat, transfert de connaissances des séniors vers les plus jeunes, ont été mises en place pour anticiper et lisser l'effet Papy-boom (désigne le grand nombre de départs à la retraite qui doivent avoir lieu entre 2006 et 2025 dans les pays développés.)

En France, le recours à la sous-traitance, le turnover induit (perte du savoir) et le taux d'emploi faible des séniors concourrent à une situation de blocage.

On sait qu'il faut environ 2 ans de pratique quotidienne pour maîtriser a minima un domaine, Cobol ou Java compris.

Que voit-on sur le marché ?
Des offres de re)conversion pour des jeunes Bac +5 scientifiques (moins de 28 ans pour la POEI - préparation opérationnelle à l’emploi individuelle - financée par l'état), comme avant l'an 2000 et le passage à l'Euro - on prend les mêmes recettes.

Certain.e.s sont devenus d'éminents professionnels, d'autres ont quitté le navire, changé de domaine d'activité, etc.
4  0 
Avatar de chaton-garrou
Nouveau membre du Club https://www.developpez.com
Le 27/12/2021 à 15:32
Citation Envoyé par Escapetiger Voir le message
  • Nouvelle interopérabilité Java/COBOL qui étend les modèles de programmation d'applications existants avec la prise en charge de l'adressage parallèle 31 bits et 64 bits, simplifiant ainsi la modernisation des applications d'entreprise.
  • Amélioration des performances et de la facilité d'utilisation pour le composant z/OS Container Extensions (zCX) pour intégrer des applications et des utilitaires Linux dans z/OS.
  • Des capacités supplémentaires pour intégrer le stockage Cloud par le biais de la hiérarchisation transparente du Cloud (TCT) et la prise en charge de la hiérarchisation en Cloud par la méthode d'accès aux objets (OAM) pour aider à réduire les dépenses d'investissement et d'exploitation avec le transfert de données vers des environnements de stockage en Cloud hybride pour un archivage et une protection des données simplifiés sur l’IBM Z.

Source :
IBM z/OS V2.5, un système d'exploitation de nouvelle génération conçu pour le Cloud hybride et l'Intelligence

et également :
IBM crée un compilateur COBOL pour les systèmes GNU/Linux basé sur l'architecture x86
Dont la disponibilité générale est annoncée pour le 16 avril
Jolies sources, c'est effectivement la direction prise, le cloud hybrid, c'est pas mal, y'a une belle interface graphique pour gérer ses applis
Par contre me demande pas de bien comprendre tout les principes TCT et OAM (j'ai décroché quand on m'en as parlé)

Le système de conteneur semble bien pensé. Enfin faut s'y habituer à tout ces trucs là...

Je parle de cobol unix car certains utilisent un serveur bancale, aucun mainframe, et en plus te crée des applications pour normaliser le développement cobol...
Je te laisse imaginer le résultat après quelques années si ton référentiel de code ne suit pas la route, c'est des livraisons bloquées dans le meilleur des cas.
Mais ça c'est un autre débat...

Le système Z/Os n'est pas conçu par des bricoleurs, il y a une réputation à tenir, un public cible important et professionnel.... Ce genre de système doit être plus stable que du "bricolage" qu'on trouve parfois.
Si IBM foire ce genre de conception, vu les clients ce serais la douche froide. Je suis donc optimiste concernant cette version unix. (Après c'est un avis personnel)

Je rajouterais bien une petite touche, ce sujet est soumis à débat...
Mais on connais tous un autre sujet qui réveille des débats "L'agilité", est-ce toujours utile?
La réponse étant bien sur "ça dépends du projet" mais à cause d'une sorte d'effet de mode tout le monde voulait que ça arrive (même dans des cas inadéquates).
Alors vous allez me dire "Mais chaton tu diverge!", mais là où je veux en venir c'est que je sent que ce sujet va faire suivre le même effet de mode...
J'entends par là que certains vont faire des dérives et prendre des décisions inadaptés, mais il faudra apprendre à utiliser le cloud hybrid aux bons endroits, et correctement juger ses avantages et inconvénients.

C'est un projet ambitieux, et pour certains projets, je pense qu'il vaut mieux être accompagner. Tout traiter en interne serait selon moi une erreur à ne pas commettre car les coboliste d'aujourd'hui n'ont pas encore la connaissance nécessaire à la migration, et un développeur java ne l'a pas non plus. (je m'inclus dans les personnes n'ayant pas ce savoir et ce même si nous avons des outils de conversion et que j'ai des bases en java)
Je vois déjà au loin certains bidouillage maison pour "limiter les dépenses"
3  0 
Avatar de autran
Rédacteur https://www.developpez.com
Le 29/12/2021 à 13:03
Bonjour JPLAROCHE, je suis content que tu reviennes vers la problématique initiale de migration car le combat sur les langages n’est pas très productif.
N’étant pas du tout un expert du Cobol, je te crois sur parole quand tu me dis que le nouveau COBOL ILE est aussi Objet et portable que Java. Mais il n’en demeure pas moins que bien des entreprises souhaitent migrer leurs plate-forme COBOL faute de ressources sur ce merveilleux langage. Donc leurs proposer de se débarrasser de leur vieux COBOL pour le nouveau COBOL ILE sorti en 2021 mais que personne ne connait ne sera pas acceptable.
Et pour généraliser je dirai que la problématique est similaire pour le FORTRAN où la encore je ne critique pas les performances du langage ni son âge. Mais les développeurs fortran sont des ressources tout aussi particulièrement difficile à trouver.
Alors oui je pense que le fond du problème est bien de changer de langage. Quant à l’architecture qui permet cette migration, c’est un chantier annexe.
3  0 
Avatar de JPLAROCHE
Membre éprouvé https://www.developpez.com
Le 25/12/2021 à 20:06
Citation Envoyé par thamn Voir le message
vous auriez un argument pour soutenir votre choix?
Parce que vous décrivez ce que vous feriez, mais vous ne dites pas pourquoi il serait plus efficace de le faire comme ça et pas autrement.
Beaucoup parle du cobol en ce référent au cobol PC opensource , mais ne connaisse que très peu le monde IBM MainFrame .

Alors oui les 360/370 etc... peuvent migrer sur des IPOWER qui eux traitent aussi bien avec HTML / que les applications natives. De plus la notion OBJET y est fortement implémenté. L'implémentation Cobol-ILE y est natif voir l'installation avec le RPG-ILE
la lecture des sources ce fait tel un membre d'un fichier rien en vous empêche de monter une moulinette pour convertir si besoin est et profiter de l'apport que propose IPOWER , ce n'est que du texte qui est compilé...

J'ai pratiqué des conversions sur des sources IBM3.8 3.12 3.15 34 36 38 Systemi (AS400) IPOWER (OS400) voir des sources en carte et remis sur membre fichier source. j'ai eu aussi des propositions pour convertir des 360 vars AS400.

Ne pas oublier que l'on s'adresse à des applications de gestion

http://www.ombrebleu.com/wxsrc/src/ section ADMOPS idem produit rational d'IBM, mais en mode texte. Très performant pour celui qui connait son travail modifiable à volonté. j'ai fait cela en 1995 les premiers jets... de l'analyse de texte et de la reconfiguration, c'est le b a ba de la maintenance... le produit est fait à partir de l'étude d'un produit IBM ADM advanced manager de projet sources n'étant plus distribué par IBM je me suis vu le réécrire, à l'époque le produit rational était loin d'être aussi abouti.


https://www.ibm.com/fr-fr/it-infrastructure/power


lien donnant un aperçu du Cobol-ile
https://www.volubis.fr/news/liens/AF...R10TXT/ILE.htm

https://www.ibm.com/docs/en/i/7.3?to...uage-reference

https://www.ibm.com/docs/en/i/7.2?to...grammers-guide

tout ça nécessite une connaissance du Cobol. D'autre part il est exclu sur l'IPOWER d'utiliser les routines assembleur du 360/370

mais le Fortran il est possible de l'implémenter sur un IPOWER

autre possibilité exemple :

https://conversion-migration.com/con..._migration.php

https://conversion-migration.com/con...LEUR_COBOL.php

https://www.ibm.com/docs/fr/rpp/9.5....g-pacbase-data
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
un peu d'ironie...

J'aurai bien continué avec des ordres ayant une relation avec la gestion puisque c'est principalement sa fonction.

move Movel add sub mult div reste etc.... le read write delete update ( 90% des instructions) bref beaucoup de bla bla contre la gestion
le forms est depuis longtemps en Cobol mis par ds dds ---> DSPF display file qui sont des objets qui gèrent la saisie et affichage
donc la migration avec un peu d'huile de coude est faisable
vous seriez surpris de la simplicité mis a disponibilité que non pas encore aujourd'hui nos langages sur PC par exemple les subroutines les call interactif tel qu'ils sont mis à disposition chez IBM , oh bien-sur j'en ai fait en Pc, mais quelle galère et pas aussi fructueux et je doute que cela soit vraiment employé aux vues de ce que je peux lire y compris sur développer.com ( exemple de source et études de cas) car cela fait appel à du fondamental même dans les livres approprier qui parle du cœur de Linux on aborde pratiquement pas ce sujet. Alors vous me direz le thread pour le multi-tâche ben non sur mainframe c'est beaucoup plus.....
3  1 
Avatar de chaton-garrou
Nouveau membre du Club https://www.developpez.com
Le 26/12/2021 à 17:13
Tout d'abord merci @TotoParis d'avoir taper ce pavé à ma place... J'ai perdu le courage en lisant certains commentaires.

En revanche, je vais compléter un peu.

Premièrement, on parle d'Amazon, qui certes est une bonne entreprise, mais les serveurs font défaut ces derniers temps.

Deuxièmement, nous avons de plus en plus de devs en France qui ne connaissent pas TSO et font du cobol... Comment?
RDZ est inclus dans les derniers packs IBM lors de la location d'un mainframe, libre à chaque DSI de l'utiliser ou non.
Petit complément d'infos, RDZ c'est juste l'IDE Eclipse avec une surcouche mainframe qui peut inclure les outils dont TotoParis parle.

Troisièmement, on parle de java, qui voit son image se dégrader, entre la mise à jour de leurs conditions d'utilisation les 7 dernières années et la faille la plus populaire de 2021. Je pense que certaines entreprises vont un peu freiner la machine.

La problématique aujourd'hui, c'est le manque de coboliste, ça n'attire pas les jeunes.
Je suis apte à le comprendre quand on vois qu'en sortie du cursus scolaire, on leurs apprends du cobol 1.0 qui est immonde avec des préjugés sortis de je ne sais où.
A ça s'ajoute les frais de location/entretien du mainframe auquel s'ajoute le prix des licences.

La vérité étant que nous n'avons, à l'heure actuelle, pas de systèmes plus performants/sécurisés pour des batchs importants.
Niveau sécurité, nous avons RACF qui fait de l'autorisation de connexion, autorisation d'action. C'est imbuvable, mais c'est aussi sa force.
Pour le coté performance, j'arrête tout de suite les idées reçues, je parle de traitement de plusieurs millions de données avec calculs, mise à jours, etc... à faire en quelques secondes.
Les banques et assurances utilisent énormément cette technologie, ce n'est pas pour rien, et la migration d'un SI ça prends du temps et de l'argent.

Depuis combien de temps entendons nous "le cobol est mort"?
Oui, un jour il le sera, non ça ne sera pas java qui le remplacera. (autran avant que tu ne me gronde là dessus, je parle de manière générale, pas pour des petits SI)
Le temps de migrer, étudier les règles métiers oubliées et tout le travail que ça peut engendrer en parallèle, je serais à la retraite

Une dernière info pour le plaisir Amazon a quelques années de retard sur le sujet
Certains services existent pour aider à migrer de cobol vers les services de cloud (en France), avec des garanties performances fiables,
mais ça ne touche pas tout un SI important.
On ne migre pas un ensemble métier lourd sans prévenir le client que ça sera risqué, possiblement plus long en traitement...
6  4