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.