Puntos clave: El zIIP (System Z Integrated Information Processor) de IBM permite que cargas de trabajo específicas operen a menores costes de software, mejorando la eficiencia del procesamiento. Las limitaciones clave incluyen restricciones de código elegibles, que requieren ejecución dentro de un Bloque de Solicitud de Servicio (SRB), lo que limita el acceso a ciertos servicios z/OS.
- Los procesadores zIIP ofrecen ahorros significativos en el procesamiento sin cargos de software.
- Solo el código que cumple criterios específicos puede ejecutarse en zIIP, limitando la aplicabilidad más amplia.
Como seguimiento a la publicación de Phil Grainger sobre la descarga de zIIP, pensé que valía la pena dedicar unos minutos a centrarme en las características del código que puede ejecutarse en un zIIP, así como en el código que podría sufrir una pérdida mínima de rendimiento si se reescribiera para ejecutarse en un zIIP en lugar de en un procesador de propósito general (GP). IBM introdujo el zIIP (System Z Integrated Information Processor) en 2006. IBM licencia hardware zIIP por una fracción de los cargos correspondientes para GPs. Más importante para ti, los procesadores zIIP no son contabilizados en la base de los cargos de software, así que te Ve grandes ahorros al trasladar la carga de trabajo de GPs a zIIPs. Además, los procesadores zIIP son ejecutados "a máxima velocidad", por lo que te puedes Obtén más procesamiento en menos tiempo si tus GPs no son modelos a plena capacidad. Entonces, ¿por qué no reemplazar simplemente cada GP por un zIIP y ahorrar dinero tanto en hardware como en software? Primero, IBM ha impuesto una restricción al uso de zIIP. Originalmente, no podía haber más de un zIIP por GP en un CEC, pero algunos modelos ahora permiten dos zIIP por GP. Segundo, el acuerdo de licencia de IBM impone restricciones sobre el tipo de código que es elegible para ejecutarse en un zIIP; el código debe ejecutarse en un enclave z/OS bajo el control de un SRB (bloque de solicitud de servicio). El utiliza de un enclave significa que el trabajo están despachado por z/OS Workload Manager (WLM). El código ejecutado desde el enclave puede ser gestionado por un conjunto común de controles y políticas WLM porque el código tiene un conjunto común de características. Programar un SRB en lugar de adjuntar un bloque de control de tareas (TCB) implica más restricciones; la más pertinente de estas están que no se puede emitir ningún SVC (excepto ABEND), lo que impide la utiliza de muchos servicios de z/OS que comúnmente invocan los programas de aplicación. Esto se ha malinterpretado como "te no puede hacer E/S en un zIIP", lo cual no están cierto. Sin embargo, están cierto que QSAM y BSAM, que muchos programas de aplicación utilizan para realizar E/S secuencial de archivos, no pueden invocarse desde código SRB porque emiten SVCs. Para mayor detalle, deberíamos mencionar "zAAP on zIIP", por el cual IBM permite que procesos que son elegibles para zAAP se ejecuten en un zIIP en entornos donde no son zAAPs. Muy poco código heredado encaja en este perfil, pero son vemos más instalaciones de Db2 que son convirtiendo aplicaciones COBOL heredadas a Java porque son más fáciles de encontrar programadores que los que tienen habilidades en COBOL. Un efecto secundario de esta medida están hacer que las aplicaciones heredadas sean elegibles para zIIP después de que son reescritas a Java. Entonces, ¿por qué vuestros proveedores de mainframe no habilitan zIIP en todo el código de todos sus productos? La respuesta vuelve a la segunda restricción mencionada arriba: para ser elegible para zIIP, el código debe ejecutarse bajo un SRB y, por tanto, no puede invocar muchos servicios de z/OS. La mayoría del código existente del producto fue escrito para ejecutarse en modo TCB. Históricamente, el código en modo SRB se usaba solo cuando se consideraba una forma rentable de hacer procesamiento de memoria cruzada. Veamos un fragmento hipotético de código (parte de un producto de software) que hoy se ejecuta bajo un TCB y no realiza llamadas SVC. Para Haz que el código zIIP sea elegible, debemos hacer algo así cada vez que ejecutamos el código:
- Configura el SRB en memoria para que apunte al código que se va a ejecutar.
- Emite la macro IEAMSCHED para programa la ejecución del SRB.
- El código TCB que se ejecuta originalmente debe esperar a que el código SRB se ejecute.
- Cuando el código SRB se completa, debe señalar al código TCB para que se reanude antes de terminar.
Alternativamente, podríamos Comienza el SRB una vez, luego hacer un bucle y esperar el código del SRB en lugar de programar uno nuevo cada vez que se están realizando la función. La sobrecarga al pasar del modo TCB al SRB y viceversa implicará un coste de CPU. Los proveedores sopesan las ventajas de hacer el código elegible para zIIP junto con los costes de CPU para determinar qué código será más eficiente para los usuarios. Los proveedores deberían Haz sus productos elegibles para zIIP cuando sea posible. Deberían centrarse en programas que son intensivos en CPU, que no contengan las llamadas a servicios z/OS que no se pueden hacer desde un SRB y que no requieran mucha E/S. Los programas deben ejecutarse con suficiente frecuencia como para que el ahorro de CPU en tus GPs sea sustancial. Aunque sería bueno que pudiéramos Permite todo el código de todos vuestros productos de software z/OS para que funcione en zIIP en vez de GPs, eso están poco realista. Una última cosa están que la licencia que permite a los proveedores externos habilitar su código impide específicamente que utiliza de la licencia para zIIP Permite OTRO código se ejecute en un zIIP. Así que un proveedor puede habilitar zIIP el código que ha escrito, pero no podría escribir una herramienta para habilitar zIIP el código de un cliente. Espero que la información de este artículo te proporcione la información que tú necesitas para hablar sobre la explotación de zIIP con tus proveedores.
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.