sábado, 20 de junio de 2009

¿El AS400 ha muerto?

Con el último cambio de nombre del AS400, que ha hecho IBM, parece que finalmente conseguirá su objetivo de hacerlo desaparecer por "mimemitación" con el entorno.

Repasemos:
  1. AS/400: AS quiere decir Application Server (¡¡que no estaba tan mal!!)
  2. AS/400: AS de Advanced Series.
  3. AS/400e
  4. eServer
  5. iSeries
  6. System i
  7. Power Systems
Pero realmente el ultimo cambio implica que ya no sabremos diferenciar, por el nombre, un sistema con sistema operativo AIX de otro con el i5/OS (antes llamado OS400), esto finalmente implica que desaparece virtualmente nuestro AS400 y se convierte en un mero "plugin" del nuevo hardware controlado por una consola HMC que no funciona en i5/OS.

Pros:


(espacio intencionadamente en blanco)



Contras:


(espacio intencionadamente en blanco)



Nota: Que cada cual lo rellene con sus opiniones, aunque realmente tardaremos unos años en ver el resultado de tanto "marear la perdiz".

sábado, 13 de junio de 2009

Entradas de direccionamiento

¿Para que sirven las entradas de direccionamiento?

En anteriores artículos he hecho referencia a las entradas de direccionamiento de un subsistema (Memoria para subsistema, Asignar prioridad automáticamente y Memoria para trabajos batch), en este artículo intentaré explicar como funcionan y para que las podemos utilizar.

Utilizaremos como ejemplo las entradas del subsistema QBATCH. Para verlas hemos de utilizar el mandato DSPSBSD SBSD(QBATCH) y seleccionaremos la opción 7. Routing entries:En este subsistema (de ejemplo) tenemos 4 entradas de direccionamiento y la secuencia en que se ejecutaran (Seq Nbr), las entradas hacen referencia a:
  • QIGC: Para trabajos que utilicen el sistema DBCS (Double-byte character set), si esta instalado.
  • QS36EVOKE: Para trabajos que utilizan el entorno compatible con IBM S/36.
  • QCMD38: Para trabajos que utilizan el entorno compatible con IBM S/38.
  • *ANY: Para el resto de trabajos del subsistema.
Para entender como el sistema asigna una clase al trabajo y los atributos de ejecución del mismo, deberíamos tener claro como el sistema operativo somete un trabajo y que parámetros utiliza, para ello nada mejor que leer el articulo Someter trabajos batch.

Enrevesado, no?, veamos ahora como se asigna la clase:
  1. El trabajo de control del subsistema QBATCH (WRKJOB JOB(QSYS/QBATCH) lee, de la cola/s de trabajos que tiene asignada, los trabajos que están pendientes por ejecutar.
  2. Recupera el valor del parámetro RTGDTA del trabajo, por omisión QCMDB.
  3. Ira comparando el valor RTGDTA del trabajo con el valor de CMPVAL de las entradas de direccionamiento, en el orden de la secuencia indicada en "Seq Nbr".
  4. Cuando encuentre una entrada de direccionamiento que sea igual, ejecutará el programa que se indica en la entrada de direccionamiento. Como el valor por omisión de RTGDTA es QCMDB, la entrada de direccionamiento a asignar es la 9999, que tiene el valor especial *ANY y por tanto llamará al programa QSYS/QCMD, pasando como parámetro el mandato indicado en el parámetro CMD del SBMJOB.
  5. En la entrada de direccionamiento puede definirse en que posición del parámetro RGTDTA, debe empezar a comparar (CMPVAL), con lo que se amplían las posibilidades de asignación.
  6. Entonces asignará, al trabajo, los valores de los atributos de ejecución indicados en la clase asignada a dicha entrada. Por omisión, en nuestro ejemplo, asignará los valores de la clase QSYS/QBATCH, o sea RUNPTY(50) y TIMESLICE(5000), para ver los valores de la clase podemos utilizar el mandato DSPCLS CLS(QSYS/QBATCH).
  7. También asignará el trabajo al pool de memoria donde se ejecutara, esto se indica en el parámetro POOLID de la entrada de direccionamiento, ver también Memoria para subsistema.
De esta forma el sistema asignará al trabajo los atributos de ejecución de la clase QBATCH a los trabajos que contengan cualquier cadena de caracteres en el campo RTGDTA que no sean igual a: QIGC, QS36EVOKE o QCMD38. Es obvio explicar que pasaría si contiene alguno de estos valores.

Nota: Después de lo visto habréis podido deducir que el interprete de mandatos del OS400 es el programa QSYS/QCMD, tiene similitud con el interprete de comandos de windows que es c:\windows\system32\cmd.exe; y del entorno S/38 es el QSYS/QCL.

Analicemos, ahora, las entradas de direccionamiento del subsistema QINTER:
Vemos algunas diferencias, pero creo que ya podéis deducir que:
  • QCMDI es para llamar al interprete de mandatos del OS400, pero con la clase QINTER, que asigna por omisión los atributos de ejecución QGPL/QINTER, o sea RUNPTY(20) y TIMESLICE(2000) para trabajos interactivos. Notar la diferencia entre los valores QCMDInteractivo y QCMDBatch. Es por esta entrada de direccionamiento por donde se arrancarán nuestras sesiones 5250.
  • 525XTEST esta es una entrada muy especial para ejecutar un programa de test de las pantallas 5250. Esto se conseguía pulsando una combinación de teclas al encender el terminal y aparecía una pantalla de test (programa QARDRIVE).
  • El resto de trabajos entrarán con *ANY, que por omisión utiliza la misma clase QINTER.
En este ultimo punto podríamos implementar un sencillo truco para evitar que usuarios "listillos" sometan trabajos batch por el subsistema QINTER, con la "sana" intención de que sus trabajos obtengan más prioridad en la ejecución y terminen antes, pero claro a costa de que consuman más recursos del sistema. Para ello lo único que deberíamos hacer, es cambiar la clase de la entrada de direccionamiento *ANY, del subsistema QINTER, para asignarle la clase QBATCH, en lugar de la clase QINTER:
CHGRTGE SBSD(QSYS/QINTER) SEQNBR(9999) CLS(QSYS/QBATCH)
De esta forma cuando realizan el SBMJOB, como el valor RTGDTA es QCMDB, se les asignara la prioridad de un trabajo batch en lugar de interactivo. Esto no lo soluciona todo, ya que no podremos evitar que consuman memoria del mismo pool que el asignado a los trabajos interactivos en el subsistema QINTER, habitualmente *INTERACT.

viernes, 5 de junio de 2009

Colas de trabajos

Cuando hemos de controlar la ejecución de los trabajos batch en el sistema, normalmente usamos los subsistemas, las colas de trabajo y las prioridades en la cola de trabajo (parámetro JOBPTY del CHGJOB).
Este articulo es para entender mejor como un subsistema trabaja con las colas de trabajo que tiene asignadas y como podemos crear colas de trabajo especificas para ciertas tareas. Para ello explicare algunos conceptos relacionados con las colas de trabajo, en los ejemplos nos basaremos en el sistema QBATCH (DSPSBSD SBSD(QBATCH) y opción 6).
  • El subsistema tiene un numero de trabajos máximo que puede ejecutar, se cambia con el mandato CHGSBSD SBSD(QBATCH) MAXJOBS(*NOMAX), en este ejemplo estamos diciendo al sistema, que puede ejecutar un numero ilimitado de trabajos en el subsistema, bueno el limite es el rendimiento del sistema, ya podríamos llegar a colapsarlo.
  • El subsistema tiene colas de trabajo asignadas y estas tienen un numero de secuencia, o sea el sistema primero mira si hay trabajos en la cola de trabajos de la secuencia 10, después de la 20, ..., hasta la 9999.
  • Cada cola de trabajos, asignada a un subsistema, tiene también un numero máximo de trabajos que puede ejecutar. El numero máximo de trabajos de una cola de trabajos se puede cambiar con el mandato CHGJOBQE.
  • Para complicarlo un poco más, también pueden definirse en cada cola de trabajo el numero de trabajos máximo por prioridad del trabajo, aunque por lo que he podido ver se usa poco.
  • Si el sistema encuentra un trabajo en la cola de trabajos, y no hay ejecutándose el numero máximo de trabajos activos de esa cola y el subsistema tiene menos trabajos que el máximo que tiene definido para el subsistema, entonces entraran tantos trabajos de esa cola hasta que no queden trabajos en la cola o hasta que el subsistema tenga el numero máximo de trabajos.
  • Una cola de trabajos puede estar definida en dos subsistemas diferentes, pero solo se asigna al primer subsistema que arranca.
  • Una cola puede no estar asignada a algún subsistema (o el subsistema no esta activo), en ese caso nunca entran trabajos de esa cola.
Ejemplo1:
Ejemplo1
  • En este ejemplo supongamos que el subsistema QBATCH puede ejecutar un numero ilimitado de trabajos (*NOMAX).
  • En este caso podríamos tener el numero máximo de trabajos ejecutándose de todas las colas porque 10+1+4 = 15.
  • Si en la cola QBATCH hay 17 trabajos solo se ejecutaran como máximo 10, aunque el subsistema no este ejecutando ningún trabajo del resto de colas.
Ejemplo2:
Ejemplo2Igual que en el Ejemplo1 pero con dos colas más (con *NOMAX) y el subsistema QBATCH puede ejecutar 50 trabajos al mismo tiempo como máximo:
  • Supongamos que se están ejecutando 3 trabajos de la cola QBATCH y llegan de golpe 160 trabajos a la cola QSRCTXT, de estos entraran 47 trabajos, ya que 3+47=50 es el numero máximo de trabajos activos en el subsistema, quedando el resto en cola.
  • Si en ese momento llega un trabajo por la cola QBATCH1X1, esté no podrá entrar hasta que finalice algún trabajo.
  • Si finaliza un trabajo que ha entrado por la cola QSRCTXT, entonces entraría el trabajo de la QBATCH1X1, porque tiene una secuencia mas baja que la cola QSRCTXT, cuando termine otro, si no hay ninguno en las colas de las secuencias inferiores a la QSRCTXT, irán entrando más trabajos a medida que finalicen.
  • Si mientras llega algún trabajo a la cola QBATCH pasaría antes que los de la QBATCH1X1, ya que su numero de secuencia es menor.
Recomendaciones:
  • Si queremos asignar a una cola un numero de trabajos *NOMAX, mi recomendación es ponerla al final, y deberíamos solo enviar a esa cola trabajos de ejecución muy rápida, para no colapsar la cola ni el sistema.
  • Prefiero asignar al subsistema un numero máximo de trabajos ilimitado (*NOMAX), pero debemos vigilar que las colas *NOMAX no nos puedan colapsar el sistema, en ese caso no nos quedara más remedio que asignar un numero máximo de trabajos al subsistema que nos pueda soportar el sistema (CHGSBSD), habitualmente empezaríamos por asignar la suma del numero máximo de trabajos de cada cola más un numero n de trabajos, si vemos que es demasiado para el sistema, ir reduciendo el numero máximo de trabajos activos.