Notas de la versión
Versión 8.4
E68210-01
Octubre de 2015
ACSLS 8.4 presenta mayor flexibilidad para sus clientes con una plataforma variada y preferencias de sistema de archivos. El paquete ACSLS se instala en cualquier sistema de archivos de cualquier plataforma actual de Solaris 11.2 u Oracle Linux 6.5.
Para obtener otra documentación sobre ACSLS, consulte Oracle Technical Network (OTN) en:
En esta sección, se describen los requisitos de software, sistema, explorador y alojamiento conjunto.
ACSLS 8.4 ha sido probado y está documentado para ser utilizado en:
Sun SPARC, de Oracle, y las plataformas X86 que ejecutan Solaris 11, actualización 2.
Oracle Linux 6.5.
Se realizaron pruebas con Oracle Linux en entornos con Unbreakable Enterprise Kernel de Oracle.
Otros sistemas operativos, incluidos los entornos virtuales, no se probaron y no se admiten.
Se proporcionan controladores de dispositivos especiales en ACSLS para uso con bibliotecas lógicas y bibliotecas conectadas a la fibra, como SL500 y SL150. Este es un problema para entornos de zonas de Solaris. Dado que dichos controladores de dispositivos están conectados al núcleo del sistema, deben residir en la zona global. En los casos en que se utilizan dichos controladores, los ACSLS no se pueden instalar en el entorno de zona local.
Los sistemas ACSLS 8.4 de alta disponibilidad (HA) deben estar instalados en su propio par de plataformas dedicadas.
Aprobación operativa
El producto se instaló correctamente para ejecutarse en el entorno operativo indicado debajo. Ha demostrado proporcionar la funcionalidad básica sin detrimento para el producto ni el entorno de ejecución asociado.
Red Hat Enterprise Linux
Memoria: 4 GB como mínimo
Para mostrar la memoria del sistema:
Solaris
prtconf | grep Mem
Linux
grep MemTotal /proc/meminfo
Intercambio: los sistemas actuales (con Solaris 11.2 y Linux 6.5) deben tener no menos de 4 GB de memoria y no menos de 2 GB de intercambio. Si la memoria del sistema excede los 6 GB, como regla general, se proporciona un espacio de intercambio de no menos del 30 % de la memoria física. Para comprobar el espacio de intercambio en:
Solaris
vmstat -S
El resultado se expresa en kilobytes.
Linux
vmstat -s | grep total
El resultado se expresa en kilobytes.
Sistemas de archivos y bases de datos requeridas:
ACSLS 8.4 le permite la instalación en cualquier sistema de archivos. Debe definir los siguientes directorios antes de instalar ACSLS.
Un directorio base en donde se instalarán los componentes de ACSLS.
Un directorio por defecto para las copias de seguridad de ACSLS. Se recomienda (aunque no es necesario) colocar el directorio de copias de seguridad de ACSLS en un sistema de archivos separado del directorio base de ACSLS.
Si bien se puede instalar ACSLS en cualquier directorio, los directorios que se usan por defecto para ACSLS son los siguientes:
/export/home es el directorio base por defecto de ACSLS.
/export/backup es el directorio de copia de seguridad por defecto de ACSLS.
El sistema de archivos del directorio base de ACSLS debe tener un mínimo de 5 GB libres. Se deben reservar otros 5 GB libres para las copias de seguridad de ACSLS. Para mostrar los tamaños del sistema de archivos:
df -h
La tarjeta de fibra (opcional) es opcional. Se requiere un HBA adecuado para operaciones de canal de fibra.
En el caso de la operación en modo de destino, que admite la función de biblioteca lógica, este HBA debe ser una tarjeta de fibra QLogic contemporánea (4 Gb u 8 Gb).
En el caso de la operación en modo de iniciador, una biblioteca conectada en fibra compatible como SL500 o SL150, ACSLS 8.4 se prueba y se certifica completamente con QLogic y HBA Emulex.
La GUI de ACSLS 8.4 funciona con la mayoría de los exploradores actuales comunes, aunque las pruebas formales se limitan a las versiones recientes de FireFox, Chrome e Internet Explorer. Se han realizado pruebas exhaustivas con el explorador Chrome y versiones anteriores de FireFox usando la configuración por defecto de ACSLS en el servidor de WebLogic. Internet Explorer V8 (y superiores) y FireFox V39 (y superiores) requieren valores de configuración que proporcionen un certificado digital autofirmado de 2048 bits para https. Consulte la sección "Configuración de un certificado digital autofirmado para HTTPS" en la Guía de instalación de ACSLS 8.4.
Para garantizar un servicio de bibliotecas ininterrumpido y evitar problemas no anticipados debido a una disputa por recursos, en general, se recomienda que ACSLS se ejecute en un entorno independiente en un servidor dedicado. Sin embargo, algunos sistemas están diseñados para permitir que se ejecuten varias aplicaciones en almacenamiento conjunto, como si estuvieran completamente aisladas la una de la otra. Los contenedores Solaris y Oracle Solaris VM Server for SPARC permiten posibilidades de alojamiento conjunto condicionales para el uso con ACSLS.
En la siguiente lista, se detallan las condiciones y las limitaciones asociadas con las diferentes opciones de almacenamiento conjunto para una aplicación ACSLS.
Zonas de Solaris (contenedores)
Las zonas de Solaris permiten al administrador del sistema crear particiones de un servidor estándar de bajo costo para generar cuatro sistemas Solaris independientes, cada uno con su sistema de archivos aislado y su propia interfaz de Solaris. Puede asignar recursos de red a cada zona y también reiniciar cualquier zona local (no global) sin afectar a las aplicaciones que se encuentran en otras zonas, en la misma plataforma. Sin embargo, la capacidad de compartir recursos de núcleo, como controladores de dispositivos, en varias zonas es, en el mejor de los casos, débil. Idealmente, una aplicación que requiere controladores de núcleo debería residir en la zona global. Sin embargo, no suele ser una buena práctica instalar una aplicación en la zona global, ya que cualquier condición fatal que se produzca con la aplicación podría tener impacto en todas las demás aplicaciones que se ejecuten en otras zonas.
ACSLS 8.4 puede residir en una zona de Solaris solo si no requiere más controladores que la interfaz de red. Cualquier uso de bibliotecas lógicas requiere un controlador de canal de fibra del modo de destino, y cualquier conexión a una biblioteca SL500 o SL150 requiere un controlador de canal de fibra en modo de iniciador. Cualquiera de estas configuraciones indica que el ACSLS debe estar instalado en la zona global.
No existe una versión de ACSLS HA admitida para uso en las zonas de Solaris.
Oracle VM Server for SPARC
Oracle VM Server for SPARC (anteriormente dominios lógicos o LDOM) está disponible técnicamente en los servidores SPARC de la serie T con tecnología de microprocesamiento de chip (CMT). Esta tecnología ofrece ventajas significativas sobre los contenedores Solaris en la medida en que cada dominio controla su propio núcleo de Solaris.
Un administrador de Solaris puede realizar una partición de los recursos de hardware del sistema, mediante la asignación de un recurso específico a un dominio específico. Los recursos de red de esta máquina virtual pueden compartirse de manera simple en cualquiera de los dominios invitados del servidor (hasta 128). Sin embargo, las aplicaciones que requieren acceso a dispositivos de E/S por medio del bus PCIe deben instalarse en dominios de E/S especiales. El número de dominios de E/S que puede crear en VM Server depende del número de buses PCIe discretos de la plataforma SPARC. En un sistema con un solo bus PCIe, puede tener dos dominios de E/S, uno de estos debe ser el dominio de control.
Cualquier aplicación de ACSLS que depende únicamente de la conectividad de red con la biblioteca y para aplicaciones de cliente puede instalarse en un dominio invitado del servidor. El procedimiento de configuración de la red virtual se describe en el documento Guía de administración del Oracle VM Server for SPARC 2.1 en la sección llamada "Uso de redes virtuales".
Si su aplicación ACSLS 8.4 está destinada para el uso con bibliotecas lógicas o si pretende conectarse a una biblioteca de canal de fibra, como SL500 o SL150, ACSLS debe instalarse en un dominio de E/S. Consulte la sección "Configuración de dominios de E/S" en la Guía de administración del Oracle VM Server for SPARC 2.1.
El software Solaris Cluster se admite en el Oracle VM Server for SPARC y esta plataforma se puede utilizar en una aplicación ACSLS HA. Consulte la Guía del servicio de datos de Oracle Solaris Cluster para Oracle VM Server for SPARC.
Esta versión contiene varias mejoras.
Con CAP para carga masiva, SL8500 ahora tiene dos CAP de 36 celdas en cada guía u 8 CAP por biblioteca. La compatibilidad de ACSLS con CAP para carga masiva incluye:
Mejoras importantes en la utilidad ejecting.sh, como se describe a continuación.
Nuevas variables dinámicas:
BULK_CAP_EJECT_HANDLE deja vacía una ranura en cada cargador de CAP para que se la utilice como tirador al realizar operaciones de introducción y expulsión del CAP para carga masiva. El valor por defecto es FALSO (Falso).
ENTER_CLOSE_TO_DRIVES introduce los cartuchos en las celdas de origen más cercanas a las unidades de cinta en SL8500. Esto acelera el montaje del cartucho en el futuro. El valor por defecto es TRUE (Verdadero).
DISMOUNT_AWAY_FROM_DRIVES: cuando los cartuchos se trasladan a un LSM más cercano en un punto de desmontaje de SL8500, se asigna una nueva celda de origen alejada de las unidades de cinta para dejar espacio cerca de las unidades para los nuevos cartuchos. El valor por defecto es FALSO (Falso).
LIMIT_CAP_CONCURRENT_MOVES limita el número de movimientos concurrentes de un CAP para carga masiva de SL8500, o hacia él, durante una operación de expulsión o introducción cuando ACSLS no está conectado con cada SL8500 de una cadena de bibliotecas conectadas. Esto reserva recursos de biblioteca para operaciones de montaje y desmontaje y otras solicitudes al realizar operaciones de introducción o expulsión en la mayoría de los CAP de una cadena de SL8500. El valor por defecto es FALSO (Falso).
Al introducir cartuchos mediante un CAP para carga masiva, ACSLS intenta mover el volumen a una celda de almacenamiento que se encuentre del mismo lado de la biblioteca que el CAP. Esto maximiza el rendimiento y minimiza el conflicto entre los robots de una guía.
Los clientes pueden especificar un número de mensaje de panel de operador que describa la finalidad de la operación de introducción o expulsión. Por ejemplo, 5 para "Expulsar conservar 1 mes" o 7 para "Introducir desde almacén local".
Los números de los mensajes del panel del operador (opmsg) y el texto descriptivo asociado se especifican desde SL Console. El nuevo argumento opmsg se proporciona con el comando enter o eject y cmd_proc. ACSLS envía el número de mensaje opmsg especificado a la biblioteca en las solicitudes de desbloqueo de CAP. SL Console muestra el número de mensaje y el texto descriptivo cuando se desbloquea el CAP para introducir nuevos cartuchos o para quitar cartuchos que se extrajeron.
Se agregó la nueva columna cap_type a la tabla de CAP en la base de datos. Hay valores de tipo de CAP para CAP giratorios y para carga masiva de SL8500, CAP giratorios de SL3000 y AEM. Para ver los tipos de CAP, use el comando display cap * -f type.
ejecting.shEsta mejora admite desde pequeñas hasta masivas operaciones de almacenamiento.
Un usuario envía un archivo de lista de volúmenes y especifica los CAP que se deben usar.
No hay un límite para la cantidad de volúmenes en la lista.
Puede usar cualquier combinación de CAP para la operación.
La utilidad direcciona cada volumen al CAP más cercano para obtener un rendimiento óptimo.
Para el movimiento concurrente de cartuchos se utilizan varios mecanismos robóticos.
Se puede seleccionar un orden secuencial para los volúmenes en lugar de la selección de CAP optimizada.
La operación finaliza cuando se expulsan todos los volúmenes.
Se conserva un resumen de log durante hasta diez días para cada operación de ejecting.sh.
lib_cmd con la opción eject.El comando lib_cmd eject puede expulsar una lista de cientos de volúmenes en una única operación de expulsión. Úselo para completar varias veces un AEM de SL3000. La utilidad ejecting.sh invoca el comando lib_cmd eject al expulsar volúmenes para un AEM de SL3000.
ACSLS 8.4 incluye varias mejoras de seguridad. Algunas de estas mejoras también favorecen el rendimiento de ACSLS bajo cargas intensas de transacciones.
ACSLS admite la interfaz XML API (XAPI) desde aplicaciones cliente de Enterprise Library Software (ELS). Esta interfaz permite a ACSLS actuar como servidor para las aplicaciones cliente de ELS que se ejecutan en mainframes y otras plataformas.
La utilidad watch_vols ahora puede asignar volúmenes automáticamente a agrupaciones reutilizables con nombre, utilizadas por clientes de la XAPI.
Durante install.sh, si se elige instalar compatibilidad con bibliotecas lógicas, antes era obligatoria la instalación de WebLogic y la GUI de ACSLS, sin opción ni elección. Como los clientes pueden usar bibliotecas lógicas solo con la interfaz de línea de comandos (CLI) lib_cmd, sin la GUI, ahora la compatibilidad de SMCE con bibliotecas lógicas se puede instalar sin la GUI.
checkinstallLa instalación del paquete ya no se interrumpe si los usuarios acsss, acssa o acsdb están conectados. En cambio, aparece un mensaje de advertencia en el shell del instalador.
WebLogic ahora se instala de modo que se inicie con el protocolo de seguridad TLS1 y Secure Sockets Extensions activado.
ACSLS admite ya desde hace años la generación de colas y el reintento de montajes y desmontajes cuando los recursos están temporalmente no disponibles en bibliotecas SL8500 y SL3000. ACSLS ahora admite la generación de colas y el reintento de montajes y desmontajes en bibliotecas de cambiador de medios SCSI (como SL150 y SL500).
Al seleccionar un cartucho reutilizable para mount scratch, se seleccionan solo cartuchos que admitan lectura/escritura para la unidad de cinta especificada.
query mount scratchEl comando query mount scratch muestra las unidades compatibles con los medios de una agrupación reutilizable especificada. Se muestran solo unidades que sean compatibles con lectura/escritura para los medios, sin incluir las unidades que admiten solo lectura.
cap_id al mensaje "Extraer cartuchos de CAP"Se agregó cap_id al mensaje "Extraer cartuchos de CAP" en cmd_proc.
Se agregó un nuevo campo para el estado de volúmenes lógicos en lib_cmd display volume.
psacsLa utilidad de diagnóstico psacs ahora incluye un campo para los ID de los sockets asociados con ID de procesos e ID de dispositivos mchanger asociados con procesos de dispositivo.
Esta versión contiene soluciones para los siguientes bugs que se informaron en ACSLS 8.3 y versiones anteriores.
Se hicieron las siguientes correcciones para la instalación de ACSLS.
Los archivos del bloc de notas ya no se borran después de la finalización de db_import.sh
Todos los puntos de salida desde db_import.sh ahora se envían a rutinas que borran el directorio /tmp/acsls.
Valor incoherente de PostgreSQL PGPORT
La secuencia de comandos de instalación de WebLogic ahora verifica el valor actual de PGPORT para evitar problemas cuando se haya cambiado el valor por defecto de PGPORT.
El entorno de inicio de sesión acssa
Al iniciar sesión, el usuario acssa ve de inmediato la interfaz de línea de comandos (CLI) cmd_proc. Este es el único entorno accesible disponible para acssa a menos que el administrador de ACSLS establezca una cuenta de GUI para este usuario.
La rutina de instalación de paquetes realiza controles de arquitectura de sistema
Esta corrección no permite la instalación si la arquitectura no coincide.
Se hicieron las siguientes correcciones para el inicio y el cierre de ACSLS.
Cambios en el inicio de ACSLS.
La lógica de inicio ya no se interrumpe si se detecta que hay servicios no esenciales en estado de mantenimiento. Los únicos servicios esenciales para que la secuencia de inicio se ejecute correctamente son acsdb y acsls. Si estos dos servicios están en línea, el estado de ACSLS será funcional para las operaciones de biblioteca generales.
La rutina de inicio entra en un bucle infinito si la base de datos está dañada.
Si acsls.startup determina que las condiciones existentes no permitirán la ejecución de ACSLS, la rutina de inicio no intenta reiniciar ACSLS una y otra vez.
Comando arcaico en secuencia de comandos de inicio de CSCI.
La presencia de comandos arcaicos de UNIX BSD hacían que se produjera un error en el inicio de CSCI en Solaris 11.
Un error fatal de base de datos en el inicio hace que la pantalla de inicio se bloquee sin ningún mensaje de error.
Se corrigió un error fatal de base de datos en el inicio que hacía que la pantalla de inicio se bloqueara sin ningún mensaje de error.
Se informan todos los errores al cargar archivos planos de control de acceso a la base de datos.
Cuando se produce un error al cargar archivos planos de control de acceso a la base de datos, se informa siempre el motivo del error.
El registro de PostgreSQL en Linux está configurado incorrectamente para el nivel de depuración.
El registro de PostgreSQL ahora refleja las transacciones de la base de datos, sin información adicional de depuración.
Un CAP no instalado impide que LSM se conecte automáticamente.
Si había un CAP configurado en la base de datos pero no instalado en la biblioteca, el LSM en el que se encontraba el CAP no podía conectarse durante el inicio de ACSLS. Ahora aparece un mensaje que le indica que actualice la configuración y se permite la conexión del LSM.
Se impide una condición de bloqueo con pantalla de inicio cuando el evento acsss_event.log no existe.
Esta corrección crea el evento acsss_event.log si todavía no existe.
En la barra de estado que se muestra durante el inicio de ACSLS, se agrega compatibilidad para terminales que no sean UNIX, como putty.
Cuando ACSLS se está iniciando, la barra de estado debería mostrar una única línea con 'x' contiguas que indican el avance del inicio de la misma manera en la que lo hace el shell de Solaris y Linux.
Los CAP automáticos se desbloquean cuando se inicia ACSLS.
Los CAP automáticos que estén conectados o se encuentren en estado de diagnóstico se desbloquean automáticamente durante el proceso acsss enable. (Antes, los CAP automáticos en SL8500 no se desbloqueaban durante el inicio de ACSLS).
Se hicieron las siguientes correcciones para los logs de ACSLS.
Los logs de la base de datos se archivan automáticamente.
Los logs de PostgreSQL que se encuentran en el directorio pg_log se archivan y se comprimen automáticamente en todas las plataformas.
rpTrail.log se archiva automáticamente.
rpTrail.log (registra todas las respuestas devueltas mediante acslm) se archiva y comprime automáticamente.
Se hicieron las siguientes correcciones para el montaje y el desmontaje.
Fallos de solicitudes de movimiento.
Esta corrección ahora informa si se produce un fallo en una solicitud de movimiento y la biblioteca está recuperando un cartucho.
Generación de mensajes erróneos cuando no hay más cartuchos de limpieza.
Cuando una unidad de cinta solicitaba limpieza y no había cartuchos de limpieza compatibles, se informaban otros mensajes de error. Ahora se informan solo los mensajes relevantes y se realiza el montaje subyacente.
Se permite vary offline force de unidades in_use y reservadas para que se las pueda recuperar mediante vary online.
Cuando una unidad estaba en uso o reservada, no se la podía pasar al estado fuera de línea con la opción force. Esto le impedía recuperar con facilidad unidades que hubieran quedado en estado "en uso" o "reservado".
Mejor procesamiento de las operaciones de montaje y desmontaje en bibliotecas de canal de fibra.
ACSLS informaba errores en algunas operaciones de movimiento de FC, cuando la biblioteca tal vez hubiera realizado correctamente la operación solicitada. Esto podía dejar una unidad vacía marcada como "en uso" para ACSLS, lo que requería la intervención manual (dismount force).
Estos problemas ahora se solucionaron y se informan resultados correctos. Este mejor procesamiento también permite recuperar algunas operaciones que puedan haberse interrumpido a causa de alguna interrupción temporal.
Se hizo la siguiente corrección para las utilidades de ACSLS.
volrpt
En volrpt, se informan volúmenes que tienen un ACS o un LSM de inicio que no está configurado o ya no está configurado. Esto incluye volúmenes cuya dirección de inicio se determinaba con ceros al expulsarlos. Esos volúmenes no se informaban si no había configurado un ACS 0 y un LSM 0.
Se hicieron las siguientes correcciones para los procesos de ACSLS.
ACSLS se podía bloquear cuando se ejecutaba un detector de puertos.
Esta corrección impide que ACSLS se bloquee al detectar puertos.
query drive all podía informar unidades varias veces cuando las unidades estaban asignadas a bibliotecas lógicas.
Cuando query drive all informa unidades de cinta a un cliente ACSAPI, filtra las unidades asignadas a bibliotecas lógicas. Esto podía hacer que se informara varias veces el mismo juego de unidades.
Mejora del rendimiento de query server, query acs y query lsm con colas de solicitudes voluminosas.
Cuando ACSLS procesa muchas solicitudes concurrentes, el rendimiento de estos comandos query ahora es mejor.
Recorte de espacios iniciales y finales en números de serie de unidades de cinta.
Los espacios que se informaban en el campo de número de serie de las unidades de cinta podían hacer que los números de serie válidos quedaran superpuestos por espacios. Esta corrección también recorta los espacios iniciales y finales de los nombres World Wide Names de las unidades.
Se corrigieron los mensajes "No hay formato para TYPE" en acsss_event.log y cmd_proc.
La corrección informa códigos de TYPE y valores de IDENTIFIER válidos en los errores para notificaciones de eventos y cmd_proc.
lib_cmd: compatibilidad con volúmenes que tienen caracteres de VOLSER # y $ válidos.
Se corrigió la compatibilidad adicional de lib_cmd para volúmenes que tienen los caracteres de VOLSER # y $ válidos.
La utilidad del_vol ya no genera errores para VOLSER que tengan más de seis caracteres.
La respuesta de cmd_proc audit ya no declara como 'válido' cuando se intenta hacer una auditoría de varios ACS con un único CAP.
Se corrigió un mensaje de error de cmd_proc move.
Al intentar mover un volumen a un panel inaccesible, el mensaje de error ahora indica que "el panel especificado está lleno o el LSM está lleno".
Se corrigió un mensaje de log de evento que era confuso.
Después de que el usuario desactive un CAP utilizando SL Console, ACSLS ya no sugiere que el CAP se pasará al estado fuera de línea.
Se hizo la siguiente corrección a las bibliotecas conectadas por fibra de mchanger SCSI.
ACSLS proporciona una mejor recuperación de bibliotecas FC después de interrupciones temporales.
Cuando se detecta una interrupción temporal de las comunicaciones con una biblioteca FC, ACSLS ahora actúa de manera más dinámica para reestablecer la conexión con la biblioteca. Esto resulta particularmente útil en entornos Linux, donde las rutas de los dispositivos pueden ser volátiles (mchanger de ACSLS proporciona rutas de dispositivo persistentes).
La recuperación automática de bibliotecas ahora incluye interrupciones temporales debido al reinicio de una biblioteca SL500. Anteriormente, se necesitaba una operación de recuperación manual en ese tipo de situaciones.
Se hicieron las siguientes correcciones para la GUI de ACSLS.
Rendimiento de la GUI: reducción de la frecuencia de sondeo de servidor de consultas.
Si se inicia el proceso de sustitución como parte de ACSLS (true si instala las funciones de GUI, SMCE o lib_cmd), se inicia un subproceso de consulta para supervisar periódicamente el estado de ACSLS. La frecuencia se cambió de una vez cada 11 segundos a una vez por minuto, lo que reduce el número de comandos ejecutados y reduce la cantidad de accesos a la base de datos.
userAdmin.sh no se inicializa en Linux. No se pueden agregar usuarios de la GUI.
La utilidad userAdmin.sh en Linux ahora se inicializa y agrega usuarios de la GUI.
No se muestran mensajes de error de acsss_event.log después de expulsiones pequeñas desde la GUI.
Las expulsiones de 42 cartuchos o menos desde la GUI se realizaban correctamente, pero en el log de eventos y las ventanas de cmd_proc aparecían mensajes de error.
GUI con Error 500 (error interno de servidor).
Con esta corrección se soluciona el Error 500 (error interno de servidor) al hacer clic en un CAP.
La alarma crítica del panel de control de la GUI está siempre encendida si SMCE no está instalado.
El estado de smce ahora se comprueba solo si se lo instaló.
Se hizo la siguiente corrección al controlador de modo de destino SCSI.
El controlador QLT se interrumpe de manera intermitente.
Si un iniciador de FC (cliente) agotaba el tiempo de espera mientras ACSLS todavía realizaba una operación de montaje o desmontaje, ACSLS podía seguir realizando la operación solicitada.
Había varios resultados posibles:
La operación podía finalizar correctamente.
La operación podía generar algún error.
La operación podía eventualmente agotar el timeout.
Una vez que el cliente agotaba el timeout para la operación, se producía una interrupción temporal en ese dispositivo cambiador de medios (y otros dispositivos presentados en el puerto de destino). La interrupción temporal continuaba hasta que ACSLS completaba el montaje: correcto, con errores o timeout agotado. En ese momento, el puerto de destino se restablecía y se podían reanudar las operaciones del cliente.
Para solucionar este problema, se gestionaron los valores de timeout relativos entre la aplicación de copia de seguridad y el servidor de ACSLS que presenta las bibliotecas lógicas. Este juego de cambios se implementó en dos actualizaciones relacionadas con COMSTAR para los valores de timeout.
Las operaciones de biblioteca lógica aparecen incorrectamente en lib_cmd en Linux.
Se actualizó la utilidad lib_cmd para enmascarar las operaciones de biblioteca lógica en las pantallas de los menús principales en instalaciones Linux y Solaris cuando no se ha instalado la función de compatibilidad con bibliotecas lógicas.
Se hicieron las siguientes correcciones para ACSLS HA.
Servicios acsls y acsdb en modo de mantenimiento después de perderse un sistema de archivos.
Esta corrección es aplicable a ACSLS HA, pero el cambio se hizo en ACSLS. Si se perdió el sistema de archivos, SMF no puede desactivar los servicios acsls y acsdb y los pasa al modo de mantenimiento. Esta corrección proporciona un método alternativo para que SMF desactive los servicios, lo que permite que el fallo del sistema de archivos no genere una condición de modo de mantenimiento después de que los servicios se hayan detenido y el sistema haya hecho la conmutación por error al nodo alternativo.
La secuencia de comandos de inicio de HA genera un error al intentar usar el entorno de ACSLS como origen.
ACSLS HA ya no usa DATABASE_VERSION de release.vars (no esencial) como origen.
Para obtener información sobre el compromiso de Oracle con la accesibilidad, visite el sitio web del Programa de Accesibilidad de Oracle en http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Los clientes de Oracle que hayan contratado servicios de soporte electrónico pueden acceder a ellos mediante My Oracle Support. Para obtener información, visite http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info o, si tiene alguna discapacidad auditiva, visite http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs.
Notas de la versión de StorageTek Automated Cartridge System Library Software, Versión 8.4
E68210-01
Copyright © 2015, Oracle y/o sus filiales. Todos los derechos reservados.
Este software y la documentación relacionada están sujetos a un contrato de licencia que incluye restricciones de uso y revelación, y se encuentran protegidos por la legislación sobre la propiedad intelectual. A menos que figure explícitamente en el contrato de licencia o esté permitido por la ley, no se podrá utilizar, copiar, reproducir, traducir, emitir, modificar, conceder licencias, transmitir, distribuir, exhibir, representar, publicar ni mostrar ninguna parte, de ninguna forma, por ningún medio. Queda prohibida la ingeniería inversa, desensamblaje o descompilación de este software, excepto en la medida en que sean necesarios para conseguir interoperabilidad según lo especificado por la legislación aplicable.
La información contenida en este documento puede someterse a modificaciones sin previo aviso y no se garantiza que se encuentre exenta de errores. Si detecta algún error, le agradeceremos que nos lo comunique por escrito.
Si este software o la documentación relacionada se entrega al Gobierno de EE.UU. o a cualquier entidad que adquiera las licencias en nombre del Gobierno de EE.UU. entonces aplicará la siguiente disposición:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
Este software o hardware se ha desarrollado para uso general en diversas aplicaciones de gestión de la información. No se ha diseñado ni está destinado para utilizarse en aplicaciones de riesgo inherente, incluidas las aplicaciones que pueden causar daños personales. Si utiliza este software o hardware en aplicaciones de riesgo, usted será responsable de tomar todas las medidas apropiadas de prevención de fallos, copia de seguridad, redundancia o de cualquier otro tipo para garantizar la seguridad en el uso de este software o hardware. Oracle Corporation y sus filiales declinan toda responsabilidad derivada de los daños causados por el uso de este software o hardware en aplicaciones de riesgo.
Oracle y Java son marcas comerciales registradas de Oracle y/o sus filiales. Todos los demás nombres pueden ser marcas comerciales de sus respectivos propietarios.
Intel e Intel Xeon son marcas comerciales o marcas comerciales registradas de Intel Corporation. Todas las marcas comerciales de SPARC se utilizan con licencia y son marcas comerciales o marcas comerciales registradas de SPARC International, Inc. AMD, Opteron, el logotipo de AMD y el logotipo de AMD Opteron son marcas comerciales o marcas comerciales registradas de Advanced Micro Devices. UNIX es una marca comercial registrada de The Open Group.
Este software o hardware y la documentación pueden proporcionar acceso a, o información sobre contenidos, productos o servicios de terceros. Oracle Corporation o sus filiales no son responsables y por ende desconocen cualquier tipo de garantía sobre el contenido, los productos o los servicios de terceros a menos que se indique otra cosa en un acuerdo en vigor formalizado entre Ud. y Oracle. Oracle Corporation y sus filiales no serán responsables frente a cualesquiera pérdidas, costos o daños en los que se incurra como consecuencia de su acceso o su uso de contenidos, productos o servicios de terceros a menos que se indique otra cosa en un acuerdo en vigor formalizado entre Ud. y Oracle.