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.

Porcentaje rollback realizado

Procedimiento para ver el porcentaje de Rollback que ya ha realizado un trabajo:

• Ejecutar mandato DSPJOB JOB(num_job/user_job/name_job)
• Seleccionar opcion "16. Display commitment control status, if active"
• Opcion "5=Display"
• Pulsar "F6=Display resource status"
• Pulsar AvPag.
• Seleccionar opcion "1=Select" en el recurso "Journal"
• Finalmente pulsar "F11=Display rollback status"

Restaurar archivos QHST

Como restaurar los archivos históricos desde una cinta de SAVSYS, para ello seguir el siguiente procedimiento:

1. Cargar la cinta donde realizamos el SavSys
2. DSPTAP DEV(TAP01) DATA(*SAVRST)
3. Ir pulsando Intro hasta encontrar la secuencia donde están los archivos QHST.
4. Anotar numero secuencia y ID etiqueta archivo (p.e. Q5722SS1510310090)
5. Ejecutar RSTOBJ OBJ(QHST*) SAVLIB(QSYS) DEV(TAP01) OBJTYPE(*FILE) VOL(Q5722SS1510310090) SEQNBR(33)

Mejorar teclado emulacion 5250

El IBM Client Access incluye el emulador de pantalla verde 5250 Personal Communications.

La configuración por omisión no incluye ciertas funciones que los usuarios de los sistemas operativos de ventanas encontramos a faltar, como son las teclas Inicio para ir al Inicio del Campo, Fin para ir al Fin del Campo, Ctrl+C para Copiar un texto seleccionado o Ctrl+V para Pegar un texto; Ctrl+X no tiene sentido en una emulación 5250.


Como hacer esta personalización de teclado de la emulación, pues seguir los siguientes pasos:

1. Bajaros el archivo as400_mejorado.kmp y lo guardais en la carpeta C:\Program Files\ibm\Client Access\Emulator\Private o donde os parezca mejor.
2. Desde la emulación de pantalla del Personal Communications, pulsais el icono o Edit, Preferences, Keyboard, Customize.
3. Despues File, Open y seleccionar el archivo de configuración de teclado que os habeis bajado.
4. A continuación salvar la nueva configuración.

A partir de ese momento ya podreis utilizar el teclado de la emulación de forma mas parecida a la que utilizais con un sistema operativo grafico de ventanas.


Esta configuración de teclado también convierte la tecla grande de Intro, como un Intro y no como Salida de Campo, esta la muevo a la tecla Ctrl de la derecha.

La clave de las claves

La elección de un buena contraseña, la palabra clave que franquea el acceso a un ordenador, es esencial para salvaguardar la seguridad de los datos que contiene. Los expertos recomiendan las siguientes reglas básicas:

1. Una contraseña ha de ser sencilla. Desde luego, la clave TMXKQGSW resulta bastante segura frente a hackers que lo intentan al azar, pero es muy difícil de recordar.
2. Una contraseña no debe tener significado. Las palabras con significado son las más fáciles de reventar. Esto no excluye que sean sencillas de memorizar. Ejemplos: ZAZAMELI, PERPOLAS, RATOGARU.
3. Una contraseña hay que memorizarla, no apuntarla. Quien no se fíe demasiado de su memoria a largo plazo, puede apuntar su palabra clave, pero nunca de manera que un extraño pueda reconocerla como tal. Así, nunca se la ha de escribir en el listín telefónico bajo CLAVE, SECRETO u ORDENADOR. Es mejor garabatearla en la agenda junto al recordatorio del cumpleaños de la abuela. En ningún caso se debe dejar la nota escrita cerca del ordenador, bajo el teléfono o pinchada en el panel de corcho.
4. De vez en cuando conviene cambiar la contraseña. Por si acaso alguien no autorizado ya lo conoce pero todavía no se ha decidido a usarlo. Tampoco es preciso cambiarlo muy a menudo, podría causarnos molestas equivocaciones.
5. Una contraseña se teclea en privado. Al introducir la clave antes de comenzar una sesión de trabajo, hay que asegurarse de que nadie mire por encima del hombro. Las personas de confianza hacen honor a su nombre respetando la intimidad del propietario de la clave.
6. Ciertas palabras nunca han de servir de contraseña:

• Nombres propios y apellidos.
• Apodos. El propio, jamás, pero tampoco el del perro o el gato.
• Palabras informáticas, como TEST, SYSTEM, CHECK, BYTE...
• Fechas de cumpleaños.
• Cadenas con método: ABCDEFGH, A1B2C3, QWERTY...
• Palabras de moda: CHUNGO, GUAI, SUPER, TOTAL...
• Nombres de la mitología, la literatura o ciencia-ficción: Zeus, Quijote, Spock, Frodo...
• La palabra clave por antonomasia: (ábrete) SESAMO.
  

Articulo extraído de la revista "Muy Interesante", noviembre 1.989