Gestionar receptores de diario

Estrategias de como gestionar receptores de diario

El tema es complicado, ya que depende mucho de los requerimientos de la aplicación, de seguridad, de replicación, etc..., para poder aplicar una estrategia de gestión de los receptores de diario. Intentare explicar los casos que se me ocurren en nuestra estrategia, para que sirvan de ejemplo.

Dejo aparte la gestión de los receptores del propio sistema, que habitualmente se autogestionan en tiempo de IPL, si no vamos a realizar IPL en muchos tiempo puede que tengamos también que incluirlos en nuestra estrategia, no sin antes verificar y consultar con IBM, si fuese necesario, que impacto puede tener en el sistema.

• Caso1: En los sistemas de producción los receptores de diario están gestionados por MIMIX (u otra herramienta de replicación) y se mantienen en linea unos días y después se eliminan automáticamente por el software de replicación y si se han salvado previamente a cinta.
  
• Caso2: En los sistemas de producción que no tienen MIMIX, los receptores se van salvando a cinta y eliminando periódicamente (según el sistema).
• Caso3: En los sistemas de desarrollo (que nunca tienen MIMIX) los receptores los elimina automáticamente el sistema, cuando ya no hay ningún ciclo de compromiso pendiente y aunque no estén salvados a cinta, excepto los de auditoria del sistema (QAUDJRN) que se eliminan una vez salvados a cinta.
• Caso4: Poner la vuestra...
  

Formas de detectar si hay ciclos largos de commit abiertos:

• Caso1: MIMIX detecta en que ciclo de commit estamos "encallados" y que nos retrasa la hora de aplicación de MIMIX, con la utilidad DSPJOBSEC averiguamos rápidamente que trabajo tiene el ciclo de commit abierto y podemos actuar en consecuencia.
• Caso2: Podemos deducir que con el movimiento normal podemos generar, en una semana (p.e.) 10 receptores de diario, si detectamos que hay más receptores de lo habitual es posible que hayan ciclos de commit abiertos.
• Caso3: Este es el más fácil, como mucho solo puede haber un receptor conectado al diario, ya que el resto el sistema y los va eliminando automáticamente, por tanto si vemos que hay más, es (casi) seguro que algún trabajo tiene un ciclo de commit abierto.
  

Causas de los ciclos de commit largos:

• Programas que no hacen commit (mala programación), o se meten en un bucle.
• Sentencias SQL. o QMQuery, sin ciclos de compromiso de larga ejecución; deberían evitarse o analizar si es posible lanzarlos con WITH NC (sin commit) aunque eso a veces no es posible si queremos tener consistencia en la base de datos.
• A veces detectamos algún CPYF que tiene ciclos de commit (no recuerdo bien como fue).
• Programadores que están debugando, abren un ciclo de commit, les casca el programa y van a por otra cosa, o hacen petición de sistema, o se van a comer, y el ciclo de commit se queda abierto hasta que no hacen signoff.
• Otras ?? (que cada uno añada las suyas)
  

Como detectar "automáticamente" si hay ciclos de commit abiertos:

• Estuve investigando usar el mandato WRKCMTDFN (a partir V5R4) pero de momento no puedo diferenciar los ciclos de commit abiertos con registros pendientes de los que no, aunque si se ve por pantalla con F11, a lo mejor dándole al "coco" mas tiempo....
  
• De momento se nos ocurrió: Contar el numero de receptores de diario de cada diario.
• DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*JRNRCV) OUTPUT(*OUTFILE) OUTFILE(QTEMP/JRNRCV) OUTMBR(*FIRST *REPLACE)
• Doy por supuesto que en una biblioteca no hay mas de un diario, que podría ser.
• Deberemos omitir el diario de auditoria y los de sistema, habitualmente empiezan por Q* y en bibliotecas que también empiezan por Q*.
• Otra estrategia seria hacer:
• DSPOBJD OBJ(Mylib/Myjrn1) OBJTYPE(*JRNRCV) OUTPUT(*OUTFILE) OUTFILE(QTEMP/JRNRCV) OUTMBR(*FIRST *REPLACE)
• DSPOBJD OBJ(Mylib/Myjrn2) OBJTYPE(*JRNRCV) OUTPUT(*OUTFILE) OUTFILE(QTEMP/JRNRCV) OUTMBR(*FIRST *ADD)
• DSPOBJD OBJ(MylibX/MyjrnX) OBJTYPE(*JRNRCV) OUTPUT(*OUTFILE) OUTFILE(QTEMP/JRNRCV) OUTMBR(*FIRST *ADD)
• Después contamos los receptores de cada diario, o lo hacemos por cada biblioteca cada vez, en fin múltiples posibilidades según se adapte a nuestra estrategia.
• Una vez sabemos que diario tiene un numero "anormal" de receptores, dejo para cada uno lo que es anormal, seguimos con:

Como detectar "automáticamente" que trabajo tiene un ciclo de commit abierto:

• Volcamos el contenido del diario, de las entradas relacionadas con los ciclos de commit, a fichero (esto puede tardar):
• DSPJRN JRN(Mylib/MyJrn) RCVRNG(*CURCHAIN) JRNCDE((C)) OUTPUT(*OUTFILE) OUTFILE(QTEMP/DSPJRN)
• Después ejecutamos la sentencia SQL siguiente (esto es la "madre del cordero" ¡¡ gracias Inma!!):

WITH aa AS (SELECT * FROM dspjrn WHERE joentt = 'SC'), bb AS
(SELECT * FROM dspjrn WHERE joentt <> 'SC') SELECT aa.joseqn,
aa.jodate, aa.jotime, aa.jonbr, aa.jouser, aa.jojob, aa.joccid from
aa LEFT EXCEPTION JOIN bb ON aa.joccid = bb.joccid

• Esta SELECT nos devolverá la lista de trabajos con un ciclo de commit abierto, y la hora de del ciclo de commit, ya solo nos queda ir al trabajo a ver que pasa.

Espero que, al menos, os sirva como base para detectar esos trabajos que nos pueden fastidiar, ya que normalmente los ciclos de commit largos le sientan como una "patada" al OS/400, y ya no digo si hay que hacer un rollback.

Por poner un ejemplo: Un programador un viernes y en un sistema de desarrollo (que estan 24x7) hace un call a un programa que se mete en un bucle, con un ciclo de commit abierto, haciendo updates del mismo registro como un "poseso", se cae su sesión y como no puede volver a entrar, se marcha de fin de semana. El lunes se descubre que hay una sesión en RUN todo el tiempo, se hace un ENDJOB *IMMED, con millones de cambios comprometidos en el mismo ciclo de commit. El trabajo tarda como 2 horas en empezar a hacer el rollback y 2 días en terminarlo. A todo esto la ocupación en disco ha ido subiendo, porque el sistema no elimina los receptores de diario desconectados, y salvados, ya que hay un ciclo de commit con transacciones pendientes. En fin que tenemos maquinas potentes, que si no andamos con cuidado podemos cargarnos el sistema.