En la anterior entrega hemos visto como hemos creado un workload sencillo asociado a una service class de tipo discrecional, de forma que todo trabajo BATCH que no tenga asociado otra service class, la tomará por defecto. En esta receta, vamos a crear un Workload al que asociaremos una service class del tipo TSO, de forma que daremos prioridad en función del tiempo TSO de cada usuario.
Que pasa con los usuarios de TSO?
No os ha pasado alguna vez que un usuario TSO al realizar una búsqueda de catálogo o hace una call que implica un programa que consume mucha CPU, deja al resto de usuarios de TSO en X SYSTEM? Y todo por ese usuario descuidado que no sabía muy bien lo que implicaba el Intro de su operación. También ocurre que el resto de usuarios TSO, la interacción usuario-pantalla y tiempo de respuesta no excede los 100 milisegundos, sobre todo si son cambios de pantalla, consultas rápidas, sumisión de JCL, etc. Pues bien, vamos a crear un Workload para TSO asociada a una service class que en función del tiempo de CPU consumido, vaya quitándole prioridad paulatinamente con el fin de no copar todos los recursos y dejarle trabajar al resto de gente.
Creación de una Service Class TSO
Para crear una Service Class TSO, hemos de tener creado primero el Workload TSO, workload que creamos en el primer artículo, junto al de STC.
Por tanto, desde el menú inicial de WLM, opción 4. Service Classes, iremos la pantalla donde crearemos una nueva Service class llamada TSOWLM con una serie de periodos dependientes del tiempo de CPU y tiempo transcurrido. Un ejemplo de esto, podría ser los siguientes periodos:
Periodo 1: 2000 ciclos de CPU de duración, Importancia 2 (Alta prioridad), 90% de CPU asignada los primeros 250 milisegundos. Es decir, que el primer periodo le daremos un 90% de prioridad de CPU durante los 250 primeros milisegundos o 2000 ciclos, lo que acabe antes con una prioridad alta.
Periodo 2: 5000 ciclos de duración, Importancia 3 (Media), 50% de CPU asignada los 2 segundos y 250 milisegundos siguientes. Es decir, si ya se han consumido los primeros 250 milisegundos del primer periodo, pasamos al segundo y tenemos 2 segundos y medio de trabajo con menor prioridad y con menor asignación de CPU, ya que se considera un trabajo no tan conversacional como los de costumbre.
Periodo 3: 25000 ciclos de duración, con Importancia 4 (baja), y objetivo (goal) de velocidad de ejecución del 60%. O dicho de otro modo, si pasamos a este periodo, dejaremos que los 25000 ciclos se consuman en baja prioridad con una velocidad de ejecución de 60 (que no es el consumo de CPU, sino velocidad de ejecución calculada en función de los recursos de la máquina).
Periodo 4: Importancia 5 (muy baja prioridad), en Discretionary. Es decir, que si a pesar de eso, el proceso del usuario no ha terminado, pasa a discrecional para no afectar al resto de la máquina y terminará cuando termine (o el usuario cancele por cansancio).
Este sistema evita monopolización de la máquina por cualquier usuario, y dado que el 95% de las interacciones de pantalla en TSO se producen antes de los 250 milisegundos, el usuario tendrá alta prioridad siempre, por lo que tendrá un buen tiempo de respuesta.
Pues para poner esto en practica, dentro de la pantalla de 4. Service Classes, realizaremos los siguientes pasos:
1.- En Service Class Name, pondremos TSOWLM
2.- En Workload Name, pondremos TSO (eso relacionará el workload TSO con la service class).
3.- En Action, teclearemos I para insertar un periodo. Seleccionaremos 2. Response time with percentile, en Percentile pondremos 90, en seconds pondremos 0.250, Importance 2 y 2000 en Duration.
Fig. 1: Objetivo por tiempo de respuesta en percentil
4.- Si volvemos a pulsar sobre I, añadiremos el segundo periodo, y se rellena igual que el primero, salvo por el percentil que esta vez será de 50% y el tiempo, de 2.250, así como 5000 de duración.
5.- Si volvemos a pulsar sobre I, añadiremos el tercer periodo, y esta vez cambiaremos el tipo de objetivo y seleccionaremos 3. Execution velocity, y añadiremos 60% de porcentaje durante una duración de 25000, tal y como muestra la siguiente figura:
Fig. 2: Objetico de velocidad de ejecución
6.- Y por último, añadiremos el cuarto periodo, que es el discrecional, que simplemente, es buscar como objetivo el 4. Discretionary. Al final, debe quedar una pantalla como la siguiente:
Fig. 3: Service Class TSOWLM al completo.
Instalación y Activación de la nueva política WLM
Para poner en marcha la política, desde el menú principal, nos iremos al menu superior, Utilities, y de allí a 1. Install Definition, nos pedirá reescribir el fichero COUPLE de WLM, lo hacemos, y una vez salvado, seleccionaremos sobre 3. Activate service policy para ponerla en marcha de forma dinámica, tal y como hemos hecho en la primera entrega.
Para la tercera entrega nos meteremos con la service Class de BATCH, ya que hemos creado una por defecto, BATCHLO, y la idea es crear más e ir asignando trabajos a las mismas según nombre de JOB, prioridades de ejecución, etc.
Hola, muy interesante e instructivo el POST. Realizé todos los pasos correctamente. Aunque voy a tener que profundizar algo más para entenderlo al 100%. Le cambié la SRVCLASS a mi usuario por la nueva creada y funcionó bien, me queda hacerle pruebas para intentar ver cómo le va variando la prioridad a mi usuario en función de la carga de la tarea que esté realizando. (aunque creo que no va a ser fácil)
Así como en el anterior artículo creamos una SRVCLASS para jobs y cada job que entra a ejecutarse la toma por defecto, me resulta curioso que en este caso no sea igual. He logueado con otro usuario y la SRVCLASS que le pone es la de siempre y no la nueva que he creado:
JOBNAME U% Workload SrvClass
IBMUSER 0 MIWLTSO TSOWLM —-> usuario al que se la he cambiado manualmente
ADCDA 0 SYSTEM SYSOTHER —-> Usuario logueado tras activar la política
¿el WLM sólo gestiona el uso de CPU% o también gestiona/prioriza otros aspectos que pueden influir en la velocidad de ejecución de un job/tarea como podría ser la I/O.?
Muchas gracias por tus artículos estoy aprendiendo mucho con ellos.
No entiendo por que te pasa eso. En principio, si has seguido los pasos correctamente, toda la carga de TSO (y por lo tanto, todos aquellos usuarios cuyos procesos empiezan por TSUXXXX), debería automáticamente pasar a formar parte de la Service Class TSOWLM. Te has asegurado de añadir a las Classification Rules de tu WLM, en la entrada relativa al TSO con el valor por defecto TSOWLM? Y has salvado y activado la politica?