Imagine una empresa que usa mainframes para ejecutar (parte de) sus aplicaciones comerciales (a menudo de misión crítica), y que usa z / OS (también conocido como OS / 390 o MVS ).
¿Cuáles son los softwares típicos que usan para facilitar la gestión de Cambio de Software y Configuración, para el software que se implementa / usa en esos mainframes?
Respuestas:
Desde mi propia experiencia, estos son algunos de los paquetes de software típicos:
Todos estos paquetes pueden gestionar, más o menos de forma inmediata, cualquier cosa que esté almacenada en componentes "PDS" normales (una estructura de archivo típica utilizada en z / OS).
Cuando se trata de una empresa que evalúa cuál se ajusta mejor a ellos, a menudo se reduce a estos criterios:
IBM SCLM se percibe como libre de cualquier tarifa de licencia / mantenimiento (en realidad está incluido en la licencia z / OS, que en sí misma no es gratuita). Entonces, si no hay un presupuesto dedicado disponible, entonces este es a menudo el paquete de software que se selecciona (mejor que ningún paquete). Si hay un presupuesto, este es a menudo el que no llega a la lista.
CA Endevor tiene la base de instalación más alta. Su fortaleza clave, IMO, es la forma en que puede rastrear para cada ejecutable cómo se ha compilado / vinculado usando qué versión de qué bloques de construcción (cuadernos, etc.).
La base de instalación de SERENA ChangeMan ZMF está bastante por debajo de la de CA Endevor . Algunas de sus fortalezas clave son:
Compuware ISPW es como el "niño nuevo en la ciudad" (en comparación con la alternativa CA Endevor o SERENA ChangeMan ZMF ). Se percibe comúnmente como la solución donde "cualquier requisito SCM personalizado se puede implementar con él, con un esfuerzo relativamente bajo para hacerlo".
Mirándolo desde el punto de vista de la arquitectura, entonces SERENA ChangeMan ZMF y Compuware ISPW parecen tener la arquitectura más abierta, que es lo que necesitará si desea ajustarlo para que administre componentes de software escritos en un lenguaje 4GL que es ( lo que algunos llaman) más exótico, en comparación con los lenguajes 3GL como COBOL , PL / I , etc. Es decir, porque los componentes de software se almacenan en sistemas de archivos que no se almacenan en PDS estándar. Algunos ejemplos de esos idiomas son:
Atención: tener una "arquitectura abierta" es excelente para que se ajuste a sus requisitos personalizados (el cielo es el límite). Sin embargo, cuando se trata de actualizar a nuevas versiones, también tiene un precio para actualizar esos requisitos personalizados.
Nota : más bien accidentalmente, durante un entrenamiento de CA Endevor para los expertos de SERENA ChangeMan ZMF, descubrimos que CA Endevor y SERENA ChangeMan ZMF parecen tener las mismas raíces (desde algún lugar a fines de la década de 1980 ...). Para aquellos que están un poco familiarizados con ambos: verifique cuál es la funcionalidad de estos programas de utilidad, con nombres con nombres similares ... (se sorprenderá ...):
Las respuestas anteriores suponen que la gestión del código fuente para z / OS tiene que ser diferente de cualquier otra plataforma. La respuesta hace 10 años podría haber sido la anterior. Pero z / OS ha evolucionado junto con el hardware z y ya no está separado. Puede usar un administrador de código fuente moderno como Git para todo su código fuente, incluido cualquier COBOL o PL / I o ensamblador que pueda tener. Git se actualizó para manejar la traducción de ASCII a EDBCIC si obtiene el puerto de Rocket Software. Todavía es gratuito y de código abierto, simplemente hicieron la compilación para ejecutarse en la plataforma. Tener su código fuente z / OS en el mismo SCM también le permite tener sus casos de prueba y otros artefactos junto a ellos. Puede que se sorprenda de la cantidad de herramientas de código abierto que puede usar con z / OS.
Si tiene un canal de DevOps, probablemente solo funcione también con z / OS, como ejemplo, Jenkins se ejecuta en la plataforma. Con un PTF a z / OS actual, incluso puede almacenar sus artefactos de construcción en Artifactory o Nexus como lo hace con cualquier otra plataforma. El proceso y las prácticas que se utilizan en otras plataformas también funcionan para z / OS, por lo que no hay razón para que tenga que separarse o ser diferente.
Hay una compañía de Bélgica que ha estado en el mercado de SCM (ahora etiquetan su producto como DevOps) durante más de 12 años. Pero como no son un gigante como IBM o CA, son menos conocidos.
Sin embargo, tienen su producto (IKAN ALM) funcionando en grandes bancos y compañías de seguros, principalmente como reemplazo de Changeman. Admiten Mainframe y Distributed, esto significa que las empresas podrán administrar Mainframe y, por ejemplo, el desarrollo (y despliegue) de Java utilizando la misma herramienta.
Tienen una marca llamada BlueBridge , que en realidad es su producto principal ya configurado para Mainframe.