cobol2j — Beyond Mainframe

Cómo funciona

Del primer inventario al sistema en producción

Cuatro pasos, en este orden, y lo que viene después. Cada uno termina en algo que se le puede poner delante a un comité.

1 · Pre-assessment

El traductor real lee su fuente tal como llega —un ZIP o una carpeta— y reporta programa por programa: qué hay, qué falta, qué depende de qué y cuánto se traduce limpio. Como esa lectura sale del motor que va a hacer el trabajo, la estimación y la migración no pueden contradecirse. Se entra al caso de negocio con un número que cualquiera puede reproducir un martes. Y lo corre usted mismo: una descarga, sin herramienta de construcción, sin acceso a la red y sin IA de por medio — el fuente no sale de su casa, y no hay nada que configurar para que así sea.

2 · Migración

COBOL, CICS, JCL y SQL embebido se convierten en Java 21 imperativo: código legible, con sus propios nombres adentro, no una caja negra con una API. Lo que el traductor no sabe hacer queda marcado e informado en vez de adivinado, así que una traducción equivocada nunca pasa en silencio. El equipo revisa el resultado en un espacio de trabajo web con roles de desarrollo, sistemas, operación y seguridad, y un repositorio Git por usuario. Lo que sale es código que un desarrollador Java puede leer en una revisión, que es justamente el sentido de dejar atrás el COBOL.

3 · Despliegue

El sistema va a su Kubernetes con sus regiones en línea, su cola de trabajos, su spool y su consola de operación, y con el dato VSAM cargado byte a byte en PostgreSQL. Los programas migrados siguen hablando CICS y JCL: las pantallas y el batch nocturno se comportan como el negocio ya los conoce, y quien lo opera el viernes lo opera igual el lunes. Es su cluster, en su nube o en su datacenter, sin un medidor sobre la carga de trabajo.

4 · Certificación

Cuando un programa pasa sus pruebas, se certifica: la herramienta deja de regenerarlo y lo entrega de forma definitiva. Ese solo acto separa una migración de una dependencia — desde ahí el programa vive en su build de Maven y se mantiene como cualquier otro Java. El proyecto tiene fecha de término, y después de esa fecha no se le debe a nadie una licencia para cambiar el propio código.

Y después: lo que se construye encima

La próxima aplicación no tiene que ser COBOL ni pasar por el runtime. El dato se publica como contrato SQL para leer y como repositorio Spring Data para leer y escribir por clave: un servicio nuevo llega al archivo maestro con herramientas comunes. La migración deja de ser un proyecto que termina y pasa a ser la plataforma sobre la que se apoya la próxima década de trabajo.

Sin vueltas: un programa migrado sale como Java fiel, no como un microservicio artesanal. Esa reescritura es una decisión posterior, y es suya, porque para entonces el código le pertenece.