Imaginez une entreprise utilisant des mainframes pour exécuter (une partie de) leurs applications commerciales (souvent critiques) et utilisant z / OS (également connu sous le nom d' OS / 390 ou MVS ).
Quels sont les logiciels typiques qu'ils utilisent pour faciliter la gestion des modifications et de la configuration des logiciels, pour les logiciels déployés / utilisés sur ces mainframes?
Réponses:
D'après ma propre expérience, voici quelques-uns des packages de logiciels typiques:
Tous ces packages peuvent gérer, plus ou moins prêts à l'emploi, tout ce qui est stocké dans des composants "PDS" normaux (une structure de fichier typique utilisée dans z / OS).
Quand il s'agit d'une entreprise qui évalue celle qui lui convient le mieux, cela se résume souvent à ces critères:
IBM SCLM est perçu comme exempt de tout frais de licence / maintenance (en fait, il est inclus dans la licence z / OS, qui elle-même n'est pas gratuite). Donc, si aucun budget dédié n'est disponible, c'est souvent le package logiciel qui est sélectionné (mieux alors aucun package du tout). S'il y a un budget, celui-ci est souvent celui qui ne parvient pas à la liste restreinte.
CA Endevor possède la base d'installation la plus élevée. Sa principale force, l'OMI, est la façon dont vous pouvez retracer pour chaque exécutable comment il a été compilé / lié en utilisant quelle version de quels blocs de construction (cahiers, etc.).
La base d'installation de SERENA ChangeMan ZMF est bien inférieure à celle de CA Endevor . Certaines de ses principales forces sont:
Compuware ISPW est comme le "nouveau venu en ville" (par rapport à l' alternative CA Endevor ou SERENA ChangeMan ZMF ). Il est généralement perçu comme la solution où "toutes les exigences SCM personnalisées peuvent être mises en œuvre avec, avec un effort relativement faible pour le faire".
Du point de vue de l'architecture, SERENA ChangeMan ZMF et Compuware ISPW semblent avoir l'architecture la plus ouverte, ce dont vous aurez besoin si vous souhaitez la régler pour lui permettre de gérer les composants logiciels écrits dans un langage 4GL qui est ( ce que certains appellent) plus exotique, par rapport aux langages 3GL tels que COBOL , PL / I , etc. C'est-à-dire parce que les composants logiciels sont stockés dans des systèmes de fichiers qui ne sont pas stockés dans des PDS standard. Voici quelques exemples de ces langues:
Attention: avoir une "architecture ouverte" est formidable pour l'adapter à vos besoins personnalisés (le ciel est la limite). Cependant, en ce qui concerne la mise à niveau vers de nouvelles versions, il est également proposé de mettre à niveau ces exigences personnalisées.
Remarque : plutôt accidentellement, lors d'une formation CA Endevor pour les experts SERENA ChangeMan ZMF, nous avons découvert que CA Endevor et SERENA ChangeMan ZMF semblent avoir les mêmes racines (quelque part à la fin des années 1980 ...). Pour ceux qui sont un peu familiers avec les deux: allez vérifier quelles sont les fonctionnalités de ces programmes utilitaires, avec des noms de même nom ... (vous serez choqué ...):
Les réponses ci-dessus supposent que la gestion du code source pour z / OS doit être différente de toute autre plate-forme. Il y a 10 ans, la réponse aurait pu être la précédente. Mais z / OS a évolué avec le matériel z et il n'est plus séparé. Vous pouvez utiliser un gestionnaire de code source moderne tel que Git pour tout votre code source, y compris tout COBOL ou PL / I ou assembleur que vous pourriez avoir. Git a été mis à jour pour gérer la traduction ASCII en EDBCIC si vous obtenez le port de Rocket Software. C'est toujours gratuit et open source, ils ont juste fait la compilation pour fonctionner sur la plateforme. Le fait d'avoir votre code source z / OS dans le même SCM vous permet également d'avoir vos cas de test et autres artefacts à côté d'eux. Vous pourriez être surpris du nombre d'outils open source que vous pouvez utiliser avec z / OS.
Si vous avez un pipeline DevOps, il fonctionne probablement aussi avec z / OS, comme un exemple que Jenkins exécute sur la plate-forme. Avec un PTF actuel vers z / OS, vous pouvez même stocker vos artefacts de construction dans Artifactory ou Nexus comme vous le faites sur n'importe quelle autre plate-forme. Le processus et les pratiques utilisés sur d'autres plates-formes fonctionnent également pour z / OS, il n'y a donc aucune raison pour qu'ils soient séparés ou différents.
Il y a une entreprise belge qui est sur le marché SCM (maintenant ils étiquettent leur produit comme DevOps) depuis plus de 12 ans. Mais comme ils ne sont pas un géant comme IBM ou CA, ils sont moins connus.
Cependant, leur produit (IKAN ALM) fonctionne dans de grandes banques et compagnies d'assurance, principalement en remplacement de Changeman. Ils prennent en charge Mainframe et Distributed, ce qui signifie que les entreprises seront en mesure de gérer Mainframe et, par exemple, le développement (et le déploiement) Java en utilisant le même outil.
Ils ont une marque appelée BlueBridge , qui est en fait leur principal produit déjà configuré pour Mainframe.