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)

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:

• Manifiesto por el IBM i, un ejemplo a seguir 
  
• La iniciativa "IBM i Manifest" sigue ganando adeptos
• i + POWER: The Spanish iManifest

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.

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

Cambio hora verano/invierno

La madrugada del ultimo domingo de Octubre los sistemas deben cambiar la hora al horario de invierno, o sea a las 3:00 se retrasara la hora a las 2:00 horas.

Actualmente, a partir de la V5R4, podemos configurar el sistema para que automáticamente realize el cambio de hora sin nuestra intervención, para ello debéis seguir las indicaciones del articulo:

Sincronizar la hora del AS400

Pero si tenemos un sistema con una versión anterior del OS400, podemos utilizar mi utilidad SUMWIN para realizar el cambio de hora automáticamente.

La estrategia para realizar el cambio de hora es añadir un trabajo automático al planificador de tareas el siguiente mandato (con usuario QSECOFR):

ADDJOBSCDE JOB(SUMWIN) CMD(CALL PGM(SUMWIN)) FRQ(*MONTHLY) SCDDATE(*NONE) SCDDAY(*SUN) SCDTIME(020000) RELDAYMON(*LAST) JOBQ(QSYSNOMAX) TEXT('Cambio automático a horario de verano-invierno')

Con esto conseguimos que cada ultimo domingo de mes se lance el trabajo y solo cambiara la hora cuando sea:

• El ultimo domingo del mes de Marzo a las 02:00:00 sumara una hora o
• El ultimo domingo del mes de Octubre esperara a las 03:01:00 y restara una hora,
• En ambos casos envía un mensaje al operador.
• El resto de meses no hará nada.

Podéis bajaros el código en este enlace.

Cambios en variable de sistema QLMTDEVSSN (V6R1)

La nueva versión del i5/OS V6R1, incluye un muy esperado nuevo valor para la variable del sistema QLMTDEVSSN (Limit device session).

Hasta la versión V5R4 podíamos tener los siguientes valores:

0=Do not limit = El usuario puede abrir tantas sesiones interactivas como quiera.

1=Limit = El usuario solo puede abrir una sesion interactiva.

Con la V6R1 se modifican los valores de esta variable como sigue:

0=Do not limit = El usuario puede abrir tantas sesiones interactivas como quiera.

1-9=Maximum device sessions = Este valor nos indica cuantas sesiones podrá abrir como máximo un usuario 1,2,.. y hasta 9 sesiones interactivas concurrentes.

Para ver que valor tiene el sistema: 
DSPSYSVAL SYSVAL(QLMTDEVSSN)

Por defecto es preferible, sobretodo en los sistemas de Producción, que este valor de sistema este a 1, así todos los usuarios, que en el parámetro LMTDEVSSN de su perfil de usuario tengan el valor *SYSVAL, solo podrán abrir una sesión interactiva por defecto. A los Operadores y/o Administradores podemos darles más sesiones cambiando este valor en su perfil de usuario.

Pero puede ser interesante tener el valor de sistema a 2 o 3 en los sistemas de Desarrollo, para que al crear un nuevo programador, y sin tener que cambiar su perfil de usuario, ya pueda tener más de una sesión interactiva, cosa muy solicitada y recomendable para poder realizar pruebas, del código que están creando y probando, mas cómodamente.