Módulo 4 — Assure Quick EDD

Qué es

Assure QuickEDD es la solución de HA/DR de Precisely para IBM i, basada en replicación lógica en tiempo real desde un servidor de producción a uno o varios servidores de respaldo. El servidor de respaldo queda listo para asumir el rol productivo (role-swap) o para recuperar datos a un punto en el tiempo.

La replicación utiliza sincronización sin bloqueos (no-lock synchronization), lo que significa que el proceso de replicación no pone en hold ni bloquea los objetos durante la captura de cambios. Esto elimina el impacto sobre el rendimiento de la aplicación productiva. La solución es compatible con un amplio rango de versiones de IBM i y combinaciones de storage, y escala desde entornos SMB hasta enterprise sin cambiar el modelo de licenciamiento o administración.

Linaje del producto

QuickEDD nació en la línea Quick Software de Trader's, empresa especializada en soluciones IBM i que fue adquirida y absorbida por Precisely. Hoy es parte del portafolio Assure de Precisely para IBM i — una suite integrada de productos de protección de datos, HA/DR y calidad de datos para la plataforma IBM i. El nombre "EDD" responde a "Enhanced Data Distribution", concepto central de su arquitectura basada en distribución continua de cambios del journal hacia el target.

Qué replica

Quick EDD replica una variedad amplia de objetos:

• •Objetos de base de datos (archivos físicos y lógicos).
• •Stream files de IFS.
• •System values.
• •User profiles.
• •Spool files.
• •Job queues.
• •Job scheduler.

Esta amplitud de cobertura es significativa: muchas soluciones de replicación lógica para IBM i solo replican archivos de base de datos, dejando fuera elementos del sistema operativo como user profiles o system values que son críticos para que el target pueda realmente operar en producción tras un role-swap.

Qué garantiza

• •Replicación en tiempo real del source al target.
• •Validación de sincronía mediante auditorías programadas, on-demand y monitoreo continuo. Las divergencias se reparan automáticamente sin poner objetos en hold.
• •Topologías múltiples y multi-nodo (más de un target, encadenamientos).
• •Compatibilidad amplia con distintos niveles de IBM i y combinaciones de storage, escalable de SMB a enterprise.
• •Procedimientos de switch personalizables, ejecutables paso a paso, interactivos o en batch.

Cómo se administra

Assure QuickEDD ofrece dos interfaces de administración complementarias:

• •Interfaz gráfica con soporte para siete idiomas (inglés, francés, español, entre otros), pensada para administración centralizada y visión de estado del entorno HA.
• •Interfaz 5250 para administración en consola tradicional IBM i, familiar para operadores y administradores acostumbrados al entorno nativo.

Las alertas se entregan por email, MSGQ y SNMP, lo que permite integración con cualquier consola de monitoreo corporativo (Nagios, Zabbix, AUI Enterprise Monitor, etc.) y facilita el monitoreo desatendido en guardia nocturna o fin de semana.

El portal de soporte de Precisely (support.precisely.com) provee documentación técnica en inglés y francés, incluyendo referencias de comandos propios del producto (EDHCTL, EDHMONITOR, EDH_STATUS, PMEDHSTR), guías de configuración de journaling y SSH, checklists de operación diaria y artículos de troubleshooting con códigos de error específicos (EDH0734, SYS0403, CPF codes). También documenta integraciones con SAP, MQ Series y NetServer.

Por qué importa el journaling

Quick EDD es replicación lógica: lee los journals de IBM i y aplica los cambios en el target. Si un objeto crítico no está journaled, no se replica. Por eso la primera tarea de cualquier proyecto Quick EDD es relevar y completar journaling de los objetos productivos.

Objetivo del rol en este módulo: RCA, tuning, recovery y conducción de role-swaps reales.

Root cause analysis típicos

• •Divergencia que no autoresuelve — interpretar audit logs, identificar qué cambió.
• •Apply lag persistente — buscar contention, problemas de red, volumen anormal de cambios.
• •Objetos no replicables — entender por qué (tipo no soportado, journaling incompleto, autoridad).
• •Conflictos en bidireccional — resolución de colisiones según política.

Árbol de decisión para diagnosticar apply lag

El apply lag es el problema más frecuente y más impactante en un entorno Quick EDD. Un lag elevado significa que ante un role-swap, se perdería la ventana de datos no aplicados. La secuencia de diagnóstico debe seguirse en orden — cada paso descarta una capa antes de pasar a la siguiente:

Paso 1 — Verificar el estado general de la replicación:

EDHCTL OPTION(*STATUS)

Salida esperada (entorno sano):

QuickEDD Status Report
  Replication State . . . : ACTIVE
  Apply Status  . . . . . : RUNNING
  Apply Lag (seconds) . . : 3
  Last Apply Timestamp  . : 2026-05-08-14.32.15.000000
  Objects in Scope  . . . : 1,247
  Pending Entries . . . . : 42

Si Replication State no es ACTIVE o Apply Status no es RUNNING, el problema es que la cadena de replicación está detenida — no es un problema de lag sino de operación.

Si Apply Lag es mayor a lo aceptable para el cliente (típicamente >30 segundos en entornos críticos, >300 segundos en entornos menos exigentes), continuar con el árbol.

Paso 2 — Red entre source y target:

PING RMTSYS('TARGET_IP') MSGLEN(1024) NBRPKT(10)

Verificar: latencia <5ms en LAN, <50ms en WAN. Packet loss 0%. Si hay packet loss o latencia anormal, el problema es de red — escalar a networking.

Para un análisis más fino, verificar el throughput sostenido con una transferencia FTP de prueba entre source y target y medir MB/s. Comparar contra el volumen de journal entries/segundo que genera el source.

Paso 3 — Espacio en disco y receivers:

WRKDSKSTS

Verificar que ningún ASP supere el 90% de ocupación. Un ASP lleno impide la creación de nuevos receivers y detiene la replicación.

WRKJRN JRN(QGPL/QAUDJRN)

Verificar el tamaño del receiver activo. Si excede 1 GB sin rotación, el apply puede estar leyendo un receiver muy grande de forma ineficiente. El threshold de receivers debe estar configurado para rotar entre 100 MB y 500 MB según el volumen del entorno.

Paso 4 — Object locks en el target:

WRKOBJLCK OBJ(BIBLIOTECA/ARCHIVO) OBJTYPE(*FILE)

Un archivo bloqueado en el target impide que el apply process escriba. Causas comunes:

• •Un job de batch que corre en el target y abrió un archivo replicado con *EXCL.
• •Un usuario conectado al target que tiene abierto un archivo.
• •Un proceso de backup que bloqueó temporalmente los archivos.

Resolución: identificar el job que posee el lock con WRKOBJLCK, evaluar si puede terminarse con ENDJOB, y prevenir recurrencia ajustando la programación de batches en el target.

Paso 5 — Interferencia de batch en source:

WRKACTJOB SBS(QBATCH)

Un batch masivo en el source (carga masiva, reorganización, imports) genera un pico de journal entries que puede superar la capacidad del apply process. Verificar:

• •Volumen de journal entries por segundo durante el batch: DSPJRN JRN(BIBLIOTECA/JOURNAL) OUTPUT(*OUTFILE) y contar entries por timestamp.
• •Si el batch genera >10,000 entries/segundo sostenido, el apply necesitará catch-up post-batch.

Paso 6 — Tamaño del journal receiver activo:

DSPJRN JRN(BIBLIOTECA/JOURNAL) RCVRNG(*CURCHAIN) OUTPUT(*PRINT)

Si el receiver activo es muy grande (>2 GB), el apply process puede estar experimentando tiempos de seek elevados. Configurar THRESHOLD en el journal para forzar rotación automática:

CHGJRN JRN(BIBLIOTECA/JOURNAL) JRNRCV(*GEN) THRESHOLD(500000)

El valor 500000 es en KB (≈500 MB). Ajustar según el volumen del entorno.

Comandos Quick EDD con salida esperada

EDHMONITOR — Monitor de replicación en tiempo real:

EDHMONITOR

Salida esperada:

QuickEDD Replication Monitor
  Source System  . . . . : PRODSYS
  Target System  . . . . : HASYS01
  ------------------------------------------
  Apply Lag  . . . . . . :          4 sec
  Entries/Min (source) . :      3,247
  Entries/Min (applied)  :      3,241
  Pending Entries  . . . :         23
  Audit Status . . . . . : SYNC
  Last Audit . . . . . . : 2026-05-08 14:00:00
  Next Audit . . . . . . : 2026-05-08 15:00:00
  Active Apply Jobs  . . :          3
  Errors (last 24h)  . . :          0

Claves a monitorear: si Entries/Min (applied) es consistentemente menor que Entries/Min (source), el apply no alcanza al source — hay que tunearlo. Si Audit Status no es SYNC, revisar la auditoría.

EDH_STATUS — Estado detallado programático:

EDH_STATUS

Este comando devuelve información detallada para scripting y automatización. La salida incluye:

EDH Status Detail
  Environment ID . . . . : PROD_HA
  Configuration  . . . . : ACTIVE
  Source LPAR  . . . . . : PRODSYS
  Target LPAR  . . . . . : HASYS01
  Replication Mode . . . : REALTIME
  Apply Process State  . : ACTIVE
  Apply Lag Seconds  . . : 4
  Journal State  . . . . : NORMAL
  Receiver: QZRDJRN0042  Size: 234 MB
  Last Error . . . . . . : NONE
  Switch Ready . . . . . : YES

El campo Switch Ready: YES es crítico — indica que el target está en condiciones de asumir el rol productivo. Si muestra NO, hay que investigar qué condición falta antes de intentar un role-swap.

PMEDHSTR — Historial del proceso de replicación:

PMEDHSTR PERIOD(*LAST24H)

Muestra eventos de las últimas 24 horas: arranques, paradas, errores, cambios de receiver, auditorías completadas. Fundamental para RCA de problemas intermitentes.

Códigos de error comunes y su significado

| Código | Significado | Acción | |---|---|---| | EDH0734 | Object not journaled — un objeto en scope de replicación no tiene journaling activo. | Verificar con DSPFD si el archivo tiene journal asignado. Si no, ejecutar STRJRNPF. | | EDH0812 | Apply process detenido por error irrecuperable en el target. | Revisar joblog del apply job, identificar el objeto/operación que causó el fallo, corregir, reiniciar apply. | | EDH0956 | Receiver no accesible — el receiver que el apply necesita leer ya fue eliminado o movido. | El receiver fue purgado antes de que el apply lo procesara. Requiere re-sincronización parcial o completa. | | EDH1023 | Communication failure entre source y target. | Verificar red, firewalls, DNS. Ejecutar PING al target. Verificar que el subsistema de comunicación esté activo. | | EDH1101 | Authority error — el perfil de QuickEDD no tiene autoridad sobre un objeto. | Otorgar *USE o *CHANGE según corresponda al perfil de servicio de QuickEDD sobre el objeto afectado. | | EDH1250 | Audit divergence detected — la auditoría encontró diferencias entre source y target. | Si la auto-reparación no resolvió, verificar manualmente el objeto con DSPOBJD en ambos sistemas y forzar re-sincronización del objeto. | | EDH1415 | Journal receiver threshold exceeded. | Forzar rotación con CHGJRN y verificar que la política de purga no elimine receivers antes de que el apply los procese. | | SYS0403 | System resource constraint — memoria o CPU insuficiente para el proceso de replicación. | Verificar WRKSYSSTS en el target. Si el pool donde corre QuickEDD tiene menos de 500 MB disponibles, reasignar memoria. |

Secuencia de diagnóstico para role-swap fallido

Un role-swap que falla a mitad de ejecución es un escenario crítico. La secuencia paso a paso para diagnosticar y recuperar:

1. •Identificar en qué paso falló el switch procedure. Revisar el log del switch — QuickEDD registra cada paso con timestamp y resultado.
2. •Verificar el estado del apply lag al momento del switch. Si el lag era >0 al iniciar el switch, puede haber datos no aplicados. Registrar el valor exacto.
3. •Verificar conectividad source↔target. Si la red falló durante el switch, ambos sistemas pueden estar en estado inconsistente.
4. •Revisar el joblog del switch procedure. Buscar el primer mensaje de error (CPF, EDH, MCH). Los errores típicos son:
   • •CPF2105 — objeto no encontrado (un programa del switch referencia un objeto que no existe en el target).
   • •EDH1023 — pérdida de comunicación durante el switch.
   • •CPF1124 — job terminado anormalmente (un paso del switch abortó).
5. •Determinar si el target asumió parcialmente el rol. Verificar: ¿las IPs ya se cambiaron? ¿Los subsistemas productivos arrancaron? ¿Los usuarios pueden conectarse?
6. •Decidir: avanzar o retroceder. Si el target está más de 80% convertido, suele ser más seguro completar manualmente los pasos restantes. Si está en <20%, es mejor hacer rollback al source original.
7. •Documentar TODO. Cada role-swap fallido es una lección. Registrar: hora, versión de QuickEDD, paso exacto del fallo, error, resolución aplicada, y tiempo total de indisponibilidad.

Cuándo escalar a Precisely Support vs resolver internamente

Resolver internamente:

• •Apply lag causado por contención de recursos (CPU, memoria, disco, red) — es tuning, no bug del producto.
• •Object not journaled — es configuración del entorno, no del producto.
• •Authority errors — es administración de seguridad del IBM i.
• •Role-swap fallido por error en el switch procedure customizado — es lógica del procedimiento, no del motor.
• •Divergencias detectadas por auditoría que se auto-reparan — es comportamiento esperado.

Escalar a Precisely:

• •Error con código EDH que no está documentado en la base de conocimiento del portal.
• •Apply process que se detiene repetidamente sin causa identificable en los logs.
• •Comportamiento inconsistente tras un upgrade de QuickEDD o del IBM i (nuevo TR/PTF).
• •Corrupción de datos en el target que no es explicable por la secuencia de journal entries.
• •Performance degradation del apply que no responde a tuning estándar.
• •Cualquier situación donde el campo Switch Ready muestra NO sin razón aparente.

Al escalar: adjuntar versiones exactas (QuickEDD, IBM i, TR), joblogs completos de los jobs de QuickEDD, output de EDH_STATUS y EDHMONITOR, y mensajes de QSYSOPR de la ventana del incidente.

Tuning del apply

Paralelización de apply jobs:

Por defecto, QuickEDD puede ejecutar un solo apply job. En entornos con alto volumen de cambios, paralelizar es la palanca de tuning más efectiva. Cada apply job procesa un subconjunto de objetos o bibliotecas.

Antes del tuning — apply con 1 job:

EDHMONITOR
  Entries/Min (source) . :      8,500
  Entries/Min (applied)  :      3,200
  Apply Lag  . . . . . . :        187 sec
  Active Apply Jobs  . . :          1

Después del tuning — apply con 3 jobs paralelos:

EDHMONITOR
  Entries/Min (source) . :      8,500
  Entries/Min (applied)  :      8,490
  Apply Lag  . . . . . . :          3 sec
  Active Apply Jobs  . . :          3

La regla de oro: el throughput del apply (Entries/Min applied) debe ser >= al throughput del source (Entries/Min source) en estado sostenido. Si no lo es, hay que paralelizar o tunejar.

Prioridad de subsistemas:

El subsistema donde corren los jobs de QuickEDD debe tener prioridad suficiente para no ser desplazado por batch. Verificar:

DSPSBSD SBSD(QGPL/EDHSBS)

Los activity levels y las pool sizes deben garantizar que los apply jobs no compitan por memoria con batch. Recomendación: asignar un pool de memoria dedicado (pool privado) al subsistema de QuickEDD con al menos 1 GB.

Tamaño y rotación de journal receivers:

| Parámetro | Valor recomendado | Por qué | |---|---|---| | THRESHOLD | 250 MB – 500 MB | Receivers más chicos rotan más rápido, el apply lee menos datos por receiver. | | MNGRCV(*SYSTEM) | Sí | Deja que el sistema gestione la creación y attach de nuevos receivers automáticamente. | | DLTRCV(*YES) en política de purga | Con precaución | Solo eliminar receivers que el apply ya procesó completamente. Verificar con EDHCTL OPTION(*STATUS) antes de purgar. |

Filtrado de objetos sin valor de replicación:

No todo lo que está en una biblioteca necesita replicarse. Objetos que típicamente se excluyen:

• •Archivos temporales de trabajo (QTEMPxxx, WRKxxx).
• •Spool files de batch que no son críticos.
• •Objetos de desarrollo (fuentes QRPGLESRC, QCLSRC) si el target no es un ambiente de desarrollo.

Cada objeto excluido reduce el volumen de entries que el apply process debe manejar.

Role-swap real (no solo POC)

• •Validación previa de prerequisitos en target.
• •Coordinación con aplicación, red, DBA, usuarios.
• •Ejecución del switch (modo elegido).
• •Validación post-switch.
• •Plan de retorno.

Casos límite

• •Objetos no journaled-ables por tipo o configuración.
• •Objetos con autoridades especiales (*ALLOBJ / *SECADM).
• •Programas con dependencias de naming absoluto.
• •Situaciones de catch-up tras una caída larga (red, target detenido).

Upgrades de QuickEDD

• •Validar compatibilidad con la versión de IBM i del cliente.
• •Procedimiento controlado, idealmente coordinado con ventana.
• •Tener plan de rollback.