Hice unos cuantos posts hace unos meses (Sonar – Análisis Cobol con Jenkins, Open Source & código Legacy) con el fin de demostrar que no es necesario ser un gurú de J2EE o un experto Open Source para analizar aplicaciones Legacy de Cobol (o ABAP) con Sonar y Jenkins.
Y veo bastante visitantes llegando a estas páginas a mi blog, lo que refleja el interés por este tema.
Pero alguien me dijo recientemente: «Estamos analizando código J2EE regularmente con Sonar, y todo va de maravilla. También tenemos planes para poner las aplicaciones Cobol en Sonar y Jenkins, pero no sé nada del mundo del mainframe».
Por lo tanto, este post (y los siguientes) tendrá como objetivo ayudar a la implantación de un proceso de análisis de código Cobol con Sonar y Jenkins.
No voy a hacer un curso de Mainframe-Cobol, supongo que se encuentra fácilmente en Internet, y eso nos llevaría varios posts.
No. La idea es la siguiente: tienes que poner en marcha este proceso de análisis de código Cobol. Está previsto un encuentro con algunos representantes del mundo Mainframe de tu empresa. Para preparar esta reunión:
- ¿Qué necesitas saber?
- ¿Qué preguntas debes hacer?
Primero. Necesitas saber: lo que se puede analizar
Componentes Cobol
En código Java, se trabaja con clases, métodos, librerias (.jar), etc. Estos son los objetos del lenguaje Java. Con código Cobol, los tipos de componentes que debes conocer son:
- Programa Cobol: un archivo de instrucciones, que se compila en un ejecutable.
- Copy-Book: un archivo de instrucciones Cobol, que se utiliza como un ‘Include’. Equivalente de un componente reutilizable. También se llaman ‘Copys’, porque la llamada a este archivo se hace con una instrucción COPY.
Por ejemplo, el siguiente programa llama en la línea 65 al Copy-Book ‘MYCOPY’:
que he creado, con el siguiente código:
Cuando se compila el programa (en este caso, cuando lo analizamos), podemos ver que el código del Copy-Book se insertó en el programa donde fue llamado:
He deliberadamente incluido un error para interrumpir el proceso de análisis con el fin de mostrar el código del Copy-Book ‘expanded’ en el programa Cobol.
Los Copy-Books son el equivalente de componentes reutilizables, muy útiles. Por ejemplo, las declaraciones de las estructuras de las tablas de base de datos se hacen en un Copy. De este modo, cada programa que está haciendo un tratamiento con la tabla (re)utiliza el Copy-Book. Cualquier cambio en la estructura de la tabla se realizará a través del Copy, evitando así tener que buscar y cambiar todos los programas que trabajan con la tabla.
Entiendes que los programas y los Copys son dos componentes con código Cobol que queremos análizar.
Otros tipos de objetos Mainframe a conocer:
- Transacciones CICS – pronunciar ‘KiKs’ para parecer un experto :): archivo que utiliza el servidor de transacciones en los mainframes de IBM. Cuando realizas una transacción bancaria, como sacar dinero de tu cuenta bancaria, es probable que miles de personas se encuentran actualmente realizando la misma operación en el mismo momento que tú. Es el trabajo del CICS Transaction Server de manejar esas miles de transacciones (y otras) en paralelo.
- JCL: un archivo batch. El JCL es un lenguaje (Job Control Language) específico, no muy fácil. Una vez realizada tu transacción bancaria, el sistema registra una escritura contable, por ejemplo. Pero no hay necesidad de hacerlo enseguida, lo que seria un uso innecesario de los recursos del ordenador (CPU, memoria) cuando se necesita el mejor rendimiento para las operaciones online. Este tratamiento se puede hacer durante la noche y este será el papel de un batch JCL.
No hay prácticamente ningún estándar de calidad para las transacciones CICS o los archivos JCL, y no son reglas críticas, así que evitaremos un esfuerzo con pocos beneficios, de extraer y analizar estos archivos, .
Hay otros tipos de objetos y otros tipos de código (Assembler, PL1, …) en el mundo del Mainframe, pero nadie te va a criticar si no sabes lo que es. Todo lo que necesitas recordar para tu reunión es que:
- Vamos a analizar los componentes Cobol, programas y Copys.
- El JCL y el ‘KiKs’ no son interesantes para estimar la calidad de las aplicaciones Mainframe.
Las aplicaciones Cobol
Oye, hablando de aplicaciones Mainframe, otra cosa que saber.
Un banco tiene de promedio aproximadamente 20 millones de líneas de Cobol. Así que no se analiza en una sola vez. De repente, lo normal es de empezar con las aplicaciones más críticas. El problema: la noción de aplicación no tiene sentido en Cobol.
Se trata de sistemas Legacy, que existen desde décadas, y están muy imbricados y entrelazados. Por ejemplo, el código Cobol que te permite realizar tus transacciones bancarias usa probablemente algunos Copy-books que también serán necesarios para el sistema de contabilidad y el batch para gravar la escritura contable. En cual sistema pertenecen los Copys? El de movimientos de cuentas o el de contabilidad? En realidad, a los ‘cobol-ers’, no les importa.
Ahora, es obvio que no se pueden agrupar en un solo lugar todos los archivos que constituyen los millones de líneas de código del portafolio Cobol de la empresa. Un mainframe es un ordenador con un sistema de archivos y los archivos se organizan en librerías o bibliotecas, el equivalente de las carpetas en tu propio ordenador personal. Lo que vamos a analizar es el contenido de un directorio, que vamos a extraer y descargar desde el mainframe hasta nuestra plataforma Sonar / Jenkins.
Así que no te sorprendes si en la reunión, algunos hablan de «módulos» en lugar de aplicaciones. En cualquier caso, lo que te interesa es la forma de organizar los diferentes conjuntos de archivos en los diferentes análisis, que se refiere a aplicaciones, módulos o cualquier otro nombre que se desea darles.
Estos conceptos sencillos son el mínimo necesario que conocer para saber de que se habla en una reunión como la que te espera.
Ahora se necesita saber qué preguntas hacer para preparar los análisis. En nuestro próximo post.
Esta entrada está disponible también en Lire cet article en français y Read that post in english.