C'est en fait tout l'écosystème qu'il faudrait changer, et là c'est une autre paire de manche.
Pour ceux qui ne connaissent pas z/OS, il faut comprendre que comme sur un PC, une partition n'est pas livrée « nue », et que la configuration est quasi la même partout.
C'est la très grande force du z : même s'il y a des (parfois grandes) différences culturelles entre sites, on retrouvera quasiment toujours :
- un TSO : l'interface 3270 standard. Mais qu'on se rassure, on peut utiliser VScode (un vrai bonheur !), Eclipse (qui a révolutionné l'expérience développeur site central), même si beaucoup d'outils système n'existent qu'en interface 3270 ;
- qui donne un accès au spool (sur les z les log sont centralisées : pas besoin de chercher où peut bien être cachée cette foutue log, elle est nécessairement sous SDFS ou sous l'outil d'archivage du site) ;
- un DB2 ;
- un moniteur transactionnel IMS ou CICS ;
- un moniteur de transfert, au hasard CFT ;
- du JCL comme langage de script qui avec DFSORT permet de triturer un fichier comme on le souhaite ;
- différents outils permettant de lire les fichiers en mode tabulaire (en exploitant la structure COBOL) ;
- Un ordonnanceur permettant de lancer les tâches planifiée ;
- différents outils permettant de visualiser les tables DB2 dont OPTIM qui permet en y déclarant le MCD de littéralement se promener dans les données ;
- tout un tas d'outils de supervision permettant de couper la tête à celui qui s'est amusé à rechercher la date du jour à la lecture de chaque ligne d'un fichier...
- un outil de GCL pour gérer les différentes version des source COBOL et JCL et leur déploiement dans les environnement hors prod et de prod ;
- et pour ceux qui ne jurent que par l'Unix, l'USS : la partition UNIX !
Cette très forte intégration fait que plein de sujets « open » (non z/OS) n'ont pas cours sur site central, et qui permet une disponibilité d'au moins 99,99 %.
Par exemple, il y a quelques années, il y a eu une volonté de se lancer dans le Zdevops sur mon site. Mais piloté par une personne ne connaissant pas le z/OS, il lui a fallu 3 (longues) années avant de comprendre que pour nous, compiler (builder), déployer tout ça tout ça était un non sujet (pas besoin de s'appuyer sur chaîne d'outils qui changent constamment de version pour des raisons des sécurité : on a des outils très bien fait pour ça comme ISPW - CodePipeline, son nouveau nom): ça marche correctement depuis au moins 30 (voire 50) ans, avec des hauts et des bas, mais ça on sait (très bien) faire.
Le vrai sujet Zdevops, c'est le test : mais là aussi, avec des outils aussi puissant qu'OPTIM, ou des suites du marché, ça n'est pas vraiment un problème. Le seul problème du Zdevops, c'est d'accepter d'inverser la pyramide des tests.
Mais on part sur un autre débat ! (^ _ ^ )
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
# En vrai, COBOL n'est pas le sujet...
Posté par PhRæD . En réponse au lien Faut-il se débarrasser des systèmes COBOL ? Entre dédain et transmission des savoirs. Évalué à 5.
C'est en fait tout l'écosystème qu'il faudrait changer, et là c'est une autre paire de manche.
Pour ceux qui ne connaissent pas z/OS, il faut comprendre que comme sur un PC, une partition n'est pas livrée « nue », et que la configuration est quasi la même partout.
C'est la très grande force du z : même s'il y a des (parfois grandes) différences culturelles entre sites, on retrouvera quasiment toujours :
- un TSO : l'interface 3270 standard. Mais qu'on se rassure, on peut utiliser VScode (un vrai bonheur !), Eclipse (qui a révolutionné l'expérience développeur site central), même si beaucoup d'outils système n'existent qu'en interface 3270 ;
- qui donne un accès au spool (sur les z les log sont centralisées : pas besoin de chercher où peut bien être cachée cette foutue log, elle est nécessairement sous SDFS ou sous l'outil d'archivage du site) ;
- un DB2 ;
- un moniteur transactionnel IMS ou CICS ;
- un moniteur de transfert, au hasard CFT ;
- du JCL comme langage de script qui avec DFSORT permet de triturer un fichier comme on le souhaite ;
- différents outils permettant de lire les fichiers en mode tabulaire (en exploitant la structure COBOL) ;
- Un ordonnanceur permettant de lancer les tâches planifiée ;
- différents outils permettant de visualiser les tables DB2 dont OPTIM qui permet en y déclarant le MCD de littéralement se promener dans les données ;
- tout un tas d'outils de supervision permettant de couper la tête à celui qui s'est amusé à rechercher la date du jour à la lecture de chaque ligne d'un fichier...
- un outil de GCL pour gérer les différentes version des source COBOL et JCL et leur déploiement dans les environnement hors prod et de prod ;
- et pour ceux qui ne jurent que par l'Unix, l'USS : la partition UNIX !
Cette très forte intégration fait que plein de sujets « open » (non z/OS) n'ont pas cours sur site central, et qui permet une disponibilité d'au moins 99,99 %.
Par exemple, il y a quelques années, il y a eu une volonté de se lancer dans le Zdevops sur mon site. Mais piloté par une personne ne connaissant pas le z/OS, il lui a fallu 3 (longues) années avant de comprendre que pour nous, compiler (builder), déployer tout ça tout ça était un non sujet (pas besoin de s'appuyer sur chaîne d'outils qui changent constamment de version pour des raisons des sécurité : on a des outils très bien fait pour ça comme ISPW - CodePipeline, son nouveau nom): ça marche correctement depuis au moins 30 (voire 50) ans, avec des hauts et des bas, mais ça on sait (très bien) faire.
Le vrai sujet Zdevops, c'est le test : mais là aussi, avec des outils aussi puissant qu'OPTIM, ou des suites du marché, ça n'est pas vraiment un problème. Le seul problème du Zdevops, c'est d'accepter d'inverser la pyramide des tests.
Mais on part sur un autre débat ! (^ _ ^ )
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »