Je travaille dans le domaine bancaire et précisément sur un site fonctionnant sur ce modèle.
Toutes les applications sont sur du mainframe Z/OS + DB2 et transactions IMS, mais la moitié utilisent une du java J2EE pour la partie présentation (et l'autre moitié des écrans 3270 mais qui sont justement en train d'être remplacés).
Dans ce contexte j'adorerais disposer dans mon équipe de plus de monde ayant la double compétence. Malheureusement ça ne court pas les rues et il n'est pas évident de faire comprendre à ma hiérarchie qu'il serait rentable d'investir pour avoir plus de monde avec la double compétence (soit par formation interne, soit en étant prêt à payer plus pour attirer les bonnes personnes).
Ceci dit sur le long terme il y a aussi des projets d'attaquer les bases DB2 directement depuis la couche J2EE sans passer par des serveurs écrits en cobol. Il ne resterait alors en cobol que les batchs de traitement. Mais on parle là d'une échéance de 5-10 ans.
Un truc sur lequel je m'interroge souvent c'est si réellement il est justifié de conserver le mainframe tout court. Les performances sont-elles réellement à ce point meilleures pour justifier les inconvénients comme :
- le coût du CPU facturé par IBM,
- le système de fichier qui nécessite de déclarer la taille et le format des fichiers avant de les créer,
- le coût élevé de mise en place de choses qu'on considère comme acquises sur micro comme la gestion en parallèle de plusieurs branches de développement (problème au niveau des outils de gestion de source disponible, des environnements à mettre en place, etc).
Bon à coté c'est vrai qu'il y a certains avantages à passer par le cobol : l'injection de code SQL est impossible par exemple.
[^] # Re: double compétence
Posté par ... a little wood elfe . En réponse au journal Sursis pour le Cobol ??. Évalué à 1.
Toutes les applications sont sur du mainframe Z/OS + DB2 et transactions IMS, mais la moitié utilisent une du java J2EE pour la partie présentation (et l'autre moitié des écrans 3270 mais qui sont justement en train d'être remplacés).
Dans ce contexte j'adorerais disposer dans mon équipe de plus de monde ayant la double compétence. Malheureusement ça ne court pas les rues et il n'est pas évident de faire comprendre à ma hiérarchie qu'il serait rentable d'investir pour avoir plus de monde avec la double compétence (soit par formation interne, soit en étant prêt à payer plus pour attirer les bonnes personnes).
Ceci dit sur le long terme il y a aussi des projets d'attaquer les bases DB2 directement depuis la couche J2EE sans passer par des serveurs écrits en cobol. Il ne resterait alors en cobol que les batchs de traitement. Mais on parle là d'une échéance de 5-10 ans.
Un truc sur lequel je m'interroge souvent c'est si réellement il est justifié de conserver le mainframe tout court. Les performances sont-elles réellement à ce point meilleures pour justifier les inconvénients comme :
- le coût du CPU facturé par IBM,
- le système de fichier qui nécessite de déclarer la taille et le format des fichiers avant de les créer,
- le coût élevé de mise en place de choses qu'on considère comme acquises sur micro comme la gestion en parallèle de plusieurs branches de développement (problème au niveau des outils de gestion de source disponible, des environnements à mettre en place, etc).
Bon à coté c'est vrai qu'il y a certains avantages à passer par le cobol : l'injection de code SQL est impossible par exemple.