Duración de un RCLSTG

Como averiguar la duración del ultimo proceso de Reclaim Storage (RCLSTG) realizado en el sistema, para ello ejecutar el mandato:
DSPDTAARA DTAARA(QUSRSYS/QRCLSTG)

Tal como se ve en la imagen el ultimo RCLSTG se ejecuto desde las 05:45:15h hasta las 09:51:46 del 01/06/2008, por tanto el proceso duro 4h 6min. 31seg.

En el histórico del sistema se graba el mensaje CPC8208 "Proceso de RCLSTG terminado" que nos informa de la cantidad de objetos procesados y suprimidos.

Para imprimir el histórico del sistema con los mensajes de como ha ido:

DSPLOG PERIOD((hora_inicio fecha_inicio) (hora_fin fecha_fin)) OUTPUT(*PRTSECLVL) MSGID(CPC8208 CPF3120 CPC3308 CPF8240 CPF8262 CPF8260 CPFA914 CPI8202 CPI8A10 CPC8A21 CPC8A22)

Para ver el contenido de la biblioteca QRCL , donde van a parar los objetos recuperados por el RCLSTG, ejecuta el mandato:

DSPLIB LIB(QRCL)

Esto es conveniente porque se puede haber recuperado algún objeto de tamaño considerable y que seguramente se debería eliminar.

De paso recordar que se debería pasar un RCLSTG periódicamente o, cuando ha habido una caída del sistema, y es casi obligatorio pasarlo antes de la instalación de una nueva release del sistema operativo.

También tener en cuenta que a partir de la V5R4 (algunos antes) tenemos algunos mandatos para reclamar cosas sin tener el sistema restringido:

• RCLDBXREF Reclaim DB Cross-Reference
• RCLDLO Reclaim Document Lib Object
• RCLLIB Reclaim Library
• RCLLNK Reclaim Object Links
• RCLOBJOWN Reclaim Objects by Owner
• RCLSPLSTG Reclaim Spool Storage
• RCLSTG Reclaim Storage

Cuenta iSeries gratuita

Como no siempre disponemos de un sistema AS400, cuantas veces nos hemos quedado con las ganas de probar algo en un sistema que no fuera el nuestro, o cuando no estamos en nuestro trabajo, o simplemente por aprender cosas nuevas.

Pues bien existe la web de Innovative Systems que nos da esa posibilidad

Solo hemos de registrarnos y esperar que nos envíen el usuario y la contraseña para acceder a un sistema AS400 remoto a través de Internet.

Espero que os sirva de ayuda :o)

Nefarious Masqueraders

Un articulo que llamo mi atención, hace tiempo, es el titulado "Nefarious Masqueraders" publicado en la web de The AS/400 School.

En él, se nos introduce en las técnicas para introducirse en un AS/400 y que nos puede servir, como administradores de sistemas, para ser conscientes de las vulnerabilidades del sistema y, de esta forma, poder tomar medidas para proteger mejor nuestros sistemas.

Traducción online del articulo

Lógicos en diferente biblioteca

Una manera rápida de como averiguar qué archivos lógicos no están en la misma biblioteca que sus archivos físicos, es mediante la siguiente instrucción SQL, que accede al fichero QSYS/QADBFDEP :

SELECT DbFLib, DbFFil, DbFLDp, DbFFDp
FROM Qsys/QADbFDep
WHERE DbFLib <> DbFLDp
ORDER BY DbFLib, DbFFil, DbFLDp, DbFFDp

Una de las razones para controlar este tipo de situación es que, en caso de restauración de las bibliotecas, debe hacerse en el orden correcto, ya que sino podemos dejar de restaurar algún archivo lógico, y nos obligaría a realizar una segunda restauración con el parámetro *NEW.
Esto también se aplica a archivos con restricciones, aunque en este caso es recomendable no tener archivos dependientes en diferentes bibliotecas y evitemos, siempre que podamos, estas situaciones.

Por ejemplo, si restauramos desde las copias de seguridad, realizadas con *ALLUSR, las bibliotecas están salvadas en la cinta en orden alfabético, pero el archivo LIB1/INDEX1 no se restaurara, porque no encuentra el archivo físico FILE1, del que depende, ya que esta en la biblioteca LIB2 que aun no se ha restaurado.

Library File Type
LIB1 INDEX1 LF
LIB2 FILE1 PF

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.