Hola Hector,
He estado mirando como podía hacerlo de forma fácil, pero la verdad es que
no se me ocurre. El tema es complicado, ya que depende mucho de como
gestionas los receptores de diario; intento explicar los casos que se me
ocurren, para que sirva de ejemplo.
*Estrategias para gestionar receptores de diario:*
- *Caso1: *En los sistemas de producción los receptores de diario están
gestionados por MIMIX y se mantienen en linea un par días y después se
eliminan si se han salvado previamente a cinta.
- *Caso2:* En los sistemas 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 se elimina automáticamente por el sistema cuando no hay ningún
ciclo de compromiso pendiente y aunque no estén salvados a cinta (excepto
los de auditoría 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
(que ya pase ayer) 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
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 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.
Ya ves que el "demonio" depende mucho de como gestionas tus receptores de
diario. En nuestro caso para complicarlo aun más tenemos decenas de
receptores de diario, con lo cual aun se complica un poco más, pero te voy a
dar unos ejemplos, para que cada cual se construya el suyo, o uno parecido:
*Causas de los ciclos de commit largos:*
- Programas que no hacen commit (mala programacion), 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 hemos detectado algun CPYF que tiene ciclos de commit (no
recuerdo bien como fue).
- Programadores que están debugando abren un ciclo de commit, les casca y
van a por otra cosa, o hacen petición de sistema 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 (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 solo 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 una diario, que
podría ser.
- Deberemos omitir el diario de auditoría 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 journal por diario, o lo hacemos por 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:
- DSPJRN JRN(Mylib/MyJrn) RCVRNG(*CURCHAIN) JRNCDE((C))
OUTPUT(*OUTFILE) OUTFILE(QTEMP/DSPJRN)
- Esto puede tardar, 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 revolverá 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.
En fin otro rollo que os he metido; 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: Una 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.
En fin no es viernes, pero casi me lo parece.
Saludos
2008/6/18 Hector Vera G. <[EMAIL PROTECTED]>:
> Marti,
>
> Eso también me ocurre cuando lanzó a fin de mes procesos de cierre y nos
> hechamos a buscar quien no esta liberando los recursos (commit). Si no es
> mucha molestia te agradecere compartas tu "demonio" con nosotros.
>
> Gracias,
>
> Hector
>
>
>
> *De:* Marti Riera [mailto:[EMAIL PROTECTED]
> *Enviado el:* Miércoles, 18 de Junio de 2008 02:08 a.m.
> *Para:* forum.help400
> *Asunto:* Re: Registros no comprometidos
>
>
>
> Hola,
>
>
> Nosotros nos tuvimos que hacer un "demonio" que se recorre todos los
> diarios (de una lista), cuando encuentra uno que tiene *n* receptores
> asociados, lanza otro trabajo que averigua los trabajos que tienen ciclos de
> commit abiertos desde hace mas de *x* minutos, si es así ,nos envía un
> mensaje para que averigüemos que hace ese trabajo.
>
> Esto nos sucede a menudo y es causa de grandes incrementos en disco y
> rollbacks eternos, con peligro de afectar al sistema y al resto de
> aplicaciones, es por eso que lo controlamos continuamente. Causas
> habituales: mala programación, normalmente porque los entornos de pruebas no
> tienen un conjunto de datos tan grande como producción y no se suelen
> detectar estos problemas.
>
> Saludos.
>
>
> 2008/6/18 Pedro Pinedo <[EMAIL PROTECTED]>:
>
>
> Gracias, lo que necesito es al reves, sabiendo el fichero, saber que
> trabajo esta pendiente de commit, (suelo tener 700, no es cuestion de mirar
> uno por uno)
>
>
> Pedro Pinedo Hernandez: Analista-Programador
> Grupo Amcor Flexibles Hispania S.L.
> Departamento de Informática / IT Department
> tfno.:+34 941 28 60 90 - 941 03 01 39
> fax: +34 941 03 01 39
> Avd. Burgos 67-95
> 26006 Logroño Spain
> [EMAIL PROTECTED]
> (quitar nospam del dominio, para enviar)
>
> ______________________________________________________
>
> AMCOR FLEXIBLES - LEADING THROUGH INNOVATION
> ______________________________________________________
>
> CAUTION - This message may contain privileged and confidential information
> intended only for the use of the addressee named above. If you are not the
> intended recipient of this message you are hereby notified that any use,
> dissemination, distribution or reproduction of this message is prohibited.
> If you have received this message in error please notify AMCOR FLEXIBLES
> immediately. Any views expressed in this message are those of the individual
> sender and may not necessarily reflect the views of AMCOR FLEXIBLES.
>
>
> __________________________________________________
> Forum.HELP400 es un servicio m&#225;s de NEWS/400.
> &#169; Publicaciones Help400, S.L. - Todos los derechos reservados
> http://www.help400.es
> _____________________________________________________
>
> Para darte de baja visita la siguente URL:
> http://listas.combios.es/mailman/listinfo/forum.help400
>
>
>
>
> --
> Martí Riera
>
> __________________________________________________
> Forum.HELP400 es un servicio m&#225;s de NEWS/400.
> &#169; Publicaciones Help400, S.L. - Todos los derechos reservados
> http://www.help400.es
> _____________________________________________________
>
> Para darte de baja visita la siguente URL:
> http://listas.combios.es/mailman/listinfo/forum.help400
>
--
Martí Riera
__________________________________________________
Forum.HELP400 es un servicio m&#225;s de NEWS/400.
&#169; Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
