Marti, De hecho que sirve y bastante tu explicación, ahora mismo estoy probando con un aplicativo que lo tengo en la mira.
Muchas gracias, hv De: Marti Riera [mailto:[EMAIL PROTECTED] Enviado el: Jueves, 19 de Junio de 2008 12:47 p.m. Para: forum.help400 Asunto: Re: Registros no comprometidos 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
