Para verificar la paridad entre un proceso por lotes heredado de COBOL y su reemplazo en Java, un tester manual debe ejecutar ambos sistemas contra conjuntos de datos de entrada idénticos y realizar una reconciliación campo por campo. La metodología implica una muestra estratificada de registros, priorizando transacciones de alto valor, fechas límite (por ejemplo, el 29 de febrero, cambios de año) y casos límite de punto flotante, en lugar de una comparación exhaustiva. Los testers deberían exportar las salidas a formatos neutros (como CSV) y utilizar herramientas de comparación de diferencias mientras inspeccionan manualmente campos financieros críticos en busca de discrepancias de redondeo. Debe prestarse especial atención a las conversiones de fecha juliana y al comportamiento aritmético de decimal empaquetado (COMP-3) en comparación con las implementaciones de punto flotante IEEE 754. Finalmente, la validación de sumas de verificación y comparaciones de hash de archivos de salida completos sirven como una prueba básica antes de que comience un análisis detallado de campo a campo.
En un banco multinacional, se me asignó la tarea de validar la migración de un trabajo por lotes de acumulación de intereses nocturnos de un sistema COBOL en IBM Mainframe a un microservicio de Spring Boot que se ejecuta en Linux. El sistema legado había procesado miles de millones en transacciones durante décadas utilizando aritmética decimal empaquetada COMP-3 y formatos de fecha juliana (YYDDD), mientras que la nueva aplicación Java utilizó BigDecimal y calendarios gregorianos estándar. El problema principal era garantizar una salida idéntica a nivel de bits; incluso una discrepancia de un solo centavo entre millones de cuentas constituiría un defecto financiero crítico, y diferencias sutiles en los modos de redondeo o cálculos de años bisiestos podrían generar variaciones materiales.
Una solución considerada fue una comparación de archivos de fuerza bruta de todos los registros de salida. Este enfoque ofrecía cobertura exhaustiva y certeza absoluta de que cada byte coincidía. Sin embargo, los pros fueron superados por graves contras: el conjunto de datos contenía más de cincuenta millones de registros, lo que hacía que la comparación manual fuera prácticamente imposible dentro de la ventana de trabajo por lotes nocturna, y el gran volumen de ruido proveniente de las diferencias esperadas en los metadatos (como las marcas de tiempo) enmascararía los defectos reales de los datos.
Otra opción fue una selección aleatoria simple de un porcentaje fijo de registros, digamos uno por ciento. Si bien esto proporcionó una visión general estadísticamente significativa y fue rápido de ejecutar, los contras eran inaceptables para la auditoría financiera: la selección aleatoria podría perder fácilmente valores atípicos de alto impacto, como un tipo de cuenta específico con reglas de redondeo únicas o transacciones que ocurren el 29 de febrero de 2024, que históricamente provocaron errores en la lógica de conversión de días de Juliana.
La solución elegida fue una estrategia de muestra estratificada combinada con scripts de comparación automática para validación manual. Clasificamos los registros por niveles de riesgo: el Nivel 1 incluía todas las cuentas con saldos superiores a un millón de dólares y todas las transacciones en fechas límite (fin de mes, fin de año, días bisiestos), mientras que el Nivel 2 cubría muestras aleatorias de diferentes tipos de productos. Este enfoque fue seleccionado porque equilibró la necesidad de certeza absoluta en transacciones de alto riesgo con las limitaciones prácticas del tiempo de prueba manual.
Para el Nivel 1, realizamos una reconciliación manual a nivel de campo del 100% utilizando Beyond Compare y scripts personalizados en Python para resaltar las diferencias, mientras que para el Nivel 2, verificamos sumas de verificación agregadas y revisamos al azar campos individuales. El resultado fue el descubrimiento de un defecto crítico donde COBOL truncaba resultados de cálculos intermedios en cinco lugares decimales, mientras que la división por defecto de BigDecimal de Java mantenía la escala de manera impredecible, causando una variación de $0.01 en cuentas de alto interés. Una vez identificado, ajustamos el modo de redondeo de Java a HALF_UP con una escala explícita, logrando perfecta paridad.
¿Cómo detectas la corrupción de la codificación al validar archivos de ancho fijo migrados de EBCDIC a ASCII?
Muchos testers inspeccionan visualmente los datos en editores de texto, perdiendo de vista que los mainframes de COBOL suelen usar la página de código EBCDIC CP037, mientras que los sistemas Java utilizan UTF-8. Los caracteres especiales como los símbolos de moneda (€, £) o letras acentuadas en los nombres de los clientes pueden asignarse incorrectamente. Para verificar, debes abrir archivos en un editor hexadecimal para comparar representaciones a nivel de byte, asegurando que los espacios finales en COBOL (a menudo hex 40) no se confundan con terminadores nulos en Java (hex 00), y que los campos de decimal empaquetado (COMP-3) se descompriman correctamente sin corrupción de bits de signo.
¿Por qué pueden dos cálculos matemáticamente equivalentes dar resultados diferentes en COBOL en comparación con Java, incluso cuando ambos usan tipos "decimales"?
Los candidatos a menudo asumen que BigDecimal garantiza un comportamiento idéntico al decimal empaquetado de COBOL. Sin embargo, COBOL realiza aritmética en base 10 con una precisión fija dictada por la cláusula PIC (por ejemplo, PIC 9(9)V99), truncando resultados intermedios en cada paso de operación según las reglas comerciales. BigDecimal de Java, por defecto, mantiene precisión arbitraria a menos que se establezca explícitamente un MathContext y un RoundingMode. La solución es replicar la lógica de truncamiento de COBOL encadenando operaciones con llamadas explícitas a setScale() y haciendo coincidir el modo de redondeo heredado (a menudo HALF_UP o HALF_EVEN) en cada paso intermedio, no solo en el resultado final.
¿Cómo validas la precisión temporal cuando el sistema heredado ignora el horario de verano (DST) mientras que la nueva aplicación Java utiliza UTC o la hora local con conciencia de DST?
Esto a menudo se pasa por alto porque los testers comparan marcas de tiempo superficialmente. Si el trabajo heredado de COBOL se ejecuta en EST (hora estándar del este) durante todo el año mientras que el servicio Java utiliza America/New_York (que cambia a EDT), las transacciones que ocurren entre las 2:00 AM y las 3:00 AM del segundo domingo de marzo tendrán un desfase de una hora. Para resolver esto, los testers deben convertir ambas marcas de tiempo a un formato canónico (por ejemplo, milisegundos de época UTC) durante la validación manual, verificar que los parámetros de corte de lote de "fin de día" (a menudo "23:59:59") se interpreten de manera consistente y asegurar que la lógica de límite de fecha (por ejemplo, "último día hábil del mes") no se desplace debido a la hora faltante en primavera o a la hora extra en otoño.