En la anterior entrega hemos visto como hemos creado una Service Class para usuarios de TSO, en los que gestionaba la prioridad en base al consumo que hacia de CPU y al tiempo de ejecución de la transacción, de forma que una transacción larga no monopolizara el tiempo de ejecución de todo el sistema. Pues en BATCH puede pasar exactamente lo mismo, por lo que vamos a seguir las mismas operatorias para asignar prioridad en función del tiempo que pasa un proceso BATCH en la máquina.
Creación de una Service Class BATCH
Recordemos que de hecho ya existe una Service Class BATCH llamada BATCHLO que creamos en la primera entrega de este monográfico, y que básicamente, era una ejecución discrecional de los trabajos que compiten por igual los recursos de la CPU. Pero… ¿Y si queremos que existan trabajos que tengan mucha mayor prioridad que el resto?
Por tanto, iremos seleccionando al igual que en la segunda entrega, las opciones del menú correspondientes, a saber, desde el menú inicial de WLM, opción 4. Service Classes, iremos la pantalla donde crearemos una nueva Service class llamada BATCHI con una serie de periodos dependientes del tiempo de CPU y tiempo transcurrido. Un ejemplo de esto, podría ser la siguiente pantalla:
Fig. 1: Browse de un Service Class BATCHHI creado con anterioridad
Las operaciones para poner esos percentiles y duración se hacen exactamente de la misma forma que en el pasado artículo. Salvamos la Service Class y pasamos a crear otra que tenga una prioridad media (BATCHMED):
Fig. 2: Service Class BATCHMED al completo.
Reglas de Clasificación para las Service Classes
Ahora que ya tenemos las Service Clases de distintas prioridades para BATCH, el único paso que nos falta es añadir una Regla de Clasificación, de forma que cuando se lancen trabajos BATCH, en función del nombre, utilice una service class u otra, dando distintas prioridades a distintos trabajos. Para ello, desde el menú principal de WLM, nos vamos a 6. Classification Rules, y allí seleccionamos los atributos de clasificación. En este caso, entraremos en el de JES, que es el subsistema donde se ejecutan los trabajos, y crearemos una nueva regla en la que todo trabajo que empiece por P* (tipo TN), adquiera la service Class BATCHHI, y trabajos que empiecen por D*, adquiera la service class BATCHMED.
Fig. 3: Reglas y Subreglas de clasificación JES
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.
Fig. 4: Prueba de JOB empenzando por P* que tiene asignada la Clase BATCHHI
En la siguiente y ultima entrega sobre WLM, y asi dejaros una base para que podáis complicar el sistema lo que os dé la gana, configuraremos iniciadores dinámicos del JES que estén relacionados con el WLM.
