La migración de datos no puede realizarse de forma aislada; debe evolucionar en paralelo con las aplicaciones COBOL que leen y escriben esos conjuntos de datos. Esta limitación define el desafío que supone la modernización de VSAM. VSAM (Virtual Storage Access Method) no es simplemente un formato de archivo. Es el contrato de datos entre programas, la especificación implícita, definida únicamente en las entradas FD y las cláusulas SELECT, que rige cómo cada programa de un sistema empresarial produce y consume sus datos de negocio más críticos. Un único cambio en el diseño de un registro que no se refleje en todos los programas que lo leen produce corrupción de datos que puede no manifestarse hasta que un informe regulatorio se ejecute sobre datos que ya no significan lo que el programa consumidor esperaba.
Las organizaciones que logran modernizar sus datos VSAM no son las que parten del esquema de destino, sino las que comienzan con una comprensión completa y basada en evidencia de lo que contienen los archivos VSAM, cómo están estructurados, qué programas acceden a ellos, con qué patrones y qué contratos implícitos existen entre productores y consumidores. Esta comprensión, el análisis de la estructura de los archivos VSAM, es el requisito previo para cada decisión posterior: qué conjuntos de datos VSAM se asignan a tablas relacionales, cuáles requieren arquitecturas de destino diferentes, qué diseños de registros necesitan conversiones de tipos de datos que preserven la precisión y qué conjuntos de datos compartidos deben migrar como unidades coordinadas en lugar de hacerlo de forma independiente.
Los conjuntos de datos compartidos requieren una migración coordinada.
SMART TS XL Extrae automáticamente todos los detalles de la estructura de los registros que requiere el diseño del esquema de destino.
DESCUBRE MÁS…Las cuatro organizaciones VSAM y los requisitos de cada una
Los conjuntos de datos VSAM se presentan en cuatro organizaciones distintas. Cada una tiene una estructura diferente, un patrón de acceso típico distinto y una correspondencia natural diferente con las arquitecturas de destino modernas. Tratar todos los conjuntos de datos VSAM de forma idéntica, convirtiéndolos masivamente a una tabla relacional, produce destinos que funcionan para algunos conjuntos de datos y que tienen un rendimiento deficiente o fallan funcionalmente para otros.
KSDS (Key-Sequenced Data Set) es la organización VSAM más común. Los registros se ordenan físicamente mediante una clave primaria, lo que permite tanto el acceso directo por clave como el acceso secuencial según el orden de la clave. Los archivos KSDS pueden tener índices alternativos, rutas de clave secundarias que permiten la recuperación por campos distintos de la clave primaria. El destino natural de un KSDS es una tabla relacional donde la clave primaria se convierte en la clave principal y los índices alternativos se convierten en índices SQL.
ESDS (Entry-Sequenced Data Set) almacena los registros en el orden en que fueron escritos. No tiene clave; los registros se direccionan mediante su desplazamiento físico de byte (RBA: Relative Byte Address). Los archivos ESDS se utilizan normalmente para datos de tipo registro: pistas de auditoría, diarios de transacciones y flujos de eventos. El destino natural para un ESDS es una tabla relacional de solo escritura, un flujo de eventos (tema de Kafka) o una base de datos de series temporales, según cómo los programas que consumen los datos accedan a ellos.
RRDS (Relative Record Data Set) almacena registros de longitud fija direccionados mediante un número de registro relativo. Cada ranura del archivo corresponde a un número de registro; las ranuras pueden estar vacías (eliminadas). Los archivos RRDS se utilizan en escenarios de acceso directo donde el número de registro es relevante para la aplicación, y suelen emplearse como tablas de búsqueda simples o almacenamiento basado en hash. El destino natural es una tabla relacional con un identificador de secuencia numérica, o una estructura de búsqueda en memoria si el conjunto de datos es pequeño y se accede con frecuencia.
LDS (Linear Data Set) es un sistema de almacenamiento direccionable por bytes sin estructura de registro visible para VSAM. Lo utilizan aplicaciones (normalmente DB2, cargas de trabajo Java o programas personalizados) que gestionan su propio formato interno dentro del rango de bytes de VSAM. Los archivos LDS no se pueden analizar mediante las entradas estándar de descriptores de archivo de COBOL; su estructura solo existe en la capa de aplicación que los escribe.
El resultado del análisis de cada conjunto de datos debe identificar qué organización utiliza, porque la organización determina todo lo que viene después: la arquitectura de destino, el patrón de acceso y el análisis específico necesario para comprender su estructura.
El problema del análisis del diseño del registro
La disposición de los registros es la dimensión analíticamente más compleja del análisis de la estructura VSAM. A diferencia de un esquema relacional, donde cada columna tiene un tipo, nombre y restricción definidos por el motor de base de datos, los registros VSAM carecen de una estructura autodescriptiva. La disposición reside completamente en la entrada FD de COBOL, y las entradas FD rara vez son simples.
Entradas FD y miembros COPY
La estructura de registro de un conjunto de datos VSAM se define en la entrada FILE DESCRIPTION (FD) de la DATA DIVISION de COBOL. En bases de código bien mantenidas, la entrada FD hace referencia a un miembro COPY, un copybook compartido que define la disposición del registro y que es incluido por cada programa que accede al conjunto de datos:
cobol
FILE SECTION.
FD CUSTOMER-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 250 CHARACTERS.
01 CUSTOMER-RECORD.
COPY CUSTMSTR.El miembro COPY CUSTMSTR define la disposición real del campo. Si 47 programas incluyen CUSTMSTR, entonces 47 programas comparten una dependencia del diseño de registro que define. Un cambio de nombre de campo en CUSTMSTR afecta a los 47. Este es el problema de acoplamiento de copybook aplicado a los datos: el diseño de registro VSAM es una dependencia compartida que no puede cambiar sin coordinar todos los programas que lo utilizan.
Para el análisis de migración, cada entrada de FD debe rastrearse hasta su copybook, y cada copybook debe asignarse a cada programa que la incluye. El grafo de dependencias de diseño compartido es la base para comprender el alcance de la migración.
REDEFINE: Múltiples diseños, un solo registro
El REDEFINES La cláusula REDEFINES es donde el análisis de registros VSAM se vuelve realmente complejo. REDEFINES permite que diferentes interpretaciones de campos se superpongan al mismo almacenamiento físico. Un registro VSAM que contiene un código de tipo de transacción puede usar REDEFINES para interpretar los bytes restantes de manera diferente según ese código:
cobol
01 TRANSACTION-RECORD.
05 TXN-TYPE PIC X(2).
05 TXN-COMMON-DATA PIC X(48).
05 TXN-DETAIL REDEFINES TXN-COMMON-DATA.
10 TXN-PAYMENT.
15 PAY-AMOUNT PIC S9(11)V99 COMP-3.
15 PAY-CURRENCY PIC X(3).
15 PAY-METHOD PIC X(2).
15 FILLER PIC X(28).
05 TXN-WITHDRAWAL REDEFINES TXN-COMMON-DATA.
10 WDR-AMOUNT PIC S9(11)V99 COMP-3.
10 WDR-ACCOUNT PIC 9(12).
10 WDR-BRANCH PIC 9(5).
10 FILLER PIC X(18).Este registro no tiene un diseño sino tres, dependiendo de TXN-TYPEEn el esquema relacional de destino, esto generalmente requiere un diseño de tabla polimórfica (tabla única ancha con columnas que admiten valores nulos para cada variante), un diseño normalizado (fila principal más filas secundarias específicas del tipo) o una columna JSON que contenga los datos de la variante. Ninguna de estas decisiones se puede tomar sin analizar qué TXN-TYPE Existen valores en los datos y qué variantes de REDEFINES se utilizan realmente.
Un análisis completo del diseño del registro debe:
- Identifique cada jerarquía REDEFINES en cada entrada FD.
- Determinar qué variante de REDEFINES está activa y bajo qué condiciones (requiere análisis de la lógica del programa, no solo análisis de FD).
- Documentar los tipos de campo, las longitudes y la precisión decimal empaquetada para cada variante.
- Recomendar la estrategia de normalización adecuada para el esquema de destino.
COMP-3 y precisión numérica
COBOL PIC S9(11)V99 COMP-3 (decimal empaquetado) tiene características específicas de precisión y escala que no tienen un equivalente directo en los tipos de datos estándar SQL. V indica un punto decimal implícito, el valor se almacena como un entero con una escala implícita de 2 lugares decimales. COMP-3 Cada byte contiene dos dígitos decimales, y el último medio byte contiene el signo.
Cuando este campo se migra a una base de datos relacional, el destino SQL correcto es DECIMAL(13, 2)no, FLOAT, lo que introduciría errores de redondeo, y no INTEGER, lo que perdería los decimales. Para los sistemas financieros donde los campos COMP-3 contienen cantidades monetarias, el requisito de precisión no es negociable. Una migración que convierte PIC S9(11)V99 COMP-3 La conversión a un tipo de punto flotante en el esquema de destino introduce errores de redondeo que se acumulan en las ejecuciones por lotes y pueden afectar a los informes reglamentarios.
Antes de comenzar el diseño del esquema de destino, cada campo COMP-3 de cada entrada FD debe estar documentado con su precisión, escala y convención de signos exactas.
Análisis de patrones de acceso VSAM en código fuente COBOL
La entrada FD describe el contenido del registro. La división de procedimiento COBOL describe cómo el programa lo utiliza. Ambas son necesarias para un análisis estructural completo. El análisis de patrones de acceso examina cada verbo de acceso a archivos en cada programa que interactúa con el conjunto de datos.
La cláusula SELECT: Primera señal
La cláusula SELECT en la DIVISIÓN DE ENTORNO establece cómo el programa COBOL accederá al archivo VSAM:
cobol
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT CUSTOMER-FILE
ASSIGN TO CUSTFILE
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS CUST-PRIME-KEY
ALTERNATE RECORD KEY IS CUST-ALT-KEY
WITH DUPLICATES
FILE STATUS IS WS-CUST-STATUS.Esta cláusula SELECT revela:
ORGANIZATION IS INDEXED→ KSDSACCESS MODE IS DYNAMIC→ El programa utiliza acceso secuencial y aleatorio.ALTERNATE RECORD KEY IS CUST-ALT-KEY WITH DUPLICATES→ Existe un índice alternativo y este programa lo utiliza.
El modo de acceso dinámico es particularmente significativo: un programa que accede a un KSDS en modo DINÁMICO puede utilizar READ con una llave para acceso directo y READ NEXT para el escaneo secuencial desde un punto posicionado. Ambos patrones de acceso deben replicarse en el destino, lo que puede requerir soporte tanto para la búsqueda directa (consulta de clave primaria) como para el escaneo de rango (recorrido ordenado) en el esquema relacional.
Verbos de acceso y sus implicaciones para la migración
Cada verbo de acceso a archivos revela una dimensión diferente de cómo el programa interactúa con el conjunto de datos VSAM:
LEER (directo): READ CUSTOMER-FILE KEY IS WS-CUST-KEY, búsqueda directa de clave. Se asigna a SELECT ... WHERE primary_key = ?La mayoría de los programas KSDS utilizan este patrón; se traduce directamente en una búsqueda indexada relacional.
LEER (secuencial): READ CUSTOMER-FILE NEXT RECORD, escaneo secuencial desde la posición actual. Se asigna a SELECT ... ORDER BY primary_key con posicionamiento del cursor. La dependencia de orden implícita, los programas que dependen del orden natural de las teclas de VSAM para el procesamiento secuencial, deben conservarse explícitamente en el destino.
INICIO: START CUSTOMER-FILE KEY >= WS-SEARCH-KEY seguido por READ NEXT, escaneo de rango desde una posición de clave parcial. Se corresponde con una consulta de rango: SELECT ... WHERE primary_key >= ? ORDER BY primary_keyLos programas que utilizan START establecen un límite inferior para el escaneo secuencial; este es un patrón de acceso crítico para los archivos KSDS que no tiene un equivalente simple a menos que la tabla de destino tenga el mismo orden de claves.
ESCRIBIR: Inserta un nuevo registro por clave. Se asigna a INSERT INTOSi el archivo VSAM tiene índices alternativos, la escritura debe mantener la coherencia con esos índices; en VSAM, esto es automático; en una base de datos relacional, se requiere un disparador de base de datos o código a nivel de aplicación para mantener tablas de índices secundarios equivalentes.
VOLVER A ESCRIBIR: Actualiza un registro en el lugar. El registro debe estar actualmente en posesión (después de una LECTURA con intención de retención). Se asigna a UPDATE ... WHERE primary_key = ?REWRITE es un patrón de lectura-modificación-escritura; la migración debe preservar la integridad transaccional tanto en la lectura como en la escritura.
ELIMINAR: Elimina un registro por clave. En los archivos KSDS, ELIMINAR es una eliminación física. Los programas que esperan que la ranura eliminada no esté disponible para futuras exploraciones secuenciales dependen de este comportamiento de eliminación física; una eliminación lógica (indicador de eliminación lógica) en el destino no produce un comportamiento equivalente a menos que cada programa que la consume se actualice para filtrar los registros eliminados lógicamente.
Uso alternativo del índice: La dependencia oculta
Los índices alternativos en los archivos KSDS son una de las dependencias que con mayor frecuencia se pasan por alto en la migración de VSAM. Un índice alternativo permite que un programa acceda a un archivo KSDS mediante un campo distinto de la clave principal. El índice alternativo es, a su vez, un conjunto de datos VSAM independiente (una ruta) que debe mantenerse sincronizado con el clúster base.
Un programa que accede CUSTOMER-FILE a través de su clave alternativa CUST-ALT-KEY tiene una dependencia que es invisible si solo se analiza la entrada FD del clúster base. La migración debe:
- Identificar qué programas utilizan qué claves alternativas (visibles en la cláusula SELECT)
ALTERNATE RECORD KEYdeclaraciones) - Asigne cada clave alternativa al índice SQL equivalente en la tabla de destino.
- Asegúrese de que las operaciones INSERT y DELETE en la tabla de destino mantengan automáticamente el equivalente del índice alternativo, normalmente a través de índices SQL únicos o no únicos que el motor de la base de datos mantiene de forma transparente.
El análisis debe enumerar cada índice alternativo para cada conjunto de datos KSDS y asignar cada uno a sus programas consumidores.
El problema del conjunto de datos compartido: contratos de datos implícitos
Los archivos VSAM se comparten frecuentemente entre varios programas y múltiples pasos de trabajos JCL. Este intercambio crea contratos de datos implícitos, acuerdos entre programas sobre la estructura de los registros, los rangos de claves y los patrones de acceso que no existen en ningún otro lugar que no sea el propio código.
La dependencia del conjunto de datos compartido tiene dos dimensiones:
Relaciones productor-consumidor. El programa A escribe registros que el programa B lee. La estructura, los valores clave y el orden de los registros que produce el programa A deben coincidir exactamente con lo que el programa B espera consumir. Si A y B se migran de forma independiente a esquemas de destino diferentes sin coordinar el contrato de datos compartidos, se produce una corrupción silenciosa de los datos: las lecturas de B se realizan correctamente en la base de datos de destino, pero los datos se devuelven en un formato que la lógica de B no maneja correctamente.
Acceso concurrente entre pasos de trabajo. Un flujo de trabajo JCL puede tener varios pasos, cada uno ejecutando un programa diferente sobre el mismo conjunto de datos VSAM en secuencia. El paso 1 escribe, el paso 2 lee y transforma, y el paso 3 escribe los resultados. La migración debe preservar esta dependencia secuencial; el orden en que los programas acceden y modifican el conjunto de datos compartido forma parte de la especificación de comportamiento del sistema.
Un análisis completo de un conjunto de datos compartidos debe:
- Enumerar todos los conjuntos de datos VSAM y todos los programas que acceden a ellos.
- Clasifique el acceso de cada programa como productor (ESCRITURA/REESCRITURA/BORRAR), consumidor (LECTURA) o ambos.
- Documentar el contexto del trabajo JCL en el que se ejecuta cada programa, qué paso, en qué trabajo, en qué cadena de dependencias del planificador
- Identificar pares productor-consumidor donde el formato de salida del productor debe coincidir exactamente con el formato de entrada esperado por el consumidor.
Este análisis no puede realizarse examinando un solo programa de forma aislada. Requiere un análisis estructural que abarque varios programas y diferentes JCL.
Entregables previos a la migración: qué análisis debe producir
Un análisis estructural de VSAM suficiente para la planificación de la modernización de datos produce seis resultados:
Entregable 1: Inventario del conjunto de datos VSAM
Cada conjunto de datos VSAM en el entorno, con: organización del conjunto de datos (KSDS/ESDS/RRDS/LDS), longitud promedio y máxima de los registros, recuento estimado de registros (a partir de parámetros JCL SPACE o entradas del catálogo), estructura de la clave (desplazamiento de la clave principal, longitud; estructuras de clave alternativas) y si el conjunto de datos tiene índices alternativos.
Entregable 2: Catálogo de maquetación de registros
Para cada conjunto de datos, cada entrada FD y los libros de copia a los que hace referencia, con: todas las definiciones de campo, incluidas las jerarquías REDEFINES, cada campo COMP-3 con su precisión y escala exactas, cada campo binario (COMP/COMP-5) con su longitud en bytes, cada elemento de longitud variable (OCCURS DEPENDING ON con su campo de control) y cada variante condicional o de diseño implícita por REDEFINES.
Entregable 3: Clasificación del patrón de acceso por programa
Para cada programa que accede a cada conjunto de datos: las características de la cláusula SELECT (organización, modo de acceso, uso de claves alternativas), el conjunto completo de verbos de acceso utilizados (READ/START/WRITE/REWRITE/DELETE), si el programa utiliza acceso secuencial y depende del orden de las claves, qué índices alternativos utiliza el programa y si el programa tiene patrones de lectura-modificación-escritura (requisitos de transacción implícitos).
Entregable 4: Mapa del conjunto de datos compartido
Un grafo dirigido donde los nodos son conjuntos de datos y programas VSAM, y las aristas representan relaciones de acceso con su tipo (lectura/escritura). El grafo muestra cada productor, cada consumidor, pares productor-consumidor y el contexto de la secuencia de trabajo JCL para cada acceso.
Entregable 5: Recomendaciones sobre el esquema objetivo
Para cada conjunto de datos VSAM, la arquitectura objetivo recomendada se basa en su organización y patrones de acceso:
| Tipo VSAM | Patrón de acceso primario | Objetivo recomendado |
|---|---|---|
| KSDS, acceso directo mediante llave únicamente | Búsquedas puntuales por clave primaria | Tabla relacional, indexada |
| KSDS, con INICIO/LEER SIGUIENTE | Escaneos de rango en orden clave | Tabla relacional con índice agrupado |
| KSDS con índices alternativos | Acceso con clave de múltiples rutas | Tabla relacional con múltiples índices |
| ESDS, solo anexo | Añadir secuencialmente, sin clave. | Tabla, flujo de eventos o registro de solo adición |
| ESDS, con acceso RBA | Posicionamiento con desplazamiento de bytes | Almacenamiento de objetos con índice de metadatos |
| RRDS | Acceso al número de registro | Tabla relacional con columna de secuencia |
| Hojas de datos de seguridad de sistemas (KSDS) grandes (a granel, para análisis) | Escaneos secuenciales completos | Almacenamiento columnar o lago de datos |
| LDS | Formato interno gestionado por la aplicación | Requiere análisis de la capa de aplicación |
Entregable 6: Registro de campo de alta precisión
Cada campo COMP-3, COMP, COMP-5 y de punto flotante en cada conjunto de datos, con su definición COBOL, la asignación correcta del tipo de datos SQL y un indicador para cualquier campo donde la asignación requiera una validación de precisión antes y después de la migración.
¿Qué diferencia el análisis VSAM del análisis de esquemas relacionales?
Los equipos con experiencia en la migración entre bases de datos relacionales a veces subestiman el análisis VSAM porque aplican el modelo mental de migración de esquemas: extraer el DDL, rediseñar el esquema y migrar los datos. VSAM no tiene DDL en el sentido de base de datos. El esquema se distribuye a través del código fuente, en entradas FD, en copybooks, en cláusulas SELECT y en la lógica de PROCEDURE DIVISION que determina qué variante REDEFINES está activa para cada registro.
Tres propiedades hacen que el análisis VSAM sea estructuralmente diferente:
El esquema reside en el código. La estructura de registros de un conjunto de datos VSAM se define en el código fuente COBOL, no en un catálogo de base de datos. Encontrarla requiere analizar el código fuente. Modificarla requiere coordinar todos los programas que comparten el archivo de configuración. Comprender todas sus variantes requiere analizar la lógica del programa, no solo la entrada del descriptor de archivo.
Los patrones de acceso están implícitos en el comportamiento del programa. Una base de datos relacional expone los patrones de consulta mediante planes EXPLAIN y registros de consultas. Los patrones de acceso VSAM solo son visibles en la DIVISIÓN DE PROCEDIMIENTOS de los programas que acceden al archivo. Para comprender si un programa depende del orden de las claves, del acceso alternativo a índices o del escaneo de rangos, se requiere un análisis del código.
Los conjuntos de datos compartidos crean contratos ocultos. En una base de datos relacional, el esquema es un artefacto a nivel de base de datos que todos los usuarios comparten y visualizan. En VSAM, la estructura de los registros está integrada en el archivo de copia de cada programa. Dos programas pueden tener copias divergentes de lo que nominalmente es la misma estructura de registros, y descubrir esta divergencia requiere comparar las definiciones de los archivos de copia entre programas, no inspeccionar una única definición de esquema.
Cómo SMART TS XL Realiza análisis estructurales VSAM
SMART TS XL, análisis de código estático Analiza cada elemento de la estructura VSAM presente en el código fuente COBOL: entradas FD, expansiones de miembros COPY, declaraciones de cláusulas SELECT (organización, modo de acceso, especificaciones de clave primaria y alternativa) y cada verbo de acceso a archivos en la DIVISIÓN PROCEDURE. Para cada conjunto de datos VSAM, el análisis genera la clasificación del patrón de acceso, el diseño del registro con resolución REDEFINES completa y el registro de campos COMP-3 con metadatos precisos.
El mapeo de dependencias de la aplicación crea el mapa de conjuntos de datos compartidos: cada programa que accede a cada conjunto de datos VSAM, clasificado por tipo de acceso, con las relaciones productor-consumidor identificadas y el gráfico de compartición de copybooks resuelto. Cuando 47 programas comparten un copybook que define un diseño de registro VSAM, el mapa de dependencias hace visibles los 47 antes de tomar cualquier decisión de migración, y no después de que un cambio de diseño haya afectado a 47 programas de forma inesperada.
La capacidad de expansión de JCL proporciona el contexto operativo: qué pasos de trabajo de JCL hacen referencia a qué conjuntos de datos VSAM en sus sentencias DD, en qué secuencia y en qué flujos de trabajo. Las relaciones productor-consumidor que existen a nivel de trabajo de JCL, donde el Paso 1 escribe en un conjunto de datos VSAM que el Paso 3 lee, son visibles en el análisis de dependencias de JCL, lo que permite una secuenciación de migración que preserva las dependencias de orden operativo que impone la programación por lotes.
La capacidad de análisis de impacto responde a la pregunta que precede a cada decisión de migración de VSAM: si cambia la estructura de este conjunto de datos, ¿qué programas se verán afectados? El alcance del impacto, cada programa que comparte el archivo de copia correspondiente y cada paso JCL que hace referencia al conjunto de datos, se enumeran antes de que comience cualquier trabajo de migración, lo que proporciona la base para una planificación de migración coordinada en lugar de descubrir los programas afectados uno por uno.
La capacidad de búsqueda empresarial permite consultar el inventario completo de VSAM durante todo el programa de modernización: encuentre en segundos, en millones de líneas de COBOL, cada programa que acceda a un conjunto de datos VSAM específico, cada copybook que defina un diseño de registro específico, cada programa que utilice patrones START/READ NEXT (que indican dependencias de ordenación) y cada campo definido como COMP-3 (que requiere una asignación de destino con precisión).
Como se describe en el contexto de Migración de estructuras de datos IMS y VSAM junto con programas COBOLLa migración de datos y el análisis de código deben realizarse en paralelo. SMART TS XLEl análisis estructural VSAM proporciona el inventario que hace que ese paralelismo sea manejable, los diseños de registros compartidos, los patrones de acceso y las relaciones productor-consumidor que determinan si la migración de datos puede proceder de forma independiente o debe coordinarse con los cambios del programa.
La estructura que comprendes es la estructura que puedes migrar.
El análisis de la estructura de archivos VSAM no supone una sobrecarga en un programa de modernización; es la base para la toma de decisiones. El esquema de destino no puede diseñarse sin conocer las variantes de la disposición de los registros. La migración no puede secuenciarse sin conocer las relaciones productor-consumidor. La precisión de los campos COMP-3 no puede preservarse sin saber qué campos requieren tipos de destino que admitan decimales.
Todo programa de modernización que omite este análisis descubre lo que pasó por alto durante la ejecución de la migración: cuando una variante de REDEFINES no analizada produce registros con formato incorrecto en el destino; cuando se migra un conjunto de datos compartido sin coordinar a todos sus usuarios; cuando un escaneo de rango que dependía del ordenamiento de claves de VSAM devuelve resultados con un orden indefinido en una tabla de destino que no fue diseñada con un índice agrupado. Estos descubrimientos durante la ejecución cuestan mucho más de lo que habría costado el análisis durante la planificación.
Primero, comprenda la estructura. Después, migre los datos. El orden no es una mera formalidad. Es la diferencia entre una migración que produce resultados correctos y una que produce datos que parecen correctos hasta que se realiza la primera auditoría regulatoria.
