7 Detección y corrección de problemas del VTCS

En esta sección, se describe qué hacer cuando se presentan problemas. Ya ha realizado las tareas diaria que se describen en "Uso del panel de control de VTCS" y las tareas que surgen según las necesidades en "Restauración del CDS de una copia de seguridad", y aún así tiene inconvenientes. Aquí encontrará información sobre cómo reanudar el funcionamiento del VTCS cuando se produzcan problemas, empezando por problemas simples que probablemente se presenten, en "Resolución de problemas comunes".

Nota:

La recuperación del CDS es principalmente una tarea del HSC, pero también involucra en parte al VSM. Para obtener más información, consulte "Uso de PITCOPY para realizar copias de seguridad del CDS".

Resolución de problemas comunes

“Comunes”, en este contexto, hace referencia a aspectos que probablemente causen problemas, a pesar de que haga lo posible para evitarlos. Para detectar los problemas, generalmente deberá controlar más de una vez el panel de control del VTCS ; las soluciones generalmente las encontrará en las tareas que surgen según las necesidades.

Antes de comenzar con los problemas de rendimiento de montaje del VTV, se presentan los problemas comunes que generalmente podrá diagnosticar y resolver usted mismo. Sin embargo, si después de intentarlo los problemas no se resuelven, deberá solicitar ayuda al soporte al cliente. También hay algunas herramientas que no se analizan aquí, como rastreos, básicamente porque las usará únicamente según las instrucciones del servicio de asistencia de Oracle.

Rendimiento de montajes del VTV bajo

Si los montajes del VTV se producen con mucha lentitud o no se producen, controle lo siguiente:

  • ¿Los montajes fallan en una única VTD? Esto generalmente se produce porque un host solicita un montaje de un VTV, que reside en el MVC, que el VSM no puede recuperar. Si es así, realice lo siguiente:

    • Introduzca el comando Display Queue DETail para comprobar las recuperaciones en cola. Si una recuperación está en cola esperando un MVC, es posible que otro proceso del VTCS lo esté usando. Puede comprobar esto con el comando Display Active DETail.

    • Si el MVC no está en uso, introduzca el comando HSC DISPLAY VOLUME. ¿El MVC está realmente en el ACS? Si no está allí, deberá volver a introducir el MVC para completar la recuperación.

    • Luego, ¿hay RTD disponibles para montar el MVC con el fin de recuperar el VTV? Introduzca el comando Display RTD para comprobar la disponibilidad de la RTD. Si no hay RTD disponibles, use el comando Display en todos los hosts para comprobar los procesos activos y en cola.

      Si es necesario, use Cancelar para cancelar los procesos y liberar una RTD para que se pueda completar la recuperación. Mediante la cancelación, el VTCS intenta detener todos los procesos sin afectar los recursos o la información del sistema; por lo tanto, es posible que la cancelación no se produzca de inmediato. Por ejemplo, el VTCS podrá esperar los períodos de timeout antes de finalizar un proceso mediante el uso de una RTD específica.

      Nota:

      Si cancela una solicitud principal, detendrá las solicitudes principales y secundarias. Si cancela una solicitud secundaria, la solicitud principal continuará su procesamiento.

      Precaución:

      Si cancela una tarea asociada con un programador de migraciones (con el parámetro MIGrate o mediante un ID de proceso específico), esta tarea finalizará, pero el programador de migraciones iniciará otra tarea en el próximo intervalo del temporizador. Sin embargo, puede usar la migración a umbral para detener la migración automática mediante la especificación de un valor mayor que el de la DBU actual.

      Sugerencia:

      La configuración del parámetro IMMEDmig de la sentencia MGMTclas en KEEP o DELETE usa preferentemente el procesamiento de migración (y la RTD para migración) y puede aumentar la E/S en las RTD.

      Además, tenga en cuenta que puede cambiar la configuración de los parámetros CONFIG MAXMIG y MINMIG para reequilibrar la tareas de migración automática con otras tareas (como recuperación y reclamo) para las RTD que ha definido para cada VTSS.

  • ¿Los montajes fallan en varias VTD? Si es así, compruebe lo siguiente:

    • Compruebe el estado de la VTD con el comando Display VTD.

    • Introduzca el comando Display Active. Si no hay procesos activos, asegúrese de que el VTCS, el HSC, todos los VTSS y todas las comunicaciones estén funcionando normalmente.

    • Asegúrese de tener suficiente espacio en el VTSS.

    • Compruebe si el sistema se está quedando sin MVC disponibles o sin espacio del MVC utilizable.

    • El aumento del AMT bajo tiende a mantener más VTV residentes en el espacio del VTSS, lo que puede ayudar a evitar el fallo de montajes virtuales.

  • Si un montaje de VTV falla, incluso si las VTD están en línea, use el comando VARY del MVS cambiar el estado de las VTD en línea, use el comando UNLOAD del MVS para borrar las VTD y, a continuación, use los comandos MOUNT y DISMOUNT del HSC para reintentar la operación.

Rendimiento de migración bajo

Si la migración del VTV se realiza con mucha lentitud, compruebe lo siguiente:

  • Comience con el comando Display MIGrate, que le muestra, en líneas generales, si el rendimiento de las diversas tareas de migración es bueno o bajo. Es posible que pueda reorganizar el escenario (por ejemplo, aumentar los valores MAXMIG/MINMIG) para acelerar el proceso.

  • Asegúrese de que el suministro de RTD y MVC sea bueno, tal como se describe en "Comprobación del estado de cintas virtuales (diaria)". Si desea más información, use también Display Queue DETail para comprobar el estado de los procesos en cola. Si hay muchos procesos esperando las RTD y está compartiendo las RTD con el MVS, es posible que desee cambiar los transportes fuera de línea al MVS y los transportes en línea al VSM.

Nota:

En el entorno JES3, los montajes del VTV pueden fallar si no ha creado e instalado las modificaciones correctas de la salida de usuario.

Fallos de migración

Solamente hay algo peor que el rendimiento de migración bajo, y es que no haya migración. Afortunadamente, el VTCS proporciona información detallada acerca de los fallos de migración, como se describe en las siguientes secciones:

Mejoras de mensajes

Para proporcionar información más detallada acerca de fallos, se ha sustituido el mensaje SLS6700E por los siguientes mensajes:

  • SLS6853E Falló la clase de almacenamiento de la migración:stor-clas-name ACS:acs-id VTSS:vtss-name: MVCPool poolname no está definido

  • SLS6854E Falló la clase de almacenamiento de la migración:stor-clas-name ACS:acs-id VTSS:vtss-name: no se encontraron MVC para los medios especificados

  • SLS6855E Falló la clase de almacenamiento de la migración:stor-clas-name ACS:acs-id VTSS:vtss-name: no se encontraron MVC para los medios/SC/ACS especificados

  • SLS6856E Falló la clase de almacenamiento de la migración:stor-clas-name ACS:acs-id VTSS:vtss-name: no se encontraron MVC utilizables para los medios/SC/ACS especificados

  • SLS6857E Falló la clase de almacenamiento de la migración:stor-clas-name ACS:acs-id VTSS:vtss-name: no se encontraron RTD para los medios y el ACS solicitados

  • SLS6858E Falló la clase de almacenamiento de la migración:stor-clas-name ACS:acs-id VTSS:vtss-name: todas las RTD para los medios y el ACS solicitados están fuera de línea

  • SLS6859E Falló la calase de almacenamiento de la migración:stor-clas-name ACS:acs-id VTSS:vtss-name: motivo desconocido (X'xx')

Además, el mensaje SLS6860I se muestra siempre después de la ejecución de cualquiera de los mensajes anteriores para proporcionar detalles sobre la clase de almacenamiento. Si corresponde, SLS6860I también informa sobre errores relacionados con la satisfacción de los requisitos de migración:

  • Si la agrupación del MVC no está definida.

  • Si la agrupación del MVC no contiene ninguno de los medios especificados.

  • Si la agrupación del MVC no contiene MVC libres de los medios especificados.

  • Si el VTSS/ACS no tiene RTD adecuadas definidas para escribir el MVC de migración.

  • Si todas las RTD adecuadas están fuera de línea.

El resultado es que ahora obtendrá más información detallada y más recomendaciones específicas para correcciones cuando se produzcan fallos de migración.

Display STORCLas

Display se mejora con el parámetro STORCLas, cuya salida es:

  • Las características de la clase de almacenamiento (ACS, agrupación del MVC y medio).

  • VTV que esperan migración a la clase de almacenamiento desde cualquier VTSS.

  • Requisitos de los MVC para ser usados para migración.

  • Tipos de dispositivos necesarios de las RTD para escribir en los MVC de migración.

  • Cualquier error relacionado con la satisfacción de los requisitos de migración.

Una vez más, el VTCS proporciona información acerca de un elemento crítico (clases de almacenamiento) en el escenario de migración.

Validación de agrupación del MVC mejorada

La validación de las agrupaciones de MVC se mejoró para comprobar la existencia de errores comunes de configuración:

  • ¿Se ha definido al menos una agrupación del MVC válida? Si la respuesta es no, se ejecutará el mensaje SLS6845E. La funcionalidad del VTCS se ve seriamente degradada porque no se pueden producir migraciones. Si recibe este mensaje, deberá definir las agrupaciones de MVC adecuadas. Consulte la viñeta siguiente.

  • ¿Existe la agrupación del MVC predeterminada (DEFAULTPOOL)? DEFAULTPOOL se usa cuando se realizan migraciones a una clase de almacenamiento que no especifica una agrupación del MVC con nombre y en situaciones de errores con la clase de almacenamiento !ERROR. Si DEFAULTPOOL no existe, se ejecutará el mensaje SLS6846W.

    Indica que las migraciones a una clase de almacenamiento deberán usar una agrupación del MVC determinada mediante la codificación de MVCPool(pool-name) en la sentencia STORCLAS. Si MVCPool(pool-name) no está codificado, el VTCS tratará a STORCLAS como si MVCPool(DEFAULTPOOL) estuviera codificado.

Validación de clase de almacenamiento mejorada

Para continuar con este tema, la validación de las clases de almacenamiento se mejoró para comprobar la existencia de errores comunes de configuración:

  • Si especificó una agrupación del MVC con nombre en una clase de almacenamiento (STORCLAS NAME(stor-clas-name) MVCPOOL(poolname)), el VTCS comprobará que se haya definido la agrupación del MVC con nombre. Por lo tanto, si codifica STORCLAS NAME(stor-clas-name) MVCPOOL(poolname), asegúrese de que exista la agrupación del MVC con nombre. Si no existe, el VTCS ejecutará el mensaje SLS6848W. Si obtiene este mensaje, defina la agrupación del MVC con nombre, cambie la definición de clase de almacenamiento o ambos.

  • De manera similar, si no especifica una agrupación del MVC con nombre en una clase de almacenamiento (STORCLAS NAME(stor-clas-name), el VTCS comprobará que se haya definido DEFAULTPOOL. Por lo tanto, si codifica STORCLAS NAME(stor-clas-name), asegúrese de que haya al menos una sentencia MVCPOOL que no cree una agrupación del MVC con nombre. Si no hay, el VTCS ejecutará el mensaje SLS6846W. Si obtiene este mensaje, codifique al menos una sentencia de MVCPOOL que no cree una agrupación del MVC con nombre, cambie la definición de la clase de almacenamiento, o ambos.

  • Si especifica un medio del MVC en una clase de almacenamiento (STORCLAS NAME(stor-clas-name) MEDIA(media-type)), el VTCS comprobará que la agrupación del Pool contenga medios del tipo media-type (si no se especificó una agrupación del MVC, DEFAULTPOOL estará implícito). De lo contrario, el VTCS ejecutará el mensaje SLS6849W. Asegúrese de que el tipo de medio exista en la agrupación correspondiente, cambie la definición de la clase de almacenamiento o ambos.

  • Si especifica un ACS y un tipo de medio en una clase de almacenamiento (STORCLAS NAME(stor-clas-name) ACS(acs-id) MEDIA(media-type)), el VTCS comprobará que haya RTD en el ACS especificado compatible con el tipo de medio especificado. De lo contrario, el VTCS ejecutará el mensaje SLS6851W. Asegúrese de que el tipo de RTD exista en el ACS especificado, cambie la definición de la clase de almacenamiento o ambos.

  • Si especifica un tipo de medio de almacenamiento sin un ACS específico en una clase de almacenamiento (STORCLAS NAME(stor-clas-name) MEDIA(media-type)), el VTCS comprobará que haya RTD en la configuración compatible con el tipo de medio especificado. De lo contrario, el VTCS ejecutará el mensaje SLS6851W. Asegúrese de que los tipos de RTD existan en la configuración, cambie la definición de la clase de almacenamiento o ambos.

Fallos de la RTD o el MVC

Al principio, es posible que no sepa si está observando un fallo de unidad o de medio. Es decir, si el VTCS detecta errores de lectura o escritura en un MVC, el VTCS cambiará el MVC a otra RTD. Si el VTCS no detecta más errores de lectura y escritura en el MVC, el VTCS asumirá que el primer RTD tiene un error.

El mensaje SLS6662A indica que un RTD está en modo de mantenimiento y este estado también se informa en la salida de Display RTD. Un RTD en modo de mantenimiento generalmente tiene un error y requiere la asistencia de las operaciones de hardware o del personal de servicio. Tenga en cuenta que se está inicializando un RTD en modo de recuperación (cuando se cambia al estado en línea, por ejemplo) y que generalmente no tiene errores.

Si una RTD fallada no se puede reparar rápidamente o si la RTD fallada está conectada a un ACS remoto, es posible que desee eliminar la RTD de la configuración para evitar intentos de asignar esa RTD. Elimine la sentencia de la RTD para la RTD y vuelva a ejecutar CONFIG.

Precaución:

En una configuración de dos ACS (dos ACS conectados a un único VTSS), asegúrese de no permitir que todas las RTD en ninguno de los ACS no estén disponibles para el VTSS durante un período extendido. Si no hay RTD disponibles en ese ACS, no se podrán producir migraciones a ese ACS ni recuperaciones desde ese ACS, y es posible que se llene el espacio del VTSS. Además, esta condición también puede causar la detención de migraciones a las RTD en el otro ACS.

Por lo tanto, en una configuración de dos ACS, si debe marcar todas las RTD de un ACS como no disponibles durante un período prolongado, elimine las RTD de la configuración, como se describe arriba.

¿Es un MVC defectuoso?

Si recorrió la lista de comprobación de errores de la RTD de arriba y no detectó el problema y, además, hizo todos los esfuerzos razonables posibles para liberar más espacio del MVC y comparó los volsers del informe de resumen del MVC con un informe de volumen del HSC, entonces los MVC estaban realmente en el ACS. De lo contrario, vuelva a introducir los MCV que no se muestran en el informe de volúmenes del HSC o sustitúyalos.

Parece realmente un problema de medios. Podrá ver de qué tipo de problema de medio se trata en los informes del MVC y el VTV que se describen en "Comprobación del estado de cintas virtuales (diaria)". Esa sección trata algunas de las correcciones para las anomalías más simples del MVC. A continuación, se muestra una lista exhaustiva de los estados del MVC que no desea ver en los informes del MVC y el VTV, y qué hacer con ellos:

BROKEN (Interrumpido)

Error genérico que indica que el MVC, la unidad o una combinación de ambos tienen un problema. El VTCS intenta eliminar la preferencia de los MVC con este estado. En general, para borrar este estado:

Si el MVC causó un problema, use el comando DRAIN(EJECT) para eliminar el MVC del servicio.

Si la RTD causó el problema, use la utilidad MVCMAINT para restablecer el estado del MVC.

Tenga en cuenta además que se ejecutarán uno o más de los siguientes mensajes para el estado INTERRUMPIDO: SLS6686, SLS6687, SLS6688, SLS6690. Para obtener procedimientos de recuperación detallados para estos mensajes, consulte Mensajes y códigos del VTCS.

DATA CHECK (Comprobación de datos)

Se ha informado una condición de comprobación de datos para este MVC. El VTCS intenta eliminar la preferencia de los MVC con este estado. Para borrar este estado:

Si todos los VTV del MVC son dobles, use MVCDRain en el MVC sin la opción Eject. Esto recuperará todos los VTV y eliminará el MVC del servicio.

Si todos los VTV en el MVC no son dobles, use AUDIT en el VTCS para el MVC. Es posible que falle la auditoría. Después de la auditoría, use MVCDRAIN (sin expulsión). Esto recuperará los VTV antes del área de comprobación de datos en orden de ID de bloque ascendente y los VTV después del área de comprobación de datos en orden de ID de bloque descendiente. El procesamiento de los VTV en esta secuencia garantiza que el VTCS recuperará tantos VTV como sea posible del medio. A continuación, deberá recrear los datos para todos los VTV que aún están en el MVC.

Después de borrar las comprobaciones de datos, extraiga y sustituya los MVC con errores de comprobación de datos, como se describe en "Extracción permanente de los MVC". Este procedimiento también le indica cómo extraer un MVC del uso del VTCS y regresarlo a las operaciones de Nearline.

DRAINING (Drenaje)

El MVC se está drenando o ha experimentado un MVCDRain con fallo.

IN ERROR (Con error)

Se produjo un error mientras se montaba el MVC.

INITIALIZED (Inicializado)

Se ha inicializado el MVC.

LOST - FAILED TO MOUNT (Perdido: error de montaje)

El VTCS intentó montar un MVC y el montaje no se completó dentro de un período de timeout de 15 minutos. El VTCS está intentando recuperarse de una situación que podría ser causada por problemas de hardware, problemas del HSC o por la extracción del MVC del ACS. El VTCS intenta eliminar la preferencia de los MVC con este estado.

Si el VTCS realiza un montaje subsiguiente correcto de un MVC con estado LOST(ON), el VTCS configura el estado en LOST(OFF).

Determine la causa del error y corríjalo. También puede usar la utilidad MVCMAINT del VTCS para configurar LOST(OFF) para los siguientes eventos:

LOST(ON) se configuró debido a fallos del LSM o errores de la unidad que se han resuelto.

LOST(ON) se configuró porque el MVC estaba afuera del ACS y se ha vuelto a introducir.

MARKED FULL (Marcado como completo)

El MVC está completo y no es un candidato para futuras migraciones.

MOUNTED (Montado)

El MVC está montado en una RTD.

NOT-INITIALIZED (No inicializado)

El MVC se definió mediante la utilidad CONFIG, pero no se usó nunca.

READ ONLY (Solo lectura)

El MVC se marcó como de solo lectura debido a una de las siguientes condiciones:

  • El MVC era el destino de una exportación o proceso de consolidación. El estado de solo lectura protege el MVC contra futuras actualizaciones.

  • El medio del MVC está configurado para proteger los archivos. Corrija el error y use la utilidad MVCMAINT para configurar READONLY(OFF).

  • El MVC no tiene las reglas de la SAF configuradas para activar los VTCS con el fin de actualizar el MVC. Corrija el error (para obtener más información, consulte “Definición de un ID De usuario del sistema de seguridad para el HSC, el SMC y el VTCS” en Instalación de ELS y use la utilidad MVCMAINT para configurar READONLY(OFF).

BEING AUDITED (En auditoría)

El MVC se está auditando o ha experimentado una auditoría con fallo. Si la auditoría falló, el VTCS no usará el MVC para migración. Para borrar esta condición, vuelva a ejecutar la utilidad AUDIT contra este MVC.

LOGICALLY EJECTED (Expulsado lógicamente)

El MVC experimentó una expulsión de MVCDRain o una llamada de RACROUTE ejecutó el MVC para actualización. El MVC no se usará nuevamente para migraciones o recuperaciones. Para borrar esta condición, use MVCDRain contra el MVC sin la opción Eject.

RETIRED (Retirado)

Se ha retirado el MVC. El VTCS realiza recuperaciones desde el MVC, pero no realiza migraciones al MVC. Sustituya el MVC en cuanto sea posible.

WARRANTY HAS EXPIRED (Garantía caducada)

La garantía del MVC ha caducado. El VTCS continúa usando el MVC. Deberá comenzar a planear la sustitución del MVC cuando alcance el estado Retired.

INVALID MIR (MIR no válido)

El VTCS ha recibido el estado de una RTD para indicar a la MIR (registro de información de medios) que un medio 9x40 o T10000 no es válido. La MIR no válida no evita el acceso a los datos, pero puede causar problemas importantes de rendimiento mientras que se accede a los registros de la cinta. El MVC no tiene la capacidad de realizar búsquedas de alta velocidad en las áreas de la cinta que no tienen una entrada de MIR válida.

El VTCS intenta eliminar la preferencia de los MVC con esta condición. Para recuperaciones, si el VTV reside en varios MVC, el VTCS selecciona los MVC con MIR válidos antes que los MVC con MIR no válidos. El VTCS evita el uso de los MVC con MIR no válidos para migración, a menos que la migración esté en el inicio de la cinta. La migración desde el inicio de la cinta corrige la MIR.

El VTCS detecta la condición de MIR no válido al momento del montaje o el desmontaje. Si lo detecta al momento del montaje y la operación se puede completar con otro MVC, el VTCS desmontará el primer MVC y seleccionará un MVC alternativo. Tenga en cuenta que el VTCS tiene únicamente una capacidad limitada de cambiar a un MVC alternativo. Es decir, se usa principalmente para migraciones y montaje virtual.

Para los MVC con MIR no válidos, determine la causa del error, que podría deberse a problemas de medios o unidades, y corrija el error.

Para recuperar un MVC con una MIR no válida, ejecute la utilidad INVENTRY . Por ejemplo, para recuperar MVC707, introduzca:

INVENTRY MVCID(MVC707) 

Recuperación de un MVC con comprobación de datos

Esta es una instancia muy específica de los problemas de “MVC defectuosos” y sabrá que es necesaria cuando vea un error de comprobación de datos en los informes del MVC y el VTV.

Para recuperar un MVC con comprobación de datos:

  1. Ejecute una auditoría del MVC contra el MVC.

    La auditoría intentará leer los metadados del VTV secuencialmente desde el MVC. La auditoría falla cuando encuentra la comprobación de datos, lo que deja al MVC en estado de auditoría. Esto evita que el VTCS seleccione este MVC para salidas.

  2. Ejecute MVCDRain Eject para el MVC.

    Esto hace que todos los VTV disponibles se recuperen en un VTSS y, a continuación, se vuelvan a migrar a un nuevo MVC sin errores. Esto lógicamente elimina el MVC de la agrupación del MVC.

    Nota:

    • Debido al estado de error del MVC, si es posible, el VTCS recupera los VTV de los MVC alternativos.

    • Si los VTV se deben recuperar desde el MVC con error (no hay otras copias disponibles), entonces:

      • Los VTV que se encuentran antes del área de comprobación de datos se recuperan en orden de ID de bloque ascendente.

      • Los VTV que se encuentran después del área de comprobación de datos se recuperan en orden de ID de bloque descendente.

  3. Determine si no se han podido recuperar VTV del MVC.

    Ejecute un informe detallado del MVC para el MVC. Si aún se informan VTV presentes en el MVC, estos VTV no son recuperables; deberá usar otros métodos para recuperar los datos.

  4. Gestione el MVC defectuoso realizando una de las siguientes acciones:

    Sustituya el MVC defectuoso con un volumen de cinta inicializado con las mismas etiquetas internas y externas:

    1. Introduzca el comando EJECT del HSC para el MVC defectuoso.

    2. Introduzca el comando ENTER del HSC para el MVC sustituto.

    3. Inicialice la cinta según sea necesario.

    4. Introduzca el comando AUDIT del HSC para el nuevo MVC.

    5. Ejecute el comando MVCDRAIN (sin EJECT) para regresar el MVC a la agrupación de MVC.

    Extraiga el MVC del sistema:

    1. Introduzca el comando EJECT del HSC para el MVC defectuoso.

    2. Edite las definiciones de la agrupación del MVC para extraer el MVC defectuoso de la agrupación.

    3. Introduzca el comando VT MVCDEF en todos los hosts activos para activar las definiciones de la nueva agrupación del MVC.

Uso de la utilidad RTV

La utilidad RTV es otro elemento que probablemente usará después de hablar con el servicio de Oracle, ya que la RTV está diseñada para leer datos del VTV directamente desde un MVC sin ayuda del VTCS, por ejemplo, en caso de que realmente haya perdido el CDS.

RTV es una utilidad independiente y lee un VTV desde un MVC, descomprime el VTV y, a continuación, escribe los datos en una única cinta de salida (volumen de cinta real), de modo que otras aplicaciones puedan leer los datos. Dado que la utilidad RTV es una utilidad independiente; puede ejecutar la RTV cuando un VSM está inactivo pero el sistema de MVS está en funcionamiento.

Qué puede recuperar la utilidad RTV

La utilidad RTV puede recuperar:

  • Todos los VTV o los VTV especificados de un MVC especificado. Si no conoce la ubicación de la versión más actualizada de un VTV en el MVC, especifique únicamente el volser del VTV y la utilidad RTV convertirá la versión más actualizada del VTV que descubra en este MVC.

  • Un VTV en un ID de bloque en un MVC especificado. La lista del parámetro LISTONLY proporciona un valor de ID de bloque que puede usar como entrada a la utilidad RTV para convertir un VTV en un volumen de Nearline. La especificación del volser y el ID de bloque aceleran el tiempo de posicionamiento.

  • Un VTV especificado por un número de juego de datos lógicos en un MVC especificado. La especificación del número del juego de datos lógicos y del volser tendrá un tiempo de posicionamiento mucho más largo, en comparación con la especificación de un ID de bloque o de volser. El uso del ID de bloque y de volser es el método preferido para acceder a un único VTV.

Nota:

Si se especifica más de un VTV o si no se especifica ningún parámetro de ID de bloque o FILEnum, el MVC completo será de lectura y el contenido del MVC se mostrará como parte de la salida. La lectura del MVC completo es necesaria para garantizar que se descomprimirá únicamente la copia más reciente de un VTV.

Directrices de uso general  

  • El volumen de salida que contiene los VTV convertidos debe tener al menos el tamaño máximo del VTT (400 MB, 800 MB, 2 GB, 4 GB o 32 GB) para garantizar que podrá contener un VTV individual.

  • Los informes del MVC del VTCS y el VTV proporcionan información para especificar cuál copia de un VTV desea que recupere la utilidad RTV. Asegúrese de tener una copia actualizada de estos informes antes de ejecutar la utilidad RTV. Además, para ayudar a identificar los VTV que desea convertir, puede usar el parámetro LISTONLY para generar una lista de los VTV en un MVC.

    Dado que pueden existir múltiples copias en el mismo VTV o en MVC diferentes, analice detenidamente los informes del VTV y el MVC, y las listas de LISTONLY para asegurarse de que está usando el MVC correcto para convertir la copia más actualizada del VTV.

  • La utilidad RTV no actualiza el catálogo del sistema ni el TMC con información acerca de los volúmenes convertidos; deberá hacerlo manualmente.

Consideraciones de seguridad

  • Deberá tener acceso de lectura a los VTV que desea convertir y al MVC que contiene estos VTV o no se podrá ejecutar la aplicación de seguridad del sistema. De lo contrario, la conversión fallará.

  • Asegúrese de que APF autorice la biblioteca de carga de la utilidad RTV.

  • La utilidad RTV no intenta omitir ninguna protección del TMS. Todos los montajes de cintas de la utilidad RTV están sujetos al control total del TMS.

Nota:

Dado que la utilidad RTV debe tener la capacidad de rescribir las etiquetas estándar de la cinta en la unidad de salida y de reposicionar la información de la etiqueta en la unidad de entrada, la asignación dinámica se usa para invocar la omisión del procesamiento de etiquetas (BLP) en los volúmenes de cinta. Esto requiere que la biblioteca que contiene el código ejecutable SWSRTV sea autorizada por APF.

Ejemplos del JCL

A continuación, se muestra ejemplos de JCL que usan la utilidad RTV.

Visualización de VTV en un MVC

En el siguiente ejemplo, se muestran JCL de muestra para visualizar los VTV en el MVC MVC001.

//JOBVRECJOB(account),programmer 
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’ 
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR 
//SLSPRINTDD SYSOUT=A 
//SLSINDD * 
RTV  MVC(MVC001)INUNIT(/1AB4) LISTONLY  
/* 
// 

Conversión de un único VTV mediante la especificación del volser

En el siguiente ejemplo, se muestra un JCL de muestra para ejecutar la utilidad RTV con el fin de convertir el VTV VTV200 en MVC MVC001, que se monta en un transporte 3490E. La salida (VTV VTV200 convertido) va al volumen de salida montado en el transporte 280 y la utilidad RTV copia el VTV VOLID en el volumen de salida.

//JOBVRECJOB(account),programmer 
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’ 
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR 
//SLSPRINTDD SYSOUT=A 
//SLSINDD * 
  RTV  MVC(MVC001) INUNIT(3490E) VTV(VTV200) CPYVOLID OUTUNIT(280) 
/* 
// 

Conversión de un único VTV mediante la especificación del volser y el ID de bloque

En el siguiente ejemplo, se muestra un JCL de muestra para ejecutar la utilidad RTV con el fin de convertir el VTV VTV200 en el ID de bloque x’8EA484AB’ del MVC MVC001, que se monta en un transporte 3490E. La salida (el VTV VTV200 convertido) va al volumen de salida montado en el transporte 480.

//JOBVRECJOB(account),programmer 
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’ 
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR 
//SLSPRINTDD SYSOUT=A 
//SLSINDD * 
  RTV  MVC(MVC001) INUNIT(3490E) VTV(VTV200) BLOCK(8EA484AB) OUTUNIT(480) 
/* 
//