Bob se encuentra con el mainframe

Cuando lanzamos Bob, dijimos que el problema interesante no era escribir código nuevo sino trabajar dentro de un sistema que ya existe — encontrar el lugar correcto para hacer un cambio, respetar las convenciones que un equipo estableció hace años, mantener el comportamiento consistente a través de archivos que llevan mucho tiempo creciendo.

La versión que más tiempo lleva en ejecución de un «sistema que ya existe» corre en un mainframe. Décadas de COBOL y PL/I, millones de líneas, decenas de miles de programas interconectados a través de Db2, CICS, IMS y programadores batch — código que continúa haciendo funcionar el negocio sin ninguna interrupción que no se puedan permitir.

Hoy ponemos a disposición general IBM Bob Premium Package for Z (Bob PP4Z). Reemplaza a IBM watsonx Code Assistant for Z y trae la experiencia de IBM Z — lenguajes de plataforma, conciencia de middleware y análisis determinista a escala empresarial — directamente a la experiencia de Bob.

Esta es la historia de ingeniería, no un recorrido por funcionalidades. En lugar de listar todo lo que hace PP4Z, queremos hacer tres cosas:

Explicar por qué un modelo de propósito general se equivoca con tus aplicaciones mainframe más a menudo de lo que admite.
Mostrar cómo anclamos a Bob en hechos deterministas sobre tu entorno en lugar de probabilidades.
Recorrer los modos, skills y workflows específicos de Z — y qué puedes construir con ellos.

1. Por qué el mainframe es el caso difícil

Un modelo de propósito general apuntado a un entorno mainframe se encuentra con tres problemas que ningún prompting inteligente realmente soluciona. El diseño de PP4Z ofrece soluciones para cada uno.

1.1. Escala y lo que le hace a una ventana de contexto

Una sola aplicación de negocio puede ser millones de líneas de COBOL, decenas de miles de módulos interconectados a través de COBOL, PL/I y ensamblador, y miles de trabajos batch encadenados por un programador empresarial. Incluso un fragmento «pequeño» de 200 programas equivale cómodamente a cientos de miles de líneas de código.

Eso no cabe en una ventana de contexto, y el problema no es solo la ventana. A medida que el contexto crece, el rendimiento del modelo se degrada (Chroma Research Context Rot Study, 2025) — las respuestas se vuelven incompletas, inconsistentes o confiadamente incorrectas. Incluir «los archivos relevantes» asume que ya sabes cuáles son relevantes, que es exactamente lo que estabas intentando descubrir.

1.2. Significado que no está en el código

El código mainframe es semánticamente denso. El significado de negocio vive en nombres de campos y décadas de convenciones, no en nada que un parser pueda leer. Algo se puede adivinar — SERIALN es probablemente un número de serie, TOT-STTM probablemente una liquidación total. La mayoría no: ¿qué es C-M? ¿M-CAP? ¿Por qué el prefijo CCZD? ¿Qué separa NO-SIN, NO-EVN y NO-CNT?

El significado es real y estructural, pero no se puede deducir solo del código. La respuesta tradicional es un diccionario de datos — pero la escala (millones, si no miles de millones de variables) lo hace difícil de construir a mano o con fuerza bruta y un modelo de lenguaje.

1.3. La respuesta más probable no es la respuesta correcta

Un modelo de lenguaje devuelve lo que es estadísticamente probable. Los modelos son no deterministas; la misma pregunta puede obtener respuestas diferentes en días distintos. En un sistema donde una respuesta incorrecta sobre el flujo de control puede malinterpretar la lógica de negocio, eso es un riesgo significativo.

Es un escenario que probablemente has encontrado tú mismo, asumiendo que lo reconociste. Toma una aplicación batch COBOL real: 233 programas, 742 copybooks, más de 20 MB de código, con una utilidad de fecha muy utilizada, N991DATE. Los metadatos indican que 30 programas la llaman. Ahora pregúntale directamente a un modelo frontier:

Día 1. No puede cargar todo, así que busca sentencias CALL estáticas y reporta 13. Preguntado sobre llamadas dinámicas, amplía el regex y reporta 29. El que se pierde, CHKOUTB, vive en un archivo llamado ROCHKOUT.cbl — porque por convención el nombre del archivo suele coincidir con su PROGRAM-ID, pero nunca es obligatorio.
Día 2. Misma pregunta, heurísticas distintas, y ahora reporta 31 — sobrecontando. Un falso positivo, N285RODR, simplemente declara el literal 'N991DATE' en working storage y nunca lo usa. El modelo llega a esa conclusión solo después de varias preguntas de seguimiento.

Ninguna de estas heurísticas es irrazonable. Simplemente no son suficientemente buenas, y «quién llama a X» es una de las preguntas centrales durante el análisis de impacto y la comprensión de programas. Las preguntas más avanzadas — qué tablas se actualizan en más de un programa, qué archivos se leen pero nunca se escriben, qué variables alimentan el cálculo de WS-UIT02 en PREMPZ72 — necesitan un análisis completo y preciso que la coincidencia de patrones no puede proporcionar.

La conclusión no es «los modelos no son útiles para entender programas mainframe». Es que la calidad de las respuestas mejora sustancialmente cuando hay algo verdadero sobre lo que razonar. Los modelos de lenguaje destacan en el procesamiento de datos.

2. Anclando a Bob en hechos, no en probabilidades

La respuesta de PP4Z es dejar de pedirle al modelo que reconstruya el sistema desde el código fuente, y en su lugar darle una representación determinista y consultable del entorno para razonar sobre ella. Tres mecanismos hacen el anclaje: el modelo recibe instrucciones de señalar construcciones z/OS ambiguas en la propia solicitud; los prompts se enriquecen con insights autorizados de IBM Z, documentación de IBM, material de referencia, muestras verificadas y más, suprimiendo activamente los sesgos de programación de propósito general; y el modelo recibe instrucciones de responder primero desde los metadatos de análisis. El objetivo es hacer las respuestas trazables al sistema IBM Z, no a una distribución de entrenamiento.

2.1. Z Understand: un modelo consultable de tu entorno

Z Understand es la plataforma de análisis estático que subyace a PP4Z. Corre en un servidor con acceso a tu fuente completa, incluye escáneres para COBOL, PL/I y ensamblador más JCL y programadores como Control-M y TWS, y procesa miles de programas en paralelo en un repositorio consultable. Mantiene estructura determinista y consistente en entornos de 10.000+ programas.

Ayuda pensarlo como una pipeline de compilación con una salida diferente: no un ejecutable, sino conocimiento estructurado y consultable — definiciones de datos, flujo de control a través de programas y trabajos, flujo de datos preciso (incluyendo REDEFINES y offsets de memoria) e interacciones de subsistemas.

2.2. Dejar que el modelo escriba sus propias consultas

Cómo se exponen los metadatos importa tanto como los propios metadatos. Las APIs fijas y los patrones de consulta MCP predefinidos son muy eficientes para preguntas conocidas y esperadas, pero fallan en el análisis abierto. Durante el análisis abierto, una pregunta real se ramifica en muchas subconsultas que cambian a medida que avanza el razonamiento.

Así que hemos enseñado a Bob a ir más allá de las consultas predefinidas y a generar y ejecutar sus propias consultas contra los metadatos. Esto aprovecha lo que los modelos realmente hacen bien — razonamiento y generación de consultas — y escala como escalan los datos estructurados: tanto si tienes 10 programas como 10.000, la consulta es la misma; solo crece el conjunto de resultados.

2.3. Extensibilidad, escáneres personalizados y datos en tiempo de ejecución

El análisis puramente sintáctico pasa por alto las relaciones que importan cuando llamadas dinámicas, abstracciones de API y preprocesadores ocultan el flujo real. El framework Z Understand Extensibility cierra esa brecha:

Resolución de llamadas API / macros mapea llamadas indirectas y controladas por parámetros a sus objetivos reales, reemplazando aristas de llamada genéricas por relaciones concretas llamante-llamado, mediante config JSON o user exits.
Extensibilidad de preprocesadores interpreta sentencias no estándar preservando la vista original del código fuente, mapeando limpiamente entre código pre- y post-procesado.
Escáneres personalizados incorporan lenguajes propietarios, 4GLs e incluso fuentes que no son código en un modelo, a través de una interfaz JSON basada en esquema.

El análisis estático te dice lo que puede ocurrir; los datos de ejecución te dicen lo que ocurrió. PP4Z convierte el depurador en un instrumento de recopilación de datos y entrega esos trazos precisos a Bob.

2.4. El diccionario de datos: relevancia sobre completitud

Documentar miles de millones de variables no es factible ni mantenible, así que PP4Z no lo intenta. El análisis determinista clasifica las variables por cuánto impulsan realmente el comportamiento — frecuencia de uso, distribución en regiones de código, participación en el flujo de control, interacción con bases de datos e I/O — y selecciona el pequeño conjunto que revela el propósito de un programa.

El hallazgo útil aquí: la cobertura limitada es suficiente. Definir aproximadamente las 10-20 variables principales por programa mejora materialmente la comprensión sin documentación exhaustiva. Z Understand Services automatiza esto en portfolios completos desde la CLI, una puntuación de confianza conserva solo las definiciones por encima de un umbral, y un paso human-in-the-loop en el IDE permite revisar, corregir y alinear la salida con glosarios existentes.

3. Especializando a Bob para Z

El anclaje le da a Bob buenos hechos. La especialización es lo que lo hace predecible en un entorno donde los outputs tienen que ser explicables y los procesos tienen que satisfacer la gobernanza. PP4Z se construye sobre cuatro piezas: modos, herramientas, skills y workflows.

Los modos establecen el rol y los límites para un flujo de interacción. Un modo de arquitecto prioriza análisis, documentación y descubrimiento de dependencias, con la modificación de código explícitamente prohibida. Un modo de desarrollador está ajustado para generación y refactoring con aplicación de estándares de codificación integrada.
Las herramientas dan al modelo acceso directo al conocimiento estructurado del sistema — escaneo de programas, interrogación de metadatos, búsqueda en diccionario de datos, servicios de análisis a escala empresarial.
Los skills codifican la experiencia recurrente en pasos repetibles y auditables. El skill de planificación de implementación, por ejemplo, aplica una secuencia fija: adquirir y validar contexto, formular requisitos, mapear impacto desde metadatos, luego producir un plan persistido y revisable.
Los workflows añaden orquestación con estado — aplicando orden, validando resultados intermedios, deteniéndose ante entradas incorrectas. El workflow del diccionario de datos se detiene si no encuentra variables en lugar de inventar algunas.

Los estándares y la gobernanza se aplican por defecto a través de reglas agents.md a nivel de repositorio. Puedes crear tus propios skills también, sin escribir código.

Cuando estos se combinan, un único prompt puede impulsar una tarea de extremo a extremo:

«Añade una columna a la Motor Policy Table que capture si el vehículo es eléctrico. Aplica mis estándares de codificación y actualiza todos los programas afectados.»

Bob lee la intención, construye un plan, selecciona los modos, skills y reglas de repositorio correctos, y ejecuta de forma segura las herramientas necesarias — gobernanza, ejecución y razonamiento en un solo paso, con tu aprobación de los cambios.

4. Qué puedes construir hoy

Documentación que no se queda desactualizada. Trata los docs como un artefacto generado anclado en metadatos deterministas más contexto de fuente y ejecución — regenerable bajo demanda, alineado con el sistema actual.
Transición determinista de COBOL a Java en z/OS. PP4Z usa metadatos como columna vertebral de la transformación, construyendo modelos paralelos de fuente y destino para que la arquitectura sea reproducible y la lógica de negocio se mapee con precisión.
Refactoring dirigido y extracción de funciones. Bob produce una lista priorizada de candidatos a refactoring anotados con función de negocio, luego extrae módulos autocontenidos con entradas y salidas claras.
Herramientas nativas de z/OS. Capacidades de Z Open Editor más nuevas herramientas MCP: Dependency Based Build (DBB), Z Code Scan e IBM Debug for z/OS para convertir sesiones de depuración en vivo en análisis de causa raíz asistido por IA.

Una nota sobre la honestidad, ya que este es un post de ingeniería: nada de esto elimina al desarrollador del proceso, y no está pensado para hacerlo. Los modos, las puertas de aprobación y el diccionario de datos human-in-the-loop existen porque en estos sistemas «mayormente correcto» es el modo de fallo, no el objetivo.

5. Cómo obtener acceso

Bob Premium Package for Z (PP4Z) es un complemento de IBM Bob, no un producto separado que necesitas descargar. PP4Z corre contra un entorno mainframe activo dentro de un entorno empresarial — la habilitación es dirigida por ventas.

Comienza con tu representante de IBM, o usa Contactar con Ventas en bob.ibm.com. Ellos configuran el plan base de IBM Bob y el complemento Z para tu organización.
Una vez que tu administrador de Bob te asigna un puesto con el complemento Z, la habilitación se detecta cuando usas IBM Bob. Instala la Bob IDE, inicia sesión, y los modos, skills y herramientas específicos de Z aparecen.

6. Cómo empezar

Si ya estás usando Bob, PP4Z añade los modos, skills y herramientas específicos de Z encima de lo que tienes.
Usa la capacidad de comprensión integrada para obtener perspectivas más profundas del código en tu workspace.
Apunta Z Understand a una aplicación real donde ya conozcas las respuestas correctas — y comprueba el análisis de Bob con tu verdad de referencia.
Comienza con una pregunta a la que nunca has obtenido una respuesta directa: ¿quién realmente llama a esta utilidad? ¿Qué tablas toca este trabajo? ¿Qué significa esta variable?
Haz preguntas más desafiantes que mezclen datos y razonamiento: «Dame un call graph con diagramas organizados por temas»

Links