El SMC incluye varias funciones que se utilizan para configurar y gestionar el entorno de TapePlex de StorageTek. La configuración se puede realizar en un host compartido o en varios hosts mediante la función de cliente/servidor del SMC.
El SMC proporciona la interfaz entre el sistema operativo z/OS de IBM y los sistemas de control de bibliotecas StorageTek, HSC y MVS/CSC. El SMC puede funcionar con estos sistemas de control de bibliotecas de las siguientes formas.
El SMC puede funcionar directamente con el HSC en el mismo host o de forma remota con un HSC en un host diferente, mediante TCP/IP y el componente del servidor HTTP del SMC.
El SMC puede funcionar con MVS/CSC en el mismo host para comunicarse con ACSLS.
Nota:
MVS/CSC 7.1 y posterior no es compatible con StorageTek LibraryStation. En un entorno de MVS único, debe usar el SMC de StorageTek y el componente del servidor HTTP para permitir la comunicación entre hosts de MVS.El SMC se puede comunicar con un servidor ACSLS con compatibilidad con XAPI activada (sin necesidad de MVS/CSC). Consulte Interfaz del cliente XAPI para el servidor ACSLS para obtener más información.
Un TapePlex es una única configuración de hardware de StorageTek, generalmente representada por un solo conjunto de datos de control (CDS) del HSC. Un TapePlex puede contener varios sistemas de cartuchos automatizados (ACS) y subsistemas de almacenamiento de cinta virtual (VTSS).
Es recomendable usar el comando TAPEPlex
del SMC para definir explícitamente todos los sistemas Tapeplex a los que podrá acceder un subsistema SMC.
Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre el comando TAPEPlex
del SMC.
La función de cliente/servidor permite que el SMC se comunique con sistemas HSC que no están en el mismo host que el SMC. Esta función le permite realizar lo siguiente:
Reducir el número de hosts en los que se inicia el HSC.
Es recomendable ejecutar el HSC solamente en dos hosts (el segundo es de respaldo). La ejecución del HSC en solamente uno o dos hosts reduce la contención del CDS y elimina la necesidad de gestionar varios archivos syslog de MVS.
Comunicarse con varios sistemas TapePlex del HSC que representan configuraciones de hardware físicamente diferentes.
Reducir las interrupciones de procesamiento de cintas proporcionando una segunda instancia del HSC para conmutación por error.
Todos los usuarios que desean que el SMC se comunique con un subsistema HSC remoto deben definir un segmento de OMVS en RACF para el ID de usuario asociado con el SMC. De lo contrario, se producirá un error de inicialización del proceso UNIX de z/OS. Para definir el segmento de OMVS, consulte la publicación de IBM z/OS IBM Communications Server IP Migration Guide (Guía de migración IP del servidor de comunicaciones z/OS de IBM). Si está usando un producto de seguridad funcionalmente equivalente (por ejemplo, ACF2), consulte la documentación de ese producto.
De manera opcional, puede proteger (cifrar) comunicaciones completas con la utilidad de seguridad de capa de transporte transparente de la aplicación (AT-TLS), una aplicación distribuida como parte del sistema operativo z/OS de IBM.
AT-TLS permite cifrar y descifrar datos sobre la base de las declaraciones de políticas especificadas en el agente de políticas. Para obtener más información sobre la implementación de AT-TLS, consulte la información sobre la seguridad de capa de transporte transparente de la aplicación (AT-TLS) en z/OS Communications Server: IP Configuration Guide (Servidor de comunicaciones z/OS: Guía de configuración IP) y la información sobre el agente de políticas en z/OS Communications Server: IP Configuration Reference (Servidor de comunicaciones z/OS: Referencia de configuración IP).
Para cualquier TapePlex del HSC que reside en un host diferente que el SMC, debe ejecutar el comando SERVer
del SMC. Este comando define una ruta designada al sistema de control de bibliotecas del HSC, o al servidor, en un host MVS diferente.
El primer servidor que define se considera el servidor principal. Los servidores adicionales son los servidores secundarios. Si se produce un error de comunicación en el primer servidor durante el procesamiento del montaje o la asignación, el SMC automáticamente cambia la comunicación al primer servidor secundario disponible. Si se produce un error de comunicación en este servidor secundario, el SMC automáticamente cambia al siguiente servidor secundario disponible.
Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre el comando SERVer
del SMC.
El SMC ofrece varias funciones de supervisión que garantizan que el subsistema SMC y todas las comunicaciones de cliente/servidor funcionan correctamente. Consulte Capítulo 7, Funciones de supervisión y procedimientos de recuperación para obtener más información.
El componente del servidor HTTP del SMC permite la comunicación entre el SMC (cliente) y un HSC en otro host (servidor). Se ejecuta en el espacio de direcciones del SMC en el host donde el HSC se ejecuta como un servidor. No es necesario en un host donde únicamente se ejecuta el SMC.
El componente del servidor HTTP del SMC no se inicia automáticamente durante la inicialización del SMC.
Para iniciar el servidor HTTP del SMC, debe incluir el comando HTTP
STArt
del SMC en el juego de datos SMCPARMS
o SMCCMDS
.
Un vez que el servidor HTTP del SMC está activo, puede ejecutar el comando HTTP
del SMC desde la consola para detener o reiniciar el servidor HTTP en cualquier momento.
Nota:
Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre el comandoHTTP
del SMC.Ejecute el comando HTTP
del SMC con el parámetro LIst
para visualizar información de estado del servidor HTTP del SMC y estadísticas de intervalo.
Incluya el parámetro DETail
para visualizar información adicional, como recuentos de E/S, de errores, de aceptación y rechazo, y de uso de CGI.
Nota:
Consulte la publicación Mensajes y códigos de ELS para ver una lista de mensajes del servidor HTTP del SMC.Cuando un cliente del SMC dirige las solicitudes de la UUI al servidor HTTP del SMC, todas o algunas de estas solicitudes se ejecutarán en el espacio de direcciones del SMC donde se está ejecutando el servidor HTTP. Si intenta ejecutar varias solicitudes simultáneamente, es posible que se produzcan finalizaciones anormales debido a un espacio de almacenamiento insuficiente en el SMC.
Las funciones de la UUI que pueden consumir una gran cantidad de espacio de almacenamiento virtual incluyen la función EXPORT
de VTCS e informes que utilizan la función SORT
, como VOLRPT
, VTVRPT
y MVCRPT
.
Se recomienda que asigne el tamaño máximo de región (0M) al SMC donde se ejecuta el servidor HTTP.
SMC 7.3 introduce una nueva función de seguridad de XAPI para la comunicación cliente/servidor, que está activada como opción por defecto en el servidor HTTP de SMC.
El método preferido para proteger las transacciones de la XAPI en TapePlexes que alojan aplicaciones cliente de ELS solamente (SMC y cliente de VM) es usar las utilidades de AT/TLS como se describe en la Guía de seguridad de StorageTek Enterprise Library Software. AT/TLS es una utilidad de la capa de transporte que es externa y transparente para ELS.
Use la función de seguridad de la XAPI de ELS 7.3 para proteger TapePlexes que alojen clientes que no sean de ELS (clientes de sistemas abiertos) o una combinación de clientes de ELS (SMC y cliente de VM) y clientes que no sean de ELS. AT-TLS se puede usar en estos entornos además de la función de seguridad de la XAPI de ELS 7.3. Sin embargo, no protegerá las transacciones de la XAPI para los clientes que no sean de ELS.
ELS 7.3 proporciona utilidades de autenticación de usuario adicionales como parte del protocolo de su XAPI que son internas de ELS y están íntegramente contenidas en este. ELS 7.3 implementa un protocolo de comprobación/respuesta para autenticar transacciones individuales de cliente/servidor de la XAPI. Este protocolo requiere que use el nuevo comando XUDB
del SMC para definir ID de usuario y contraseñas para clientes y servidores. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre este comando. La comprobación y la respuesta de inicio operativo son completamente transparentes, y no requieren intervención adicional del usuario o del operador. Se requiere el inicio de sesión en la XAPI para cada operación de TapePlex (montaje, desmontaje, consulta, asignación como volumen nuevo, etc.). El servidor no guarda ni almacena nunca en caché los ID de usuario y las contraseñas en nombre del cliente.
ELS 7.3 requiere que la seguridad de XAPI sea la configuración por defecto. Sin embargo, ELS proporciona utilidades que le permiten controlar la seguridad de cada cliente.
Puede usar el comando XCLIENT
del SMC para activar un servidor de ELS 7.3 que "exima" a clientes individuales de usar el protocolo de seguridad de la XAPI. Los clientes de ELS de niveles anteriores (por ejemplo, un cliente 7.2 que se comunica con un servidor 7.3) requieren una definición del comando XCLIENT
de ELS 7.3 para que se les permita solicitar servicios del servidor de ELS 7.3 sin iniciar sesión en la XAPI.
Puede usar el comando HTTP
con el parámetro XSECurity (OFF)
para desactivar el protocolo de seguridad de la XAPI globalmente. Si se especifica HTTP XSECurity(OFF)
, el protocolo de la XAPI de ELS 7.3 funciona de manera idéntica al protocolo de la XAPI de ELS 7.2 (sin autenticación de usuarios).
Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre estos comandos.
El protocolo de seguridad de la XAPI requiere que IBM z/OS Cryptographic Services ICSF sea HCR7740 o superior. ICSF se debe iniciar tanto en el sistema servidor como en el cliente. Consulte la Guía del programador del sistema ICSF de servicios criptográficos de z/OS de IBM (SA22-7520) para obtener información sobre la inicialización de ICSF. Si bien para la seguridad de la XAPI se requiere ICSF, no se requiere un coprocesador de cifrado.
ADVERTENCIA:
Si IBM z/OS Cryptographic Services ICSF no está instalado, se debe desactivar la función de seguridad de la XAPI del SMC. SMC no desactiva la función de seguridad de la XAPI como opción por defecto aunque reconozca que ICSF no está instalado. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener información sobre el uso del comando HTTP
del SMC para desactivar la función de seguridad de la XAPI.
La API de XML (XAPI) es una API de Oracle StorageTek que permite a los clientes y los servidores de StorageTek comunicarse con un protocolo común mediante TCP/IP.
Con la presentación de esta XAPI, los clientes que anteriormente requerían el uso de un servidor basado en MVS (componente de software de host de Oracle StorageTek) para procesamiento real de cintas ahora pueden usar ACSLS 8.4 o posterior (con compatibilidad con XAPI activada) de la siguiente manera:
Un cliente del SMC de MVS ahora puede realizar solicitudes de cinta real desde un servidor ACSLS con la compatibilidad con XAPI activada (sin necesidad de MVS/CSC).
El cliente de VM ahora puede solicitar servicios de cinta real desde un servidor ACSLS con la compatibilidad con XAPI activada.
Si está usando el cliente de VM o del SMC para conectarse a un servidor ACSLS con compatibilidad con XAPI activada, deberá usar los comandos TAPEPlex
y SERVer
del cliente de VM para definir la aplicación de ACSLS en un TapePlex y definir la ruta de control de TCP/IP entre el cliente y el servidor. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener información sobre estos comandos.
La mayoría de las interacciones de cliente y servidor, entre clientes de VM y SMC, y un servidor ACSLS con XAPI son transparentes para el usuario final. El cliente de VM y el SMC generan las solicitudes de información de volumen, montajes y desmontajes automáticamente y se procesan sin intervención del operador. Además de estas interacciones automáticas, el servidor ACSLS con XAPI proporciona comandos adicionales de administrador, configuración y operador que permiten gestionar el componente XAPI. Consulte la publicación de ELS XAPI Client Interface to ACSLS Server Reference (Referencia de interfaz de cliente XAPI para el servidor ACSLS) para obtener información acerca de estos comandos.
En esta sección, se describen los siguientes escenarios comunes de configuración del SMC:
Escenario 2: TapePlex único con la función de cliente/servidor del SMC
Escenario 3: Dos sistemas TapePlex a los que accede un único SMC
Estos escenarios no pretenden ser una lista exhaustiva de los escenarios de cliente/servidor. El SMC no limita el número de sistemas TapePlex o rutas de comunicación que pueden definirse.
Además, estos escenarios incluyen el SMC en la comunicación de MVS/CSC, que es necesaria cuando el servidor es ACSLS.
Nota:
MVS/CSC 7.1 y posterior no es compatible con LibraryStation. En un entorno de MVS único, debe usar el SMC y la función de cliente/servidor para permitir la comunicación entre hosts de MVS. Consulte Uso de la función de cliente/servidor del SMC para obtener más información.En una configuración con varios sistemas TapePlex de StorageTek (como se muestra en el escenario 3), el SMC dirige la asignación de cada sentencia DD al TapePlex adecuado, sobre la base de las sentencias TAPEREQ
y los comandos POLicy
, las ubicaciones de los volúmenes específicos y los volúmenes reutilizables disponibles.
En este escenario, el SMC y el HSC se ejecutan en el mismo host MVS conectado a un único TapePlex (representado por un solo CDS).
La siguiente figura ilustra este escenario:
Esta configuración utiliza tres espacios de direcciones:
Espacio de direcciones de iniciador, donde se originan los eventos de asignación y de montaje
Espacio de direcciones del SMC, que intercepta esos eventos
Espacio de direcciones del HSC, hacia donde el SMC envía las solicitudes de datos de unidades y volúmenes, y las solicitudes de montaje
El siguiente comando TAPEPlex
define el TapePlex del HSC local:
TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC0)
PLEX1
es el nombre del TapePlex local y HSC0
es el nombre del subsistema MVS local para el HSC.
En este escenario, el SMC se ejecuta en un host de cliente sin HSC, con varias rutas a un TapePlex remoto (representado por un solo CDS) y un HSC que se ejecuta en varios hosts.
La siguiente figura ilustra este escenario:
Los siguientes comandos TAPEPlex
y SERVer
son necesarios para el SMC en MVSA:
TAPEPLEX NAME(PLEX1) SERVER NAME(MVSBPATH) TAPEPLEX(PLEX1) HOST(MVSB) SERVER NAME(MVSCPATH) TAPEPLEX(PLEX1) HOST(MVSC)
Las solicitudes que se originan en un espacio de direcciones de iniciador en MVSA son interceptadas por el espacio de direcciones del SMC en MVSA. El SMC en MVSA envía solicitudes de datos de volúmenes y unidades, y solicitudes de montaje al servidor en MVSB o MVSC.
En MVSB y MVSC, el SMC puede funcionar únicamente con el HSC local o puede usar la función de comunicaciones para proporcionar una copia de seguridad, como se muestra:
Los siguientes comandos TAPEPlex
y SERVer
son necesarios para el SMC en MVSB:
TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC1) SERVER NAME(MVSCPATH) TAPEPLEX(PLEX1) HOST(MVSC)
El componente HTTP está definido para el SMC en MVSB:
HTTP START
Los siguientes comandos TAPEPlex
y SERVer
son necesarios para el SMC en MVSC:
TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC2) SERVER NAME(MVSBPATH) TAPEPLEX(PLEX1) HOST(MVSB)
El componente HTTP está definido para el SMC en MVSC:
HTTP START
Los comandos TAPEPlex
y SERVer
precedentes permiten que MVSB funcione como servidor de bibliotecas de respaldo para MVSC y que MVSC funcione como servidor de bibliotecas de respaldo para MVSB.
Nota:
Consulte Sincronización de información de tipo de unidad del SMC para obtener información sobre cómo el SMC adquiere información sobre el tipo de unidades del HSC y MVS/CSC.En este escenario, un único SMC se comunica con dos sistemas TapePlexes (representados por dos CDS).
La siguiente figura ilustra este escenario:
En este escenario, se asume que hay dos sistemas TapePlexes (representados por dos CDS).
El SMC se comunica directamente con el HSC en el mismo host
El SMC usa el servidor HTTP para comunicarse con el HSC en diferentes hosts (MVSB y MVSC).
Las solicitudes de asignación y montaje que se originan en un espacio de direcciones del iniciador en MVSA son interceptadas por el SMC en MVSA. A continuación, estas solicitudes se envían al HSCL local que se ejecuta en el mismo host, al HSC1 que se ejecuta en el host MVSB o al HSC2 que se ejecuta en el host MVSB.
Los siguientes comandos TAPEPlex
y SERVer
son necesarios para el SMC en MVSA:
TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC0) TAPEPLEX NAME (PLEX2) SERVER NAME(MVSBPATH) TAPEPLEX(PLEX2) HOST(MVSB) SERVER NAME(MVSCPATH) TAPEPLEX(PLEX2) HOST(MVSC)
Nota:
Consulte Selección de TapePlex del SMC para obtener información sobre cómo el SMC selecciona entre varios sistemas TapePlex para determinar el propietario de cada solicitud de asignación (es decir, cada DD en un paso de trabajo puede tener un propietario de TapePlex diferente).Los siguientes comandos TAPEPlex
y SERVer
son necesarios para el SMC en MVSB:
TAPEPLEX NAME(PLEX2) LOCSUBSYS(HSC1) SERVER NAME(MVSCPATH) TAPEPLEX(PLEX2) HOST(MVSC)
El componente HTTP está definido para el SMC en MVSB:
HTTP START
Los siguientes comandos TAPEPlex
y SERVer
son necesarios para el SMC en MVSC:
TAPEPLEX NAME(PLEX2) LOCSUBSYS(HSC2) SERVER NAME(MVSBPATH) TAPEPLEX(PLEX2) HOST(MVSB)
El componente HTTP está definido para el SMC en MVSC:
HTTP START
Nota:
No existen límites predefinidos para el número de sistemas TapePlex o rutas del servidor que pueden configurarse en un solo SMC.El SMC y el HSC ofrecen funciones que permiten gestionar un entorno en el cual las direcciones de las unidades son diferentes entre los hosts de cliente y de servidor. Use los siguientes escenarios para determinar si se requiere la asignación de direcciones de unidades de cliente/servidor y cuáles son las acciones y funciones necesarias.
No se utiliza el procesamiento de cliente/servidor.
Cada host MVS ejecuta una copia del HSC.
Acción necesaria: ninguna
Se utiliza el procesamiento de cliente/servidor.
Las direcciones de los dispositivos están definidas de forma idéntica para todos los hosts que participan en una única red de cliente/servidor.
Acción necesaria: ninguna
Se utiliza el procesamiento de cliente/servidor.
Las direcciones de los dispositivos están definidas de forma idéntica en una única red de cliente/servidor, pero no todos los dispositivos están definidos para todos los hosts.
Acción necesaria: no es necesaria la asignación de direcciones de unidades. Sin embargo, debe usar la utilidad SET SLIDRIVS del HSC para definir todas las direcciones de unidades en los hosts que se utilizarán como servidores, aún si los dispositivos no están definidos para el host. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre la utilidad SET SLIDRIVS
.
Se utiliza el procesamiento de cliente/servidor.
Las direcciones de los dispositivos están definidas de forma idéntica para todos los hosts, pero uno o varios hosts del SMC de cliente únicamente usan un conjunto de direcciones para el mismo dispositivo.
Acción necesaria: use el comando DRIVemap
del SMC para asignar las direcciones de host de cliente del SMC a las direcciones de host del HSC. El SMC realiza las conversiones de direcciones necesarias para influir en las asignaciones y solicitar montajes del servidor. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre el comando DRIVemap
del SMC.
Se utiliza el procesamiento de cliente/servidor.
Dos hosts MVS (MVS1 y MVS2) que ejecutan HSC y SMC.
Un host MVS (MVS3) que ejecuta solamente el SMC, pero que se comunica con cualquiera de los dos hosts como un servidor.
Las direcciones de los dispositivos están definidas de forma diferente entre los tres hosts. Por ejemplo:
MVS1 (AA0-AAF)
MVS2 (BA0-BAF)
MVS3 (CA0-CAF)
Acción necesaria:
Dado que el SMC en MVS3 se puede comunicar con el host MVS1 o el host MVS2 para un evento de montaje determinado, debe emplear la utilidad SET
del HSC, SET DRVHOST
, para designar uno de estos hosts como el "host de unidad principal". Por ejemplo, MVS1 (AA0-AAF)
.
Una vez que se especifica el host de unidad principal en el CDS del HSC, las direcciones asociadas con ese host principal (AA0-AAF) son utilizadas por MVS1 y por MVS2 al comunicarse con el SMC.
Si lo desea, puede agregar un ID de host ficticio al DRVHOST
del HSC y usar las direcciones de unidades no existentes para asignarlas a las direcciones de cliente. Por ejemplo, emplee la utilidad SET NEWHOST
del HSC para definir el nombre de host DRVDUMMY
y definir el rango del dispositivo como 000-00F
.
Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre el la utilidad SET DRVHOST
del HSC y la utilidad SET NEWHOST
del HSC.
Use el comando DRIVemap
del SMC en los clientes MVS2 y MVS3 para asignar las direcciones de unidades BA0-BAF
y CA0-CAF
a las direcciones de servidor AA0-AAF
. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre el comando DRIVemap
del SMC.
El SMC adquiere información de tipo de unidad de los sistemas de control de bibliotecas ELS, el HSC y MVS/CSC mediante consultas de configuración enviadas desde el SMC a cada TapePlex definido.
Para subsistemas de HSC, los cambios de configuración de unidades son reconocidos automáticamente por el SMC, tanto para sistemas locales como remotos.
Para subsistemas MVS/CSC, se debe ejecutar el comando RESYNChronize
del SMC cuando se ejecuta el comando de MVS/CSC equivalente. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre el comando RESYNChronize
del SMC.
El comando UNITAttr
del SMC permite aumentar o sustituir la información devuelta por la configuración del sistema de control de bibliotecas ELS, según lo requerido por la configuración de los dispositivos de unidad de cinta del host local. Específicamente, el comando UNITAttr
le permite hacer lo siguiente:
Configurar MODEL=IGNORE
para las direcciones de dispositivos no disponibles para este host.
Especificar tipos de modelos para dispositivos no pertenecientes a una biblioteca en este host.
Especificar NOTAPEPLEX
para un rango o dirección de dispositivo no perteneciente a una biblioteca en este host, pero que son dispositivos pertenecientes a TapePlex en otros hosts.
Especificar la propiedad de TapePlex para un rango o dirección de dispositivo definidos para varios sistemas TapePlex; sin embargo, para este host, los dispositivos conectados pertenecen al TapePlex especificado.
Especificar el modelo y la propiedad de TapePlex para los dispositivos a los que puede hacer referencia un montaje una vez que se inicia el SMC, pero antes de que se inicialice el TapePlex.
Nota:
Los comandosUNITAttr
no son necesarios y únicamente deben ejecutarse en las condiciones que se describen en esta sección.Para definir dispositivos representados por un UCB, a los cuales no puede accederse desde este host, ejecute un comando UNITAttr
del SMC para cada dispositivo inaccesible, de la siguiente manera:
UNITATTR ADDR(ccuu) MODEL(IGNORE)
UNITAttr MOdel(IGNORE)
El procesamiento no se modifica con respecto a versiones anteriores. Como resultado, el SMC no incluye el dispositivo en el procesamiento.
Para definir tipos de dispositivos no pertenecientes a una biblioteca en este host, ejecute un comando UNITAttr
del SMC para cada dispositivo no perteneciente a una biblioteca, de la siguiente manera:
UNITATTR ADDR(ccuu) MODEL(model)
Un dispositivo no perteneciente a una biblioteca es un dispositivo StorageTek que requiere la definición de información adicional sobre el modelo para diferenciarlo de otros dispositivos no pertenecientes a una biblioteca con características de UCB similares.
Si una dirección de dispositivo del host se superpone con una dirección de un dispositivo perteneciente a TapePlex, y no se puede acceder a este último dispositivo desde este host, ejecute un comando UNITAttr
del SMC especificando el parámetro NOTAPEPlex
, de la siguiente manera:
UNITATTR ADDR(ccuu) MODEL(model) NOTAPEPLEX
Como resultado, si un TapePlex, como HSC, reclama la propiedad según los datos devueltos por una consulta de configuración, NOTAPEPlex
sustituye el TapePlex. Se ignora la información de configuración y el dispositivo sigue siendo un dispositivo no perteneciente a una biblioteca.
Si no especifica NOTAPEPlex
, la información de configuración del TapePlex sustituye el UNITAttr
especificado sin el parámetro NOTAPEPlex
y la definición del dispositivo cambia de dispositivo no perteneciente a una biblioteca a dispositivo perteneciente a TapePlex.
Si la configuración incluye varios sistemas Tapeplex con direcciones o rangos superpuestos, y ambos sistemas Tapeplex está definidos para el SMC, introduzca un comando UNITAttr
con el parámetro TAPEPlex
para establecer a qué Tapeplex pertenece el dispositivo o el rango especificado en este host. Introduzca un comando UNITAttr
para cada una de las direcciones de unidades duplicadas, de la siguiente manera:
UNITATTR ADDR(ccuu) MODEL(model) TAPEPLEX(name)
Suponga lo siguiente:
El host MVSA incluye dos sistemas TapePlex, HSC1 y HSC2.
HSC1 incluye un rango de dispositivos 9840 de 2900 a 2903.
HSC2 incluye un rango de dispositivos 4480 de 2900 a 2903.
Sin embargo, en MVSA, los dispositivos 2900 a 2903 están conectados a HSC1. MVSA no tiene conexión con el rango de dispositivos HSC2.
En este escenario, ejecute un comando UNITATTR
del SMC, de la siguiente manera:
UNITATTR ADDR(2900-2903) MODEL(9840) TAPEPLEX(HSC1)
Este comando indica al SMC que ignore la información de configuración para los dispositivos especificados de cualquier TapePlex, excepto el TapePlex especificado.
Nota:
Si MVSA reconoce el rango de direcciones de 2900 a 2903 definido para HSC2 como un rango de direcciones diferente (por ejemplo, 4900 a 4903), MVSA debe usar las funcionesSET DRVHOST
para definir el rango de direcciones de 2900 a 2903 en HSC2 como un rango de direcciones de 4900 a 4903 para las consultas de configuración de cualquier cliente. Consulte Asignación de direcciones de unidades de cliente/servidor para obtener más información.Para definir dispositivos pertenecientes al TapePlex cuando los trabajos de cinta se ejecutan después de que se inicia el SMC pero antes de la inicialización del TapePlex, introduzca un comando UNITAttr
del SMC para todos los dispositivos pertenecientes al TapePlex, de la siguiente manera:
UNITATTR ADDR(2900-2903) MODEL(9840) TAPEPLEX(HSC1) ... UNITATTR ADDR(9000-903F) MODEL(VIRTUAL) TAPEPLEX(HSC1)
Esto indica al SMC que realice un seguimiento de las políticas de cinta para los montajes pendientes, incluido VTCS MGMTCLAS
.
Cuando el SMC intercepta una solicitud de asignación específica o nueva, selecciona un TapePlex propietario para que se ocupe de la solicitud. El SMC evalúa los siguientes criterios en el orden mostrado para determinar qué TapePlex controla la solicitud de asignación:
Los sistemas TapePlex se interrogan en el orden en el que están definidos. Si hay comandos TAPEPlex
definidos para el SMC, se utiliza el orden de los comandos TAPEPlex
. Si hay comandos TAPEPlex
definidos para el SMC, se utiliza el orden de la tabla SSCVT
de MVS.
Si la lista de dispositivos elegibles (EDL) para la solicitud no contiene unidades pertenecientes a un TapePlex específico, ese TapePlex no puede ser el propietario de la solicitud.
Si un POLicy
del SMC aplicable solicita un TapePlex específico, se selecciona como el propietario de la solicitud.
Si el grupo esotérico POLicy
del SMC contiene solamente unidades en un TapePlex único, se selecciona como propietario de la solicitud.
Si el número de serie de volumen específico solicitado está especificado en una sentencia TAPEREQ
, el comando POLicy
asociado con el TAPEREQ
determina el propietario.
Si un volumen específico solicitado se encuentra en un TapePlex, ese TapePlex se considera el propietario, a menos que sea sustituido por una selección explícita de TapePlex o de grupo esotérico. Si el volumen no se encuentra en un TapePlex, pero ese TapePlex contiene una definición de VOLPARM
para ese volumen, el TapePlex se considera el propietario si el volumen específico no se encuentra en ningún otro TapePlex.
Si un TapePlex indica que tiene volúmenes nuevos para la solicitud, se considera el propietario, a menos que sea sustituido por una selección explícita de TapePlex o de grupo esotérico. Si el TapePlex no contiene volúmenes nuevos para la solicitud, pero el nombre de la subagrupación especificada es conocido para el TapePlex, el TapePlex se considerará el propietario si no se encuentran volúmenes nuevos en ningún otro TapePlex.
Para seleccionar un propietario de TapePlex entre varias bibliotecas, especifique un nombre de TapePlex con el parámetro TAPEPlex
en el comando POLicy
del SMC. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener información sobre este comando.