IMS no es un sistema heredado en el sentido de estar obsoleto. Es el motor de base de datos que sustenta las cuentas por cobrar de los principales bancos, la administración de pólizas de las compañías de seguros y el procesamiento de reclamaciones de las aseguradoras sanitarias. IBM continúa desarrollándolo. El problema no es que IMS haya dejado de funcionar, sino que todos los desarrolladores que sabían cómo navegar por sus árboles de segmentos jerárquicos se están jubilando, cualquier cambio en un sistema basado en IMS requiere comprender un modelo de datos que no utiliza SQL, y cualquier plan de migración que trate a IMS como una base de datos relacional descubre la diferencia por las malas.
El camino difícil consiste en descubrir, a mitad de la migración, que un programa COBOL accede a IMS no mediante una simple búsqueda por clave, sino mediante un recorrido jerárquico que debe replicarse en el sistema de destino con una lógica de navegación equivalente. O descubrir que una relación lógica entre dos bases de datos IMS físicas crea una dependencia que la DBD de ninguna de las bases de datos documenta completamente, y que la migración convirtió ambas bases de datos de forma independiente, dejando inoperativos todos los programas que utilizaban dicha relación lógica. O descubrir que una base de datos de índices secundaria, una estructura que la mayoría de los planes de migración nunca inventarian, era la única vía por la que un programa de informes crítico accedía a sus datos.
Ninguna de estas sorpresas sobrevive al análisis riguroso de las dependencias previas a la migración. Sobreviven al análisis de suposiciones.
Análisis de dependencias de IMS a escala de cartera
SMART TS XL Identifica dependencias IMS entre bases de datos que no son visibles únicamente en el código fuente COBOL.
MÁS INFORMACIÓN¿Qué hace que el análisis de dependencias de IMS sea diferente?
El análisis de dependencias en un entorno de base de datos relacional (DB2, Oracle, SQL Server) sigue un procedimiento bien definido. Se analiza el código SQL de la aplicación, se identifican las referencias a tablas y columnas, se crea un mapa que indica qué programas acceden a qué tablas y se utiliza dicho mapa para determinar el alcance y la secuencia de la migración. La estructura es explícita. Las dependencias son visibles en el texto SQL.
El análisis de dependencias de IMS es más complejo en todas sus dimensiones.
La estructura es jerárquica, no relacional. Una base de datos IMS está organizada como un árbol de tipos de segmentos, donde cada tipo de segmento tiene una relación padre-hijo definida. Un programa COBOL que lee registros de pacientes de una base de datos IMS no se ejecuta SELECT * FROM PATIENTS WHERE ID = ?El programa realiza una llamada Get Unique (GU) para navegar por la jerarquía hasta el segmento raíz, y luego llamadas Get Next Within Parent (GNP) para recorrer los elementos secundarios. La dependencia del programa no radica en una tabla, sino en una ruta específica a través de una estructura jerárquica, y modificar dicha estructura puede provocar fallos en los programas que la recorren de maneras que ningún análisis a nivel SQL detectaría.
Las dependencias se distribuyen en tres estructuras separadas. Para comprender completamente lo que hace un programa COBOL con IMS, es necesario analizar:
- El DBD (Descriptor de Base de Datos): define la jerarquía del segmento físico, los campos clave, los métodos de acceso (HDAM, HIDAM, HISAM, HSAM) y cualquier índice secundario o relación lógica.
- El PSB (Bloque de Especificación del Programa): define a qué bases de datos tiene permitido acceder un programa, a través de qué PCB, con qué especificaciones de sensibilidad e intención.
- El código fuente de COBOL: Contiene las llamadas DL/I reales que determinan a qué segmentos se accede, con qué funciones de llamada, en qué secuencia y con qué SSA.
Ninguna fuente por sí sola ofrece una visión completa. Un análisis que solo lee el código fuente COBOL muestra los tipos de llamadas y los nombres de los segmentos, pero no la estructura física de la base de datos. Un análisis que solo lee el DBD y el PSB muestra lo que el programa tiene permitido hacer, pero no lo que realmente hace.
La navegación depende de la posición. En una base de datos relacional, cada fila se puede acceder de forma independiente mediante una clave. En IMS, la posición actual de un programa en la jerarquía afecta a lo que devuelven las llamadas posteriores. Una llamada GN (Get Next) devuelve el siguiente segmento en la secuencia jerárquica desde la posición actual del programa. La dependencia no se limita al tipo de segmento, sino que también depende de la ruta de recorrido que condujo a la posición actual. Los programas que se basan en el ordenamiento jerárquico implícito de IMS presentan una dependencia que desaparece cuando los datos se migran a una base de datos relacional, donde no se garantiza un ordenamiento equivalente.
El inventario de llamadas DL/I: lo que revela el código fuente COBOL
El análisis previo a la migración más útil consiste en un inventario completo de cada llamada DL/I en cada programa COBOL que accede a IMS. Este inventario le indica al equipo de migración qué hace cada programa con IMS, no qué tiene permitido hacer (que define el PSB), sino qué hace realmente.
Las llamadas DL/I en COBOL aparecen de dos formas:
cobol
* Form 1: EXEC DLI interface (CICS-compatible, high-level syntax)
EXEC DLI
GU DB2PCB
SEGMENT(CUSTROOT)
WHERE(CUSTID = WS-CUST-ID)
END-EXEC
* Form 2: xxxTDLI call interface (batch programs, assembler-compatible)
CALL 'CBLTDLI' USING WS-FUNCTION-CODE
PCB-CUSTOMER
WS-CUSTOMER-SEGMENT
WS-SSA-CUSTOMERAmbas formas contienen la misma información analítica: el código de función, el PCB utilizado, el segmento de destino y, opcionalmente, el SSA (Argumento de Búsqueda de Segmento) que califica la llamada. Un inventario completo de llamadas DL/I extrae toda esta información de cada programa.
La taxonomía de códigos de función y sus implicaciones para la migración.
El código de la función DL/I es el elemento más importante para la migración en cada llamada. Cada código de función implica un patrón de acceso a datos diferente que debe replicarse en la base de datos relacional de destino:
Funciones de solo lectura: GUObtener datos únicos: navegue directamente a un segmento utilizando SSA calificados. Equivalente a una sentencia SELECT con cláusula WHERE en términos relacionales. Fácil de migrar si la clave del segmento se asigna correctamente a una clave primaria relacional.
GNObtener siguiente: pasa al siguiente segmento en la secuencia jerárquica. Este es el código de función que no tiene un equivalente relacional directo; se basa en el estado posicional y el orden implícito de IMS. Los programas que utilizan GN de forma extensiva requieren un análisis cuidadoso del orden del que dependen.
GNPObtener el siguiente elemento dentro del elemento principal: recupera los elementos secundarios subsiguientes del segmento principal actual. Equivalente a obtener todas las filas en una relación de clave externa. Generalmente se corresponde directamente con una sentencia SELECT con una cláusula WHERE de clave externa.
Funciones de retención (requisitos previos para la actualización): GHU, GHN, GHNPObtenga los equivalentes de GU, GN y GNP en la instrucción Hold. El indicador "hold" señala que a continuación se realizará una operación de actualización (REPL) o eliminación (DLET). Los programas que utilizan llamadas a hold son programas de lectura, modificación y escritura; la migración debe preservar la integridad transaccional durante la retención y la actualización posterior.
Actualizar funciones: ISRT, Insertar: agrega una nueva ocurrencia de segmento. Equivalente a INSERTAR. DLET, Eliminar: elimina el segmento actualmente retenido y todos sus dependientes. El comportamiento de “todos los dependientes” es una cascada específica de IMS que debe implementarse explícitamente en el sistema de destino. REPL, Reemplazar: actualiza el segmento actual con nuevos datos. Equivalente a ACTUALIZAR.
Por qué esto es importante para el alcance de la migración: Un programa con solo llamadas GU y GNP es un consumidor de datos IMS de solo lectura, lo que reduce el riesgo de migración y simplifica su validación. Un programa que utiliza GHU, REPL y DLET es un programa de procesamiento de transacciones que modifica estructuras jerárquicas; su migración requiere preservar la integridad transaccional en todas las operaciones que IMS actualmente aplica de forma atómica.
Los tres tipos de dependencia que complican toda migración
Relaciones lógicas
Las relaciones lógicas de IMS conectan segmentos entre dos bases de datos físicamente separadas. Un segmento lógico hijo en la base de datos A tiene un segmento lógico padre en la base de datos B. Cuando un programa COBOL navega a través de una relación lógica, recorre una ruta que cruza físicamente los límites de las bases de datos, un recorrido que IMS gestiona de forma transparente pero que desaparece cuando las bases de datos se migran de forma independiente.
Las relaciones lógicas representan el tipo de dependencia de mayor riesgo en la migración a IMS por una razón: son invisibles en el código fuente COBOL. El programa COBOL llama a GNP para obtener los elementos secundarios de un segmento. El hecho de que GNP atraviese una relación física padre-hijo o una relación lógica lo determinan el PSB y el DBD, no el código COBOL. Un equipo de migración que analice únicamente el código fuente COBOL no tiene forma de saber que una llamada a GNP está cruzando el límite de una relación lógica sin analizar por separado el PSB y el DBD.
Los programas que utilizan relaciones lógicas requieren que la migración replique la semántica de la relación lógica en el sistema de destino, normalmente una operación JOIN en el modelo relacional, y que valide que cada programa que utiliza la relación recibe resultados equivalentes de la operación JOIN a los que recibió del recorrido lógico de IMS.
Bases de datos de índices secundarios
Las bases de datos de índices secundarios de IMS proporcionan una ruta de acceso alternativa a la base de datos principal, lo que permite a los programas recuperar segmentos mediante un campo distinto de la clave raíz. Una base de datos de índices secundarios es una base de datos IMS independiente con su propio DBD, pero sus datos se derivan de la base de datos principal.
Los equipos de migración suelen descubrir las bases de datos de índices secundarios durante el análisis, en lugar de durante la planificación, porque:
- Se definen en DBD que no siempre están agrupados con los DBD de la base de datos principal.
- Los programas que utilizan índices secundarios nombran la base de datos de índices en sus PSB, pero los programas que navegan a la base de datos principal a través de un índice secundario pueden no hacer esto obvio en el código fuente de COBOL.
- La documentación puede describir la base de datos principal sin mencionar sus índices secundarios.
Un programa que accede a IMS mediante un índice secundario tiene una dependencia de patrón de acceso que debe replicarse en el destino como un índice sin clave primaria o una estrategia de consulta diferente. Si esto no se tiene en cuenta durante la migración, el programa se ejecutará sin errores, pero no podrá encontrar los registros que busca.
Bases de datos GSAM
Las bases de datos GSAM (Método de Acceso Secuencial Generalizado) son la interfaz de IMS para el procesamiento secuencial por lotes, lo que permite que los programas por lotes de COBOL utilicen llamadas DL/I para lo que funcionalmente es E/S de archivos secuenciales. Las bases de datos GSAM no tienen jerarquías de segmentos; son estructuras secuenciales planas a las que se accede a través de IMS para aprovechar las capacidades de recuperación y reinicio de IMS.
Los programas que utilizan bases de datos GSAM son programas por lotes que dependen de la función de reinicio/punto de control de IMS para su recuperación. La migración debe preservar esta funcionalidad de recuperación o reemplazarla por un mecanismo equivalente en la plataforma de destino.
Creación del inventario de dependencias previo a la migración
Un análisis completo de las dependencias de IMS genera seis entregables que, en conjunto, definen el alcance, el riesgo y la secuencia de la migración.
Entregable 1: Mapeo de PCB a base de datos
Cada PCB en cada PSB se corresponde con una DBD específica (una base de datos IMS específica). Al listar cada PCB en todos los PSB y asignar cada uno a su DBD, se obtiene la lista definitiva de qué programas tienen permiso para acceder a qué bases de datos. Este es el punto de partida para comprender el alcance, pero sobreestima las dependencias reales, ya que los programas pueden tener PSB que incluyan más bases de datos de las que realmente utilizan.
Entregable 2: Inventario real de llamadas por programa
El análisis de las llamadas DL/I de cada programa COBOL genera la lista de uso real: qué PCB llama cada programa, qué códigos de función utiliza, a qué tipos de segmento accede y si utiliza SSA cualificados (acceso mediante clave de segmento) o navegación no cualificada (recorrido posicional). Esto reduce el alcance, pasando de los permisos definidos por PSB al comportamiento real del programa.
Entregable 3: Mapa de uso de relaciones lógicas
La comparación del inventario de llamadas con las DBD permite identificar qué llamadas GNP o GN de los programas atraviesan relaciones lógicas. Esto requiere analizar no solo el código fuente COBOL y el PSB, sino también las estructuras DBD que definen qué relaciones padre-hijo son físicas y cuáles son lógicas.
Entregable 4: Mapa de uso del índice secundario
Los programas que nombran bases de datos de índices secundarios en sus PSB o que realizan llamadas con SSA que hacen referencia a campos de clave que no son raíz se identifican como usuarios de índices secundarios. El mapa documenta qué índices secundarios existen, qué bases de datos primarias admiten y qué programas dependen de ellos.
Entregable 5: Distribución del tipo de llamada por base de datos
Para cada base de datos IMS incluida en el ámbito de aplicación, la distribución de los tipos de llamadas entre todos los programas que acceden a ella indica la complejidad de su migración:
- Las bases de datos a las que solo se accede mediante funciones de lectura (GU, GN, GNP) son más fáciles de migrar.
- Las bases de datos a las que se accede mediante funciones de retención y actualizaciones (GHU + REPL, GHN + DLET) requieren replicación de integridad transaccional.
- Las bases de datos con un alto uso de GN indican dependencias de navegación posicional que requieren un análisis de ordenación.
- Las bases de datos con relaciones lógicas requieren semántica JOIN entre bases de datos en el destino.
Entregable 6: Clasificación de riesgos del programa
Utilizando la distribución del tipo de llamada y el inventario del tipo de dependencia, cada programa se clasifica según su riesgo de migración:
Los programas que utilizan únicamente GU y GNP con SSAs cualificados, acceden a una sola base de datos sin relaciones lógicas y no realizan llamadas de retención/actualización son los candidatos de menor riesgo para las primeras oleadas de migración. Los programas que utilizan GN de forma extensiva, acceden a múltiples bases de datos mediante relaciones lógicas o realizan secuencias complejas de retención/actualización son los de mayor riesgo y requieren un análisis y una validación exhaustivos antes de la migración.
Qué cambios introduce el análisis en la planificación migratoria
El análisis de dependencias no solo documenta lo que existe, sino que también modifica las decisiones posteriores.
Decisiones de secuencia. Los programas que comparten bases de datos IMS mediante relaciones lógicas no pueden migrarse de forma independiente. Si el programa A lee un segmento hijo lógico cuyo padre lógico se encuentra en la misma base de datos que el segmento raíz del programa B, migrar A sin migrar B (o sin crear un puente) provoca la interrupción de A. El gráfico de dependencias determina qué programas deben migrarse juntos.
Decisiones de diseño del objetivo. La distribución del tipo de llamada determina cómo debe estructurarse el esquema relacional de destino. Una relación jerárquica padre-hijo a la que se accede exclusivamente mediante llamadas GU y GNP con clave se traduce fácilmente en una relación de clave externa en el destino. La misma relación a la que se accede mediante llamadas GN con dependencias posicionales requiere que el esquema de destino conserve un orden equivalente, ya sea mediante ORDER BY explícito, un campo de secuencia o un patrón de acceso diferente que logre el mismo resultado.
Decisiones sobre el alcance de la validación. El análisis identifica qué programas son consumidores de datos IMS de solo lectura y cuáles son procesadores de transacciones. Los programas de solo lectura se pueden validar comparando los resultados de salida entre el sistema IMS original y el sistema migrado. Los procesadores de transacciones requieren pruebas de equivalencia transaccional, lo que garantiza que la misma secuencia de operaciones en el sistema de destino produzca cambios de estado de datos equivalentes a los del sistema original.
Clasificación de riesgos. La relación lógica y los hallazgos del índice secundario son los principales insumos para la clasificación de riesgos. Todo programa de migración cuenta con un registro de riesgos. El análisis de dependencias de IMS indica al equipo qué entradas debe incluir en dicho registro.
Cómo SMART TS XL Realiza análisis de dependencias de IMS
SMART TS XL, análisis de código estático Analiza las llamadas DL/I de cada programa COBOL, tanto las de interfaz de llamada EXEC DLI como las de xxxTDLI, extrayendo el código de función, la referencia PCB, el nombre del segmento y la estructura SSA de cada llamada. Esto genera el inventario de llamadas a nivel de programa, en todo el conjunto de programas COBOL, sin necesidad de un sistema IMS en ejecución ni de una revisión manual del código.
El mapeo de dependencias de la aplicación extiende este inventario a un gráfico de dependencias entre programas: qué programas comparten acceso a qué bases de datos IMS, qué programas utilizan los mismos PCB y qué patrones de acceso de programas se superponen de forma que requieren una migración coordinada. Cuando una relación lógica conecta segmentos entre bases de datos, el mapa de dependencias representa esta conexión entre bases de datos como una relación explícita que debe conservarse en el sistema de destino.
La capacidad de análisis de impacto responde a la pregunta que todo equipo de migración debe plantearse antes de convertir cualquier base de datos: si se migra esta base de datos IMS, ¿qué programas se verán afectados, qué patrones de acceso deben replicarse y qué casos de prueba deben validarse para confirmar la equivalencia? La respuesta no es una estimación, sino una lista enumerada derivada del inventario real de llamadas DL/I.
La capacidad de expansión de JCL añade el contexto operativo: qué pasos de trabajo de JCL invocan qué programas que acceden a IMS, en qué secuencia y con qué especificaciones PSB. La cadena de dependencia operativa, la secuencia de trabajos por lotes que procesa los datos de IMS a través de múltiples programas, es tan importante para la planificación de la migración como los patrones de acceso a nivel de programa. Migrar la base de datos sin migrar la orquestación de trabajos por lotes que la rodea produce un sistema que procesa los registros correctamente de forma aislada, pero falla en producción cuando se ejecuta la secuencia de trabajos.
Para los equipos que realizan modernización heredada de sistemas respaldados por IMS, la evidencia estructural producida por SMART TS XL es la entrada para cada decisión de migración posterior: qué programas migran en qué oleada, qué bases de datos se pueden convertir de forma independiente y cuáles requieren una conversión coordinada, qué patrones de acceso requieren una reestructuración en lugar de una traducción directa. Como se describe en el contexto de Migración de estructuras IMS y VSAM junto con programas COBOLLa interconexión entre los programas COBOL y las estructuras de datos heredadas implica que la migración de datos y el análisis de código deben realizarse en paralelo; el inventario de dependencias es el mecanismo que posibilita la planificación paralela.
El inventario no es la migración.
El análisis de dependencias de IMS genera conocimiento. La migración aún requiere decisiones, ingeniería y validación. Lo que cambia el análisis es la calidad de las decisiones, la exhaustividad del alcance de la ingeniería y la confianza en la validación.
Las organizaciones que migran bases de datos IMS con éxito no son las que tienen los plazos más ajustados ni los mayores presupuestos de migración. Son las que sabían lo que tenían antes de empezar la migración: cada programa que accedía a cada base de datos, cada código de función que revelaba el patrón de acceso de cada programa, cada relación lógica que creaba dependencias entre bases de datos, cada índice secundario que proporcionaba una ruta de acceso que no sobreviviría a la conversión sin una replicación explícita.
Ese conocimiento no proviene de la documentación. Proviene del análisis del código.
