Bienvenido a “Lista de tareas que debe realizar el VTCS (en algún momento)”, también conocida como “Lista de tareas según las necesidades”. Por ejemplo, supongamos que esta semana decide ejecutar DELETSCR para reducir a cero una lista de VTV marcados como nuevos que están usando una gran cantidad de su valioso espacio en el VTSS y el MVC. Muy bien, buen trabajo. ¿Cuánto tiempo cree que deberá pasar hasta que deba ejecutar nuevamente la misma operación? ¿En especial, si no cambia las políticas de supresión de volúmenes nuevos? Respuesta: Es posible que pase un día, un mes o un año, pero deberá hacerlo nuevamente.
Sin embargo, no se preocupe. En este documento, se analizan los procedimientos útiles para ayudarlo a reducir la lista de tareas que debe realizar (en algún momento) y, como pudo notar en la lectura de "Uso del panel de control de VTCS", si controla de cerca los informes del MVC y el VTV, es posible que incluso no necesite una lista, ya que los informes le indican cuándo es el momento de realizar las tareas necesarias o las tareas que surgen según las necesidades.
Además, hay otra clase de “Tareas que debe realizar (en algún momento)” que son prácticamente decisiones de la política, pero se incluyen aquí porque (a) son preventivas por naturaleza, lo que hace que sean doblemente valiosas como mejores prácticas de tareas “que surgen según las necesidades” y (b) son técnicas operativas que puede usar, retirar y volver a introducir, ya que benefician (o no) a su planta en un momento determinado. Dicho esto, comience con tres de nuestros puntos favoritos de esta categoría, como se describe en "Realización de recuperaciones de espacio bajo demanda, migraciones y recuperaciones".
Estas tareas son opcionales pero, especialmente en el caso de las recuperaciones de espacio bajo demanda, se recomienda el uso de las mejores prácticas por motivos que pronto serán obvios.
Como sabe, el VSM recupera automáticamente espacio del MVC en cada uno de los hosts que ejecutan recuperaciones, la palabra clave es automáticamente. Eso significa que la recuperación siempre está trabajando y, aunque es una tarea en segundo plano, si tiene muchos MVC fragmentados, el trabajo de recuperación de espacio puede interferir seriamente con la migración o la recuperación, en especial, durante los períodos de procesamiento de mayor actividad.
Si el resumen del MVC o el comando Display MVCPool muestran un alto nivel de fragmentación en los MVC del sistema (y este nivel se encuentra por debajo del valor especificado en el parámetro CONFIG RECLAIM THRESHLD o en el parámetro MVCPool THRESH), es posible que desee programar la recuperación de espacio en el MVC bajo demanda como un trabajo por lotes en las horas de menor actividad.
Las recuperaciones de espacio en el MVC bajo demanda se realizan con RECLaim. Abra la Referencia de comandos, sentencias de control y utilidades de ELS y verá algunas herramientas útiles que puede usar para optimizar la recuperación bajo demanda y ejecutarla de manera más eficaz:
Puede usar solamente uno de los parámetros MVCPOOL, STORCLAS, ACSid o MVC para filtrar la lista de MVC que se procesarán. Los informes del MVC y el VTV, como se describe en "Uso del panel de control de VTCS", lo ayudan a acotar la lista de posibles candidatos para una agrupación de MVC, una clase de almacenamiento, un ACS específico, o un rango o lista de MVC. Introduzca esta lista en RECLaim y estará usando la herramienta adecuada para el trabajo.
Tenga en cuenta que si no especifica uno de estos parámetros, la recuperación de espacio selecciona los MVC de la agrupación de MVC con nombre (si se ha implementado) o del tipo de medio (para entornos de medios con varios MVC), en la mayoría de los casos frente a la necesidad de liberar espacio.
Los parámetros MAXMVC (máximo de MVC procesados por una única tarea de recuperación de espacio), THRESH (porcentaje fragmentado de MVC que lo convierte en un candidato de reclamo) y CONMVC (número máximo de MVC que el VTCS procesa simultáneamente para drenaje y recuperación) le permiten sustituir los parámetros globales correspondientes de CONFIG RECLAIM para la recuperación bajo demanda. Esto le brinda la capacidad de ajustar las migraciones bajo demanda para que sean más o menos intensas que las migraciones automáticas.
NOWAIT es una manera de acelerar el proceso y CONMVC es otro método de ajuste para influenciar el número de MVC procesados por vez (consulte Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información).
ELAPSE es una manera de detectar si se han producido recuperaciones bajo demanda durante el intervalo que especifica. Si no hay recuperaciones en este período, el trabajo se detiene.
Además, tenga en cuenta que el VTCS aplica el factor de limitación más estricto. Por ejemplo, si ejecuta RECLAIM y especifica el valor de ELAPSE igual a 5 horas y el valor de MAXMVC igual a 10 horas, y el VTCS recupera 10 MVC en una hora, el VTCS finalizará la recuperación antes de que caduque el valor de ELAPSE.
El VTCS y el HSC deben estar activos para procesar una solicitud de RECLAIM.
Como se indicó anteriormente, el VTCS/ELS es básicamente un servidor. Por ejemplo, el VSM gestiona automáticamente el espacio del VTSS y migra los VTV para asegurar un equilibrio de disponibilidad óptima de datos, uso de recursos y protección de datos.
Eso es ideal para un entorno estable, pero ¿qué ocurre si detecta que el sistema del VSM está a punto de recibir una gran cantidad de datos de aplicación? Respuesta: Es posible que sea el momento de ejecutar un trabajo de migración por lotes bajo demanda para liberar espacio del VTSS antes de que se produzca el evento de procesamiento de cintas de mayor actividad mencionado anteriormente.
Las migraciones bajo demanda se realizan, por supuesto, con MIGRATE, que proporciona las siguientes opciones:
Puede migrar VTV:
por volser (se permiten repeticiones),
por clase de gestión,
por el nombre del juego de datos asociado con el VTV (este es el método más eficaz).
También existe la opción DELETE(YES) que posiblemente desee emplear, que suprime el VTV del espacio del VTSS después de que se completa correctamente una migración. Generalmente, usará DELete (YES) (valor predeterminado) para los VTV a los que probablemente no se accederá nuevamente. Como alternativa, puede especificar DELete (NO) para garantizar que los datos críticos estén disponibles y se migren rápidamente para los VTV a los que posiblemente se acceda nuevamente.
La opción NOWAIT lo ayuda a acelerar el proceso. Eso es todo en relación con el uso de MIGRATE Format 1; consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información.
Como alternativa, puede usar MIGRATE Format 2 para realizar una migración a umbral bajo demanda para todos los VTSS o para un VTSS específico. Es una buena herramienta para hacer lo que desee con la DBU y el VTCS se encargará de los detalles.
Además, tenga en cuenta que, con SET MIGopt, puede disminuir el AMT alto para forzar la migración bajo demanda de manera eficaz.
El VTCS proporciona un proceso de recuperación automático que se inicia cuando un trabajo solicita un juego de datos en un VTV que se migra a una cinta, pero que no reside en el VTSS. Sin embargo, ¿qué ocurre cuando se presenta una situación opuesta a la anterior? Por ejemplo, si está realizando el procesamiento de fin de año y sabe que hay una cantidad de trabajos que desean leer datos desde los VTV que están únicamente en la cinta. La recuperación bajo demanda es la solución.
RECALL le proporciona toda la flexibilidad de control que necesita:
Al igual que con MIGRATE, puede recuperar VTV por volser, clase de gestión o nombre del juego de datos asociado.
Puede especificar el VTSS en el que desea recuperar los VTV. De lo contrario, el valor predeterminado es el VTSS de creación y hay algunas consideraciones asociadas con la política de recuperación del VTSS. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información.
RECALWER le permite especificar si desea recuperar VTV con comprobaciones de datos de lectura.
Existe la opción NOWAIT para acelerar el proceso.
Hay muchos aspectos de la gestión de las RTD que puede restringir a “Búsqueda y resolución de problemas del VTCS”, ya que son casi exclusivamente escenarios de recuperación de errores. Las mejores prácticas para las RTD deben ser suficientes y mantener todo mencionado anteriormente en funcionamiento. Recuerde que las RTD se usan para migraciones, recuperaciones y reclamos, de modo que el mantenimiento de las RTD para todos estos trabajos es un acto de equilibrio crítico. Para ajustar esta combinación mediante los parámetros operativos, consulte "Comprobación del estado de cintas virtuales (diaria)".
Además del ajuste de los parámetros operativos de las RTD, cuenta con otra herramienta principal para las RTD, el comando VTCS Vary RTD, que se usa para cambiar los estados de las RTD. Puede cambiar el estado de las RTD a en línea, fuera de línea o modo de mantenimiento si necesita realizar un mantenimiento en las RTD.
Las principales tareas que probablemente surgirán según las necesidades están relacionadas y las primeras dos usan Vary RTD:
"Cambios de tipos de dispositivos de las RTD", que consiste esencialmente en cómo realizar una actualización de tecnología en algunas o todas las RTD del sistema.
Deberá considerar la manera en la que especifica los medios del MVC. Aunque estas son realmente consideraciones para el MVC, se producen debido a un cambio en los tipos de dispositivos de las RTD. Para obtener más información, consulte Configuración del HSC y el VTCS.
Use el siguiente procedimiento para cambiar los tipos de dispositivos de las RTD. Tenga en cuenta que el cambio de los tipos de dispositivos de las RTD requiere que detenga el VTCS en todos los hosts.
Para cambiar los tipos de dispositivos de las RTD, realice lo siguiente:
Revise las políticas del VSM.
Por ejemplo, es posible que desee revisar las definiciones de clase de gestión y clase de almacenamiento si este tipo de dispositivo de RTD se usa para migraciones.
Cambie las RTD anteriores fuera de línea al VTCS.
Si los nuevos dispositivos de RTD usan una nueva dirección de dispositivo de MVS, realice lo siguiente:
Defina las nuevas direcciones en el MVS.
Ejecute DECOMP para mostrar la salida de las sentencias CONFIG.
Edite las sentencias CONFIG para cambiar las direcciones de RTD a los nuevos valores.
Ejecute CONFIG RESET.
Precaución:
No cambie los nuevos transportes en línea al MVS. De lo contrario, se podrían asignar como transportes Nearline.Instale las nuevas RTD.
Cambie los LSM en los que se sustituyó el estado de los transportes al estado fuera de línea.
Cambie los LSM en los que se sustituyó el estado de los transportes al estado en línea.
Cambie las RTD nuevas en línea al VTCS.
Si es necesario, agregue MVC.
Para obtener más información, consulte "Agregación de MVC".
Como sabe, es un poco complicado limitar un análisis a una de las entidades virtuales. Los MVC contienen VTV, de modo que es difícil hablar acerca de uno de ellos de forma aislada, porque inevitablemente terminará hablando acerca del otro. Además, si está analizando los VTV, también estará hablando de los VTSS y los VTD.
Dicho eso, las siguientes secciones tratan algunos de los procedimientos básicos para realizar las tareas típicas más comunes con los MVC que “surgen según las necesidades” y se realizan por una variedad de motivos. Por ejemplo, es posible que desee agregar MVC porque se está agotando el espacio, como se describe en el escenario anterior, o porque están siendo preventivo y no desea que surjan problemas.
Nota:
Si suprime MVC de la configuración como resultado del procesamiento de SET VOLPARM o CONFIG MVCVOL:No puede volver a introducir los volser en la configuración como VTV.
No use los volser para las cintas nativas de HSC.
El mensaje SLS6944I indica el número de MVC que se suprimieron.
ELS 7.2 ha facilitado mucho la agregación de volúmenes. Ahora puede usar las sentencias VOLPARM y POOLPARM del HSC para definir todos los volúmenes y sus subagrupaciones: volúmenes Nearline nativos, cartuchos de limpieza, MVC y VTV, y la utilidad SET VOLPARM del HSC para cargarlos. Para obtener más información, consulte Configuración del HSC y el VTCS y la Referencia de comandos, sentencias de control y utilidades de ELS.
Para agregar MVCS:
Cree una sentencia VOLPARM para definir los MVC.
Por ejemplo, para definir un rango de volúmenes T10000 completos para cifrar:
VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE)
Cree una sentencia POOLPARM para definir la agrupación del MVC.
Por ejemplo, para definir la agrupación T10000 del MVC con parámetros de recuperación:
POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)
Cree o actualice las sentencias MGMTCLAS o STORCLAS según sea necesario.
Por ejemplo, si agregó un nuevo tipo de medio del MVC, siga las recomendaciones de Configuración del HSC y el VTCS.
Actualice los parámetros de salida POLICY o TAPEREQ según sea necesario.
Por ejemplo, si creó una nueva clase de gestión en el paso 3, actualice o cree sentencias TAPEREQ o POLICY para apuntar a la nueva clase de gestión.
¿Necesita definir los VTV?
Si la respuesta es afirmativa, vaya a "Definición de los VTV". De lo contrario, vaya a "Validación y aplicación de definiciones de volúmenes".
Para definir los VTV:
Cree sentencias POOLPARM o VOLPARM para definir los VTV.
Por ejemplo, para definir dos rangos de VTV para uso de los hosts MVS1 y MVS2:
POOLPARM NAME(SYS1VTV1)TYPE(SCRATCH) VOLPARM VOLSER(V5000-V5499)MEDIA(VIRTUAL) POOLPARM NAME(SYS1VTV2)TYPE(SCRATCH) VOLPARM VOLSER(V5500-V5999)MEDIA(VIRTUAL)
Vaya a "Validación y aplicación de definiciones de volúmenes".
Ejecute SET VOLPARM para validar las sentencias VOLPARM/POOLPARM.
SET VOLPARM APPLY(NO)
APPLY(NO) valida las sentencias sin cargarlas. Si está conforme con los resultados, vaya al paso 2. De lo contrario, vuelva a procesar las definiciones de volúmenes y, a continuación, vaya al paso 2.
Ejecute SET VOLPARM para cargar las sentencias VOLPARM/POOLPARM.
SET VOLPARM APPLY(YES)
Introduzca físicamente los cartuchos reales en el ACS.
Para obtener más información, consulte "Introducción de cartuchos".
¿Por qué debería extraer MVC de la agrupación? Un escenario típico sería si cambia unidades anteriores por una nueva actualización de tecnología para las RTD y desea retirar los medios anteriores. En ese caso, agregará nuevos MVC a la agrupación, tal como se describe en Agregación de MVC y, a continuación, extraerá los medios anteriores, como se describe en "Extracción permanente de los MVC".
Tenga en cuenta que hay ocasiones en las posiblemente desee extraer temporalmente los MVC de la agrupación. Por ejemplo, si tiene medios con errores o sospecha que hay medios con errores. Deseará extraer el medio con errores y colocar sustitutos, básicamente en los mismos volsers, como se describe en "Extracción temporal de MVC".
Para extraer de forma permanente los MVC de la agrupación, realice lo siguiente:
Introduzca MVCDRain para drenar los MVC.
Por ejemplo, para ejecutar MVCDRain para drenar los MVC en la clase de almacenamiento STORCL1, expulse de forma virtual los MVC y para regresar después de que se haya enviado la solicitud, introduzca lo siguiente:
MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT
Si los MVC ya no son necesarios en un ACS, use el comando Eject del HSC para expulsar los MVC del ACS.
Elimine las restricciones de seguridad y las restricciones del sistema de gestión que definió para el MVC.
Si usa las definiciones VOLPARM and POOLPARM y el nivel del CDS es G o superior, continúe con el paso 4. De lo contrario, vaya al paso 5.
Si desea volver a usar el volser de cinta para uso de Nearline (no de VTCS) y usar las definiciones VOLPARM/POOLPARM:
Actualice las sentencias POOLPARM/VOLPARM para los MVC que desea eliminar.
Ejecute SET VOLPARM APPLY(YES) en todos los hosts para aplicar los cambios.
Ejecute el comando SCRAtch del HSC para marcar los volúmenes que ya no son MVC como nuevos.
Si desea volver a usar el volser de cinta para uso de Nearline (no de VTCS) y no usar VOLPARM and POOLPARM, deberá realizar una de las siguientes acciones:
Ejecute el comando EJECT del HSC para extraer los MVC del ACS.
Cambie la etiquete de código de barras externa del cartucho.
Deberá cambiar la etiqueta de código de barras externa, ya que los volsers originales del MVC se conservan en el CDS y estos volsers son únicamente para uso como MVC.
INTRODUZCA los cartuchos nuevamente en el ACS.
O bien
Cree un nuevo juego de datos del CDS.
Ejecute la utilidad MERGECDS del HSB; para ello, especifique DELVirt para eliminar los rangos de MVC no deseados.
Nota:
Se deberán detener todos los HSC cuando se use esta opción, ya que se crean nuevos juegos de datos del CDS.Para extraer de forma temporal los MVC de la agrupación:
Introduzca MVCDRain Eject para el MVC.
Por ejemplo, para ejecutar MVCDRain para drenar los MVC en la clase de almacenamiento STORCL1, expulse de forma virtual los MVC y para regresar después de que se haya enviado la solicitud, introduzca lo siguiente:
MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT
Esto realiza lo siguiente:
Recupera todos los VTV en el MVC y vuelve a migrarlos a los nuevos MVC.
Hace que el MVC no se pueda seleccionar para las migraciones del VTCS.
Para regresar el MVC a la agrupación de MVC, introduzca MVCDRain para el MVC.
La introducción de MVCDRain sin el parámetro EJect para el MVC hace que esté nuevamente disponible.
Por ejemplo, para ejecutar MVCDRain para drenar los MVC en la clase de almacenamiento STORCL1 y regresar después de que se haya enviado la solicitud, introduzca lo siguiente:
MVCDRAIN STORCLAS(STORCL1) NOWAIT
Nota:
Como alternativa, puede usar MVCMAINT para marcar un MVC como de solo lectura. Esto evita que el VTCS seleccione el MVC para migraciones, pero no elimina los VTV del MVC. También puede usar MVCMAINT para desactivar la marcación de solo lectura.Si usa las definiciones VOLPARM/POOLPARM, la opción NOMIGRAT se puede especificar en la sentencia POOLPARM para evitar que los MVC se usen para nuevas migraciones.
Use MVCDRain para “drenar” un MVC (recuperar todos los VTV en el MVC). Generalmente, se drena un MVC por los siguientes motivos:
Un informe o Display de MVC muestra errores de comprobación de datos del MVC. El VSM no migra al MVC y debe extraerlo de la agrupación de MVC.
Un informe o Display de MVC muestra errores diferentes a los errores de comprobación de datos del MVC.
Una clase de almacenamiento o agrupación de MVC con nombre ya no está en uso, y desea extraer y reutilizar los MVC asociados.
Para seleccionar los MVC para drenar, puede especificar uno de los siguientes parámetros:
MVCid para drenar uno o más MVC por volser.
MVCPOOL para drenar los MVC en una agrupación de MVC con nombre. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre las agrupaciones de MVC con nombre.
STORCLAS para drenar los MVC en una clase de almacenamiento. Consulte la Referencia de comandos, sentencias de control y utilidades de ELS para obtener más información sobre las clases de almacenamiento.
Puede usar MVCDRain para sustituir la configuración de CONFIG RECLAIM CONMVC. Puede ejecutar MVCDRain desde cada host, que inicia las tareas de drenaje en ese host con el mismo valor que CONMVC. Estas tareas de drenaje se pueden ejecutar simultáneamente con tareas de drenaje iniciadas por otros hosts.
También, tenga en cuenta lo siguiente:
Para los VMVC, MVCDRAIN con el parámetro EJECT elimina físicamente los VTV.
Precaución:
Si usa la utilidadDRCHKPT o el parámetro CONFIG GLOBAL PROTECT para proteger el contenido de copia de seguridad del CDS para los VMVC, la especificación de MVCDR EJECT invalida el contenido del VMVC de la copia de seguridad del CDS.Para ambos VMVC y MVC, MVCDRAIN sin el parámetro EJECT no suprime los VTV, pero actualiza el registro del CDS para no mostrar VTV en el VMVC/MVC.
Para obtener más información, consulte la Referencia de comandos, instrucción de control y utilidades de ELS.
MVCMAINT es una herramienta útil similar de VSM Land y los parámetros describen sus capacidades:
En primer lugar, el volser del MVC (rango, lista, volser individual) o MANIFEST son dos criterios de selección del MVC. El volser del MVC tiene sentido, ¿pero por qué MANIFEST? Puede crear un archivo de manifiesto (una lista de MVC y de los VTV que contienen) cuando ejecuta EXPORT, que es algo que posiblemente desee hacer cuando mueva los MVC de un sistema a otro. Cuando importa los MVC en el nuevo sistema, probablemente sea una buena idea si inician sus nuevas vidas en modo de solo lectura, de modo que no se sobrescriban hasta que los pueda definir correctamente.
READONLY (ON u OFF). Consulte la viñeta anterior. Además, ¿recuerda el análisis acerca de cómo agregar MVC a la agrupación? Es posible que desee introducirlos en el ACS con estado nuevo, pero algunas plantas incorporan todo con estado no marcado como nuevo y luego lo resuelven. Si necesita marcar los MVC nuevos con capacidad de escritura, MVCMAINT READONLY(OFF) es la herramienta.
LOST (ON u OFF). ¿Cómo se pierde un MVC? Por ejemplo, ¿se pueden perder los MVC? Créalo o no, se pueden perder. Por ejemplo, si un montaje de MVC iniciado por el VTCS no se completa (en oposición a si se completa con un error), el VTCS marca el MVC como “perdido” en el CDS y lo elimina de las preferencias.
Los VTV de multiplexión que residen en un MVC “perdido” se recuperan desde un MVC alternativo. El VTCS no intenta usar los MVC “perdidos” para migración a menos que no haya otros MVC válidos. Cuando un MVC con estado “perdido” se monta correctamente, el estado “perdido” se elimina del registro del MVC.
¿Qué ocurre si sabe que el MVC no está realmente perdido? Respuesta: Puede usar MVCMAINT para desactivar el estado LOST.
Este es un uso interesante de MVCMAINT digno de mención. ¿Qué ocurre si tiene un LSM que está temporalmente en modo manual? Es posible que desee (temporalmente) eliminar las preferencias de la selección del MVC en ese LSM y podrá hacer esto con LOST(ON). A continuación, cuando el LSM esté nuevamente en modo automático, invierta el proceso con LOST(OFF).
ERROR (ON u OFF). Un MVC puede (erróneamente) entrar en estado de error, por diferentes motivos, por ejemplo:
El VTCS no reconoce el volumen montado en la RTD como un MVC. Esto puede ser causado por algún trabajo de MVS que está sobrescribiendo el MVC. Determine qué ocurrió con el MVC. Si ya no contiene datos de VTV válidos, reinicialice el volumen y regréselo a la agrupación del MVC.
El MVC no se puede escribir, esto puede deberse a que el ajuste está definido en solo lectura o a que el paquete de seguridad no permite que el VTCS escriba en el volumen. Restablezca el ajuste o cambie las reglas del paquete de seguridad para permitir la escritura en el MVC.
Se ha detectado un ID de bloqueo erróneo y debe auditar (en el VTCS) el MVC para intentar corregir la condición.
Después de corregir la condición de error como se describe, use MVCMAINT para restablecer el estado del MVC a ERROR(OFF).
EJECT (ON u OFF) especifica el estado de “expulsión lógica” del MVC. ¿Cómo se define este estado y por qué es posible que desee cambiarlo? Si drena de forma explícita un MVC mediante MVCDRAIN, probablemente se deba a que cree que el medio es erróneo, de modo que elimina la preferencia mediante la configuración del estado de “expulsión lógica”. A continuación, expulsa realmente el MVC, ejecuta algunas pruebas, descubre que todo es correcto y vuelve a introducirlo. En ese punto, use MVCMAINT) para configurar EJECT(OFF).
A continuación, se muestra un grupo de atributos de MVC específicos de los medios T9840/T9940, todos con conmutadores ON/OFF:
WARRANTY. El VTCS también detecta la caducidad de la garantía de medios y configura el estado WARRANTY en ON. De forma alternativa, puede usar la SMF, los datos de LOGREC o sus informes de MVC y VTV para detectar los MVC que están llegando al final de su vida útil y usar MVCMAINT para configurar manualmente el ajuste WARRANTY en ON. Si sabe que la garantía ha caducado, puede planear la sustitución de medios antes de que lleguen al final de su vida útil (consulte la viñeta siguiente). ¿Qué ocurre si sabe que un MVC se marcó de forma errónea con el estado de garantía caducada? Respuesta: Simplemente use MVCMAINT para restablecer el estado de garantía caducada.
RETIRED. El VTCS también detecta automáticamente el final de la vida útil de los medios y configura el estado RETIRED en ON. Como arriba, puede usar la SMF, los datos de LOGREC o los informes del MVC y el VTV para detectar los MVC que están llegando al final de su vida útil, y puede usar MVCMAINT para configurar manualmente el ajuste de RETIRED en ON, o restablecer el estado de RETIRED a OFF para los MVC que se han marcado erróneamente como retirados.
El VTCS detecta automáticamente una región de información de medios (MIR) no válida y configura el estado de INVLDMIR en ON. Puede recuperar la MIR mediante el uso de la utilidad disponible desde el panel del operador para el transporte o mediante el uso de la utilidad disponible mediante el MPST. Una vez que haya recreado la MIR, podrá usar MVCMAINT para configurar INVLDMIR en OFF para el MVC.
Nota:
La ejecución de MVCMAINT también produce un informe de MVC de los volúmenes afectados por el trabajo de MVCMAINT.La utilidad MEDVERfy realiza la verificación de medios (MV), verifica que los datos del VTV se pueden leer en los MVC o en los VMVC (ELS 7.1 y VLE 1.2, y versiones posteriores). Para la VLE, MEDVERfy garantiza que los VMVC con duplicación anulada se puedan “rehidratar” (reconstituir).
La utilidad informa acerca de los MVC que pasan o no la verificación, y también produce salidas XML. Para obtener más información acerca de la utilidad MEDVERfy, consulte Referencia de comandos, sentencias de control y utilidades de ELS.
En las siguientes secciones, se muestran ejemplos de cómo usar la utilidad MEDVERfy para MV.
MEDVERFY MVC(VMC000)
En este ejemplo:
MEDVERfy selecciona un único VMVC.
MAXMVC muestra el valor predeterminado 99.
CONMVC muestra el valor predeterminado 1, por lo tanto, solamente se procesa un MVC por vez.
No se especifica ningún timeout.
MEDVER MVCPOOL(MP1)
En este ejemplo:
MEDVERfy selecciona MVC en la agrupación de MVC MP1 para procesamiento.
FREQency no se especifica y MAXMVC usa el valor por defecto 99, de modo que MEDVERfy selecciona los mejores 99 candidatos de MVC según la hora de la última verificación.
CONMVC muestra el valor predeterminado 1, por lo tanto, solamente se procesa un MVC por vez.
No se especifica ningún timeout.
MEDVER MVC(MVC000-MVC049) CONMVC(2) TIMEOUT(720)
En este ejemplo:
MEDVERfy selecciona un rango de 50 volsers del MVC para procesamiento.
FREQency no se especifica y MAXMVC usa el valor por defecto 99, de modo que MEDVERfy procesa todos los 50 MVC especificados.
El valor de CONMVC es 2, de modo que MEDVERfy procesa dos MVC simultáneamente.
MEDVERfy se ejecuta durante 12 horas antes del timeout.
MEDVER STORCLAS(SC1) MAXMVC(50) FREQ(365)
En este ejemplo:
MEDVERfy selecciona MVC en la clase de almacenamiento SC1 para procesamiento.
El valor de MAXMVC es 50 y FREQency especifica 365 días, de modo que MEDVERfy selecciona los 50 mejores candidatos del MVC que no se han verificado durante un año o más.
CONMVC muestra el valor predeterminado 1, por lo tanto, solamente se procesa un MVC por vez.
No se especifica ningún timeout.
La principal tarea que puede realizar con los VTSS, según sea necesario, es usar el comando o la utilidad VTCS Vary VTSS para cambiar un estado en línea o fuera de línea a un estado desactivado. Sepa siempre lo que hace y porqué lo hace, cuando cambie un VTSS fuera de línea al estado desactivado. El porqué probablemente sea que el VTSS necesita mantenimiento o tal vez cambie el estado para eliminarlo de la configuración. Este tema se trata en "Detección y corrección de problemas del VTCS".
Sin embargo, en primer lugar, el siguiente gráfico muestra qué ocurre cuando cambia un VTSS a cada uno de los modos admitidos (y porqué debe usar preferentemente el estado QUIESCED en lugar del estado OFFline, si es posible).
| Parámetro de Vary VTSS especificado | Primer estado del VTSS | Siguiente estado del VTSS |
|---|---|---|
|
ONline |
Online Pending: en el estado pendiente en línea, el proceso en línea se ha iniciado pero no se ha completado en todos los hosts. |
Online: en el estado en línea, el VTSS está en línea y disponible, y acepta los trabajos de la interfaz del usuario y del servidor. Si el VTSS está fuera de línea, cuando vuelve a estar en línea ejecuta un mensaje de advertencia que recomienda una auditoría del VTCS. |
|
QUIESCED |
Quiescing: en estado desactivado, el VTCS no direcciona asignaciones de DD al VTSS, pero aún acepta montajes pendientes para permitir trabajos de larga duración con cadenas unit=aff para completar. Cuando ya no se está usando ninguna VTD (los UCB no están asignados en el MVS), el VTSS cambia al estado desactivado. En el estado desactivado, el VTSS continúa aceptando y procesando el trabajo del servidor; por ejemplo, migraciones, recuperaciones y auditorías. |
Quiesced: en el estado desactivado, el VTSS continúa aceptando y procesando el trabajo del servidor; por ejemplo, migraciones, recuperaciones y auditorías. Es decir, puede usar los comandos de recuperación y migración, y las utilidades para llevar a cabo estas operaciones mediante el VTSS desactivado. |
|
OFFline |
Offline Pending: en el estado pendiente fuera de línea, el proceso fuera de línea se ha iniciado pero no se ha completado en todos los hosts. El VTCS apaga de inmediato el VTSS e interrumpe y depura todas las tareas activas, y depura todas las tareas en cola. La tarea del servidor del VTSS finaliza y ya no acepta nuevos trabajos de la interfaz del usuario ni del servidor. El VTCS crea nuevos VTV y monta o desmonta los VTV existentes únicamente en VTSS alternativos, si están disponibles. |
Offline: en estado fuera de línea, el VTSS está fuera de línea en todos los hosts y no acepta trabajos de la interfaz del usuario ni del servidor. Si una copia del VTV reside en un VTSS fuera de línea y además en un MVC, y un trabajo requiere el VTV, el VTCS recupera automáticamente el VTV en un VTSS alternativo, si está disponible. |
Nota:
En un entorno de cliente y servidor (el MVS/CSC y LibraryStation, o el servidor HTTP del SMC en hosts del cliente), el VTCS no puede determinar si los trabajos de larga duración están activos en los hosts del cliente. Después de que el VTSS entra en un estado fuera de línea, deberá (a) cambiar de forma explícita las VTD fuera de línea al MVS o (b) asegurarse de que haya cesado la actividad en el host del cliente.En configuraciones de VTSS en cluster o replicación cruzada entre sistemas TapePlex (CTR), los CLINK del VTSS se deberán cambiar al estado fuera de línea para detener la replicación y el procesamiento de exportación electrónica.
Antes de realizar el servicio de un VTSS, desactive el VTSS de la siguiente manera:
En todos los hosts, cambie el estado de las VTD del VTSS a fuera de línea.
En todos los hosts, espere que los dispositivos estén fuera de línea. Tenga en cuenta que las VTD no pasan por el proceso fuera de línea hasta que no dejan de estar asignadas. Si un trabajo de larga duración está usando una VTD, deberá esperar a que se complete el trabajo o cancelar el trabajo.
Cambie el estado QUIESCED del VTSS desde cualquier sistema del VTCS donde esté definido el VTSS con nombre.
Espere a que se muestre el mensaje SLS6742I en cada sistema del VTCS, que indicará que se ha desactivado el VTSS.
Opcionalmente, puede migrar los datos desde el VTSS.
Cambie el estado OFFLINE del VTSS desde cualquier sistema VTCS donde esté definido el VTSS con nombre.
Espere a que se muestre el mensaje SLS6742I en cada sistema del VTCS, que indicará que el VTSS está fuera de línea. Ahora podrá realizar el servicio del VTSS.
Este es el escenario para la extracción de un VTSS: Tiene dos sistemas VSM separados, la carga de trabajo de uno crece mientras que disminuye la carga de trabajo del otro. Solución: saque un VTSS del Sistema A y colóquelo en el Sistema B. La Instalación de ELS analiza cómo agregar un VTSS, de modo que esta sección se restringe a qué debe hacer para extraer un VTSS.
Para extraer un VTSS:
Antes de extraer el VTSS, realice lo siguiente:
No necesitará vaciar un VTSS antes de la supresión. Necesitará garantizar que todos los VTV se hayan migrado completamente. Además, considere cambiar otros parámetros, por ejemplo, las sentencias TAPEREQ, de modo que el trabajo nuevo no se envíe a los VTSS extraídos.
Si se eliminan todos los tipos de un dispositivo o una combinación de ACS del VTSS, asegúrese además que primero se migren completamente. Al igual que arriba, considere cambiar otros parámetros para reflejar las capacidades de migración cambiadas del VTSS (por ejemplo, clases de almacenamiento, que apuntan a clases de almacenamiento que especifican ACS y medios).
Cambie el estado del VTSS a Quiesced (desactivado).
Cuando esté fuera de línea, continúe con el paso 3.
Extraiga los VTSS y, a continuación, vuelva a ejecutar CONFIG para eliminarlo lógicamente.
A continuación, se presenta un JCL de muestra para ejecutar CONFIG con el fin de actualizar la configuración para denegar el acceso del host al VTSS2 que extrajo físicamente de la configuración. En este ejemplo, se especifica la sentencia del VTSS para VTSS2 sin parámetros para denegar el acceso del host a este VTSS.
//UPDATECFGEXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSCNTLDD DSN=FEDB.VSMLMULT.DBASEPRM,DISP=SHR //SLSCNTL2DD DSN=FEDB.VSMLMULT.DBASESEC,DISP=SHR //SLSSTBYDD DSN=FEDB.VSMLMULT.DBASETBY,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * CONFIG GLOBALMAXVTV=32000MVCFREE=40 RECLAIMTHRESHLD=70MAXMVC=40 START=35 VTSSNAME=VTSS1 LOW=70 HIGH=80 MAXMIG=3 RETAIN=5 RTDNAME=VTS18800 DEVNO=8800 CHANIF=0A RTDNAME=VTS18801 DEVNO=8801 CHANIF=0I RTDNAME=VTS18802 DEVNO=8802 CHANIF=1A RTDNAME=VTS18803 DEVNO=8803 CHANIF=1I RTDNAME=VTS18811 DEVNO=8811 CHANIF=0E RTDNAME=VTS18813 DEVNO=8813 CHANIF=1E VTDLOW=8900 HIGH=893F VTSSNAME=VTSS2
Esta sección comprende las principales tareas que probablemente necesite llevar a cabo según surja la necesidad: supresión de VTV nuevos y cambio de los atributos de los VTV.
Nota:
Si suprime VTV de la configuración como resultado del procesamiento de SET VOLPARM o CONFIG MVCVOL:No puede volver a introducir los volser en la configuración como MVC.
No use los volser para las cintas nativas de HSC.
El mensaje SLS6944I indica el número de VTV que se suprimieron.
Existen dos maneras de suprimir VTV nuevos:
Mediante política, con la especificación de DELSCR(YES) en una clase de gestión de VTV y mediante sincronización de volúmenes nuevos del HSC o LCM para realizar la supresión real de los volúmenes.
Mediante tareas específicas, con la utilidad DELETSCR. DELETSCR suprime los VTV nuevos del VTSS y desvincula los VTV migrados del MVC. Los VTV suprimidos se marcan como no inicializados, aunque se conserva la información de versión.
La Instalación de ELS trata la eliminación de VTV nuevos, de modo que la siguiente información analiza la versión de eliminación “según sea necesario”.
Tenga en cuenta la siguiente advertencia:
Precaución:
Cuando usa DELETSCR para suprimir VTV nuevos, los datos de esos VTV desaparecen y no se pueden recuperar.La eliminación de VTV no es algo que haga porque no tiene nada más que hacer. Si debe suprimir VTV nuevos manualmente, se debe a que está en problemas, como se muestra en el escenario .
Para evitar la supresión involuntaria de VTV mediante un comando del operador, DELETSCR es únicamente una utilidad de SLUADMIN y tiene las siguientes capacidades:
Puede especificar VTV por volser (volser individual, lista o rango), clase de gestión o agrupación nueva del HSC. Mediante el uso de los informes del MVC y el VTV, ya tendrá una buena idea de la mejor manera de identificar los candidatos y aplicar la opción DELETSCR correspondiente. Solamente puede especificar una opción (VTVid, MGMTclas o SCRpool) y, si no especifica nada, DELETSCR suprime todos los VTV elegibles. Es posible que esto sea lo que desea, pero piense antes de usar ese método.
El parámetro obligatorio NOTREF especifica los días transcurridos desde que se hizo referencia al VTV (1-999). NOTREF es efectivamente un período de gracia; y los VTV a los que se hace referencia dentro del período de gracia no se suprimen.
Hay un parámetro MAXVTV práctico (opcional) que especifica el número máximo de VTV que suprime DELETSCR. Tenga en cuenta que este es un valor máximo, no un destino. Si ejecuta DELETSCR de manera preventiva durante un período no pico, es posible que no le interese MAXVTV. Si tiene problemas, probablemente le interesará.
Tenga en cuenta que el rango de MAXVTV es de 0 a 999. ¿Qué ocurre si especifica 0? En ese caso, DELETSCR no suprime los VTV, pero el informe de resumen muestra cuántos VTV se han suprimido hasta el momento en el que ejecutó DELETSCR (es decir, el informe es tan solo una instantánea).
Finalmente, podrá ver los resultados del trabajo mediante los informes de DELETSCR, estándares o detallados (mediante la especificación del parámetro DETAIL).
En el siguiente ejemplo, se presenta un JCL de muestra para ejecutar DELETSCR con el fin de suprimir VTV en la clase de administración MC1 a la que no se ha hecho referencia en los últimos 60 días, con un máximo de 800 VTV, y producir un informe detallado.
//DELETSCR EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * DELETSCR MGMTCLAS(MC1) NOTREF(60) MAXVTV(800) DET
VTVMAINT es otra herramienta práctica, esta vez para mantenimiento de VTV, que realiza lo siguiente:
Selecciona los VTV por volser (rango, lista o volser individual, según elija).
Desenlaza los VTV de los MVC, ya que es probable que desee hacer esto si cambia una clase de gestión de VTV, como se describe en "Cambio de clase de gestión del VTV y anulación de enlaces de VTV desde MVC".
Cambia la clase de gestión del VTV. Esto se hace cuando desea que se gestionen los VTV de una manera diferente. Hay otras dos manera de hacer esto, pero la mejor herramienta es claramente VTVMAINT, como se describe en "Cambio de clase de gestión del VTV y anulación de enlaces de VTV desde MVC".
Desmonta de manera lógica los VTV especificados en un VTSS fuera de línea. Esto se explica mejor en "Desmontaje lógico de los VTV en un VTSS fuera de línea".
"Gestión de VTV replicados mediante replicación cruzada entre sistemas TapePlex (CTR)".
Nota:
No olvide que la ejecución de VTVMAINT también produce un informe del VTV de los volúmenes afectados por el trabajo de VTVMAINT.Puede usar VTVMAINT para cambiar una clase de gestión del VTV. Si la nueva clase de gestión especifica una clase de almacenamiento diferente, la ubicación actual del VTV en los MVC es incorrecta. En el siguiente procedimiento, se indica cómo usar VTVMAINT para cambiar una clase de gestión y una clase de almacenamiento del VTV.
Para cambiar una clase de gestión del VTV y desenlazarla:
Recupere el VTV.
El VTV deberá residir en el VTSS para que se pueda realizar correctamente la anulación del enlace en el paso 2.
Use VTVMAINT ULINKMVC para desenlazar el VTV de los MVC en los que se encuentra.
Use VTVMAINT MGMTclas para asignar una nueva clase de gestión.
Vuelva a migrar los VTV para colocarlos en los MVC correctos o consulte Cambio de clase de almacenamiento del VTV con RECONcil para conocer los procedimientos para mover los VTV a MVC según sea necesario.
Si un VTV está montado cuando un VTSS pasa al estado fuera de línea y si existe una copia del VTV en un MVC, el VTCS no recupera los VTV migrados a un VTSS alternativo porque el VTV tiene el estado “montado” en el VTSS fuera de línea. En esta situación, puede usar VTVMAINT para desmontar de manera lógica los VTV del VTSS fuera de línea (desactive la parte “montada” en el CDS) y, a continuación, recupere el VTV en un VTSS alternativo. El VTCS registra todos los desmontajes de VTV exitosos en el campo SMF14STA del registro de SMF, subtipo 14. La opción VTVRPT (UNAVAIL) informa el estado de los VTV no disponibles en un VTSS fuera de línea. Para obtener más información, consulte la Referencia de comandos, sentencias de control y utilidades de ELS.
No desmonte los VTV no disponibles en un VTSS fuera de línea a menos que esté absolutamente seguro de que las copias del MVC, si existen, tengan contenido idéntico al de los VTV no disponibles. De lo contrario, pondrá en riesgo la recuperación de un VTV con datos de una versión anterior en un VTSS alternativo. Por ejemplo, probablemente sea seguro desmontar un VTV montado para lectura para recuperación en un VTSS alternativo. Sin embargo, un VTV montado para escritura probablemente no sea seguro para desmontar, ya que probablemente se haya actualizado y, por lo tanto, las copias del MVC serán de una versión anterior.
En el siguiente procedimiento, se proporcionan los pasos generales para realizar el desmontaje lógico de un VTV y acceder a ese VTV desde un VTSS diferente.
Para desmontar de forma lógica un VTV y acceder a ese VTV desde un VTSS diferente:
Cambie el estado del VTSS afuera de línea para el VTCS con el siguiente comando:
VT VARY VTSS(name) OFFLINE
Si la E/S estaba activa y el VTSS falló, el MVS deberá aislar las VTD y desmontar los VTV montados desde la perspectiva del MVS. Sin embargo, si las comunicaciones con el VTSS fallan antes de que el VTSS haya desmontado realmente los VTV montados, es posible que aún tengan el estado en línea para el VTCS. Por lo tanto, primero deberá cambiar el estado del VTSS a fuera de línea para el VTCS.
Si el MVS aisló las VTD y desmontó los VTV montados, vaya al paso 3. De lo contrario, continúe con el paso 2.
Desmonte el VTV (perspectiva del MVS).
No podrá volver a montar el VTV en un VTD de otro VTSS si el MVS aún considera que está montado en el VTSS fuera de línea. Siga uno de estos pasos:
Use el comando UNLOAD del MVS para desmontar el VTV.
Use VARY OFFLINE para cambiar la VTD a fuera de línea, donde se encuentra montado el VTV, lo que también desmonta el VTV.
Ejecute VTVMAINT; especifique el VTSS fuera de línea y los VTV que desea desmontar de forma lógica.
Por ejemplo, para desmontar de forma lógica los VTV VV6823, VV6825 y VV6688 en VTSS01 fuera de línea, introduzca la siguiente sentencia SLSIN DD en su JCL:
VTVMAINT DISMOUNT VTV(VV6823,VV6825,VV6688) VTSS(VTSS01)
Si existen copias migradas de los VTV desmontados a las que puede acceder un VTSS en línea, ahora puede usar este VTSS para acceder a los VTV.
Precaución:
Si se modificó la copia del VTV montada en el VTSS fuera de línea y no se migró, la copia del MVC que recupera en un VTSS alternativo no estará actualizada. Por lo tanto, Oracle recomienda no recuperar estas copias del MVC que no están actualizadas.Sugerencia:
Cuando el VTSS fuera de línea está listo para volver a estar en línea, Oracle recomienda auditar el VTSS antes de ejecutar trabajos de producción que usen el VTSS. Además, asegúrese de borrar las condiciones de VTD aisladas antes de ejecutar el comando VARY ONLINE del VTSS.Puede usar VTVMAINT para cambiar el estado de los VTV replicados mediante CTR de la siguiente manera:
Use VTVMAINT OWNRPLEX para cambiar los sistemas TapePlex que son propiedad de los VTV.
Use VTVMAINT DELEXpot para eliminar el nombre de un sistema TapePlex que hace referencia a un VTV.
Use VTVMAINT ADDEXpot para agregar el nombre de un sistema TapePlex que hace referencia a un VTV.
Para obtener más información, consulte Guía de gestión de datos fuera del sitio y recuperación ante desastres de ELS.
Como se describe en "Cambio de clase de gestión del VTV y anulación de enlaces de VTV desde MVC", puede usar VTVMAINT para cambiar la clase de gestión de un VTV, que puede, por supuesto, cambiar la clase de almacenamiento. ¿Y si desea mover de forma explícita el VTV de una clase de almacenamiento a otra? Respuesta: use RECONcil.
Antes de enviar el primer trabajo de RECONcil (únicamente para la utilidad SLUADMIN), sepa por qué desea cambiar la clase de almacenamiento de un VTV. Hay esencialmente tres motivos
Igual que arriba, está cambiando de forma explícita la clase de gestión o la clase de almacenamiento de un VTV.
Los VTV están en el medio incorrecto, en el ACS incorrecto o en ambos.
Un ACS no está disponible durante un período considerable de tiempo, luego se coloca nuevamente en línea. En ese caso, primero cambie el parámetro MIGpol en la sentencia MGMTclas para los VTV afectados para que apunten a un ACS diferente (y a un medio, si lo desea). Cuando el ACS original vuelva a estar en línea, cambie el parámetro MIGpol en la sentencia MGMTclas para apuntar al ACS original y, a continuación, ejecute RECONcil. Para ello, especifique las sentencias actualizadas MGMTclas (o STORclas) para mover los VTV al ACS original.
Tenga en cuenta que este análisis trata acerca del uso de RECONcil para conciliar una clase de almacenamiento de VTV incorrecta (medio del MVC o ubicación del ACS incorrectos, o ambos). ¿Qué ocurre si desea mover los VTV a cuyos datos ahora se accede con menor frecuencia desde medios centrados en el acceso (como cartuchos T9840) hasta medios centrados en el almacenamiento (como cartuchos T9940) y un ACS de almacenamiento extendido o externo? En ese caso, generalmente deberá configurar una política de archivo mediante los parámetros ARCHAge/ARCHPol de la sentencia MGMTCLAS, y el movimiento de los VTV se producirá automáticamente según la especificación de ARCHPol cuando se supere el valor de ARCHAge y se recupere y vuelva a migrar el VTV.
Por lo tanto, una política de archivo automática es como una migración automática. Ambas se producen con el tiempo y tiempo es lo que no tiene si uno o más VTV están realmente en el lugar incorrecto. En ese caso, use RECONcil.
Para cambiar el medio o el ACS de un VTV con RECONcil:
Para seleccionar los VTV para validación (es decir, ¿necesitan conciliación?), puede especificar uno de los parámetros de RECONcil:
STORclas: especifica una o más clases de almacenamiento. Aquí, RECONcil realiza lo siguiente:
Busca la definición del ACS y del medio para las clases de almacenamiento especificadas.
Analiza los MVC que se encuentran actualmente en las clases de almacenamiento. ¿El ACS y el medio del MVC coinciden con la definición de la clase de almacenamiento? Si no coinciden, muestre los MVC o VTV con error.
MVC: especifica una lista o rango de MVC. RECONcil realiza lo siguiente:
Determina el ACS actual y el medio para los MVC especificados.
¿El ACS y el medio del MVC coinciden con la definición de la clase de almacenamiento para el MVC? Si no coinciden, muestre los MVC o VTV con error.
MGMTclas : especifica una o más clases de gestión. RECONcil realiza lo siguiente:
Busca la definición del ACS y del medio, como se especifica en el parámetro MGMTclas MIGpol.
Analiza los VTV que se encuentran actualmente en las clases de gestión. ¿Se encuentra el VTV en un MVC con un ACS o medio que coincida con la especificación de MMGMTclas MIGpol? Si no coinciden, muestre los VTV en los MVC con error.
VTV: lista o rango de VTV. RECONcil realiza lo siguiente:
Determina las clases de gestión para los VTV especificados.
Busca la definición del ACS y del medio, como se especifica en el parámetro MGMTclas MIGpol.
Analiza los VTV que se encuentran actualmente en las clases de gestión. ¿Se encuentra el VTV en un MVC con un ACS o medio que coincida con la especificación de MMGMTclas MIGpol? Si no coinciden, muestre los VTV en los MVC con error.
Nota:
Como puede imaginar, si no especifica ninguno de los parámetros de selección, el VTCS validará todos los VTV. En el paso 2, se muestra más información acerca de esto.Acepte el valor predeterminado cuando ejecute RECONcil por primera vez, que consiste en generar únicamente un informe. Como imaginará, no mueve datos, pero simplemente informa acerca de los VTV que son candidatos para conciliación.
Precaución:
Dado que la conciliación de VTV puede hacer un uso intensivo de los recursos, Oracle recomienda ejecutar RECONcil sin MOVEVTV primero y, a continuación, ajustar el trabajo según sea necesario antes de especificar MOVEVTV.Si es necesario, ajuste el trabajo de RECONcil .
Por ejemplo, si ejecutó el informe en el paso 2 y parece que la conciliación durará mucho tiempo, considere realizar lo siguiente:
Ejecute el comando RECONcil durante los períodos de procesamiento de menor actividad, tal como haría con una recuperación de espacio del MVC bajo demanda.
Use los parámetros de la utilidad RECONcil para sustituir la configuración de CONFIG RECLAIM THRESHLD, MAXMVC y CONMVC con el fin de optimizar el rendimiento de la conciliación.
Especifique el tiempo máximo en minutos para la conciliación en el parámetro ELAPSE.
Nota:
Hay varios factores limitantes que influencias las conciliaciones (por ejemplo, MAXMVC y ELAPSE). El VTCS aplica el factor de limitación más estricto. Por ejemplo, si ejecuta RECONcil y especifica el valor de ELAPSE igual a 5 horas y el valor de MAXMVC igual a 10 horas, y el VTCS concilia 10 MVC en una hora, el VTCS finalizará las conciliaciones antes de que caduque el valor de ELAPSE.Existe también una opción RECONcil POLICYdd, que también está disponible en la utilidad ARCHive y puede ser un diagnóstico útil. POLICYdd, que aplica la producción de únicamente un informe, apunta a un archivo que contiene un juego alternativo de sentencias MGMTclas.
Sugerencia:
Esto es básicamente una herramienta valiosa de simulación que indica si cambió algunas de las clases de VTV que se analizan en Cambio de clase de gestión del VTV y anulación de enlaces de VTV desde MVC (incluidas otras especificaciones de clase de almacenamiento) y, a continuación, ejecutó RECONcil, ¿qué le parece? Ahora podrá saberlo antes de cambiar realmente una clase de gestión del VTV.Nota:
El VTCS y el HSC deben estar activos para procesar una solicitud de RECONcil, excepto cuando especifique el parámetro POLICYdd.Ha realizado todas las simulaciones, ajustes y programas requeridos en las horas de menor actividad.
Ahora es el momento de hacerlo realmente. A continuación, se muestra un JCL de ejemplo para ejecutar RECONcil:
Concilie los VTV en las clases de gestión LOCALPROD1 y LOCALPROD2.
Configure MAXMVC en 60, CONMVC en 8 y ELAPSE en 60 para el trabajo de RECONcil.
//RECONCIL EXEC PGM=SLUADMIN //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * RECON MGMT (LOCALPROD1,LOCALPROD2) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV
Por supuesto, obtendrá un informe de RECONcil después de la acción, que le indicará lo bien (o no) que resultó el proceso, de modo que pueda volver a ajustar y ejecutar el proceso si es necesario.
Puede usar la sentencia LOGUTIL FOR_LOSTMVC para recuperar los VTV que residían en MVC perdidos o dañados. ¿Cómo funciona la sentencia LOGUTIL FOR_LOSTMVC y cómo se usa de manera más eficaz?
La utilidad FOR_LOSTMVC analiza el CDS y la estructura del archivo log (si es necesario) para identificar todos los VTV en los MVC dañados o perdidos, cuyos volsers especifica, y para determinar el método de recuperación desde una copia alternativa del VTV, como se describe en la Tabla 5-2. LOGUTIL FOR_LOSTMVC genera un informe que muestra todos los VTV que existían en los MVC perdidos o dañados, y cómo se recuperan, más información de resumen de cada MVC perdido o dañado.
Tabla 5-2 Copia alternativa del VTV y proceso de recuperación
| Categoría de copia alternativa del VTV | Proceso de recuperación |
|---|---|
|
Categoría 1: actualmente reside en el VTSS. |
La recuperación se realiza desde la copia residente. Si solicitó comandos de recuperación, se generarán los comandos |
|
Categoría 2: actualmente enlazada a unas o más copias alternativas del MVC. |
La recuperación se realiza desde el mejor MVC alternativo, según cuatro factores:
Si solicitó comandos de recuperación, se generarán los comandos |
|
Categoría 3: se ha realizado la replicación cruzada entre sistemas TapePlex. |
El primer sistema TapePlex remoto encontrado que contiene una copia del VTV se usa para recuperar el VTV. Si solicitó comandos de recuperación, se generarán los comandos |
|
Categoría 4: anteriormente enlazada a una o más copias del MVC que aún pueden contener los datos del VTV. |
Se selecciona uno de los MVC enlazados anteriormente como el MVC de recuperación. Estas copias del MVC se encontraron en los archivos log y es posible que aún contengan una copia del VTV. Deberá auditar el MVC de recuperación seleccionado. La mejor copia del MVC enlazada anteriormente desde la que se realizará la recuperación se selecciona de acuerdo con los mismos factores que los MVC alternativos. Si solicitó comandos de recuperación, los comandos Se generan los comandos |
|
Categoría 5: es irrecuperable. |
Irrecuperable, las copias únicamente existían en los MVC dañados o perdidos. |
Nota:
Si solicitó comandos de recuperación, los comandosMVCMAINT también se generarán para las categorías 1, 2, 3 y 4. Estas sentencias marcan los MVC perdidos o dañados como de solo lectura y averiados, de modo que ya no se seleccionan para recuperaciones o migraciones.Nota:
En este procedimiento, los ejemplos del JCL no muestran las sentencias DD de las copias del CDS, lo que es válido si el HSC está activo y desea usar el CDS en el sistema donde está ejecutando LOGUTIL. De lo contrario, deberá especificar las sentencias DD para las copias del CDS.Para recuperar VTV mediante el uso de FOR_LOSTMVC:
Primero, ejecute el comando LOGUTIL FOR_LOSTMVC únicamente con los volsers de los MVC dañados o perdidos.
Por ejemplo, en el siguiente ejemplo se muestra:
El juego de datos de registro es LOGIN.
Nota:
Puede ejecutarLOGUTIL FOR_LOSTMVC con un LOGDD ficticio especificado para permitir la recuperación en sistemas donde el registro del CDS no se ha activado. La recuperación está limitada a los datos en el CDS, pero aún puede ser útil si todos los VTV son residentes, en una copia alternativa del MVC o se exportan mediante la replicación cruzada de sistemas Tape.El volser del MVC dañado es DMV509.
Los comandos de recuperación se registran en el juego de datos RECVCMD.
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * LOGUTIL LOGDD(LOGIN) FOR_LOSTMVC MVC(DMV509) COMMANDS(RECVCMD)
Revise el informe de LOGUTIL FOR_LOSTMVC del paso 1.
Seleccione los VTV que desee recuperar y vuelva a ejecutar LOGUTIL FOR_LOSTMVC; para ello, especifique los VTV que desea recuperar del MVC perdido o dañado. Por ejemplo:
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * LOGUTIL LOGDD(LOGIN) FOR_LOSTMVC MVC(DMV509) VTV(DX009) COMMANDS(RECVCMD)
Nota:
Si especifica un VTV que no estaba en el MVC perdido o dañado, se ignorará el VTV.Si desea recuperar todos los VTV especificados en el MVC dañado, continúe con el paso 3.
Para recuperar los VTV especificados, ejecute los comandos del juego de datos de recuperación especificados en el paso 2.
Nota:
Los comandos del juego de datos de recuperación se deberán ejecutar (mediante el JCL SLUADMIN estándar ) lo antes posible después de ejecutar FOR_LOSTMVC para garantizar su precisión.
Oracle recomienda ejecutar los comandos de recuperación en el archivo COMMANDS en el siguiente orden:
Todos los comandos EEXPORT ULINKMVC.
Todos los comandos MVCMAINT READONLY(ON).
Todos los comandos AUDIT.
Si hubiera comandos EEXPORT ULINKMVC o AUDIT, vuelva a ejecutar FOR_LOSTMVC. Con la nueva ejecución, no debería haber comandos EEXPORT o AUDIT en el archivo COMMANDS recientemente generado. Si hay, regrese al paso a.
Todos los comandos MVCMAINT READONLY(ON) ERROR(ON).
Todos los comandos ULINKMVC.
Todos los comandos RECALL.
La utilidad RECONcil.
Los comandos MVCMAINT se generan para todos los MVC perdidos o dañados especificados que existen en el CDS y que tienen al menos un VTV que califica. Los comandos MVCMAINT configuran el estado de solo lectura y el estado “averiado” o de error de los bits en los MVC perdidos o dañados para evitar que se asignen para recuperaciones o migraciones. Se pueden incluir un máximo de 3000 MVC en cada comando MVCMAINT.
Ejecute la utilidad RECONcil para garantizar la creación del número correcto de copias del MVC para cada VTV.
Por ejemplo:
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * RECONCIL VTV(DX009)