En este capítulo, se proporciona la configuración del software del host de MVS para VLE, según se describe en las siguientes secciones:
En las siguientes secciones, se describen los valores necesarios para la configuración de software que deben coincidir con los valores que normalmente ya están definidos en la configuración del hardware y que están registrados en la hoja de trabajo IP_and VMVC_Configuration.xls.
El nombre del subsistema de la VLE, definido por las secuencias de comandos de instalación de la VLE, se especifica de la siguiente manera:
El parámetro CONFIG TAPEPLEX STORMNGR de VTCS o el parámetro CONFIG STORMNGR NAME
El parámetro CONFIG RTD STORMNGR de VTCS
El parámetro STORMNGR NAME de SMC
El parámetro SERVER STORMNGR de SMC
El parámetro STORCLAS STORMNGR de HSC
Las direcciones de los puertos Ethernet de VTSS son necesarias para configurar el VTSS con la conexión IP de VLE mediante el parámetro CONFIG RTD IPIF. En los VSM5, este valor debe coincidir con los valores especificados en la IFF Configuration Status Screen de VSM5. En los VSM 6, este valor debe ser único para cada VTSS, pero no corresponde a un valor real de los puertos TCP/IP de VSM 6.
Las direcciones IP de los puertos de VLE para la comunicación de host (UUI) se requieren para el parámetro SERVER IP de SMC.
Son necesarios para definir los VMVC de SMC/VTCS; el método de definición depende de la versión de software. Consulte "Definición de VMVC de VLE para el software del host de MVS e inclusión de VMVC en una agrupación de MVC."
Para obtener más información, consulte "Especificación de la política de recuperación para VMVCS."
El parámetro STORCLAS DEDUP especifica si se ha anulado la duplicación para los datos de VTV migrados a los VMVC en el STORMNGR especificado. Por ejemplo:
STORCLAS NAME(VLEDEDUP)STORMNGR(VLE1) DEDUP(YES)
Esta instrucción de STORCLAS especifica la anulación de la duplicación de los datos de la clase de almacenamiento VLEDEDUP que se migra a la VLE1. Para obtener más información, consulte la Referencia de comandos, instrucción de control y utilidades de ELS 7.3.
La anulación de duplicación aumenta la capacidad efectiva de VMVC y es ejecutada por la VLE antes de que el VTV se escriba en un VMVC. Por lo tanto, Oracle recomienda activar la anulación de duplicación al principio, luego supervisar los resultados con el informe SCRPT y, por último, ajustar la anulación de duplicación, según sea necesario.
ETTFB (que también se conoce como la función de recuperación/montaje de cintas concurrentes) permite a las aplicaciones host leer los datos mientras se recuperan los VTV desde ya sean los VMVC o las RTD. ETTFB se realiza mediante la superposición de las fases de recuperación y montaje de VTV, lo que permite a la aplicación leer antes los datos de VTV. Si la aplicación intenta leer una parte del VTV que aún no se ha recuperado, se bloquea la solicitud de E/S de las aplicaciones hasta que se recuperan los datos necesarios del VTV. Con ETTFB para VLE, el acceso de la aplicación al primer byte se produce en menos de un segundo, lo que convierte a la VLE en una verdadera extensión del VTSS. Por lo tanto, ETTFB de VLE es una buena opción para las aplicaciones que acceden en serie a los datos del VTV. Por lo general, ETTFB de VLE no constituye una ventaja para las aplicaciones que apilan varios archivos en un mismo VTV, entre ellas, las aplicaciones de gestión de imágenes y HSM. En estos tipos de aplicaciones, los datos deseados, por lo general, no están al principio del VTV, sino en alguna ubicación aleatoria del VTV.
ETTFB está desactivado de manera predeterminada. Es posible activar ETTFB globalmente mediante el parámetro CONFIG GLOBAL FASTRECL. Si se activa ETTFB globalmente, es posible desactivarlo para VTSS individuales mediante el parámetro CONFIG VTSS NOERLYMNT .
Los VTV que han experimentado un error de recuperación de ETTFB incluirán un marcador de error en el registro de VTV del CDS. Estos VTV no se seleccionan posteriormente para ETTFB. Si desea restablecer el marcador de error, realice una de las siguientes acciones:
Introduzca un comando VTVMAINT SCRATCH(ON) para el VTV.
Migre el VTV a una nueva copia de MVC.
Importe el VTV.
Cree una versión nueva versión del VTV.
Cancele el VTV.
Para agregar VLE a un sistema VSM, se requieren las tareas que describen en las siguientes secciones:
Para obtener más información sobre los comandos y las instrucciones de control a las que se hace referencia en este capítulo, consulte la Referencia de comandos, instrucción de control y utilidades de ELS 7.x.
Para ELS 7.2 y versiones posteriores, se incluye compatibilidad en el nivel base. Para ELS 7.1, obtenga el último comando SMP/E receive HOLDDATA, los PTF (L1H16J6, L1H1674) y el comando SMP/E APPLY con GROUPEXTEND.
La VLE requiere que SMC tenga una entrada de seguridad de OMVS RACF para establecer una conexión TCP/IP con el host.
OMVS es un segmento asociado con el ID de usuario de RACF. La tarea iniciada de SMC debe tener un ID de usuario asociado con OMVS, ya sea en la definición de clase RACF STARTED o en el módulo ICHRIN03 LNKLST. El ID de usuario asociado con la tarea de SMC debe tener un segmento de OMVS definido dentro de RACF, según se indica a continuación:
ADDUSER userid DFLTGRP(groupname)OWNER(owner)OMVS(UID(uidnumber))
O, si el ID de usuario ya existe, pero no tiene un segmento de OMVS:
ALTUSER userid OMVS(UID(uidnumber))
SMC gestiona toda la comunicación entre VTCS y VLE, por lo tanto, SMC debe saber cómo conectarse al servidor de VLE. Para esto, agregue una sentencia STORMNGR de SMC para cada sistema de VLE más una o más sentencias SERVER de SMC que definen las rutas de control TCP/IP para VLE. Para las versiones 7.0 y posteriores, se recomienda hacer esto en el archivo CMDS de SMC, como se muestra en Ejemplo 2-1.
Ejemplo 2-1 Comandos de SMC para VLE
TAPEPLEX NAME(TMVSA)LOCSUB(SLS0) SERVER NAME(ALTSERV) TAPEPLEX(TMVSA) + HOSTNAME(MVSX) PORT(8888) STORMNGR NAME(VLE1) SERVER NAME(VLE1)+ STORMNGR(VLE1)IP(192.168.1.10)PORT(60000)
Ejemplo 2-1 contiene:
Una instrucción TAPEPLEX, que define un único TapePlex, TMVSA, con un HSC/VTCS que se ejecuta en el mismo host de MVS (SLS0).
Una instrucción SERVER, que define un subsistema HSC/VTCS de reserva (ALTSERV) que se ejecuta en otro host.
Un comando STORMNGR que define un VLE (VLE1).
Un segundo comando SERVER que define una ruta de comunicación de UUI con la VLE, donde:
El nombre del servidor es VLE1.
El valor del parámetro STORMNGR es VLE1.
El valor del parámetro IP es la dirección IP del puerto de VLE de 192.168.1.10 para las comunicaciones de UUI.
El valor del parámetro PORT es 60000. Este valor siempre se utiliza para el parámetro SERVER PORT para la comunicación de SMC con un VLE.
Debe actualizar la plataforma CONFIG de VTCS para definir VLE y la conectividad de los sistemas VTSS a VLE. VTCS puede definir VLE, de la siguiente manera:
Para VTCS 7.0 y versiones posteriores, la sentencia CONFIG TAPEPLEX define el TapePlex en que se ejecuta VTCS y proporciona la lista de VLE definidas en el parámetro CONFIG TAPEPLEX STORMNGR, como se muestra en el Ejemplo 2-2.
Ejemplo 2-2 VLE de configuración de VTCS 7.0
TAPEPLEX THISPLEX=TMVSA STORMNGR=VLE1 VTSS NAME=VTSS1 LOW=70 HIGH=80 MAXMIG=8 MINMIG=4 RETAIN=5 RTDPATH NAME=VL1RTD1 STORMNGR=VLE1 IPIF=0A:0 RTDPATH NAME=VL1RTD2 STORMNGR=VLE1 IPIF=0A:1 RTDPATH NAME=VL1RTD3 STORMNGR=VLE1 IPIF=0I:0 RTDPATH NAME=VL1RTD4 STORMNGR=VLE1 IPIF=0I:1 RTDPATH NAME=VL1RTD5 STORMNGR=VLE1 IPIF=1A:0 RTDPATH NAME=VL1RTD6 STORMNGR=VLE1 IPIF=1A:1 RTDPATH NAME=VL1RTD7 STORMNGR=VLE1 IPIF=1I:0 RTDPATH NAME=VL1RTD8 STORMNGR=VLE1 IPIF=1I:1 VTD LOW=6900 HIGH=69FF
En el Ejemplo 2-2, tenga en cuenta lo siguiente:
La sentencia CONFIG TAPEPLEX, que define TMVSA como el TapePlex en que se ejecuta VTCS y los nombres de todas las VLE conectadas (que en este ejemplo es una sola VLE denominada VLE1).
Las instrucciones CONFIG RTDPATH, que definen una sola RTD de VLE para cada ruta del VTSS a la VLE. En este ejemplo, las instrucciones CONFIG RTDPATH para VTSS1 especifican:
El nombre de RTDPATH.
Las conexiones con las VLE definidas (STORMNGR=VLE1).
El valor IPIF para cada VTSS para la conexión de puerto de VLE en formato ci:p, donde:
c es 0 o 1.
i es A o I.
p es un valor de 0 a 3.
Nota:
En los VSM5, este valor debe coincidir con los valores especificados en la IFF Configuration Status Screen de VSM5. En los VSM 6, este valor debe ser único para cada VTSS, pero no corresponde a un valor real de los puertos TCP/IP de VSM 6.Los sistemas VTCS 7.1 y posteriores pueden, desde luego, definir VLE 1.5.1 de la misma manera que VTCS 7.0. Sin embargo, en este modo, el número de destinos de RTD de VLE está limitado por el número de rutas de un VTSS. Además, las RTD de VLE se asignan a rutas fijas de VTSS. La ruta de un VTSS hacia la VLE siempre está reservada por el VTCS, independientemente de que se esté realizando cualquier transferencia de datos del VTSS hacia la VLE.
Sin embargo, con VTCS 7.1 y posteriores, se puede definir una VLE con más destinos de RTD de VLE que la cantidad de rutas existentes del VTSS hacia la VLE, lo que significa lo siguiente:
La ruta del VTSS a la VLE no siempre está reservada, a menos que se requiera una transferencia de datos del VTSS a la VLE.
Se pueden realizar más operaciones simultáneas de RTD de VLE. Por ejemplo, una auditoría de un VMVC no requiere una transferencia de datos entre el VTSS y la VLE.
Como se muestra en el Ejemplo 2-3, los VLE se definen mediante una instrucción CONFIG STORMNGR, no mediante el parámetro CONFIG TAPEPLEX STORMNGR. La sentencia CONFIG STORMNGR especifica las VLE a las que se conecta el VTCS. Además, para cada VLE, el parámetro CONFIG STORMNGR VLEDEV define el número de dispositivos RTD y los nombres de los dispositivos RTD que emula la VLE. Cuantos más dispositivos se definen (hasta el máximo de 96 dispositivos por VLE), mayor es el nivel de actividades concurrentes que el VTCS puede programar en las VLE.
Ejemplo 2-3 VLE de configuración de VTCS 7.1
TAPEPLEX THISPLEX=TMVSC STORMNGR NAME=VLE1 VLEDEV(S000-S05F) STORMNGR NAME=VLE2 VLEDEV(S000-S05F) VTSS NAME=VTSS1 LOW=70 HIGH=80 MAXMIG=8 MINMIG=4 RETAIN=5 RTDPATH NAME=VL1RTD1 STORMNGR=VLE1 IPIF=0A:0 RTDPATH NAME=VL1RTD2 STORMNGR=VLE1 IPIF=0A:1 RTDPATH NAME=VL1RTD3 STORMNGR=VLE1 IPIF=0I:0 RTDPATH NAME=VL1RTD4 STORMNGR=VLE1 IPIF=0I:1 RTDPATH NAME=VL1RTD5 STORMNGR=VLE2 IPIF=1A:0 RTDPATH NAME=VL1RTD6 STORMNGR=VLE2 IPIF=1A:1 RTDPATH NAME=VL1RTD7 STORMNGR=VLE2 IPIF=1I:0 RTDPATH NAME=VL1RTD8 STORMNGR=VLE2 IPIF=1I:1 VTD LOW=6900 HIGH=69FF
En el Ejemplo 2-3, tenga en cuenta lo siguiente:
La instrucción CONFIG TAPEPLEX ahora simplemente define TMVSC como el TapePlex en que se ejecuta el VTCS. No define las VLE conectadas.
Las sentencias CONFIG STORMNGR, que definen las VLE configuradas en este sistema (VLE1 y VLE2), especifican el número de dispositivos de VLE a través del parámetro VLEDEV.
En este ejemplo, cada VLE tiene el máximo de 96 dispositivos emulados, lo que permite al VTCS programar hasta 96 procesos en cada VLE. Las direcciones del dispositivo de VLE tienen el formato de Sxxx (donde xxx es un valor hexadecimal).
Ejemplo: S000-S05F representa 96 dispositivos emulados.
Las instrucciones CONFIG RTDPATH para VTSS1, que especifican:
El nombre de RTDPATH.
Las conexiones con las VLE definidas (STORMNGR=VLE1, STORMNGR=VLE2).
El valor IPIF para cada VTSS para la conexión de puerto de VLE en formato ci:p, donde:
c es 0 o 1.
i es A o I.
p es un valor de 0 a 3.
Nota:
En los VSM5, este valor debe coincidir con los valores especificados en la IFF Configuration Status Screen de VSM5. En los VSM 6, este valor debe ser único para cada VTSS, pero no corresponde a un valor real de los puertos TCP/IP de VSM 6.Los medios de MVC de VLE (VMVC) están sujetos a fragmentación y se deben recuperar como MVC reales. No obstante, el proceso de recuperación de VMVC, emplea muchos menos recursos que una recuperación estándar. El umbral de recuperación para un VMVC se especifica mediante el parámetro CONFIG RECLAIM VLTHRES. Cuanto más bajo se configura el valor de VLTHRES, con más frecuencia el VTCS ejecutará la recuperación en los VMVC y provocará mayor capacidad efectiva del VMVS (menos fragmentación).
Se deben definir VOLSER de VMVC para el software del host de MVS y para VLE. Los VMVC se definen para VLE como parte de la configuración de VLE. En las siguientes secciones, se describe cómo definir los VMVC para el software del host de MVS.
Codifique sentencias HSC POOLPARM o VOLPARM para definir las agrupaciones de VMVC.
Por ejemplo, para definir dos agrupaciones separadas para VLE1 y VLE2:
POOLPARM NAME(LEPOOL1)TYPE(MVC) VOLPARM VOLSER(VL0000-VL880) POOLPARM NAME(LEPOOL2)TYPE(MVC) VOLPARM VOLSER(VL2000-VL2880)
Ejecute SET VOLPARM para validar las sentencias POOLPARM o VOLPARM.
SET VOLPARM APPLY(NO)
APPLY(NO) valida las instrucciones sin cargarlas. Si está satisfecho con los resultados, vaya al paso siguiente. De lo contrario, vuelva a procesar las definiciones de volúmenes junto con este paso y, si las definiciones son válidas, vaya al paso siguiente.
Ejecute SET VOLPARM para cargar las sentencias POOLPARM o VOLPARM.
SET VOLPARM APPLY(YES)
En las siguientes secciones, se explica cómo actualizar las políticas de software del host de MVS para dirigir los datos al sistema VLE.
Las clases de gestión especifican cómo VTCS gestiona los VTV. La instrucción de control MGMTclas de HSC define una clase de gestión y sus atributos. Por ejemplo, el parámetro DELSCR de la instrucción MGMTclas especifica si el VTCS suprime los VTV cancelados de los VTSS. Las clases de gestión también pueden apuntar a las clases de almacenamiento, que especifican dónde residen los VTV migrados. La instrucción de control STORclas de HSC define una clase de almacenamiento y sus atributos. Se especifica el sistema VLE como el destino para los VTV migrados mediante la palabra clave STORCLAS STORMNGR. Por ejemplo:
STOR NAME(VLOCAL) STORMNGR(VLESERV1) DEDUP(YES) STOR NAME(VREMOTE) STORMNGR(VLESERV2)DEDUP(YES)
Las instrucciones anteriores definen una clase de almacenamiento “local” (VLOCAL) en la VLE1 y una clase de almacenamiento “remoto” (VREMOTE) en la VLE2. Como lo especifican estas instrucciones STORCLAS, todas las migraciones a la clase de almacenamiento VLOCLAL o VREMOTE deben dirigirse a los VLE especificados. Se especifica anulación de duplicación para ambas clases de almacenamiento.
Si se desea, se puede ser menos restrictivo que esto. Por ejemplo, si se define un MVCPOOL que contiene VMVC y MVC, se pueden establecer políticas de migración para migrar a un VLE. No obstante, si el VLE está completa o no está disponible, siga migrando a medios de cinta reales (MVC). Por ejemplo, la agrupación MVC DR se define de la siguiente manera:
POOLPARM NAME(DR)TYPE(MVC) VOLPARM VOLSER(VL0000-VL0100) VOLPARM VOLSER(ACS000-ACS099)
Por lo tanto, la agrupación DR contiene MVC y VMVC. Una clase de almacenamiento que especifica DR de agrupación migrará primero a VMVC y solamente utilizará MVC si no hay VMVC disponibles.
Ejemplo:
STOR NAME(DRCLASS) MVCPOOL(DR)DEDUP(YES)
Este método es valioso si se tiene una configuración en la que hay un ACS y un VLE conectados a los sistemas VTSS.
A continuación, para especificar la migración a VLE, se especifican las clases de almacenamiento de VLE definidas mediante el parámetro MGMTCLAS MIGPOL. Por ejemplo:
MGMT NAME(M1) MIGPOL(VLOCAL,VREMOTE) MGMT NAME(M2) MIGPOL(DRCLASS)
La clase de gestión M1 migra una copia de VTV a la VLE “remota” y una copia a la VLE “local”. La clase de gestión M2 migra una sola copia de VTV a la clase de almacenamiento que apunta a la agrupación de MVC “mixta” que contiene MVC y VMVC.
Nota:
Además de dirigir la migración a una VLE también considere lo siguiente:Si se ejecuta en ELS 7.0 o superior, se pueden utilizar MIGRSEL y MIGRVTV de HSC para ajustar la migración a VLE. Mediante estas instrucciones, se puede hacer que la migración de datos en una clase de gestión comience en una clase de almacenamiento antes que en otra. Por lo general, este método se utiliza para garantizar que se cree una copia de DR crítica en cuanto sea posible. Para obtener más información, consulte Configuración de HSC y VTCS.
En un sistema VLE 1.1 o posterior, si hay varios VLE conectados entre sí y al VTSS, por defecto, VTCS da preferencia a VLE para que las conexiones de VLE creen varias copias de VTV. Este comportamiento se puede controlar, según se describe en Control de copia de VLE a VLE.
Para las conexiones de VLE a VLE, si una copia de VTV reside en un VTSS y también en una VLE y usted quiere migrarla a la VLE conectada, la opción por defecto es usar la conexión de VLE a VLE. Por ejemplo, un escenario de DR con una VLE local (LOCVLE) y una VLE remota (REMVLE) conectada a VTSSA. Usted quiere migrar dos copias de VTV:
Primero, una copia local de VTSSA a LOCVLE.
Segundo, una copia que utiliza una copia de VLE a VLE desde LOCVLE a REMVLE mediante replicación de VLE a VLE (en lugar de migración de VTSS a VLE).
Para crear las copias de VTV deseadas, haga lo siguiente:
Cree una sentencia STORCLAS que envíe una copia de VTV a LOCVLE.
STORCLAS NAME(FORLOCAL) STORMNGR(LOCVLE)
Cree una sentencia STORCLAS que envíe una copia de VTV a REMVLE.
STORCLAS NAME(FORREMOT) STORMNGR(REMVLE)
Cree sentencias MGRVTV que especifiquen que las migraciones a la clase de almacenamiento FORLOCAL se realizan antes que las migraciones a la clase de almacenamiento FORREMOT.
MIGRVTV STOR(FORLOCAL) INITIAL MIGRVTV STOR(FORLOCAL) SUBSEQNT(360)
Por último, cree una sentencia MGMTCLAS que especifique dos copias VTV, una para el sitio local y una para el sitio remoto:
MGMTCLAS NAME(DRVLE) MIGPOL(FORLOCAL,FORREMOT)
Para enrutar datos a VLE, primero cree un comando POLICY de SMC que especifique una clase de gestión de VLE. Luego, cree sentencias TAPEREQ de SMC que enruten la carga de trabajo deseada a la política de SMC VLE. Por ejemplo:
POLICY NAME(VLEDR) MEDIA(VIRTUAL) MGMT(DRVLE)
TAPEREQ DSN(HR.**) POLICY(VLEDR)
En el ejemplo anterior, se asigna la política VLEDR a todos los juegos de datos de cinta con un HLQ de HR.