jueves 12 de noviembre de 2009

Planificador de trabajos

El objeto de planificación de trabajos contiene entradas que configuran una planificación de trabajos (WRKJOBSCDE). Puede planificar trabajos añadiendo una entrada de planificación de trabajos al objeto de planificación de trabajos (ADDJOBSCDE). 
Para que funcione el planificador de trabajos debe estar activo el trabajo QSYSSCD en el subsistema QCTL (o QBASE) y se arranca automáticamente después del IPL.


El objeto de planificación de trabajos, QDFTJOBSCD, está en la biblioteca QUSRSYS y tiene un tipo de objeto *JOBSCD. No puede crear, suprimir, redenominar ni duplicar el objeto de planificación de trabajos, y no puede moverlo a otra biblioteca. Este objeto de planificación de trabajos se suministra con la autorización de uso público *CHANGE. Esta es la mínima autorización necesaria para añadir, cambiar, retener, liberar y eliminar entradas de planificación de trabajos.

Cómo guardar o restaurar objetos de planificación de trabajos
El objeto de planificación de trabajos puede salvarse con los mandatos Salvar Biblioteca (SAVLIB), Salvar Objeto (SAVOBJ) o Salvar Objetos Cambiados (SAVCHGOBJ), y después restaurarse con los mandatos Restaurar Biblioteca (RSTLIB) o Restaurar Objeto (RSTOBJ). La restauración del objeto de planificación de trabajos hace que la próxima fecha de sometimiento se actualice para cada entrada. Puede restaurar el objeto de planificación de trabajos al sistema desde el que se salvó o a un sistema distinto, pero no puede restaurarlo a una biblioteca que no sea QUSRSYS. Si restaura el objeto de planificación de trabajos a un sistema diferente, el registro histórico de sometimiento de trabajos se borra en cada entrada.


Información extraída del manual Gestión de Trabajos, capitulo Planificación de trabajos (pag.267)

miércoles 4 de noviembre de 2009

IBM i Manifest

Por el boletín mensual de Common Europe España del mes de noviembre me he enterado de la iniciativa de 71 partners de IBM en Japón de publicar un anuncio en los periódicos pidiendo que IBM de un apoyo claro a la plataforma system i (o sea el AS400), extraído del comunicado podemos leer:

"Aprovechando la oportunidad del 20º aniversario de IBM i hemos creado el Manifiesto i de IBM para solicitar a los usuarios volver a reconocer el valor y los logros de IBM i. Les pedimos que renueven su firme confianza y la creencia de que IBM i es la mejor infraestructura disponible para apoyar la innovación gerencial y operativo."

Help400 nos cuenta en varios artículos en su blog como esta evolucionando esta iniciativa:
Ahora ya podemos adherirnos a esta iniciativa en la web de IBM i Manifest de Europa.

Esperemos que IBM oiga nuestras "plegarias" que, aunque no tienen nada que ver con el cambio climático, si  tienen que ver con el cambio en los escenarios que se nos avecinan (cloud computing) y que me recuerdan a que es el enésimo vaivén hacia una estructura informática de "cliente ligero" y sistema central. ¿No os recuerda a pantalla verde + AS400?, este binomio viene mejorado en cada cambio que se ha hecho en la historia de la informática.

Pensar un poco en esta evolución: Pantalla verde + Entorno de ventanas + Navegador + Navegador que ejecuta aplicaciones remotas = Computación en nube.

miércoles 28 de octubre de 2009

Cancelar un rollback

En un artículo anterior se explicaba como averiguar el porcentaje rollback realizado por un trabajo.

Pero en muy contadas excepciones nos puede interesar cancelar un rollback, cosa realmente peligrosa sino conocemos, pero que muy bien, lo que esta haciendo el trabajo en la base de datos.

Por norma un rollback NUNCA se debe cancelar, debemos esperar que termine.

No se os ocurra realizar un IPL para forzar la finalización de un rollback, ya que el sistema lo terminara durante el IPL, con lo os quedareis sin sistema durante un tiempo indeterminado.

Dicho lo anterior, unos ejemplos de casos en que nos puede interesar cancelar el rollback:

  • Supongamos que lanzamos un programa que crea una tabla temporal, abre un ciclo de commit y empieza a insertar registros en esta tabla, el programa se mete en un bucle y continua insertando registros, cuando lleva unos cuantos millones de insert nos damos cuenta y cancelamos el trabajo. Entonces empieza a realizar el rollback eliminando millones de registros insertados. En este caso si pudiéramos cancelar el rollback y eliminar la tabla temporal seguro que terminaría más rápido que esperar el final del rollback.
  • Un programa se mete en un bucle actualizando miles de veces el mismo registro, es importante verificarlo con las entradas del diario. Al cancelarlo el rollback empezara a realizar miles de update en sentido inverso hasta dejarlo en el valor original. También en este caso si supiéramos el valor del registro al inicio del bucle, podríamos cancelar el rollback y después realizar un update manual del registro a su valor inicial; con esto ahorraríamos seguramente mucho tiempo.
  • Un trabajo realiza cambios en una o mas tablas, utilizando un solo ciclo de commit, cuando lleva unos millones de cambios cancelamos el trabajo. Si tenemos la absoluta seguridad que tenemos una copia de las tablas antes de empezar el proceso y que ningún otro trabajo ha realizado cambios en las mismas, podríamos valorar la posibilidad de cancelar el rollback y restaurar las tablas.
A partir de la V5R3 existe un procedimiento para cancelar un rollback, es el siguiente:
  1. Definir la estrategia para reparar la base de datos: Asegurarse de que tenemos los datos necesarios, verificar que tenemos las copias de seguridad, son accesibles  y contienen las tablas implicadas (recordar los ejemplos).
  2. Conectarse con usuario con permisos *SECOFR.
  3. Lanzar el ENDJOB, con OPTION(*IMMED), del trabajo que empezara a realizar el rollback.
  4. Averiguar el ciclo de compromiso del rollback que vamos a cancelar:
  5. WRKCMTDFN JOB(012345/MYUSER/MYJOB)
  6. Pulsar F23 para ver más opciones y  aparecerá la opción 20=End rollback.
  7. Introducir la opción 20 en el ciclo de compromiso a cancelar y pulsar Intro.
  8. Nos aparecerá una pantalla (ver imagen) que nos advierte del peligro de cancelar el rollback, ya que dejaremos inconsistente la base de datos y eso podría afectar a otros trabajos.
  9. Si estamos seguros pulsaremos Intro. Sino podemos pulsar F12 para volver atras.
  10. A partir de ese momento el trabajo empezará a liberar los registros bloqueados por el commit, cancelando el rollback. Esto puede tardar algún tiempo dependiendo de la cantidad de registros.
  11. Una vez a finalizado el rollback y el trabajo, podremos reparar la base de datos, según la estrategia decidida en el primer paso. En los ejemplos: Eliminar la tabla temporal, Actualizar manualmente el registro implicado, Restaurar la/s tabla/s implicadas.


ADVERTENCIA FINAL: Es responsabilidad vuestra el utilizar, o no, este procedimiento. Como comprenderéis podéis causar un daño irreversible a la base de datos, si no estáis absolutamente seguros de lo que vais a hacer. En caso de la más mínima duda os recomiendo esperar al final del rollback.

Más información en el documento: Ending A Rollback - V530 and Later Releases