Guía para la instalación y la migración

• Los prerrequisitos de hardware y software de VisualAge(R) para Java(TM), ediciones Professional y Enterprise
• Cómo instalar VisualAge para Java, ediciones Professional y Enterprise
• Los prerrequisitos y las plataformas soportadas para el servidor de depósito en equipo (EMSRV)
• Cómo instalar el servidor de depósito en equipo (EMSRV)
• Cómo prepararse para el entorno de desarrollo en equipo
• Limitaciones y problemas conocidos de la instalación
• Cómo migrar desde una versión anterior de VisualAge para Java (información general y específica de cada componente)

En el directorio pdf también está disponible una versión PDF de esta guía. El directorio pdf está situado en el CD del producto VisualAge para Java, Professional Edition, y en el CD de características adicionales de VisualAge para Java, Enterprise Edition. 

Dónde encontrar más información acerca de VisualAge para Java

Este archivo no incluye información detallada acerca de los componentes y las características específicos de VisualAge para Java. Para obtener información al respecto, consulte las notas de release a las que puede acceder seleccionando Inicio > Programas > IBM VisualAge para Java para Windows V4.0 > Notas de release. Para todos los idiomas, las notas de release están en el CD del producto (están disponibles después de la instalación), y en el sitio web http://www.ibm.com/vadd.  

Este archivo no contiene información acerca de cómo utilizar VisualAge para Java. Para obtener información al respecto, consulte la publicación Cómo empezar y la ayuda en línea. Parte de la ayuda en línea se ha agrupado en documentos PDF que puede ver e imprimir utilizando Adobe Acrobat Reader (disponible en http://www.adobe.com/). No todos los PDF están disponibles en todos los idiomas. Los archivos PDF están disponibles en el directorio pdf. El directorio pdf está situado en el CD del producto VisualAge para Java, Professional Edition, y en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos). Si no bajó el componente que contiene los PDF, no tendrá este directorio.

En el Índice de PDF (en la guía Cómo empezar) hallará información sobre lo que contiene cada archivo PDF. En la ayuda en línea también hay una sección titulada "Recursos web" con enlaces para acceder a los recursos de VisualAge que están disponibles en Internet.

El sitio web llamado VisualAge Developer Domain (VADD) ofrece artículos técnicos, guías de aprendizaje, ejemplos y las preguntas más frecuentes (FAQ), además de proporcionar un fácil acceso a las actualizaciones de producto y soporte de VisualAge para Java. Desde este sitio, puede bajar las herramientas de desarrollo de VisualAge para Java, así como beans reutilizables, asistentes y kits de utilidades que le permitan complementar el desarrollo de los applets y servlets. Vea http://www.ibm.com/vadd. También puede emplear este sitio para solicitar componentes de los nuevos releases de VisualAge para Java.

Si ya está abonado a VisualAge Developers Domain, no es necesario que vuelva a registrarse. Puede utilizar el ID y la contraseña actuales para obtener información reciente y actualizaciones de código. Si es usted un usuario nuevo, localice el número de abonado en la caja (o en el kit de medios) que recibió. Si ha adquirido VisualAge para Java y no tiene ningún número de abonado, póngase en contacto con el representante de ventas de IBM(R).

La página inicial del producto VisualAge para Java está en http://www.ibm.com/software/ad/vajava.

Tabla de contenido

Parte A: VisualAge para Java, Professional Edition

1.0 Prerrequisitos
2.0 Instalación
      2.1 Instalación de VisualAge para Java, Versión 4.0
      2.2 Instalación posterior de componentes adicionales
      2.3 Consideraciones sobre la instalación en Windows(R) 2000
      2.4 Instalación de IBM Developer Kit, Java Technology Edition, v1.2.2
3.0 Migración desde una versión anterior de VisualAge para Java
      3.1 Migración desde VisualAge para Java Versión 3.5 o Versión 3.5.3
      3.2 Migración desde la Versión 2.0, 3.0x o 3.0x Early Adopters de VisualAge para Java
4.0 Limitaciones y problemas conocidos
      4.1 Limitaciones y problemas conocidos de la instalación
      4.2 Limitaciones y problemas conocidos de la desinstalación

Parte B: VisualAge para Java, Enterprise Edition

1.0 Prerrequisitos
      1.1 Prerrequisitos generales
      1.2 Prerrequisitos específicos de cada componente
2.0 Instalación
      2.1 Instalación de VisualAge para Java, Versión 4.0
      2.2 Instalación posterior de componentes adicionales
      2.3 Instalación de los clientes de equipo de VisualAge para Java
      2.4 Instalación de un cliente que tenga un depósito autónomo
      2.5 Consideraciones de instalación y utilización para Windows(R) 2000
      2.6 Instalación de IBM Developer Kit, Java Technology Edition, v1.2.2
3.0 Migración desde una versión anterior de VisualAge para Java
     3.1 Migración de un depósito compartido desde una versión anterior de VisualAge para Java
4.0  Limitaciones y problemas conocidos
      4.1 Limitaciones y problemas conocidos de la instalación
      4.2 Limitaciones y problemas conocidos de la desinstalación

Parte C: El servidor de depósito de equipo (EMSRV)

1.0 Prerrequisitos
      1.1 Plataformas soportadas
      1.2 TCP/IP
      1.3 Parches de Novell necesarios para ejecutar EMSRV en NetWare 4.x
      1.4 Parche de Solaris necesario para ejecutar EMSRV en Solaris     
      1.5 Sistemas de archivos soportados   
2.0 Instalación
     2.1 Instalación de EMSRV para Windows(R)
             2.1.1 Instalación de EMSRV como servicio en el registro de Windows
     2.2 Instalación de EMSRV para NetWare 
     2.3 Instalación de EMSRV para OS/2(R) Warp
     2.4 Instalación de EMSRV para AIX
     2.5 Instalación de EMSRV para HP-UX/Solaris(TM)
     2.6 Instalación de EMSRV para Linux
3.0 Migración
      3.1 Migración desde la Versión 6.x/7.0 de EMSRV a la Versión 7.1
4.0 Preparación para el desarrollo en equipo
      4.1 Preparación del servidor de equipo
      4.2 Probar una conexión de cliente
      4.3 Añadir usuarios a lista de usuarios del depósito
5.0 Limitaciones y problemas conocidos
      5.1 Rendimiento en conexiones de red de alta latencia y bajo ancho de banda
      5.2 Limitaciones de la conexión TCP/IP 
      5.3 Detección de conexiones desactivadas inesperadamente
      5.4 Intercambio de las distintas versiones de EMSRV y de los programas de utilidad de EMSRV
      5.5 Limitaciones de PAM
      5.6 Las contraseñas contienen caracteres no ASCII no pueden utilizarse para autenticar con EMSRV
      5.7 Los menús y las ventanas muestran caracteres corruptos al ejecutar en NetWare japonés
      5.8 EMADMIN no copia el directorio de recursos almacenados

Parte D: Información de migración específica de cada componente

1.0 CICS(R) Transaction Server  * +
2.0 Data Access Beans
3.0 Data Access Builder * +
4.0 Entorno de desarrollo EJB(TM)+
5.0 Enterprise Access Builder y e-connectors +
6.0 Enterprise Toolkit para AS/400(R) +
7.0 Enterprise Toolkit para OS/390(R) +
8.0 Enterprise Toolkit para estaciones de trabajo * +
9.0 Control de versiones externo
10.0 Entorno de desarrollo IDL +
11.0 Entorno de desarrollo integrado (IDE)
12.0 Entorno de desarrollo JSP/Servlet
13.0 Asistente en la migración *
14.0 Persistence Builder +
15.0 RMI Access Builder * +
16.0 Editor de composición visual
17.0 Servlet Builder y el lanzador de Servlets  * +
18.0 Clases Swing
19.0 XMI Toolkit +

* Estos componentes no están soportados en VisualAge para Java, Versión 4.0

+ Solo para Enterprise Edition

Parte E: Información general

1.0 Manejar los recursos de un proyecto y la gestión de los recursos
2.0 Migración desde OS/2 y AIX
3.0 Nuevas restricciones de seguridad en J2SDK v.1.2.2
4.0 Nueva herramienta de control de versiones externo (sustituye a la herramienta SCM externo)
5.0 Trabajar con los ORB de terceros en VisualAge para Java
6.0 Contenido del CD de características adicionales

Apéndices

Apéndice A: Comparación de las características del acceso a datos

Parte A: VisualAge para Java, Professional Edition

A.1.0 Prerrequisitos

Esta edición de VisualAge para Java, Versión 4.0, tiene los siguientes prerrequisitos de hardware y software:

• Windows(R) 98, Windows 2000 o Windows NT(R) 4.0 con el Service Pack 4 o superior. 
• Ratón y dispositivo de puntero *.
• TCP/IP instalado y configurado.
• Se recomienda un procesador Pentium(R) II o superior. Si piensa trabajar en el Entorno de prueba de WebSphere(TM), le recomendamos un procesador cuya velocidad mínima sea de 400 MHz.
• Pantalla SVGA (800 x 600) o superior (se recomienda 1024 x 768).
• 48 MB de RAM como mínimo (se recomiendan 96 MB).
• Para utilizar el depurador distribuido, necesitará un mínimo de 128 MB de RAM (le recomendamos 196 MB).
• Va a necesitar 128 MB de RAM como mínimo si desea trabajar en el entorno de prueba WebSphere de VisualAge para Java. Le recomendamos vivamente que utilice 256 MB para evitar la inestabilidad de disco.
• Un navegador web con posibilidad de marcos, como Netscape Navigator 4.7 o superior, o Microsoft(R) Internet Explorer 5.0 o superior. No debe utilizar nada inferior a Netscape Navigator 4.7 o Internet Explorer 5.0 para ver la documentación en línea.
• Requisitos de espacio en disco: (basado en NTFS) 350 MB como mínimo (se recomiendan 400 MB o más). El espacio en disco basado en FAT depende del tamaño y del particionado del disco duro:
  Si va a hacer la instalación en una unidad FAT de tamaño muy grande, el espacio que requiere VisualAge para Java es casi el doble (debido a los 32 KB de actividad general de cluster).

Si desea ejecutar concurrentemente Websphere Application Server con DB2(R) y VisualAge para Java, le recomendamos un mínimo de 512 MB.

* Nota: VisualAge para Java no da soporte al ratón de desplazamiento Logitech. Los ratones Logitech con controladores que correlacionen de nuevo la acción de desplazamiento con el ratón harán que se produzca un error del sistema cuando se utilicen para desplazar.

A.2.0 Instalación

Esta sección contiene información acerca de cómo instalar VisualAge para Java, Versión 4.0. Importante: si va a migrar desde una versión anterior de VisualAge para Java, consulte la sección 3.0 antes de instalar la Versión 4.0. Si desea información especial acerca de cómo instalar en Windows 2000, consulte la sección 2.3.

Consulte también el archivo README (que encontrará en el directorio README del CD del producto) para obtener información acerca de las limitaciones y los problemas que surgieron a última hora. 

A.2.1 Instalación de VisualAge para Java, Versión 4.0

Antes de instalar el producto, compruebe lo siguiente:

• Debe tener como mínimo 20 MB libres en la unidad del sistema de Windows, y la variable de entorno TEMP o TMP debe señalar a un directorio temporal válido que tenga libres 6 MB como mínimo.
• Si está utilizando el directorio destino por omisión, la variable PATH debe tener menos de 377 caracteres en Windows 98, y menos de 820 caracteres en Windows NT y en Windows 2000.
• La variable CLASSPATH debe tener menos de 455 caracteres. VisualAge para Java inserta aproximadamente 54 caracteres en la CLASSPATH durante la instalación. Estas cifras se basan en el supuesto de que el directorio destino tiene una longitud de 36 caracteres; por ejemplo, Archivos de programa\IBM\VisualAge for Java.

Si intenta instalar VisualAge para Java en Windows, Millennium Edition, se le pedirá que aumente el espacio del entorno. Antes de instalar, tendrá que seguir los pasos que se indican más abajo; de lo contrario, el sistema de ayuda de VisualAge para Java no funcionaría correctamente. Para aumentar el espacio del entorno, siga estos pasos:

1. Salga de la pantalla de instalación.
2. Abra el Explorador de Windows. Navegue hasta el directorio Windows (por ejemplo, C:\Windows).
3. Pulse Command.com con el botón derecho del ratón y después pulse Propiedades en el menú emergente. Pulse la pestaña Memoria.
4. En el recuadro Entorno inicial, establezca el tamaño de entorno inicial en 4.096 bytes. Pulse Aceptar.
5. Cierre el Explorador de Windows.
6. Rearranque el equipo.
7. Reinicie la instalación de VisualAge para Java.

A.2.1.1 Instalación de VisualAge para Java, Versión 4.0 desde el CD del producto

1. Inserte el CD-ROM en la unidad de CD. Si va a migrar desde una versión anterior de VisualAge para Java, lea "Migrar desde una versión anterior de VisualAge para Java" (sección 3.0 de este documento) ANTES de seguir realizando el procedimiento de instalación.
2. Si la ejecución automática está inhabilitada en el sistema, ejecute setup.exe desde el directorio raíz de la unidad de CD.
3. Seleccione Instalar productos. Seleccione Instalar VisualAge para Java para empezar la instalación de VisualAge para Java. Si piensa depurar clases que se hayan desarrollado fuera del IDE de VisualAge para Java, o depurar programas que se ejecuten en una máquina aparte, vaya a la sección A.2.1.1.1, donde hallará información para instalar el depurador distribuido (Distributed Debugger).
4. Siga las instrucciones de la pantalla.
5. Inicie el IDE de VisualAge para Java.

Instalación silenciosa
Para instalar VisualAge para Java, Versión 4.0, de forma silenciosa, invoque este mandato desde el directorio ivj40\setup:

setup /s /v/qn

VisualAge para Java se instalará automáticamente en el directorio por omisión c:\Archivos de programa\IBM\VisualAge for Java.

Para instalar de forma silenciosa en un directorio distinto (por ejemplo, d:\IBMVJava40), invoque el mandato siguiente en el directorio ivj40\setup:

setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"

siendo d:\IBMVJava40 el directorio en el que desea efectuar la instalación.

A.2.1.1.1 Instalación de Distributed Debugger desde el CD del producto
Si piensa depurar clases que se hayan desarrollado fuera del IDE de VisualAge para Java, o depurar programas que se ejecuten en una máquina aparte, debe instalar el depurador distribuido (Distributed Debugger). Distributed Debugger está soportado en estos sistemas operativos: Windows, AIX, OS/2, HP-UX, Solaris, Linux y Linux/390. Las instrucciones de instalación para cada sistema operativo se proporcionan más abajo. Todos los archivos de Distributed Debugger están en el CD del producto, en el directorio Debugger.

 Distributed Debugger para Windows

1. Ejecute setup.exe y seleccione Instalar productos. Después seleccione Instalar Distributed Debugger para instalar el depurador distribuido.

1. Cree un directorio de trabajo, por ejemplo /tmp/idebug.
2. Copie idebug.tar.Z desde el soporte de instalación en el directorio de trabajo.
3. Vaya al directorio de trabajo.
4. Descomprima el archivo idebug.tar.Z con el mandato: uncompress idebug.tar.Z
5. Extraiga las imágenes de instalación de idebug.tar con el mandato: tar -xvf idebug.tar
6. Como root, emita este mandato: installp -ac -X -V2 -g -N -d idebug
7. También puede emplear SMIT con el mandato: smitty install_latest

Distributed Debugger para OS/2

Distributed Debugger para HP-UX

Prerrequisito: 
Se requiere la versión 1.3 de Java para la instalación y la depuración Java.

1. Cree un directorio de trabajo, por ejemplo, /tmp/idebug
2. Copie el archivo install.class en el directorio de trabajo.
3. En un indicador de mandatos, abra el directorio de trabajo. Si el directorio de trabajo es /tmp/idebug, tendría que utilizar el mandato: cd /tmp/idebug para abrirlo.
4. Como root, teclee el mandato: java install.class

1. Cree un directorio de trabajo, por ejemplo, /tmp/idebug
2. Copie dbgsetup e idebug.pkg en el directorio de trabajo.
3. En un indicador de mandatos, abra el directorio de trabajo. Si el directorio de trabajo es /tmp/idebug, tendría que emitir el mandato cd /tmp/idebug para abrirlo.
4. Convierta "dbgsetup" en ejecutable emitiendo este mandato: chmod +x dbgsetup
5. Como root, entre este mandato para instalar el depurador: ./dbgsetup idebug.pkg

Distributed Debugger para Linux 

Distributed Debugger para Linux/390 

Como root, entre este mandato para instalar el depurador: rpm -Uvh DERJPICL-9-1.s390.rpm

Distributed Debugger para OS/390

1. Instale Distributed Debugger para Windows.
2. Siga las instrucciones del archivo README_install.txt, que está en el directorio de instalación base en Windows.

A.2.1.2 Instalación desde la imagen electrónica de VisualAge para Java, Versión 4.0
Para reducir el tiempo de bajada, la imagen electrónica de VisualAge para Java, Professional Edition para Windows, Versión 4.0 está dividida en componentes.

• IDE (entorno de desarrollo integrado) - comprende nueve componentes de archivador, de los cuales solo dos son obligatorios. Esto permite bajar solo las características que se desean.
• Distributed Debugger - proporciona un componente que se puede bajar por separado para cada sistema operativo que se va a utilizar como destino de depuración.
• IBM Developer Kit 1.2.2 - contiene IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9, para la plataforma Windows. 

A.2.1.2.1 IDE
Existen nueve componentes que se pueden bajar para el entorno de desarrollo integrado. Los nueve componentes son archivadores autoextraíbles. Es preciso instalar los dos primeros; los demás son opcionales. Consulte la lista siguiente para obtener información detallada acerca de lo que contiene cada archivador.

Cuando haya bajado los dos primeros componentes y los archivos opcionales que desea, ejecute cada archivador autoextraíble y asegúrese de que cada uno de ellos se extrae en el mismo directorio temporal. Cuando se hayan extraído todos los archivos, vaya al directorio temporal y ejecute setup.exe. Siga las instrucciones de la pantalla e inicie el IDE.

Si piensa trabajar en un idioma que no sea el inglés, debe bajar el componente correcto y ejecutar el archivador autoextraíble correspondiente a su idioma antes de ejecutar setup.exe. No puede cambiar ni añadir un idioma después de instalar VisualAge para Java.

Si está trabajando con una imagen electrónica de VisualAge para Java, no puede utilizar el diálogo Agregar o quitar programa (Inicio > Valores >Panel de control > Agregar o quitar programas) para instalar componentes adicionales de VisualAge para Java después de la instalación adicional. Si lo intenta, obtendrá un mensaje de error y no podrá instalar componentes adicionales. Debe ejecutar setup.exe desde el directorio en el que se extrajeron los componentes bajados para añadir componentes adicionales a VisualAge para Java.

A continuación se proporciona una descripción de cada componente de archivador:

• VisualAge para Java - IDE 1 de 9 (Solo en inglés) - OBLIGATORIO. Incluye los siguientes elementos fundamentales: el entorno de desarrollo integrado, los beans de acceso a datos (DAB) y el editor de composición visual.
• VisualAge para Java - IDE 2 de 9 (Solo en inglés) - OBLIGATORIO. Incluye los siguientes elementos fundamentales: el entorno de desarrollo integrado, la API de herramientas, el SmartGuide Servlets y XML Parser para Java.
• VisualAge para Java - IDE 3 de 9 (solo en inglés) - OPCIONAL. Soporte de base de datos mejorado (Stored Procedure Builder y SQLJ), Entorno de desarrollo JSP, Control de versiones externo.
• VisualAge para Java - IDE 4 de 9 - OPCIONAL. Entornos de despliegue y documentación en línea en formato PDF.
• VisualAge para Java - IDE 5 de 9 - OPCIONAL. Paquete de idiomas portugués (BR) y español. Contiene el texto en portugués (BR) y en español para el IDE y todos sus componentes.
• VisualAge para Java - IDE 6 de 9 - OPCIONAL. Paquete de idiomas francés e italiano. Contiene el texto en francés y en italiano para el IDE y todos sus componentes.
• VisualAge para Java - IDE 7 de 9 - OPCIONAL. Paquete de idioma japonés. Contiene el texto en japonés para el IDE y todos sus componentes.
• VisualAge para Java - IDE 8 de 9 - OPCIONAL. Paquete de idiomas alemán y coreano. Contiene el texto en alemán y en coreano para el IDE y todos sus componentes.
• VisualAge para Java - IDE 9 de 9 - OPCIONAL. Paquete de idioma chino simplificado y tradicional. Contiene el texto en chino simplificado y en chino tradicional para el IDE y todos sus componentes.

A.2.1.2.2 Distributed Debugger
Existe un componente que se baja por separado para cada sistema operativo destino soportado por el depurador distribuido (Distributed Debugger). Si piensa depurar clases que se hayan desarrollado fuera del IDE de VisualAge para Java, o depurar programas que se ejecuten en una máquina aparte, debe bajar e instalar el depurador distribuido (Distributed Debugger). Las instrucciones de instalación para cada sistema operativo se proporcionan más abajo. Estas instrucciones, además de la información sobre el acuerdo de licencia, están en el archivo readme.txt que se incluye junto con cada componente.

VisualAge para Java - Distributed Debugger para Windows contiene la interfaz de usuario y el motor de depuración para Windows. Este componente es un archivador autoextraíble. Para instalarlo, siga estos pasos:

1. Si ha bajado y extraído VisualAge para Java, ejecute setup.exe y seleccione Instalar productos. Después seleccione Instalar Distributed Debugger. 
2. Si desea instalar Distributed Debugger sin VisualAge para Java, abra este directorio desde un indicador de mandatos: DirectorioDepurador\windows (siendo DirectorioDepurador el directorio en el que ha puesto el depurador distribuido (Distributed Debugger) extraído) y ejecute este mandato: setup.bat

1. Cree un directorio de trabajo, por ejemplo /tmp/idebug.
2. Copie idebug.tar.Z desde el soporte de instalación en el directorio de trabajo.
3. Vaya al directorio de trabajo.
4. Descomprima el archivo idebug.tar.Z con el mandato: uncompress idebug.tar.Z
5. Extraiga las imágenes de instalación de idebug.tar con el mandato: tar -xvf idebug.tar
6. Como root, emita este mandato: installp -ac -X -V2 -g -N -d idebug
7. También puede emplear SMIT con el mandato: smitty install_latest

VisualAge para Java - Distributed Debugger para HP-UX contiene el motor de depuración para HP-UX.

Prerrequisito: 
Se requiere la versión 1.3 de Java para la instalación y la depuración Java.

Para instalarlo, desempaquete el archivo y siga estas instrucciones:

1. Cree un directorio de trabajo, por ejemplo, /tmp/idebug
2. Copie el archivo install.class en el directorio de trabajo.
3. En un indicador de mandatos, abra el directorio de trabajo. Si el directorio de trabajo es /tmp/idebug, tendría que utilizar el mandato: cd /tmp/idebug para abrirlo.
4. Como root, teclee el mandato: java install.class

1. Convierta "dbgsetup" en ejecutable emitiendo este mandato: chmod +x dbgsetup
2. Como root, entre este mandato para instalar el depurador: ./dbgsetup idebug.pkg

VisualAge para Java - Distributed Debugger para Linux contiene el motor de depuración para Linux. Para instalarlo, desempaquete el archivo e instale el depurador siguiendo estas instrucciones:

VisualAge para Java - Distributed Debugger para Linux/390 contiene el motor de depuración para Linux/390. Para instalarlo, desempaquete el archivo e instale el depurador siguiendo estas instrucciones:

Como root, entre este mandato: rpm -Uvh DERJPICL-9-1.s390.rpm

Distributed Debugger para OS/390

1. Instale Distributed Debugger para Windows.
2. Siga las instrucciones del archivo README_install.txt, que está en el directorio de instalación base en Windows.

A.2.1.2.3 IBM Developer Kit 1.2.2
VisualAge para Java - IBM Developer Kit 1.2.2 contiene IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9, para la plataforma Windows. Es un archivador de autoextracción. Para instalarlo, ejecute este archivo, que lanzará automáticamente el programa de instalación después de que se haya extraído del archivador, y siga las instrucciones.

A.2.2 Instalar posteriormente componentes adicionales

Para instalar componentes adicionales de VisualAge para Java en cualquier momento posterior a la instalación inicial, inserte el CD-ROM en la unidad de CD, seleccione instalar VisualAge para Java y pulse Modificar en la pantalla Mantenimiento de programa. Si la ejecución automática está inhabilitada en el sistema, deberá ejecutar setup.exe desde el directorio raíz de la unidad de CD. Si dispone de una versión electrónica de VisualAge para Java, también tendrá que ejecutar setup.exe de forma manual y seguir los mismos pasos.

Todos los componentes aparecerán listados en la ventana Editar características, con una indicación de su estado actual de instalación. Una 'X' de color rojo indica que el componente no está instalado en ese momento. Puede elegir instalar esos componentes. No seleccione ningún componente que no esté marcado con una 'X' de color rojo, pues ya están instalados. 

No puede instalar una segunda instancia de VisualAge para Java, Versión 4.0. No puede cambiar el idioma de instalación sin desinstalar primero el producto.

A.2.3 Consideraciones sobre la instalación en Windows 2000  

Este release de VisualAge para Java sigue proporcionando soporte de tolerancia (tal como lo define Microsoft) para Windows 2000.

El directorio de instalación por omisión es <Archivos de programa>\IBM\VisualAge for Java. Por omisión, para Windows 2000, solo los administradores y los usuarios estándar pueden realizar la instalación en <Archivos de programa>. Los usuarios normales (restringidos) no pueden escribir en esa ubicación.

Debido al diseño actual de VisualAge para Java, si se instala el producto en esta ubicación y lo ha de utilizar un usuario normal, tendrá que cambiar los valores de seguridad del directorio IBM o del directorio IBM\VisualAge para Java bajo <Archivos de programa> para autorizar a los usuarios normales (restringidos) el acceso de escritura. Si no se hiciera así, podrían surgir anomalías cuando se intentara iniciar el IDE.

A.2.4 Instalar IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9 

Si ha instalado VisualAge para Java desde el CD del producto, debe ejecutar install.exe desde el directorio de IBM Developer Kit para instalar IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9. Este directorio se encuentra en el CD del producto. Si tiene una versión electrónica de VisualAge para Java, este directorio está en su directorio temporal (aquel en el que ha puesto los componentes extraídos); sin embargo, no necesita ejecutar install.exe, porque el programa de instalación se lanza automáticamente después de que se ha extraído del archivador IBM Developer Kit bajado.

Para obtener información detallada acerca de IBM Developer Kit, consulte el archivo README del directorio IBM Developer Kit.

A.3.0 Migración desde una versión anterior de VisualAge para Java

En la Parte D y en la Parte E hallará información, tanto general como específica de cada componente, que conviene leer antes de empezar el proceso de migración.

Desde la Versión 3.5 o la Versión 3.5.3, puede efectuar la migración automáticamente. La Versión 4.0 se instala encima de la  Versión 3.5 o la Versión 3.5.3. En la sección 3.1 encontrará información acerca de cómo migrar desde VisualAge para Java, Versión 3.5 o Versión 3.5.3.

Desde la Versión 3.0x, Early Adopters, debe efectuar la migración manualmente.  En la sección 3.2 encontrará información acerca de cómo migrar desde VisualAge para Java, 3.0x, Early Adopters.

Si está utilizando actualmente VisualAge para Java, Versión 2.0, 3.0 ó 3.02 con el soporte de JDK 1.1.x, no puede migrar automáticamente a VisualAge para Java, Versión 4.0. Estas versiones de VisualAge para Java pueden coexistir con VisualAge para Java, Versión 4.0. En la sección 3.2 encontrará información acerca de cómo migrar el contenido del depósito y los archivos de recursos desde la Versión 2.0 ó 3.0x de VisualAge para Java.

No puede migrar desde VisualAge para Java, Versión 3.5, Entry Enterprise Edition, ni desde VisualAge para Java, Versión 3.5 o Versión 3.5.3, Enterprise Edition a VisualAge para Java, Versión 4.0, Professional Edition. Debe migrar a la Versión 4.0, Enterprise Edition.

Nota: al migrar VisualAge para Java desde la Versión 3.5 o la Versión 3.5.3 a la Versión 4.0, el proceso de instalación parece que se cuelga. Esto se produce porque la función "DoCosting" (que compara las versiones 3.5 ó 3.5.3 de los archivos con las versiones 4.0 de los archivos) puede necesitar hasta tres minutos para ejecutarse, dando la impresión de que el proceso de instalación se ha colgado.

A.3.1 Migración desde la Versión 3.5 o Versión 3.5.3

La migración desde VisualAge para Java, Versión 3.5 o Versión 3.5.3 es automática. El programa de instalación de la Versión 4.0 actualiza automáticamente a la Versión 4.0 un producto de la Versión 3.5 o Versión 3.5.3 instalado.

Migración automática

1. Haga copia de seguridad de sus datos de usuario siguiendo estos pasos. Cree copias de seguridad de los archivos de recursos y de depósito por si se produjeran problemas durante la migración.
   1. Cree una versión de los proyectos y los paquetes. Al depósito de VisualAge para Java, Versión 4.0, solo se pueden importar los proyectos y los paquetes con versión. En la ayuda en línea de VisualAge para Java hallará instrucciones para crear versiones.
   2. Guarde el depósito en una nueva ubicación fuera del árbol de directorios de VisualAge para Java. El nombre de archivo y la vía de acceso del depósito es x:\IBMVJava\ide\repository\ivj.dat, siendo x:\IBMVJava el directorio de instalación de VisualAge para Java.
      Nota: si desea migrar desde la Versión 3.5 o la Versión 3.5.3, el depósito también incluye copias con versión de los archivos de recursos de proyecto, que se encuentran en el siguiente directorio: x:\IBMVJava\ide\repository\ivj.dat.pr. Debe guardar una copia del directorio ivj.dat.pr fuera del árbol de directorios de VisualAge para Java. 
2. Si va a instalar VisualAge para Java, Versión 4.0, consulte las instrucciones de instalación que figuran en la sección 2.1.
3. Elija actualizar la instalación actual. No es necesario que desinstale la Versión 3.5 ni la Versión 3.5.3, ya que se actualizan automáticamente a la Versión 4.0. La Versión 4.0 se instalará automáticamente en el directorio en el que instaló la Versión 3.5 o la Versión 3.5.3.
4. En cuanto concluya una instalación de actualización de modo satisfactorio, todos los recursos de proyecto y todos los datos del depósito migrarán automáticamente a la Versión 4.0 en el momento de iniciar por primera vez el IDE de la Versión 4.0. 

En el caso de que se produzca una anomalía en la instalación, deberá migrar manualmente los datos de usuario. También deberá hacerlo si el IDE no puede iniciarse o encuentra un error cuando esté migrando los datos de usuario.

Migración manual

1. Verifique si ha guardado los datos del depósito (esto es, el depósito y, si está migrando desde la Versión 3.5 o la Versión 3.5.3, el directorio ivj.dat.pr) y los archivos de recursos fuera del árbol de directorios de VisualAge para Java.
2. Desinstale completamente el producto. Deben suprimirse todos los subdirectorios y archivos de la Versión 3.5 y de la Versión 3.5.3.
3. Rearranque e instale la Versión 4.0.
4. Inicie el IDE.
5. Ahora puede importar al nuevo depósito los paquetes y proyectos del depósito antiguo. En el entorno de trabajo, seleccione Archivo > Importar; luego marque el botón de selección Depósito y pulse Siguiente. En el campo Nombre de depósito, escriba la vía de acceso a la copia de seguridad del archivo ivj.dat. Después, seleccione los proyectos y los paquetes que desea importar. No podrá importar ningún proyecto ni ningún paquete que no tenga una versión. Nota: no debe tratar de importar ningún proyecto del sistema de una versión anterior de VisualAge para Java.
6. Para añadir automáticamente los proyectos seleccionados al área de trabajo, marque el recuadro de selección Añadir la edición de proyecto más reciente al área de trabajo. Este recuadro de selección solo está disponible cuando se marca el botón de selección Proyectos.
7. Pulse Terminar.
8. No es necesario que haga una copia de la copia de seguridad de los archivos de recursos y colóquela en el subdirectorio x:\IBMVJava\ide\project_resources\project, donde x:\IBMVJava es el directorio de instalación de VisualAge para Java, Versión 4.0, y project es el nombre del proyecto al que están asociados los recursos.
   Al importar los proyectos de la Versión 3.5 o de la Versión 3.5.3 al depósito, todas las copias con versión de los recursos del proyecto (que están en el directorio ivj.dat.pr) se añaden automáticamente al depósito. 

A.3.2 Migración desde la Versión 2.0, 3.0x o 3.0x Early Adopters de VisualAge para Java

Puede migrar manualmente el contenido de su depósito y sus archivos de recursos desde la Versión 2.0, Versión 3.0x, 3.0x, Early Adopters de VisualAge para Java. En el archivo de ayuda en línea titulado "Reparar referencias de clase o paquete" hallará información sobre cómo reparar las rupturas.

No es necesario que desinstale la Versión 2.0, 3.0x o 3.0x, Early Adopters, pues pueden coexistir con VisualAge para Java, Versión 4.0.

Antes de desinstalar la Versión 2.0, 3.0x o 3.0x, Early Adopters, siga todos los pasos que se indican a continuación si desea importar a la Versión 4.0 los archivos de depósito y de recursos de la Versión 2.0, 3.0x o 3.0x, Early Adopters Environment for Java 2 Platform, Standard Edition, v1.2. Si no está desinstalando la Versión 2.0, 3.0x ni 3.0x, Early Adopters, no es necesario que realice los pasos 2, 3, 4 y 8, pero sí debe realizar los demás pasos.

1. Cree una versión de los proyectos y los paquetes. A esta versión de VisualAge para Java solo se pueden importar los proyectos y los paquetes que tengan una versión. En la ayuda en línea de VisualAge para Java hallará instrucciones para la creación de versión.
2. Guarde el depósito en una nueva ubicación situada fuera del árbol de directorios de VisualAge para Java. El nombre de archivo y la vía de acceso del depósito son x:\IBMVJava\ide\repository\ivj.dat, siendo x:\IBMVJava el directorio de instalación de VisualAge para Java.
3. Haga una copia de los archivos de recursos (como los archivos de imágenes o de sonido) utilizados por las aplicaciones Java y colóquela en un directorio situado fuera del árbol de directorios de VisualAge para Java. Por omisión, los archivos de recursos de cada proyecto de VisualAge para Java se encuentran en subdirectorios llamados x:\IBMVJava\ide\project_resources\project, donde x:\IBMVJava\ es el directorio de instalación de VisualAge para Java y project es el nombre del proyecto al que están asociados los recursos.
4. Ahora ya puede desinstalar la Versión 2.0, 3.0x o 3.0x, Early Adopters, e instalar la Versión 4.0. No es necesario que desinstale la Versión 2.0, 3.0x o 3.0x, Early Adopters, pues pueden coexistir con VisualAge para Java, Versión 4.0.
5. Instale VisualAge para Java, Versión 4.0, (vea la sección 2.1) e inicie el IDE de la Versión 4.0. 
6. En la ayuda en línea hallará información sobre cómo puede importar los paquetes y los proyectos del depósito antiguo al nuevo. No podrá importar ningún proyecto ni ningún paquete que no tenga una versión. Nota: no debe tratar de importar ningún proyecto del sistema de una versión anterior de VisualAge para Java.
7. Haga una copia de la copia de seguridad de los archivos de recursos (o cree una copia de los archivos de recursos de la instalación actual de 2.0/3.0x o 3.0x, Early Adopters, si no ha desinstalado 2.0/3.0x o 3.0x, Early Adopters, y cópiela) y colóquela en el subdirectorio x:\IBMVJava\ide\project_resources\project, donde x:\IBMVJava es el directorio de instalación de VisualAge para Java, Versión 4.0, y project es el nombre del proyecto al que están asociados los recursos.
8. Tras haber verificado que la migración manual ha sido satisfactoria, podrá suprimir las copias de seguridad creadas en los pasos 2 y 3.

A.4.0 Limitaciones y problemas conocidos

Consulte también el archivo README (que encontrará en el directorio README del CD) para obtener información acerca de las limitaciones y los problemas que surgieron a última hora. 

A.4.1 Limitaciones y problemas conocidos de la instalación

La lista siguiente es una relación de las cuestiones que deben tenerse presentes durante la instalación.

4.1.1 Limitaciones de disco

• No instale en una unidad local o de red HPFS, ya que Windows 98, Windows 2000 y Windows NT 4.0 tienen dificultades para manejar los nombres largos de archivo en HPFS.
• No realice la instalación en una unidad de Novell NetWare. La instalación fallaría en una unidad de Novell NetWare.

A.4.1.2 Autorización de usuario

• Para instalar NetQuestion Search Server, debe tener derechos de acceso para escribir en el directorio raíz "\" de la unidad en la que está instalado VisualAge para Java.
• Al instalar el producto en Windows 2000, tal vez reciba un mensaje de aviso si no es usted administrador. El mensaje indica que algunos programas pueden no funcionar como es debido si no los instala un administrador. Debe iniciar la sesión como Administrador antes de empezar la instalación de VisualAge para Java.
• Los usuarios restringidos, cuando intentan instalar VisualAge para Java, Versión 4.0, en Windows 2000, pueden recibir incorrectamente un "Error de inicialización de configuración" con el mensaje "El programa de instalación ha detectado que se está usando unInstallShield. Cierre unInstallShield y reinicie la instalación. Error 432". Antes de repetir el intento de instalar el producto, verifique si tiene derechos de acceso de administrador o de usuario estándar.
• Si no tiene derechos de acceso de administrador mientras instala en Windows NT, la función de búsqueda de la ayuda en línea no funcionará. 

A.4.1.3 Consideraciones sobre TCP/IP

• El aviso "Configurado automáticamente" del programa de instalación indica que las excepciones de proxy están configuradas automáticamente para el navegador. Pregunte al administrador del sistema si 127.0.0.1 se maneja como dirección local.
• Es preciso que instale y configure TCP/IP para que pueda instalar correctamente el producto IBM VisualAge para Java. En Windows 98 y Windows 2000, debe seguir estos pasos para habilitar TCP/IP:
  1. Para una configuración de adaptador de LAN:
     • Debe tener habilitado el DNS con un nombre válido de sistema principal y de dominio.
     • El DNS de LAN ha de resolver localhost en 127.0.0.1.
     • No se puede trabajar en modalidad de desconexión con una configuración de adaptador de LAN.
  2. Para una configuración de adaptador de acceso telefónico:
     • Debe tener inhabilitado el DNS.
     • La dirección TCP/IP debe obtenerse de forma automática.

  Estas opciones de configuración serán válidas para todos los adaptadores TCP/IP, aunque solo se hayan cambiado para este. No podrá utilizar la opción de LAN y de acceso telefónico sin efectuar una reconfiguración.

  Las propiedades TCP/IP de acceso telefónico a redes del proveedor de servicios de Internet (ISP) deben estar configuradas de acuerdo con la documentación del ISP. Las propiedades TCP/IP de acceso telefónico a redes alterarán temporalmente las propiedades TCP/IP del adaptador de acceso telefónico configuradas por medio del icono Red situado en el Panel de control de Windows 98 o Windows 2000. Esta alteración temporal solo tendrá lugar si las propiedades TCP/IP del adaptador de acceso telefónico están configuradas según se ha indicado antes. No debe habilitar el DNS en las propiedades TCP/IP del adaptador de acceso telefónico ni establecer una dirección IP en ellas, ya que, si lo hace, se producirían interferencias con la configuración de acceso telefónico a redes del ISP.

  Para Windows NT 4.0, puede utilizar cualquiera de las configuraciones TCP/IP descritas más arriba. Si la máquina trabaja en modalidad autónoma, también se puede habilitar el adaptador Microsoft Loopback sin los otros dos adaptadores.

A.4.1.4 Extensión de shell (Windows NT)

Si obtiene un mensaje que indica que el programa de instalación ha detectado una extensión de shell para Windows NT, la instalación no podrá continuar. En tal caso, deberá seguir estos pasos:

1. Asegúrese de que tiene un disco para recuperación de emergencia. Las instrucciones para crearlo se encuentran en la documentación de ayuda de Windows.
2. Teclee regedit.exe en un indicador de mandatos.
3. En el editor de registro, expanda la clave
   \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
4. Seleccione el nombre de shell en las parejas nombre/datos de la clave anterior. Importante: tome nota de los datos registrados para este nombre, pues los va a necesitar después de instalar IBM VisualAge para Java.
5. Seleccione Edición > Modificar en la barra de menús para la pareja nombre/datos de shell.
6. Establezca el valor del nombre de shell en Explorer.exe. Pulse Aceptar.
7. Seleccione Registro > Salir en la barra de menús.
8. Reinicie el sistema y complete la instalación de IBM VisualAge para Java.
9. Una vez completada la instalación, restaure la entrada de registro anterior de esta manera:
   a. Teclee regedit.exe en un indicador de mandatos.
   b. En el editor de registro, expanda la clave \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
   c. Seleccione el nombre de shell en las parejas nombre/datos de la clave anterior.
   d. Seleccione Edición > Modificar en la barra de menús para la pareja nombre/datos de shell.
   e. Restaure el valor del nombre de shell, dándole el valor que anotó en el paso 4. Pulse Aceptar.
   f. Seleccione Registro > Salir en la barra de menús.

A.4.1.5 Recuperación del sistema tras una instalación fallida

Si falla la instalación, debe eliminar todos los archivos de la Versión 4.0 que se hayan instalado. Si está vacío el directorio en el que pensaba instalar VisualAge para Java, es que el proceso de instalación se ha retrotraído y ha eliminado los archivos que ya se habían instalado. Si lo desea, puede suprimir el directorio vacío, pero no es necesario que lo haga. Sin embargo, si hay archivos en el directorio, deberá iniciar otra vez el proceso de instalación. Este se abrirá en la modalidad de mantenimiento y usted deberá seleccionar que se elimine la instalación parcial de la Versión 4.0 antes de repetir el intento de instalar el producto.

También tendrá que suprimir la entrada de registro:

\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows

siguiendo para ello estas instrucciones:

1. Asegúrese de que tiene un disco para recuperación de emergencia. Las instrucciones para crearlo se encuentran en la documentación de ayuda de Windows.
2. Teclee regedit.exe en un indicador de mandatos.
3. En el editor de registro, expanda y seleccione la clave
   \\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows\4.0
4. Seleccione Edición > Eliminar en la barra de menús para esta clave.
5. Seleccione Sí cuando se le pida que confirme la supresión de la clave.
6. Seleccione Registro > Salir en la barra de menús.

Si antes de que fallara la instalación ya se habían instalado archivos de NetQuestion, también debe suprimirlos.

1. Abra un nuevo indicador de mandatos. Vea si se había instalado algún archivo de NetQuestion; para ello, teclee lo siguiente en el indicador de mandatos que acaba de abrir: set imninstsrv. Este mandato le proporcionará la ubicación en la que se ha instalado NetQuestion en su máquina. Por ejemplo:

   IMNINSTSRV=C:\imnnq_nt

   La ubicación del directorio de NetQuestion puede aparecer de manera distinta en función de en qué unidad haya instalado VisualAge para Java y de qué sistema operativo esté utilizando. Si la variable está establecida (es decir, si obtiene una ubicación que indica dónde está instalado NetQuestion), siga en el paso 2. 

   Si recibe un mensaje de error como este "Variable de entorno imninstsrv no definida", ello indica que no se instaló ningún archivo de NetQuestion o que la instalación de NetQuestion no se completó satisfactoriamente. En tal caso, seleccione Inicio > Buscar > Archivos o carpetas, y busque el siguiente archivo en el sistema: vahelp.cfg. Si encuentra este archivo en algún directorio cuyo nombre empiece por "imnnq" (por ejemplo, imnnq_NT o imnnq_98), suprímalo. No tendrá que realizar los pasos 2 y 3. 

2. Vaya al directorio de NetQuestion (esta es la información que aparece a continuación de IMNINSTSRV=)
3. Teclee vahcfg remove /p vj32

Así se eliminarán los archivos de NetQuestion que VisualAge para Java haya instalado. Ello no afectará a los archivos de NetQuestion instalados por otros productos (por ejemplo, DB2).

Haga una copia de seguridad del depósito y de los archivos de recursos si aún no lo ha hecho. Consulte la parte A, sección 3.1 para obtener información acerca de cómo realizar esta tarea. 

Rearranque y reinstale el producto una vez que haya realizado todos estos pasos. Si la ayuda falla después de que haya reinstalado VisualAge para Java, consulte la Guía para la resolución de problemas, donde hallará más información sobre cómo solucionar las anomalías de la ayuda. La Guía para la resolución de problemas (trshoot.htm) está en el CD del producto VisualAge para Java, Professional Edition, y en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Tras instalar VisualAge para Java, la guía también está en X:\IBMVJava, siendo X:\IBMVJava el directorio de instalación de VisualAge para Java.

A.4.1.6 Errores del instalador de Windows

La lista siguiente es una relación de los errores del instalador de Windows que deben tenerse presentes durante la instalación.

Si recibe el mensaje de error 1603 al instalar VisualAge para Java, es que el instalador de Windows no ha podido hacer el proceso de inicialización y la instalación no puede continuar. 

Ciertos productos (como VisualCafe de Symantec) instalan automáticamente un archivo llamado sfc.dll cuando se instalan en una plataforma Windows. Este archivo se emplea únicamente en Windows 2000; el instalador de Windows lo invoca para el proceso de seguridad. 

Si hay un archivo que tenga ese nombre en la variable PATH de Windows NT 4.0, el instalador de Windows intentará cargarlo, aunque sfc.dll solo sea aplicable a Windows 2000. Entonces el instalador de Windows fallará. 

Para evitar que se produzca este problema, siga estos pasos:

1. Seleccione Inicio > Buscar > Archivos o carpetas; busque el archivo sfc.dll en el sistema.
2. Cambie temporalmente el nombre del archivo sfc.dll (la versión que reside en la variable PATH de Windows NT 4.0) por el nombre sfc.old.
3. Instale VisualAge para Java.
4. Tras haber instalado satisfactoriamente VisualAge para Java, vuelva a cambiar el nombre sfc.old por sfc.dll.

Error muy grave de LoadLibrary()

El error muy grave de LoadLibrary() se produce porque el instalador de Windows no registró debidamente uno o varios kernels de instalación (Ikernels) de VisualAge para Java. Para soslayar este problema, debe suprimir el directorio InstallShield en el que residen los archivos de IKernel; después, reinstale VisualAge para Java siguiendo estos pasos:

1. Si es necesario, salga del proceso de instalación.
2. Suprima este directorio: x:\Archivos de programa\Archivos comunes\InstallShield, siendo x la unidad en la que ha intentado instalar VisualAge para Java.
3. Reinstale el producto. 

Error 1631 o error interno 2755 (solo en Windows NT 4.0)

Si instala VisualAge para Java en Windows NT 4.0, puede recibir uno de los siguientes mensajes de error:

• Error 1631: El servicio Instalador de Windows no se ha podido iniciar. Póngase en contacto con el personal de soporte.
• Error interno 2755: Por favor, solicite ayuda al personal de soporte del producto.

Si recibe uno de estos mensajes de error, puede ser que tenga claves de registro con valores nulos. Al iniciar la instalación de VisualAge para Java, el archivo userenv.dll intentará analizar diversas claves de registro; si algunas de ellas tienen valores nulos, la instalación fallará con uno de los mensajes de error indicados anteriormente.

Para soslayar este comportamiento, puede elegir entre eliminar las variables de entorno nulas o modificarlas (cambiar el valor nulo por un valor válido) antes de instalar VisualAge para Java. Cuando ya haya instalado VisualAge para Java, puede volver a dar a las variables sus valores originales.

Precaución: tenga cuidado al eliminar o modificar las variables nulas. Antes de eliminarlas o de modificarlas, debe tomar en consideración el efecto que ello podría tener.

Errores internos 2381, 1303, 1310, 1313 (solo en Windows NT)

Si está intentando instalar VisualAge para Java y se dan algunas o la totalidad de estas circunstancias:

• Está instalando VisualAge para Java en Windows NT 4.0.
• La unidad que contiene la carpeta winnt o la unidad en la que está instalando VisualAge para Java está formateada con el sistema de archivos NTFS
• Los permisos establecidos en esas unidades son incorrectos
• Tiene permisos solo de lectura en el directorio en el que está instalando VisualAge para Java

tal vez reciba uno o varios de los siguientes mensajes de error:

• Error interno 2381: Por favor, solicite ayuda al personal de soporte del producto.
• Error interno 1303: Los privilegios del instalador son insuficientes para acceder a este directorio: NombreDirectorio
• Error interno 1310: Error al intentar crear el archivo destino: NombreArchivo Código de error del sistema: CódigoError (este código varía en función del problema)
• Error interno 1315: No se puede escribir en la carpeta especificada 'NombreCarpeta.

Este problema se produce cuando solo hay permisos de lectura en las carpetas siguientes:

\Archivos de programa\IBM\VisualAge for Java
\WinNT\Installer

Para solucionar este problema, asegúrese de que tiene los permisos necesarios en las unidades o en los directorios. Para ello, siga estos pasos:

1. En el Explorador de Windows, seleccione la unidad o el directorio apropiado.
2. Pulse la carpeta con el botón derecho del ratón y seleccione Propiedades en el menú emergente que aparece.
3. Seleccione la pestaña Seguridad. Pulse Permisos.
4. Seleccione Todos. En el menú desplegable Tipo de acceso, seleccione Control total.
5. Marque el recuadro de selección Reemplazar permisos en subdirectorios.
6. Pulse Aceptar.
7. Pulse Sí para confirmar que desea reemplazar los permisos en todos los subdirectorios.
8. Pulse Aceptar.
9. Instale VisualAge para Java.

Error interno 2735 de inicio de motor

Si recibe el error 2735, siga estos pasos para soslayarlo:

1. Busque estos archivos en el directorio del sistema Windows 32:
   • shd401lc.dll
   • shdoclc.dll
   • shdoc401.dll
   • shdocvw.dll
2. Cambie el nombre shd401lc.dll por shd401lc.old.
3. Cambie el nombre shdoclc.dll por shdoclc.old.
4. Seleccione Inicio > Ejecutar para abrir el diálogo Ejecutar. Ejecute los siguientes mandatos para desregistrar estos archivos .dll:
   • regsvr32 /u shd401lc.dll
   • regsvr32 /u shdoclc.dll
5. Registre estos archivos dll ejecutando los siguientes mandatos en el diálogo Ejecutar:
   • regsvr32 shdoc401.dll
   • regsvr32 shdocvw.dll
6. Instale VisualAge para Java.

Si recibe el siguiente mensaje de error, puede que sea incorrecto el valor del archivo de registro de las Herramientas administrativas (Común):

Error 1606. No se ha podido acceder a la ubicación de red \Profiles\AllUsers\StartMenu\Programs\Administrative Tools\.
Error interno 2707. INSTALLDIR.

Para poder instalar VisualAge para Java, primero debe editar el valor del archivo de registro de las Herramientas administrativas (Común). Para ello, siga estos pasos:

1. Invoque regedit.exe desde un indicador de mandatos.
2. Expanda y seleccione la clave
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folder
3. Seleccione Common Administrative Tools.
4. Seleccione Edición > Modificar.
5. En el campo de datos de valor, entre: %SystemRoot%\Profiles\AllUsers\StartMenu\Programs\Administrative Tools
6. Pulse Aceptar.
7. Seleccione Registro > Salir en la barra de menús.
8. Instale VisualAge para Java.

A.4.2 Limitaciones y problemas conocidos de la desinstalación

A continuación figura una lista de cuestiones que deberá tener en cuenta al desinstalar VisualAge para Java.

4.2.1 Espacio en disco

Debe tener como mínimo 2 MB libres en la unidad del sistema de Windows, y la variable de entorno TEMP o TMP debe señalar a un directorio temporal válido que tenga libres 5 MB como mínimo.

A.4.2.2 Desinstalación de Distributed Debugger

Si ha instalado el depurador distribuido (Distributed Debugger) como parte de la instalación de VisualAge para Java, debe desinstalar VisualAge para Java antes de desinstalar Distributed Debugger. Para ello, cuando haya desinstalado VisualAge para Java, vaya al directorio de instalación del depurador y ejecute el programa de desinstalación.

Si ha desinstalado VisualAge para Java y no puede desinstalar el depurador distribuido, debe suprimir la clave de registro:

HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java

y luego repetir el intento de desinstalar el depurador. NO siga estos pasos si está utilizando el depurador distribuido junto con otros productos, pues ya no podrá utilizar el depurador tras suprimir la clave de registro.

Siga estos pasos:

1. Teclee regedit.exe en un indicador de mandatos.
2. En el editor de registro, expanda y seleccione la clave:
   HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
3. Seleccione Edición > Eliminar en la barra de menús para esta clave.
4. Seleccione Sí cuando se le pida que confirme la supresión de la clave.
5. Seleccione Registro > Salir en la barra de menús.

Asimismo, establezca en 1 el valor de la siguiente clave de registro:

HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount

A.4.2.3 Variables de entorno (Windows 98)

Al desinstalar VisualAge para Java en Windows 98, pueden haber quedado algunas entradas de entorno en el archivo autoexec.bat. Estas entradas que han quedado no suelen causar problemas, pero si desinstala y reinstala el producto varias veces, pueden producirse dos problemas. Tal vez acabe teniendo sentencias de vía de acceso conflictivas que puedan impedir el funcionamiento de la ayuda en línea, o tal vez se quede sin espacio para las vías de acceso, lo que podría impedirle reinstalar el producto satisfactoriamente.

Para solucionar estos problemas:

1. Haga una copia de seguridad del archivo autoexec.bat.
2. Determine si en el sistema tiene otro programa que requiera el motor de búsqueda HTML (como DB2); para ello, siga estos pasos:
   a) Desinstale VisualAge para Java y rearranque el sistema.
   b) Teclee regedit.exe en un indicador de mandatos y, en el editor de registro, expanda el árbol HKEY_LOCAL_MACHINE\SOFTWARE\. Si en este árbol hay un directorio de IBM, expándalo para ver si contiene un directorio de NetQuestion. Si ve este directorio, es probable que esté empleando el motor de búsqueda con otro producto de IBM.
3. Si no está utilizando el motor de búsqueda HTML para otro producto, elimine todas las entradas IMN o IMQ que vea en el archivo autoexec.bat antes de reinstalar VisualAge para Java.
4. Si está utilizando el motor de búsqueda HTML para otro producto, suprima del archivo autoexec.bat los duplicados que vea de estas entradas:
   IMNINST
   IMNINSTSRV
   IMNNQ
   IMNNQ_95
   IMQCONFIGCL
   IMQCONFIGSRV
   Suprima asimismo las entradas duplicadas de la línea IF EXIST X:\IMNNQ_95\IMNENV.BAT CALL IMNEV.BAT
5. Asegúrese de que las entradas repetidas que elimina no sean las originales. Si no está seguro de cuáles son las originales, debe determinar dónde considera el sistema que se instala NetQuestion. Siga estos pasos:
   1. Teclee regedit.exe en un indicador de mandatos.
   2. En el editor de registro, expanda la clave
      \\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\NetQuestion\Installation Directory
   3. El valor que el directorio tiene dentro de esta clave muestra la vía de acceso en la que se instala NetQuestion. Algunas variables de entorno deben contener este directorio como parte de su valor para que NetQuestion funcione correctamente.
      
      Si algunas de las variables anteriores incluyen un directorio distinto del que aparece en el registro como parte de su valor, suprímalas.

A.4.2.4 Desinstalación de NetQuestion

Cuando vaya a desinstalar VisualAge para Java, puede ser que no se desinstale NetQuestion. Podrían surgir problemas si no desinstala NetQuestion y más adelante intenta reinstalar el producto. 

Para eliminar los archivos de NetQuestion instalados por VisualAge para Java, siga estos pasos. Ello no afectará a los archivos de NetQuestion instalados por otros productos (por ejemplo, DB2).

1. Para localizar el directorio de NetQuestion, teclee lo siguiente en un indicador de mandatos: set imninstsrv. Este mandato le proporcionará la ubicación en la que se ha instalado NetQuestion en su máquina. Por ejemplo:

   IMNINSTSRV=C:\imnnq_nt

   La ubicación del directorio de NetQuestion puede aparecer de manera distinta en función de en qué unidad haya instalado VisualAge para Java y de qué sistema operativo esté utilizando. Si recibe un mensaje de error como este "Variable de entorno imninstsrv no definida", ello indica que se han desinstalado todos los archivos de NetQuestion.

2. Vaya al directorio de NetQuestion (esta es la información que aparece a continuación de IMNINSTSRV=)
3. Teclee vahcfg remove /p vj32

Así se eliminarán los archivos de NetQuestion que VisualAge para Java haya instalado.

Si más adelante reinstala VisualAge para Java y resulta que falla la ayuda, consulte la Guía para la resolución de problemas, donde hallará más información sobre cómo solucionar las anomalías de la ayuda. La Guía para la resolución de problemas (trshoot.htm) está en el CD del producto VisualAge para Java, Professional Edition, y en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Tras instalar VisualAge para Java, la guía también está en X:\IBMVJava, siendo X:\IBMVJava el directorio de instalación de VisualAge para Java.

Parte B: VisualAge para Java, Enterprise Edition

B.1.0 Prerrequisitos

B.1.1 Prerrequisitos generales

Esta edición de VisualAge para Java, Versión 4.0, tiene los siguientes prerrequisitos de hardware y software:

• Windows 98, Windows 2000 o Windows NT(R) 4.0 con el Service Pack 4 o superior. 
• Ratón o dispositivo de puntero *.
• TCP/IP instalado y configurado.
• Se recomienda un procesador Pentium II(R) o superior.  Si piensa trabajar en el Entorno de prueba de WebSphere, le recomendamos un procesador cuya velocidad mínima sea de 400 MHz.
• Pantalla SVGA (800 x 600) o superior (se recomienda 1024 x 768).
• 96 MB de RAM como mínimo (se recomiendan 160 MB).
• Va a necesitar 128 MB de RAM como mínimo si desea trabajar en el entorno de prueba WebSphere de VisualAge para Java. Le recomendamos vivamente que utilice 256 MB para evitar la inestabilidad de disco.
• Para utilizar el depurador distribuido, necesitará un mínimo de 128 MB de RAM (le recomendamos 196 MB).
• Requisitos de espacio en disco: (basado en NTFS) 400 MB como mínimo (se recomiendan 750 MB o más). El espacio en disco basado en FAT depende del tamaño y del particionado de disco duro. Si va a hacer la instalación en una unidad FAT de tamaño muy grande, el espacio que requiere VisualAge para Java es casi el doble (debido a los 32 KB de actividad general de cluster). Si va a instalar e-connectors (instalados automáticamente con Transactions Access Builder) necesitará otros 150-200 MB de espacio en disco libre.
• Un navegador web con posibilidad de marcos, como Netscape Navigator 4.7 o superior, o Microsoft(R) Internet Explorer 5.0 o superior.

Si desea ejecutar concurrentemente Websphere Application Server con DB2 y VisualAge para Java, le recomendamos un mínimo de 512 MB.

Debe utilizar EMSRV, Versión 7.1, si está trabajando en un entorno en equipo. En la Parte C hallará información sobre cómo pasar de la Versión 6.x ó 7.0 a la Versión 7.1. 

* Nota: VisualAge para Java no da soporte al ratón de desplazamiento Logitech. Los ratones Logitech con controladores que correlacionen de nuevo la acción de desplazamiento con el ratón harán que se produzca un error del sistema cuando se utilicen para desplazar.

B.1.2 Prerrequisitos específicos de cada componente

Algunos componentes tienen prerrequisitos específicos:

• Domino(TM) AgentRunner
  • Para el desarrollo de las aplicaciones, se requieren el cliente Notes 5.0.5 (o superior) y el diseñador Domino 5.0.5 (o superior). Para la ejecución de las aplicaciones, se requiere el cliente Notes 5.0 (o superior) o el servidor Domino 5.0 (o superior). 
• Domino Access Builder
  • Requiere el cliente Notes 5.0.5 (o superior) o el servidor Domino 5.0.5 (o superior).
• Enterprise Toolkit para AS/400(R) (ET/400)
  • Se requiere OS/400 Release V, V4R3M0 o superior.
• Enterprise Toolkit para OS/390(R) (ET/390)
  • En OS/390:
    • El daemon NFS ejecutándose en OS/390
    • El servidor REXEC ejecutándose en OS/390
    • El servidor FTP OMVS ejecutándose en OS/390
    • VisualAge para Java, Enterprise Edition para OS/390, característica de tiempo de ejecución 
    • Acceso de escritura al directorio /tmp en OS/390 
    • Para VisualAge para Java, Enterprise Edition para OS/390, Versión 2, el parámetro SBDATACONN de TCP se tiene que configurar en el sistema principal para definir las conversiones entre las páginas de códigos EBCDIC y ASCII al ejecutar las acciones Ejecutar ejecutable, Depurar ejecutable, Ejecutar main y Depurar main de ET/390 desde el entorno de desarrollo integrado (IDE) de VisualAge para Java. En OS/390 TCP/IP OpenEdition: Guía de configuración hallará más información sobre cómo definir este parámetro.
    • Un archivo de datos de instalación Java ET/390 debidamente configurado (javaInstall.data) que resida en el directorio /usr/lpp/hpj/. Si no ha adquirido la característica de compilador de VisualAge para Java, Enterprise Edition para OS/390, puede crear este archivo manualmente; en la ayuda en línea de ET/390 hallará información sobre las palabras clave y los parámetros de este archivo. 

  En estaciones de trabajo, el cliente NFS Maestro para Windows NT o Windows 2000. Para el cliente NFS para Windows NT, tendrá que efectuar un montaje binario para el directorio HFS al que se exportarán los archivos de clase.

• Enterprise Access Builder para SAP R/3
  • Requiere acceso a un servidor SAP R/3.
• Enterprise Access Builder para IMS(TM)
  • Para ejecutar una aplicación o un servlet Java que utilice IMS Connector para Java, los siguientes productos instalados y empaquetados por separado deben estar instalados y ejecutándose en el sistema principal destino:

  • IMS Connect V1.1 e IMS Versión 7 (recomendada) o bien
  • IMS Connect V1.1 e IMS Versión 5.1 ó 6.1

  • Los prerrequisitos para utilizar la opción Local con IMS Connector para Java, Versión 4.0, son:
    • IMS Connect V1.1 más el APAR PQ45057 que habilita la opción Local
    • IMS V7.1 Nota: la opción Local solo está soportada en IMS V7.1 o superior
  • Si desea desplegar una aplicación EAB de una versión anterior de VisualAge para Java que utilizara IMS Connector para Java, deberá utilizar los archivos de tiempo de ejecución de la siguiente Versión 4.0 (que se encuentran en IBM Connectors\classes y eab\runtime30):
    • imsconn.jar
    • ccf.jar
    • recjava.jar
    • eablib.jar

B.2.0 Instalación

Esta sección contiene información acerca de la instalación de VisualAge para Java, Versión 4.0. Importante: si va a migrar desde una versión anterior de VisualAge para Java, consulte la sección 3.0, más abajo, antes de instalar VisualAge para Java, Versión 4.0. Si desea información especial acerca de cómo instalar en Windows 2000, consulte la sección 2.5.

Consulte también el archivo README (que encontrará en el directorio raíz del CD del producto) para obtener información acerca de las limitaciones y los problemas que surgieron a última hora.

Importante: debido a una limitación en el soporte del sistema de archivos del CD-ROM (CDFS) en Windows 98, es posible que falle la instalación de determinados archivos de conectores de e-business del CD-ROM y que, en consecuencia, se visualicen uno o varios de los diálogos de error siguientes, dependiendo de los conectores seleccionados:

• Las copias de ENCINA VAJ.RUL DELCon* han fallado
• Las copias de ENCINA VAJ.RUL Deligh* han fallado
• ENCINA VAJ.RUL Drpc*
• ENCINA VAJ.RUL Transaction*
• La copia del archivo *.* de HOD VAJ.RUL ha fallado *.*

Los archivos que no se hayan instalado están almacenados en un archivo zip (econnfix.zip) ubicado en el directorio raíz del CD del producto. Si está intentando instalar VisualAge para Java en Windows 98 y recibe cualesquiera de los mensajes anteriores, debe descomprimir el archivo econnfix.zip en el directorio en el que se instaló el producto (por ejemplo, ejecutando el mandato unzip econnfix.zip -d c:\Archivos de programa\IBM\VisualAge para Java\ donde c:\Archivos de programa\IBM\VisualAge para Java\ es el directorio de instalación del producto). Una vez copiados estos archivos, los conectores funcionarán correctamente.

B.2.1 Instalación de VisualAge para Java, Versión 4.0, Enterprise Edition

Antes de instalar el producto, compruebe lo siguiente:

• La variable CLASSPATH debe tener menos de 418 caracteres. VisualAge para Java inserta aproximadamente 92 caracteres en la CLASSPATH durante la instalación. Estas cifras se basan en el supuesto de que el directorio destino tiene una longitud de 36 caracteres; por ejemplo, Archivos de programa\IBM\VisualAge for Java 
• Si está utilizando el directorio destino por omisión, la variable PATH debe tener menos de 377 caracteres en Windows 98, y menos de 820 caracteres en Windows NT y en Windows 2000.
• Debe tener como mínimo 20 MB libres en la unidad del sistema de Windows, y la variable de entorno TEMP o TMP debe señalar a un directorio temporal válido que tenga libres 6 MB como mínimo.

Si intenta instalar VisualAge para Java en Windows, Millennium Edition, se le pedirá que aumente el espacio del entorno. Antes de instalar, tendrá que seguir los pasos que se indican más abajo; de lo contrario, el sistema de ayuda de VisualAge para Java no funcionaría correctamente. Para aumentar el espacio del entorno, siga estos pasos:

1. Salga de la pantalla de instalación.
2. Abra el Explorador de Windows. Navegue hasta el directorio Windows (por ejemplo, C:\Windows).
3. Pulse Command.com con el botón derecho del ratón y después pulse Propiedades en el menú emergente. Pulse la pestaña Memoria.
4. En el recuadro Entorno inicial, establezca el tamaño de entorno inicial en 4.096 bytes. Pulse Aceptar.
5. Cierre el Explorador de Windows.
6. Rearranque el equipo.
7. Reinicie la instalación de VisualAge para Java.

Debe seguir estas instrucciones, tanto si va a instalar los clientes en equipo de VisualAge para Java como si va a instalar un cliente que tenga un depósito local. Consulte la sección 2.3 para conocer detalles acerca de la instalación de un cliente de equipo o la sección 2.4 para conocer detalles acerca de la instalación de un depósito local.

B.2.1.1 Instalación de VisualAge para Java, Versión 4.0 desde el CD del producto

1. Si va a migrar desde una versión anterior de VisualAge para Java, lea "Migrar desde una versión anterior de VisualAge para Java", en la sección 3.0 de este documento, ANTES de continuar realizando el procedimiento de instalación.
2. Inserte el CD-ROM en la unidad de CD. 
3. Si la ejecución automática está inhabilitada en el sistema, ejecute setup.exe desde el directorio raíz de la unidad de CD.
4. Seleccione Instalar productos. Seleccione Instalar VisualAge para Java para empezar la instalación de VisualAge para Java. Si piensa depurar clases que se hayan desarrollado fuera del IDE de VisualAge para Java, o depurar programas que se ejecuten en una máquina aparte, vaya a la sección B.2.1.1.1, donde hallará información para instalar el depurador distribuido (Distributed Debugger).
5. Siga las instrucciones de la pantalla.
6. Inicie el IDE de VisualAge para Java.

Instalación silenciosa
Para instalar VisualAge para Java, Versión 4.0, de forma silenciosa, invoque este mandato desde el directorio ivj40\setup:

setup /s /v/qn

VisualAge para Java se instalará automáticamente en el directorio por omisión c:\Archivos de programa\IBM\VisualAge for Java.

Para instalar de forma silenciosa en un directorio distinto (por ejemplo, d:\IBMVJava40), invoque el mandato siguiente en el directorio ivj40\setup:

setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"

siendo d:\IBMVJava40 el directorio en el que desea efectuar la instalación.

Nota: si realiza una instalación silenciosa de VisualAge para Java, no puede conectarse a un depósito compartido; cuando se instala de forma silenciosa solo se puede conectar a un depósito local. Si desea instalar de forma silenciosa y aún así trabajar en un entorno en equipo, debe instalar localmente y después conectarse al depósito compartido tras haber instalado el producto e iniciado el IDE. En el archivo team.pdf situado en el directorio pdf hallará instrucciones para instalar localmente al tiempo que se trabaja en un entorno en equipo. El directorio pdf está en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos). Si no bajó el componente que contiene los PDF, no tendrá este directorio.

B.2.1.1.1 Instalación de Distributed Debugger desde el CD del producto
Si piensa depurar clases que se hayan desarrollado fuera del IDE de VisualAge para Java, o depurar programas que se ejecuten en una máquina aparte, debe instalar el depurador distribuido (Distributed Debugger). Distributed Debugger está soportado en estos sistemas operativos: Windows, AIX, OS/2, HP-UX, Solaris, Linux y Linux/390. Las instrucciones de instalación para cada sistema operativo se proporcionan más abajo. Todos los archivos de Distributed Debugger están en el CD de características adicionales.

 Distributed Debugger para Windows

1. El depurador distribuido (Distributed Debugger) se puede instalar desde el CD de características adicionales. En la pantalla de instalación de características adicionales, seleccione Instalar productos y después Instalar Distributed Debugger.

1. Cree un directorio de trabajo, por ejemplo /tmp/idebug.
2. Copie idebug.tar.Z desde el soporte de instalación en el directorio de trabajo.
3. Vaya al directorio de trabajo.
4. Descomprima el archivo idebug.tar.Z con el mandato: uncompress idebug.tar.Z
5. Extraiga las imágenes de instalación de idebug.tar con el mandato: tar -xvf idebug.tar
6. Como root, emita este mandato: installp -ac -X -V2 -g -N -d idebug
7. También puede emplear SMIT con el mandato: smitty install_latest

Distributed Debugger para OS/2

Distributed Debugger para HP-UX

Prerrequisito: 
Se requiere la versión 1.3 de Java para la instalación y la depuración Java.

1. Cree un directorio de trabajo, por ejemplo, /tmp/idebug
2. Copie el archivo install.class en el directorio de trabajo.
3. En un indicador de mandatos, abra el directorio de trabajo. Si el directorio de trabajo es /tmp/idebug, tendría que utilizar el mandato: cd /tmp/idebug para abrirlo.
4. Como root, teclee el mandato: java install.class

1. Cree un directorio de trabajo, por ejemplo, /tmp/idebug
2. Copie dbgsetup e idebug.pkg en el directorio de trabajo.
3. En un indicador de mandatos, abra el directorio de trabajo. Si el directorio de trabajo es /tmp/idebug, tendría que emitir el mandato cd /tmp/idebug para abrirlo.
4. Convierta "dbgsetup" en ejecutable emitiendo este mandato: chmod +x dbgsetup
5. Como root, entre este mandato para instalar el depurador: ./dbgsetup idebug.pkg

Distributed Debugger para Linux 

Distributed Debugger para Linux/390 

Como root, entre este mandato para instalar el depurador: rpm -Uvh DERJPICL-9-1.s390.rpm

Distributed Debugger para OS/390

1. Instale Distributed Debugger para Windows.
2. Siga las instrucciones del archivo README_install.txt, que está en el subdirectorio Debugger\OS390 del CD del producto.

B.2.1.1.2 Instalación de la versión beta de los componentes de J2EE 
Este release de VisualAge para Java incluye una versión beta de varios componentes de la plataforma Java 2, Enterprise Edition (J2EE (TM)). Sun Microsystems Inc. aún no ha entregado de manera oficial estos componentes de J2EE. Concretamente, este release de VisualAge para Java incluye una versión beta de estos componentes de J2EE:

• J2EE Connector para CICS
• J2EE Connector para SAP R/3 
• J2EE Connector para PeopleSoft 
• J2EE Connector para J.D. Edwards OneWorld.
• J2EE Connector para Oracle Applications/Financials
• Herramientas para importar estructuras de datos que están en servidores de aplicaciones JD Edwards, PeopleSoft y Oracle
• Herramientas para generar registros en conformidad con J2EE
• Herramientas para crear y editar mandatos en conformidad con J2EE
• Herramientas para crear y editar beans de sesión EAB en conformidad con J2EE
• Herramientas para migrar aplicaciones EAB existentes a la arquitectura basada en J2EE. Estas herramientas migran registros, objetos Mandatos y objetos Navegadores. 

Los componentes beta están en el subdirectorio extras\BetaJ2EEConnectors del CD de características adicionales. Si desea usar estos componentes beta, las instrucciones para instalarlos están en el archivo README que se encuentra en el subdirectorio BetaJ2EEConnectors.

B.2.1.2. Instalación desde la imagen electrónica de VisualAge para Java, Versión 4.0
Para reducir el tiempo de bajada, la imagen electrónica de VisualAge para Java, Enterprise Edition para Windows, Versión 4.0 está dividida en componentes.

• IDE (entorno de desarrollo integrado) - comprende catorce componentes de archivador, de los cuales solo dos son obligatorios. Esto permite bajar solo las características que se desean.
• Distributed Debugger - proporciona un componente que se puede bajar por separado para cada sistema operativo que se va a utilizar como destino de depuración.
• EMSRV - un solo componente de archivador contiene el código de servidor de equipo para todas las plataformas de servidor soportadas, que se enumeran en la Parte C, sección 1.1 de este documento.
• IBM Developer Kit 1.2.2 - contiene IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9, para la plataforma Windows. 

B.2.1.2.1 IDE
Existen catorce componentes que se pueden bajar para el entorno de desarrollo integrado. Los catorce componentes son archivadores autoextraíbles. Es preciso instalar los dos primeros; los demás son opcionales. Consulte la lista siguiente para obtener información detallada acerca de lo que contiene cada archivador.

Cuando haya bajado los dos primeros componentes y los archivos opcionales que desea, ejecute cada archivador autoextraíble y asegúrese de que cada uno de ellos se extrae en el mismo directorio temporal. Cuando se hayan extraído todos los componentes, vaya al directorio temporal y ejecute setup.exe. Siga las instrucciones de la pantalla e inicie el IDE.

Si piensa trabajar en un idioma que no sea el inglés, debe bajar el componente correcto y ejecutar el archivador autoextraíble correspondiente a su idioma antes de ejecutar setup.exe. No puede cambiar ni añadir un idioma después de instalar VisualAge para Java.

Si está trabajando con una imagen electrónica de VisualAge para Java, no puede utilizar el diálogo Agregar o quitar programa (Inicio > Valores >Panel de control > Agregar o quitar programas) para instalar componentes adicionales de VisualAge para Java después de la instalación adicional. Si lo intenta, obtendrá un mensaje de error y no podrá instalar componentes adicionales. Debe ejecutar setup.exe desde el directorio en el que se extrajeron los componentes bajados para añadir componentes adicionales a VisualAge para Java.

A continuación se proporciona una descripción de cada componente:

• VisualAge para Java - IDE 1 de 14 (solo en inglés) - OBLIGATORIO. Incluye los siguientes elementos fundamentales: el entorno de desarrollo integrado, los beans de acceso a datos (DAB) y el editor de composición visual.
• VisualAge para Java - IDE 2 de 14 (solo en inglés) - OBLIGATORIO. Incluye los siguientes elementos fundamentales: el entorno de desarrollo integrado, la API de herramientas, el SmartGuide Servlets y XML Parser para Java.
• VisualAge para Java - IDE 3 de 14 (solo en inglés) - OPCIONAL. Soporte ampliado de bases de datos (Stored Procedure Builder y SQLJ), Entorno de desarrollo EJB/JSP, Persistence Builder, Control de versiones externo, ET/400, ET/390, Tivoli Connection. NOTA: esto es obligatorio si va a instalar Transaction Access Builder.
• VisualAge para Java - IDE 4 de 14 (solo en inglés) - OPCIONAL. Access Builders para aplicaciones (Domino, SAP R/3, C++), Access Builder para transacciones (requiere los componentes 3, 5 y 6), XMI Toolkit, XML Generator, Domino Agent Runner, Entorno de desarrollo IDL.
• VisualAge para Java - IDE 5 de 14 - OPCIONAL. e-connectors. Si instala este componente, también debe instalar el componente 6. NOTA: esto es obligatorio si va a instalar Transaction Access Builder.
• VisualAge para Java - IDE 6 de 14 - OPCIONAL. e-connectors. Si instala este componente, también debe instalar el componente 5. NOTA: esto es obligatorio si va a instalar Transaction Access Builder.
• VisualAge para Java - IDE 7 de 14 - OPCIONAL. Entornos de despliegue, avances tecnológicos, y Merant(TM) DataDirect SequeLink Java Edition, Versión 5.1, para Oracle y Microsoft SQLServer.
• VisualAge para Java - IDE 8 de 14 - OPCIONAL. Paquete de idiomas portugués (BR) y español. Contiene el texto en portugués (BR) y en español para el IDE y todos sus componentes.
• VisualAge para Java - IDE 9 de 14 - OPCIONAL. Paquete de idiomas francés e italiano. Contiene el texto en francés y en italiano para el IDE y todos sus componentes.
• VisualAge para Java - IDE 10 de 14 - OPCIONAL. Paquete de idioma japonés. Contiene el texto en japonés para el IDE y todos sus componentes.
• VisualAge para Java - IDE 11 de 14 - OPCIONAL. Paquete de idiomas alemán y coreano. Contiene el texto en alemán y en coreano para el IDE y todos sus componentes.
• VisualAge para Java - IDE 12 de 14 - OPCIONAL. Paquete de idioma chino simplificado y tradicional. Contiene el texto en chino simplificado y en chino tradicional para el IDE y todos sus componentes.
• VisualAge para Java - IDE 13 de 14 - OPCIONAL. Componentes de la plataforma Java 2, Enterprise Edition (J2EE) para Transaction Access Builder. Contiene IBM Connectors and Tools para J2EE(TM) - Beta (requiere la parte 4).
• VisualAge para Java - IDE 14 de 14 - OPCIONAL. Documentación en línea con formato PDF.

B.2.1.2.2. Distributed Debugger (depurador distribuido)
Existe un componente que se baja por separado para cada sistema operativo destino soportado por el depurador distribuido (Distributed Debugger). Si piensa depurar clases que se hayan desarrollado fuera del IDE de VisualAge para Java, o depurar programas que se ejecuten en una máquina aparte, debe bajar e instalar el depurador distribuido (Distributed Debugger). Las instrucciones de instalación para cada sistema operativo se proporcionan más abajo. Estas instrucciones, además de la información sobre el acuerdo de licencia, están en el archivo readme-1st.txt que se incluye junto con cada componente.

VisualAge para Java - Distributed Debugger para Windows contiene la interfaz de usuario y el motor de depuración para Windows. Este componente es un archivador autoextraíble. Para instalarlo, siga estos pasos:

1. Si ha bajado y extraído VisualAge para Java, ejecute setup.exe y seleccione Instalar productos. Después seleccione Instalar Distributed Debugger. 
2. Si desea instalar Distributed Debugger sin VisualAge para Java, abra este directorio desde un indicador de mandatos: DirectorioDepurador\windows (siendo DirectorioDepurador el directorio en el que ha puesto el depurador distribuido (Distributed Debugger) extraído) y ejecute este mandato: setup.bat

1. Cree un directorio de trabajo, por ejemplo /tmp/idebug.
2. Copie idebug.tar.Z desde el soporte de instalación en el directorio de trabajo.
3. Vaya al directorio de trabajo.
4. Descomprima el archivo idebug.tar.Z con el mandato: uncompress idebug.tar.Z
5. Extraiga las imágenes de instalación de idebug.tar con el mandato: tar -xvf idebug.tar
6. Como root, emita este mandato: installp -ac -X -V2 -g -N -d idebug
7. También puede emplear SMIT con el mandato: smitty install_latest

VisualAge para Java - Distributed Debugger para OS/2 contiene el motor de depuración de OS/2. Para instalarlo, siga las instrucciones que figuran en el archivo README_install.txt (incluido junto con el componente Distributed Debugger para OS/2).

VisualAge para Java - Distributed Debugger para HP-UX contiene el motor de depuración para HP-UX.

Prerrequisito: 
Se requiere la versión 1.3 de Java para la instalación y la depuración Java.

Para instalarlo, desempaquete el archivo y siga estas instrucciones:

1. Cree un directorio de trabajo, por ejemplo, /tmp/idebug
2. Copie el archivo install.class en el directorio de trabajo.
3. En un indicador de mandatos, abra el directorio de trabajo. Si el directorio de trabajo es /tmp/idebug, tendría que utilizar el mandato: cd /tmp/idebug para abrirlo.
4. Como root, teclee el mandato: java install.class

1. Convierta "dbgsetup" en ejecutable emitiendo este mandato: chmod +x dbgsetup
2. Como root, entre este mandato para instalar el depurador: ./dbgsetup idebug.pkg

VisualAge para Java - Distributed Debugger para Linux contiene el motor de depuración para Linux. Para instalarlo, desempaquete el archivo e instale el depurador siguiendo estas instrucciones:

VisualAge para Java - Distributed Debugger para Linux/390 contiene el motor de depuración para Linux/390. Para instalarlo, desempaquete el archivo e instale el depurador siguiendo estas instrucciones:

Como root, entre este mandato: rpm -Uvh DERJPICL-9-1.s390.rpm

Distributed Debugger para OS/390

1. Instale Distributed Debugger para Windows.
2. Siga las instrucciones del archivo README_install.txt, que está en el directorio de instalación base en Windows.

B.2.1.2.3 EMSRV (servidor de equipo)
VisualAge para Java - EMSRV 7.1 contiene el programa servidor de depósito para el entorno de desarrollo en equipo. Un único componente de archivador contiene el código de servidor para Windows, AIX, OS/2, NetWare, HP-UX, Linux y Solaris, en formato de archivo ZIP. Para instalarlo, descomprima este componente y siga las instrucciones de instmigr.htm

B.2.1.2.4 IBM Developer Kit 1.2.2 
VisualAge para Java - IBM Developer Kit 1.2.2 contiene IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9, para la plataforma Windows. Es un archivador de autoextracción. Para instalarlo, ejecute este archivo, que lanzará automáticamente el programa de instalación después de que se haya extraído del archivador y siga las instrucciones. 

B.2.2 Instalación posterior de componentes adicionales

Para instalar componentes adicionales de VisualAge para Java en cualquier momento posterior a la instalación inicial, inserte el CD-ROM en la unidad de CD, seleccione instalar VisualAge para Java, y pulse Modificar en la pantalla Mantenimiento de programa. Si la ejecución automática está inhabilitada en el sistema, deberá ejecutar setup.exe desde el directorio raíz de la unidad de CD. Si dispone de una versión electrónica de VisualAge para Java, también tendrá que ejecutar setup.exe de forma manual y, después, seguir los mismos pasos.

Todos los componentes aparecerán listados en la ventana Editar características, con una indicación de su estado actual de instalación. Una 'X' de color rojo indica que el componente no está instalado en ese momento. Puede elegir instalar esos componentes. No seleccione ningún componente que no esté marcado con una 'X' de color rojo, pues ya están instalados. 

No puede instalar una segunda instancia de VisualAge para Java, Versión 4.0. No puede cambiar el idioma de instalación sin desinstalar primero el producto.

B.2.3 Instalación de los clientes en equipo de VisualAge para Java

Para que cada miembro del equipo de desarrollo pueda seguir estos pasos, el administrador de EMSRV debe haber configurado e iniciado el servidor, probado la conexión de cliente y añadido los desarrolladores del equipo a la lista de usuarios del depósito. En la Parte C de esta guía encontrará información sobre cómo realizar estas tareas. La Parte C también facilita información sobre cómo migrar un depósito del equipo.

En las instrucciones que siguen, se presupone que el depósito compartido instalado en el servidor se llama ivj.dat. EMSRV, Versión 7.1, debe estar instalado en el servidor. Tal vez reciba un mensaje de error si intenta conectarse a una versión anterior de EMSRV.

1. Antes de empezar a instalar VisualAge para Java, Versión 4.0, pida al administrador que le facilite esta información:
   • El nombre de sistema principal o la dirección IP del servidor. 
   • El nombre de archivo del depósito compartido. Por omisión, el nombre de archivo es ivj.dat; no necesitará especificar información de vía de acceso si el administrador especifica la ubicación del depósito como directorio de trabajo de EMSRV al iniciar el servidor.
   • Su propio nombre de usuario del depósito. Deberá seleccionar este nombre como propietario del área de trabajo al iniciar el cliente VisualAge para Java.
   • Si la protección por contraseña está habilitada, pregunte también cuál es la contraseña correspondiente al propietario del área de trabajo. (Por omisión, la protección por contraseña no está habilitada.)
2. Inicie la instalación de VisualAge para Java, Versión 4.0. Los detalles de la instalación están en la sección 2.0. Si está migrando desde una versión anterior de VisualAge para Java, consulte la sección 3.0 para conocer detalles acerca del proceso de migración.
3. Cuando el programa de instalación se lo pida, especifique que desea utilizar un depósito que resida en un servidor. Si, en vez de trabajar siempre como cliente conectado a un depósito compartido, prefiere tener un depósito local en su propia estación de trabajo para trabajar en modalidad autónoma, vea las instrucciones alternativas que figuran en la sección 2.4, más abajo. Proporcione el nombre de sistema principal TCP/IP (o la dirección IP) del servidor y el nombre del depósito, tal como se los ha indicado el administrador. Si el administrador no ha especificado un directorio de trabajo al iniciar el programa EMSRV, en ese caso tendrá que calificar totalmente el nombre del depósito con la información de vía de acceso del servidor para ese archivo. El programa de instalación insertará automáticamente la dirección de servidor y la información de depósito en el archivo ide.ini del cliente.
4. Se le indicará que seleccione un nombre de propietario de área de trabajo en la lista de usuarios del depósito configurada por el administrador. Seleccione su nombre de usuario. Si la protección por contraseña está habilitada, deberá proporcionar la contraseña del usuario.
   
   Verá una barra de progreso que indica que el área de trabajo se está conectando al depósito. Si, en lugar de una lista de usuarios, aparece un mensaje que dice que se ha producido un error irrecuperable, puede haberse dado una de estas situaciones:
   1. El servidor no está activo.
   2. Ha especificado un nombre de servidor incorrecto al instalar VisualAge para Java en la estación de trabajo.
   3. Ha especificado un nombre de depósito incorrecto durante la instalación.
   
   Puede corregir la información del servidor o del depósito editando el archivo ide.ini en el cliente de equipo.

B.2.4 Instalación de un cliente que tiene un depósito autónomo

Tal vez le convenga tener en su estación de trabajo su propio depósito de código fuente de VisualAge para Java con el fin de utilizarlo cuando no esté conectado al depósito compartido. En ese caso, cuando vaya a instalar VisualAge para Java, Versión 4.0, en su estación de trabajo, especifique que su depósito estará en la máquina local, en lugar de en el servidor. El programa de instalación creará su depósito automáticamente.

Cuando desee utilizar el depósito compartido en el servidor de equipo, consulte la ayuda en línea o el archivo team.pdf. El archivo team.pdf está en el directorio pdf. El directorio pdf está situado en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos). Si no bajó el componente que contiene los PDF, no tendrá este directorio.

B.2.5 Consideraciones sobre la instalación y uso en Windows 2000  

Este release de VisualAge para Java sigue proporcionando soporte de tolerancia (tal como lo define Microsoft) para Windows 2000.

El directorio de instalación por omisión es <Archivos de programa>\IBM\VisualAge for Java. Por omisión, para Windows 2000, solo los administradores y los usuarios estándar pueden realizar la instalación en <Archivos de programa>. Los usuarios normales (restringidos) no pueden escribir en esa ubicación.

Debido al diseño actual de VisualAge para Java, si se instala el producto en esta ubicación y lo ha de utilizar un usuario normal, tendrá que cambiar los valores de seguridad del directorio de IBM o del directorio de IBM\VisualAge for Java bajo <Archivos de programa> para autorizar a los usuarios normales (restringidos) el acceso de escritura. Si no se hiciera así, podrían surgir anomalías cuando se intentara iniciar el IDE o mientras se utilizasen algunas herramientas de VisualAge para Java dentro del IDE.

Ahora, la lista de servidores del componente AS/400 Enterprise Toolkit se almacena como "<Archivos de programa>\IBM\shared files\fvdctcp.txt". Nuevamente, esta ubicación está protegida por omisión y los usuarios normales no pueden escribir en ella. Si un usuario que no posea autorización suficiente intenta crear o actualizar la lista de servidores mediante alguno de los botones de lista Añadir/Modificar servidores de los SmartGuide del AS/400, la creación o la actualización de archivo fallaría con un error de entrada/salida en el correspondiente código Java, que podría o no aparecer en las anotaciones o en la consola.

El administrador del sistema debe determinar si conviene o no otorgar acceso de escritura a los usuarios normales de esa ubicación, o si es preferible mantenerla protegida y cargar el archivo manualmente, impidiendo así que los usuarios sin autorización puedan actualizarlo.

B.2.6 Instalación de IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9 

Si ha instalado VisualAge para Java desde el CD del producto, debe ejecutar install.exe desde el directorio de IBM Developer Kit para instalar IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9. Este directorio se encuentra en el CD de características adicionales. Si tiene una versión electrónica de VisualAge para Java, este directorio está en su directorio temporal (aquel en el que ha puesto los componentes extraídos); sin embargo, no necesita ejecutar install.exe, porque el programa de instalación se lanza automáticamente después de que se ha desempaquetado del archivador IBM Developer Kit bajado.

Para obtener información detallada acerca de IBM Developer Kit, consulte el archivo README del directorio IBM Developer Kit.

B.3.0 Migración desde una versión anterior de VisualAge para Java  

En la Parte D y en la Parte E hallará información, tanto general como específica de cada componente, que conviene leer antes de empezar el proceso de migración.

La actualización de VisualAge para Java, Versión 4.0, realizará actualizaciones del depósito durante la instalación para que las bibliotecas de clase del sistema del depósito tengan el nivel de release correcto. Para ello es necesario que sea posible realizar operaciones de lectura y grabación en el depósito durante esta actualización. No se modificará código de usuario durante esta operación.

Si está migrando desde una versión anterior de VisualAge para Java, Enterprise Edition, y trabaja en un entorno autónomo (en lugar de en un entorno en equipo), y además va a continuar trabajando en un entorno autónomo, siga las instrucciones de migración para Professional Edition en la Parte A de este documento.

Nota: al migrar VisualAge para Java desde la Versión 3.5 o la Versión 3.5.3 a la Versión 4.0, el proceso de instalación parece que se cuelga. Esto se produce porque la función "DoCosting" (que compara las versiones 3.5 de los archivos con las versiones 4.0 de los archivos) puede necesitar hasta tres minutos para ejecutarse, dando la impresión de que el proceso de instalación se ha colgado.

Si migra desde un entorno en equipo o a un entorno en equipo, tenga en cuenta las siguientes cuestiones antes de iniciar el proceso de migración.

• ¿Va a continuar utilizando los depósitos existentes? En caso afirmativo, puede hacer dos cosas.
  • Puede migrar el contenido del depósito de la Versión 4.0 al depósito existente. Esto permitirá a los usuarios de entornos mixtos de desarrollo acceder al mismo depósito simultáneamente, aunque las diferencias de nivel JDK pueden impedir tratar todo el código como código común. Para obtener más información acerca de cómo realizar esta tarea, consulte la sección 3.1 de la Parte B.
  • Puede continuar utilizando el depósito existente y también instalar el depósito de la Versión 4.0 para utilizarlo por separado. En este caso, tal vez haya tratado con cuestiones como el mantenimiento dual y la planificación de una eventual migración por fases de los usuarios al depósito de la Versión 4.0.
• ¿Desde qué versión de VisualAge para Java está migrando? Si decide actualizar el depósito basado en JDK 1.1.x y migra sus aplicaciones para que funcionen adecuadamente con la plataforma Java 2, v1.2.2, las aplicaciones tal vez dejen de funcionar en la v1.1.x de la plataforma Java. Por ejemplo, las clases Swing están en un paquete diferente en J2SDK v1.2.2 que en JDK v1.1.x, y habrá que actualizar las referencias a las clases Swing si se migran aplicaciones desde 1.1.x a 1.2.2. Si tiene muchas aplicaciones dependientes de JDK, tal vez desee guardarlas en depósitos independientes. 
• ¿Cuántos depósitos intervienen? En general, hay que tener en cuenta todos los depósitos compartidos y los depósitos locales de Early Adopters Environment de la Versión 3.5 ó 3.5.3. Si tiene N usuarios de Early Adopters Environment, Versión 3.5 ó 3.5.3 (todos con depósitos locales) y R depósitos compartidos, habrá que actualizar N + R depósitos.

Los pasos que debe realizar para migrar dependerán de su situación y de las respuestas a las preguntas anteriores.

El siguiente escenario de migración es uno de los más complicados. En él hay más de un depósito compartido y N desarrolladores con depósitos locales de la Version 3.5 ó 3.5.3. Se supone que desea utilizar el nuevo depósito de la Versión 4.0, pero también quiere seguir utilizando todos los datos de sus antiguos depósitos compartidos. 

Nota: este escenario explica cómo manejar los depósitos locales de la Versión 3.5 ó 3.5.3 (Java 2), no los depósitos locales de JDK 1.1.x. Si desea importar información del depósito local de JDK 1.1.x al depósito de la Versión 4.0, siga las instrucciones de la sección 3.2 de la Parte A. 

1. Actualice EMSRV a la Versión 7.1. El administrador del equipo debe instalar EMSRV, Versión 7.1. Consulte la sección 2 de la Parte C, donde hallará instrucciones para realizar esta tarea.
2. Cree copias de seguridad de sus datos de usuario.
   1. Cree una versión de los proyectos y los paquetes. Al depósito de VisualAge para Java, Versión 4.0, solo se pueden importar los proyectos y los paquetes con versión. En la ayuda en línea de VisualAge para Java hallará instrucciones para crear versiones.
   2. Guarde el depósito en una nueva ubicación fuera del árbol de directorios de VisualAge para Java. El nombre de archivo y la vía de acceso del depósito son x:\IBMVJava\ide\repository\ivj.dat, donde x:\IBMVJava es el directorio de instalación de VisualAge para Java. 
      Nota: si desea migrar desde la Versión 3.5 o la Versión 3.5.3, el depósito también incluye copias con versión de los archivos de recursos de proyecto, que se encuentran en el siguiente directorio: x:\IBMVJava\ide\repository\ivj.dat.pr. Debe guardar una copia del directorio ivj.dat.pr fuera del árbol de directorios de VisualAge para Java.
3. El administrador del equipo realiza una instalación completa de VisualAge para Java, Versión 4.0, incluido un depósito local. Entonces, el administrador exporta todo el contenido del depósito local a todos los depósitos compartidos. Consulte la Parte B, sección 3.1 para obtener información detallada acerca de cómo realizar esta tarea.
4. Todos los usuarios de la Versión 3.5 ó 3.5.3 instalan la Versión 4.0 localmente, lo que actualizará automáticamente los N depósitos locales.

El proceso de migración ahora está completo, y los usuarios pueden conmutar entre un depósito local o un depósito compartido a su conveniencia. Nota: si migra desde un entorno en equipo a un entorno local, es preciso que exporte manualmente sus proyectos desde el antiguo depósito compartido al nuevo depósito local. Asimismo, si tenía un depósito local tendrá que importar todos los proyectos que desea utilizar desde el antiguo depósito local al nuevo depósito local de la Versión 4.0.

B.3.1 Migración de un depósito compartido desde una versión anterior de VisualAge para Java

Para poder realizar los pasos siguientes, primero debe actualizar a EMSRV 7.1. Las instrucciones para realizar esta tarea están en la sección C.3.1  

Puede actualizar su depósito compartido de la Versión 2.0 ó 3.0x (basado en JDK 1.1) o 3.0x, Early Adopters o 3.5 (basado en JDK 1.2) para que funcione con VisualAge para Java, Versión 4.0. En los siguientes pasos, el administrador del equipo realiza una instalación completa de VisualAge para Java, Versión 4.0, utilizando un depósito local. Entonces, el administrador exporta todo el contenido del depósito local a todos los depósitos compartidos.

Para actualizar un depósito existente del servidor de tal manera que funcione con VisualAge para Java, Versión 4.0, siga estos pasos:

1. Instale VisualAge para Java, Versión 4.0, como instalación completa con un depósito local. Consulte la sección 2.0 de la Parte B para obtener instrucciones acerca de cómo realizar esta tarea.
2. Inicie el IDE de la Versión 4.0. Se conectará con el depósito local.
3. En el entorno de trabajo, seleccione Archivo > Exportar, y luego seleccione el botón de selección Depósito y pulse Siguiente. Seleccione Depósito compartido con servidor EMSRV. Escriba la dirección IP o el nombre de sistema principal del servidor en el campo Depósito compartido con dirección de servidor EMSRV.
4. Pulse Examinar para localizar el depósito compartido o escriba el nombre de archivo y la vía de acceso del depósito compartido en el campo Nombre de depósito.
5. Seleccione Proyectos. Pulse Detalles para ver una lista de los proyectos con versión que se pueden exportar desde el depósito origen. 
6. Seleccione todas las ediciones de proyecto y expórtelas.
7. Pulse Terminar.

Todos los proyectos se copian en el depósito compartido. También se exportan sus archivos de recursos de proyecto. Si el depósito al que está exportando se llama sample.dat, sus recursos de proyecto se exportan a una carpeta llamada sample.dat.pr.

B.4.0 Limitaciones y problemas conocidos

Consulte también el archivo README (que encontrará en el directorio README del CD) para obtener información acerca de las limitaciones y los problemas conocidos que surgieron a última hora. 

B.4.1 Limitaciones y problemas conocidos de la instalación  

A continuación figura una lista de cuestiones que deberá tener en cuenta al instalar VisualAge para Java.

B.4.1.1 Limitaciones de disco

• No instale en una unidad local o de red HPFS, ya que Windows 98, Windows 2000 y Windows NT 4.0 tienen dificultades para manejar los nombres largos de archivo en HPFS.
• No realice la instalación en una unidad de Novell NetWare. La instalación fallaría en una unidad de Novell NetWare.

B.4.1.2 Autorización de usuario

• Para instalar NetQuestion Search Server, debe tener derechos de acceso para escribir en el directorio raíz "\" de la unidad en la que está instalado VisualAge para Java.
• Al instalar el producto en Windows 2000, tal vez reciba un mensaje de aviso si no es usted administrador. El mensaje indica que algunos programas pueden no funcionar como es debido si no los instala un administrador. Debe iniciar la sesión como Administrador antes de empezar la instalación de VisualAge para Java.
• Los usuarios restringidos, cuando intentan instalar VisualAge para Java, Versión 4.0, en Windows 2000, pueden recibir incorrectamente un "Error de inicialización de configuración" con el mensaje "El programa de instalación ha detectado que se está usando unInstallShield. Cierre unInstallShield y reinicie la instalación. Error 432". Antes de repetir el intento de instalar el producto, verifique si tiene derechos de acceso de administrador o de usuario estándar.
• Si no tiene derechos de acceso de administrador mientras instala en Windows NT, la función de búsqueda de la ayuda en línea no funcionará.

B.4.1.3 Consideraciones sobre TCP/IP

• El aviso "Configurado automáticamente" del programa de instalación indica que las excepciones de proxy están configuradas automáticamente para el navegador. Pregunte al administrador del sistema si 127.0.0.1 se maneja como dirección local.
• Es preciso que instale y configure TCP/IP para que pueda instalar correctamente el producto IBM VisualAge para Java. En Windows 98 y Windows 2000, debe seguir estos pasos para habilitar TCP/IP:
  1. Para una configuración de adaptador de LAN:
     • Debe tener habilitado el DNS con un nombre válido de sistema principal y de dominio.
     • El DNS de LAN ha de resolver localhost en 127.0.0.1.
     • No se puede trabajar en modalidad de desconexión con una configuración de adaptador de LAN.
  2. Para una configuración de adaptador de acceso telefónico:
     • Debe tener inhabilitado el DNS.
     • La dirección TCP/IP debe obtenerse de forma automática.

  Estas opciones de configuración serán válidas para todos los adaptadores TCP/IP, aunque solo se hayan cambiado para este. No podrá utilizar la opción de LAN y de acceso telefónico sin efectuar una reconfiguración.

  Las propiedades TCP/IP de acceso telefónico a redes del proveedor de servicios de Internet (ISP) deben estar configuradas de acuerdo con la documentación del ISP. Las propiedades TCP/IP de acceso telefónico a redes alterarán temporalmente las propiedades TCP/IP del adaptador de acceso telefónico configuradas por medio del icono Red situado en el Panel de control de Windows 98 o Windows 2000. Esta alteración temporal solo tendrá lugar si las propiedades TCP/IP del adaptador de acceso telefónico están configuradas según se ha indicado antes. No debe habilitar el DNS en las propiedades TCP/IP del adaptador de acceso telefónico ni establecer una dirección IP en ellas, ya que, si lo hace, se producirían interferencias con la configuración de acceso telefónico a redes del ISP.

  Para Windows NT 4.0, puede utilizar cualquiera de las configuraciones TCP/IP descritas más arriba. Si la máquina trabaja en modalidad autónoma, también se puede habilitar el adaptador Microsoft Loopback sin los otros dos adaptadores.

B.4.1.4 Extensión de shell (Windows NT)

Si obtiene un mensaje que indica que el programa de instalación ha detectado una extensión de shell para Windows NT, la instalación no podrá continuar. En tal caso, deberá seguir estos pasos:

1. Asegúrese de que tiene un disco para recuperación de emergencia. Las instrucciones para crearlo se encuentran en la documentación de ayuda de Windows.
2. Teclee regedit.exe en un indicador de mandatos.
3. En el editor de registro, expanda la clave
   \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
4. Seleccione el nombre de shell en las parejas nombre/datos de la clave anterior. Importante: tome nota de los datos registrados para este nombre, pues los va a necesitar después de instalar IBM VisualAge para Java.
5. Seleccione Edición > Modificar en la barra de menús para la pareja nombre/datos de shell.
6. Establezca el valor del nombre de shell en Explorer.exe. Pulse Aceptar.
7. Seleccione Registro > Salir en la barra de menús.
8. Reinicie el sistema y complete la instalación de IBM VisualAge para Java.
9. Una vez completada la instalación, restaure la entrada de registro anterior de esta manera:
   a. Teclee regedit.exe en un indicador de mandatos.
   b. En el editor de registro, expanda la clave \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
   c. Seleccione el nombre de shell en las parejas nombre/datos de la clave anterior.
   d. Seleccione Edición > Modificar en la barra de menús para la pareja nombre/datos de shell.
   e. Restaure el valor del nombre de shell, dándole el valor que anotó en el paso 4. Pulse Aceptar.
   f. Seleccione Registro > Salir en la barra de menús.

B.4.1.5 Recuperación del sistema tras una instalación fallida

Si falla la instalación, debe eliminar todos los archivos de la Versión 4.0 que se hayan instalado. Si está vacío el directorio en el que pensaba instalar VisualAge para Java, es que el proceso de instalación se ha retrotraído y ha eliminado los archivos que ya se habían instalado. Si lo desea, puede suprimir el directorio vacío, pero no es necesario que lo haga. Sin embargo, si hay archivos en el directorio, deberá iniciar otra vez el proceso de instalación. Este se abrirá en la modalidad de mantenimiento y usted deberá seleccionar que se elimine la instalación parcial de la Versión 4.0 antes de repetir el intento de instalar el producto.

También tendrá que suprimir la entrada de registro:

\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows

siguiendo para ello estas instrucciones:

1. Asegúrese de que tiene un disco para recuperación de emergencia. Las instrucciones para crearlo se encuentran en la documentación de ayuda de Windows.
2. Teclee regedit.exe en un indicador de mandatos.
3. En el editor de registro, expanda y seleccione la clave
   \\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows\4.0
4. Seleccione Edición > Eliminar en la barra de menús para esta clave.
5. Seleccione Sí cuando se le pida que confirme la supresión de la clave.
6. Seleccione Registro > Salir en la barra de menús.

Si antes de que fallara la instalación ya se habían instalado archivos de NetQuestion, también debe suprimirlos.

1. Abra un nuevo indicador de mandatos. Vea si se había instalado algún archivo de NetQuestion; para ello, teclee lo siguiente en el indicador de mandatos que acaba de abrir: set imninstsrv. Este mandato le proporcionará la ubicación en la que se ha instalado NetQuestion en su máquina. Por ejemplo:

   IMNINSTSRV=C:\imnnq_nt

   La ubicación del directorio de NetQuestion puede aparecer de manera distinta en función de en qué unidad haya instalado VisualAge para Java y de qué sistema operativo esté utilizando. Si la variable está establecida (es decir, si obtiene una ubicación que indica dónde está instalado NetQuestion), siga en el paso 2. 

   Si recibe un mensaje de error como este "Variable de entorno imninstsrv no definida", ello indica que no se instaló ningún archivo de NetQuestion o que la instalación de NetQuestion no se completó satisfactoriamente. En tal caso, seleccione Inicio > Buscar > Archivos o carpetas, y busque el siguiente archivo en el sistema: vahelp.cfg. Si encuentra este archivo en algún directorio cuyo nombre empiece por "imnnq" (por ejemplo, imnnq_NT o imnnq_98), suprímalo. No tendrá que realizar los pasos 2 y 3. 

2. Vaya al directorio de NetQuestion (esta es la información que aparece a continuación de IMNINSTSRV=)
3. Teclee vahcfg remove /p vj32

Así se eliminarán los archivos de NetQuestion que VisualAge para Java haya instalado. Ello no afectará a los archivos de NetQuestion instalados por otros productos (por ejemplo, DB2).

Cree una copia de seguridad del depósito y de los archivos de recursos si aún no lo ha hecho. Consulte la Parte B, sección 3.0 para obtener información acerca de cómo realizar esta tarea. 

Después de realizar todos estos pasos, rearranque y reinstale el producto. Si la ayuda falla después de que haya reinstalado VisualAge para Java, consulte la Guía para la resolución de problemas, donde hallará más información sobre cómo solucionar las anomalías de la ayuda. La Guía para la resolución de problemas (trshoot.htm) está en el CD del producto VisualAge para Java, Professional Edition, y en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Tras instalar VisualAge para Java, la guía también está en X:\IBMVJava, siendo X:\IBMVJava el directorio de instalación de VisualAge para Java.

B.4.1.6 CICS Transaction Gateway

Si instala en la máquina una versión de CICS Transaction Gateway cuando instala VisualAge para Java, VisualAge utilizará esta versión en lugar de instalar la suya propia.

B.4.1.7 Errores del instalador de Windows

La lista siguiente es una relación de los errores del instalador de Windows que deben tenerse presentes durante la instalación.

Si recibe el mensaje de error 1603 al instalar VisualAge para Java, es que el instalador de Windows no ha podido hacer el proceso de inicialización y la instalación no puede continuar. 

Ciertos productos (como VisualCafe de Symantec) instalan automáticamente un archivo llamado sfc.dll cuando se instalan en una plataforma Windows. Sin embargo, este archivo se emplea únicamente en Windows 2000; el instalador de Windows lo invoca para el proceso de seguridad. 

Si hay un archivo que tenga ese nombre en la variable PATH de Windows NT 4.0, el instalador de Windows intentará cargarlo, aunque sfc.dll solo sea aplicable a Windows 2000. Entonces el instalador de Windows fallará. 

Para evitar que se produzca este problema, siga estos pasos:

1. Seleccione Inicio > Buscar > Archivos o carpetas; busque el archivo sfc.dll en el sistema.
2. Cambie temporalmente el nombre del archivo sfc.dll (la versión que reside en la variable PATH de Windows NT 4.0) por el nombre sfc.old.
3. Instale VisualAge para Java.
4. Tras haber instalado satisfactoriamente VisualAge para Java, vuelva a cambiar el nombre sfc.old por sfc.dll.

Error muy grave de LoadLibrary()

El error muy grave de LoadLibrary() se produce porque el instalador de Windows no registró debidamente uno o varios kernels de instalación (Ikernels) de VisualAge para Java. Para soslayar este problema, debe suprimir el directorio InstallShield en el que residen los archivos de IKernel; después, reinstale VisualAge para Java siguiendo estos pasos:

1. Si es necesario, salga del proceso de instalación.
2. Suprima este directorio: x:\Archivos de programa\Archivos comunes\InstallShield, siendo x la unidad en la que ha intentado instalar VisualAge para Java.
3. Reinstale el producto. 

Error 1631 o error interno 2755 (solo en Windows NT 4.0)

Si instala VisualAge para Java en Windows NT 4.0, puede recibir uno de los siguientes mensajes de error:

• Error 1631: El servicio Instalador de Windows no se ha podido iniciar. Póngase en contacto con el personal de soporte.
• Error interno 2755: Por favor, solicite ayuda al personal de soporte del producto.

Si recibe uno de estos mensajes de error, puede ser que tenga claves de registro con valores nulos. Al iniciar la instalación de VisualAge para Java, el archivo userenv.dll intentará analizar diversas claves de registro; si algunas de ellas tienen valores nulos, la instalación fallará con uno de los mensajes de error indicados anteriormente.

Para soslayar este comportamiento, puede elegir entre eliminar las variables de entorno nulas o modificarlas (cambiar el valor nulo por un valor válido) antes de instalar VisualAge para Java. Cuando ya haya instalado VisualAge para Java, puede volver a dar a las variables sus valores originales.

Precaución: tenga cuidado al eliminar o modificar las variables nulas. Antes de eliminarlas o de modificarlas, debe tomar en consideración el efecto que ello podría tener.

Errores internos 2381, 1303, 1310, 1313 (solo en Windows NT)

Si está intentando instalar VisualAge para Java y se dan algunas o la totalidad de estas circunstancias:

• Está instalando VisualAge para Java en Windows NT 4.0.
• La unidad que contiene la carpeta winnt o la unidad en la que está instalando VisualAge para Java está formateada con el sistema de archivos NTFS
• Los permisos establecidos en esas unidades son incorrectos
• Tiene permisos solo de lectura en el directorio en el que está instalando VisualAge para Java

tal vez reciba uno o varios de los siguientes mensajes de error:

• Error interno 2381: Por favor, solicite ayuda al personal de soporte del producto.
• Error interno 1303: Los privilegios del instalador son insuficientes para acceder a este directorio: NombreDirectorio
• Error interno 1310: Error al intentar crear el archivo destino: NombreArchivo Código de error del sistema: CódigoError (este código varía en función del problema)
• Error interno 1315: No se puede escribir en la carpeta especificada 'NombreCarpeta.

Este problema se produce cuando solo hay permisos de lectura en las carpetas siguientes:

\Archivos de programa\IBM\VisualAge for Java
\WinNT\Installer

Para solucionar este problema, asegúrese de que tiene los permisos necesarios en las unidades o en los directorios. Para ello, siga estos pasos:

1. En el Explorador de Windows, seleccione la unidad o el directorio apropiado.
2. Pulse la carpeta con el botón derecho del ratón y seleccione Propiedades en el menú emergente que aparece.
3. Seleccione la pestaña Seguridad. Pulse Permisos.
4. Seleccione Todos. En el menú desplegable Tipo de acceso, seleccione Control total.
5. Marque el recuadro de selección Reemplazar permisos en subdirectorios.
6. Pulse Aceptar.
7. Pulse Sí para confirmar que desea reemplazar los permisos en todos los subdirectorios.
8. Pulse Aceptar.
9. Instale VisualAge para Java.

Error interno 2735 de inicio de motor

Si recibe el error 2735, siga estos pasos para soslayarlo:

1. Busque estos archivos en el directorio del sistema Windows 32:
   • shd401lc.dll
   • shdoclc.dll
   • shdoc401.dll
   • shdocvw.dll
2. Cambie el nombre shd401lc.dll por shd401lc.old.
3. Cambie el nombre shdoclc.dll por shdoclc.old.
4. Seleccione Inicio > Ejecutar para abrir el diálogo Ejecutar. Ejecute los siguientes mandatos para desregistrar estos archivos .dll:
   • regsvr32 /u shd401lc.dll
   • regsvr32 /u shdoclc.dll
5. Registre estos archivos dll ejecutando los siguientes mandatos en el diálogo Ejecutar:
   • regsvr32 shdoc401.dll
   • regsvr32 shdocvw.dll
6. Instale VisualAge para Java.

Si recibe el siguiente mensaje de error, puede que sea incorrecto el valor del archivo de registro de las Herramientas administrativas (Común):

Error 1606. No se ha podido acceder a la ubicación de red \Profiles\AllUsers\StartMenu\Programs\Administrative Tools\.
Error interno 2707. INSTALLDIR.

Para poder instalar VisualAge para Java, primero debe editar el valor del archivo de registro de las Herramientas administrativas (Común). Para ello, siga estos pasos:

1. Invoque regedit.exe desde un indicador de mandatos.
2. Expanda y seleccione la clave
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folder
3. Seleccione Common Administrative Tools.
4. Seleccione Edición > Modificar.
5. En el campo de datos de valor, entre: %SystemRoot%\Profiles\AllUsers\StartMenu\Programs\Administrative Tools
6. Pulse Aceptar.
7. Seleccione Registro > Salir en la barra de menús.
8. Instale VisualAge para Java.

B.4.2 Limitaciones y problemas conocidos de la desinstalación 

A continuación figura una lista de puntos que conviene tener presentes durante la desinstalación.

B.4.2.1 Espacio en disco

Debe tener como mínimo 2 MB libres en la unidad del sistema de Windows, y la variable de entorno TEMP o TMP debe señalar a un directorio temporal válido que tenga libres 5 MB como mínimo.

B.4.2.2 Desinstalación de Distributed Debugger

Si ha instalado Distributed Debugger como parte de la instalación de VisualAge para Java, debe desinstalar VisualAge para Java ANTES de desinstalar Distributed Debugger. Para ello, cuando haya desinstalado VisualAge para Java, vaya al directorio de instalación del depurador y ejecute el programa de desinstalación.

Si ha desinstalado VisualAge para Java y no puede desinstalar el depurador distribuido, debe suprimir la clave de registro:

HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java

y luego repetir el intento de desinstalar el depurador. NO siga estos pasos si está utilizando el depurador distribuido junto con otros productos, pues ya no podrá utilizar el depurador tras suprimir la clave de registro.

Siga estos pasos:

1. Teclee regedit.exe en un indicador de mandatos.
2. En el editor de registro, expanda y seleccione la clave
   HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
3. Seleccione Edición > Eliminar en la barra de menús para esta clave.
4. Seleccione Sí cuando se le pida que confirme la supresión de la clave.
5. Seleccione Registro > Salir en la barra de menús.

Asimismo, establezca en 1 el valor de la siguiente clave de registro:

HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount

B.4.2.3 Variables de entorno (Windows 98)

Al desinstalar VisualAge para Java en Windows 98, pueden haber quedado algunas entradas de entorno en el archivo autoexec.bat. Estas entradas que han quedado no suelen causar problemas, pero si desinstala y reinstala el producto varias veces, pueden producirse dos problemas: tal vez acabe teniendo sentencias de vía de acceso conflictivas que puedan impedir el funcionamiento de la ayuda en línea, o tal vez se quede sin espacio para las vías de acceso, lo que podría impedirle reinstalar el producto satisfactoriamente.

Para solucionar estos problemas:

1. Haga una copia de seguridad del archivo autoexec.bat.
2. Determine si en el sistema tiene otro programa que requiera el motor de búsqueda HTML (como DB2); para ello, siga estos pasos:
   a) Desinstale VisualAge para Java y rearranque el sistema.
   b) Teclee regedit.exe en un indicador de mandatos y, en el editor de registro, expanda el árbol HKEY_LOCAL_MACHINE\SOFTWARE\. Si en este árbol hay un directorio de IBM, expándalo para ver si contiene un directorio de NetQuestion. Si ve este directorio, es probable que esté empleando el motor de búsqueda con otro producto de IBM.
3. Si no está utilizando el motor de búsqueda HTML para otro producto, elimine todas las entradas IMN o IMQ que vea en el archivo autoexec.bat antes de reinstalar VisualAge para Java.
4. Si está utilizando el motor de búsqueda HTML para otro producto, suprima del archivo autoexec.bat los duplicados que vea de estas entradas:
   
   IMNINST
   IMNINSTSRV
   IMNNQ
   IMNNQ_95
   IMQCONFIGCL
   IMQCONFIGSRV
   Suprima asimismo las entradas duplicadas de la línea IF EXIST X:\IMNNQ_95\IMNENV.BAT CALL IMNEV.BAT
5. Asegúrese de que las entradas repetidas que elimina no sean las originales. Si no está seguro de cuáles son las originales, debe determinar dónde considera el sistema que se instala NetQuestion. Siga estos pasos:
   1. Teclee regedit.exe en un indicador de mandatos.
   2. En el editor de registro, expanda la clave \\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\NetQuestion\Installation Directory
   3. El valor que el directorio tiene dentro de esta clave muestra la vía de acceso en la que se instala NetQuestion. Algunas variables de entorno deben contener este directorio como parte de su valor para que NetQuestion funcione correctamente.
      
      Si algunas de las variables anteriores incluyen un directorio distinto del que aparece en el registro como parte de su valor, suprímalas.

B.4.2.4 Desinstalación de NetQuestion

Cuando vaya a desinstalar VisualAge para Java, puede ser que no se desinstale NetQuestion. Podrían surgir problemas si no desinstala NetQuestion y más adelante intenta reinstalar el producto. 

Para eliminar los archivos de NetQuestion instalados por VisualAge para Java, siga estos pasos. Ello no afectará a los archivos de NetQuestion instalados por otros productos (por ejemplo, DB2).

1. Para localizar el directorio de NetQuestion, teclee lo siguiente en un indicador de mandatos: set imninstsrv. Este mandato le proporcionará la ubicación en la que se ha instalado NetQuestion en su máquina. Por ejemplo:

   IMNINSTSRV=C:\imnnq_nt

   La ubicación del directorio de NetQuestion puede aparecer de manera distinta en función de en qué unidad haya instalado VisualAge para Java y de qué sistema operativo esté utilizando. Si recibe un mensaje de error como este "Variable de entorno imninstsrv no definida", ello indica que se han desinstalado todos los archivos de NetQuestion.

2. Vaya al directorio de NetQuestion (esta es la información que aparece a continuación de IMNINSTSRV=)
3. Teclee vahcfg remove /p vj32

Así se eliminarán los archivos de NetQuestion que VisualAge para Java haya instalado.

Si más adelante reinstala VisualAge para Java y resulta que falla la ayuda, consulte la Guía para la resolución de problemas, donde hallará más información sobre cómo solucionar las anomalías de la ayuda. La Guía para la resolución de problemas (trshoot.htm) está en el CD del producto VisualAge para Java, Professional Edition, y en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Tras instalar VisualAge para Java, la guía también está en X:\IBMVJava, siendo X:\IBMVJava el directorio de instalación de VisualAge para Java.

Parte C: EMSRV

Debe utilizar EMSRV, Versión 7.1, si tiene previsto trabajar en un entorno en equipo con la versión Enterprise Edition de VisualAge para Java.

Todos los archivos de EMSRV están en el CD de características adicionales.

C.1.0 Prerrequisitos

Antes de instalar EMSRV, lea la sección que trata sobre "Limitaciones y problemas conocidos", al final de la Parte C.

C.1.1 Plataformas soportadas

El servidor EMSRV está soportado para las siguientes plataformas de sistema operativo:

• Novell NetWare 4.2
• Novell NetWare 5.1
• OS/2(R) Warp Versión 4.0
• OS/2 Warp Server para e-business
• Windows NT (R) Workstation Versión 4.0 (con el Service Pack 5) **
• Windows NT Server Versión 4.0 (con el Service Pack 5) **
• Windows (R) 2000 Professional **
• Windows 2000 Professional Server **
• Windows 2000 Advanced Server **
• Sun Solaris (TM) Versión 2.6 (con el parche 106757-05) +
• Sun Solaris Versión 7.0
• HP-UX Versión 10.20 *
• HP-UX Versión 11.0 *
• AIX(R) Versión 4.3.2
• AIX Versión 4.3.3
• Red Hat Linux 6.1
• Red Hat Linux 6.2

* Nota: HP-UX únicamente está soportado en las máquinas de estación de trabajo de la clase 700. Se ha probado en una máquina HP-UX 9000/715/60 y en una máquina HP-UX 9000/782/200+. Puesto que las máquinas (servidores) de la clase 800 tienen una arquitectura distinta y necesitan binarios diferentes, EMSRV no está soportado en las máquinas de la clase 800.

+ La información que indica cómo obtener este parche está en la sección C.1.4.

IBM ha dejado de dar soporte a EMSRV en Netware 4.11 o Netware 5.0, pero EMSRV se puede ejecutar en dicha plataforma si se carga CLIBAUX.NLM antes de cargar EMSRV.NLM. CLIBAUX.NLM se incluye junto con el Support Pack 8a de Novell, pero también se puede adquirir por separado en Novell, en el archivo CLIBAUX1.EXE, que se encuentra en esta ubicación:

http://support.novell.com/cgi-bin/search/download?/pub/updates/nw/nw42/clibaux1.exe

Retirada de soporte para el hardware SMP

** NOTA IMPORTANTE: si ejecuta un release de EMSRV para Windows NT/2000 en una máquina que tenga más de un procesador, se podrían dañar los depósitos.

EMSRV ha dejado de estar soportado en los servidores Windows NT/2000 que se ejecutan en hardware SMP (máquinas que tienen más de un procesador). La decisión de retirar el soporte para el hardware SMP se basa en la frecuencia de informes de daños provocados en el depósito en relación con los servidores Windows y con el hardware SMP. EMSRV sigue dando soporte al hardware SMP en los demás sistemas operativos.

IBM DECLINA TODA RESPONSABILIDAD POR DAÑOS INFLIGIDOS COMO RESULTADO DEL USO DE EMSRV EN UN SERVIDOR WINDOWS NT/2000 QUE SE EJECUTE EN HARDWARE SMP, INCLUIDOS, SIN LIMITARSE A ELLOS, LOS DAÑOS QUE USTED RECLAME BASÁNDOSE EN LAS RECLAMACIONES DE TERCEROS. EN NINGÚN CASO IBM, NI SUS SUMINISTRADORES, AGENTES Y EMPLEADOS, SERÁN RESPONSABLES DE LOS DAÑOS INDIRECTOS, ESPECIALES, PUNITORIOS, EJEMPLARES NI CONSECUENTES QUE SE PUEDAN DERIVAR DEL USO DE EMSRV EN UN SERVIDOR WINDOWS NT/2000 QUE SE EJECUTE EN HARDWARE SMP.

Si desea usar EMSRV en un servidor que se ejecute en hardware SMP, deberá emplear el parámetro -mp cuando inicie EMSRV. Ello eludirá la comprobación de la existencia de hardware SMP. Así, estará ejecutando EMSRV en una plataforma no soportada y deberá asumir toda responsabilidad (IBM DECLINA TODA RESPONSABILIDAD) si los depósitos se dañan como consecuencia de ello.

EMSRV no aprovecha los procesadores adicionales, en virtud del hecho de que EMSRV es un proceso ligado a entrada/salida, no un proceso ligado a procesador. Por ello, el rendimiento de EMSRV no se ve afectado por el número de procesadores que haya en el servidor.

C.1.2 TCP/IP

Es preciso instalar y configurar TCP/IP en su servidor.

C.1.3 Parches de Novell necesarios para ejecutar EMSRV

Le recomendamos que obtenga y aplique la lista mínima de parches de NetWare. Estos archivos de parche están disponibles en http://support.novell.com/misc/patlst.htm. Debe seleccionar y aplicar los parches adecuados para la versión de NetWare que está utilizando.

C.1.4 Parche necesario para ejecutar EMSRV en Solaris

Hay un error en la implementación de Solaris, Versión 2.6, de PAM, que impide el funcionamiento correcto de EMSRV. Tendrá que aplicar el parche 106257-05 si va a utilizar EMSRV en Solaris, Versión 2.6. El parche está disponible en:

http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F106257&zone_32=PAM

El error específico que se arregla con este parche es:

4092227 Miembro pam_conv appdata_ptr no pasa a través de la función conv() tal como indica la documentación

No es necesario aplicar este parche si va a trabajar con la Versión 7.0 de Solaris.

C.1.5 Sistemas de archivos soportados

EMSRV ha sido probado y certificado con los siguientes sistemas de archivos:

NetWare

• NWFS (sistema de archivos NetWare) con espacio de nombres DOS
• NWFS con espacio de nombres OS/2 o LONG
• NSS (servicios de almacenamiento Novell) con espacio de nombres DOS
• NSS con espacio de nombres OS/2 o LONG

OS/2

• HPFS (sistema de archivos de alto rendimiento)
• FAT

Windows NT y Windows 2000

• NTFS (sistema de archivos de nueva tecnología)
• FAT32
• FAT

Solaris

• UFS (sistema de archivo Unix)

HP-UX

• VxFS (sistema de archivo Veritas)

AIX

• JFS (sistema de archivos de diario)

Linux

• EXT2FS (segundo sistema de archivos ampliado)

EMSRV solo da soporte a sistemas de archivos montados localmente.

C.2.0 Instalación

Esta sección contiene instrucciones para instalar el programa servidor de depósito EMSRV y un depósito compartido. Si desea instrucciones para iniciar el servidor, consulte el tema "Configuración y administración del servidor", en el archivo emsrv71.htm (emsrv70 para todos los idiomas que no sean el inglés), que encontrará en el directorio TeamServer\docs.

C.2.1 Instalación de EMSRV para Windows(R)

Configuración de EMSRV para Windows
Antes de instalar EMSRV en Windows, debe tener en cuenta los siguientes hechos sobre los tipos de archivo:

• La vía de acceso a un depósito al que se accede por medio de EMSRV para Windows NT debe especificarse en la línea de mandatos como vía de acceso FAT, NTFS o UNC, relativa al directorio de trabajo de EMSRV (es decir, la vía que especifique para acceder al depósito debe empezar por el directorio de trabajo de EMSRV). No es posible acceder a un depósito que resida en un volumen remoto (es decir, en una unidad remota de almacenamiento de datos). Ejemplos de ello son las unidades compartidas mediante Microsoft(R) Networking que residen en otras máquinas, y los volúmenes de NetWare a los que se puede acceder mediante Gateway (y Cliente) Services para NetWare.
• Cuando se utiliza EMSRV para Windows NT o Windows 2000, los nombres largos de archivo se pueden crear y ver en los volúmenes FAT, FAT32 y NTFS. A diferencia de las implementaciones de FAT anteriores, la implementación para Windows NT y Windows 2000 tiene soporte para los nombres largos de archivo. El soporte de nombres largos de archivo es necesario para la característica de gestión de recursos almacenados empleada por VisualAge para Java, Versión 4.0.

Instalación de EMSRV en Windows
Para instalar el programa servidor de depósito EMSRV y un depósito compartido en un servidor Windows NT o Windows 2000, siga estos pasos:

1. Vaya al directorio TeamServer/Windows del CD de características adicionales y ejecute el archivo setup.exe.
2. Siga las instrucciones de la pantalla. Cuando se le indique que seleccione un directorio de instalación, seleccione un subdirectorio que forme parte de su variable PATH o cree un subdirectorio y añádalo a dicha variable PATH. Le sugerimos que los coloque en una ubicación que tenga una gran cantidad de espacio libre, porque el archivo emsrv.log se escribirá en el subdirectorio que seleccione.
3. Extraiga lo siguiente del archivo ide.zip y colóquelo en el directorio deseado: 
   • ivj.dat (archivo de depósito)
   • directorio ivj.dat.pr (directorio de recursos de proyecto)

   El archivo ide.zip está en el directorio ivj40\backup que se encuentra en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos).

Este directorio es donde piensa almacenar los depósitos de código fuente compartido. Cuando inicie el servidor más adelante, especificará este subdirectorio como directorio de trabajo de EMSRV, utilizando el parámetro de inicio -W de EMSRV al iniciar el servidor.

EMSRV debe poseer plenos derechos para leer, escribir y buscar en todo el árbol de directorios en el directorio ivj.dat.pr. El directorio ivj.dat.pr siempre se debe copiar en el mismo directorio que ivj.dat; de lo contrario, no se podrá acceder a los recursos de proyecto.

Tal vez elija cambiar el nombre del archivo de depósito, dándole otro nombre como team1.dat, por ejemplo. Si cambia el nombre del depósito después de copiarlo en el servidor, tendrá que dar al directorio de recursos de proyecto un nombre que se corresponda con el del depósito. Por ejemplo, si cambia el nombre del depósito por team1.dat, debe cambiar el nombre del directorio de recursos de proyecto por team1.dat.pr.

Los miembros del equipo tendrán que especificar el nombre del archivo de depósito cuando instalen el código de cliente de VisualAge para Java. También deberán especificar la vía de acceso en la máquina servidor.

1. Si desea habilitar la comprobación de contraseñas mediante el uso de un archivo passwd.dat, haga una copia del archivo passwd.dat que está en el directorio TeamServer y coloque la copia en el mismo directorio donde ha copiado el archivo ivj.dat. Si desea obtener más información sobre los tipos de comprobación de contraseña disponible, consulte el tema "Configuración y administración del servidor", en el archivo emsrv71.htm (emsrv70 para todos los idiomas, excepto el inglés), que encontrará en el directorio TeamServer\docs.
2. Verifique si TCP/IP está instalado y correctamente enlazado a un adaptador de LAN. Para verificar el enlace, puede utilizar el mandato ping (por ejemplo, ping dirección IP/nombre de sistema principal) para comunicarse con el servidor desde una estación de trabajo de la LAN.
3. Instale EMSRV en el registro de Windows NT (opcional), autorice al usuario de EMSRV e inicie EMSRV. Estos temas se explican en el archivo "Configuración y administración del servidor", emsrv71.htm (emsrv70.htm para todos los idiomas que no sean el inglés).

Si prefiere iniciar EMSRV como servicio, en vez de hacerlo desde un indicador de mandatos, puede instalar EMSRV en el registro de Windows. El hecho de instalar EMSRV como servicio tiene dos ventajas:

• Puede especificar el inicio automático, de forma que EMSRV se iniciará siempre que se arranque el servidor del depósito.
• Puede especificar los valores por omisión que desea que utilice EMSRV. Por ejemplo, podría ser conveniente asegurarse de que la validación de contraseñas estuviera siempre habilitada.

Consejo: si EMSRV se inicia como servicio, el directorio de trabajo por omisión de EMSRV es el directorio system32\ de Windows NT o Windows 2000. Le recomendamos que cambie este valor por omisión utilizando el parámetro -W cuando instale EMSRV como servicio en el registro de Windows NT o Windows 2000.

Importante: EMSRV ha dejado de estar soportado en los servidores Windows NT/2000 que se ejecutan en hardware SMP (máquinas que tienen más de un procesador). La decisión de retirar el soporte para el hardware SMP se basa en la frecuencia de informes de daños provocados en el depósito en relación con los servidores Windows y con el hardware SMP. EMSRV sigue dando soporte al hardware SMP en los demás sistemas operativos.

IBM DECLINA TODA RESPONSABILIDAD POR DAÑOS INFLIGIDOS COMO RESULTADO DEL USO DE EMSRV EN UN SERVIDOR WINDOWS NT/2000 QUE SE EJECUTE EN HARDWARE SMP, INCLUIDOS, SIN LIMITARSE A ELLOS, LOS DAÑOS QUE USTED RECLAME BASÁNDOSE EN LAS RECLAMACIONES DE TERCEROS. EN NINGÚN CASO IBM, NI SUS SUMINISTRADORES, AGENTES Y EMPLEADOS, SERÁN RESPONSABLES DE LOS DAÑOS INDIRECTOS, ESPECIALES, PUNITORIOS, EJEMPLARES NI CONSECUENTES QUE SE PUEDAN DERIVAR DEL USO DE EMSRV EN UN SERVIDOR WINDOWS NT/2000 QUE SE EJECUTE EN HARDWARE SMP.

Si desea instalar e iniciar EMSRV como servicio Windows NT/2000 en hardware SMP, debe instalar el servicio utilizando el parámetro -mp. Ello eludirá la comprobación de la existencia de hardware SMP. Así, estará ejecutando EMSRV en una plataforma no soportada y deberá asumir toda responsabilidad (IBM DECLINA TODA RESPONSABILIDAD) si los depósitos se dañan como consecuencia de ello.

Si no instala el servicio utilizando el parámetro -mp, el servicio no se iniciará y usted recibirá el siguiente mensaje de error:

No se ha podido iniciar el servicio EMSRV en \\sistemaprincipal
Error 2140: se ha producido un error interno de Windows NT.

Si intenta instalar EMSRV de nuevo como servicio (por ejemplo, para añadir el parámetro -mp), el servicio se instalará satisfactoriamente, pero usted recibirá este error:

El archivo de mensajes emsrvmsg.dll no se ha podido copiar en C:\WINNT\System32\emsrvmsg.dll

--- Error 1224 de OS: no se ha podido realizar la operación solicitada en un archivo con una sección abierta correlacionada por usuario. Asegúrese de que la DLL está en el mismo directorio que EMSRV.EXE.

Puede hacer caso omiso de este mensaje de error, ya que la DLL ya se ha instalado al instalarse el servicio anteriormente.

Para instalar EMSRV como servicio:

1. Desde un indicador de mandatos, cambie de directorio para ir a donde está instalado el programa ejecutable EMSRV.
2. Emita el mandato emsrv -install [parámetro2] [parámetro3] ... El primer parámetro debe ser -install; los demás son los parámetros de inicio de EMSRV que ha elegido para su entorno.
   
   A continuación se proporciona un ejemplo de este mandato:
   
   emsrv -install -u joe -p donttell -W j:\sharedrep -rn
   
   Este ejemplo instala EMSRV como servicio en el registro de Windows, donde joe es el nombre del usuario de EMSRV y donttell es la contraseña de joe. Por omisión, el directorio de trabajo de EMSRV será j:\sharedrep y se utilizará la validación de contraseña nativa.
   
   Un mensaje confirma que se ha instalado EMSRV.
3. Los pasos a y b son ligeramente distintos para Windows NT y Windows 2000.
   a) En el Panel de control de Windows NT, pulse dos veces Servicios. Aparecerá el cuadro de diálogo Servicios. Seleccione EMSRV en la lista de servicios. 
   b) En el Panel de control de Windows 2000, pulse dos veces Herramientas administrativas. Pulse dos veces Servicios. Pulse dos veces EMSRV.
   Puede iniciarlo manualmente desde aquí. EMSRV está ahora instalado como servicio en el registro y se han copiado las DLL necesarias en el directorio del sistema.
4. En el cuadro de texto Parámetros de inicio, teclee los parámetros de inicio de EMSRV que desee utilizar. Si está especificando el directorio de trabajo que ha de emplear EMSRV, debe teclear una barra inclinada invertida adicional por cada barra inclinada invertida de la vía de acceso. A continuación figura un ejemplo:
   
   -u emsrvacc -p secret -W d:\\javateam
5. Pulse Iniciar. Mediante un mensaje, se le comunicará que EMSRV está en proceso de iniciarse.

Si desea obtener más información sobre cómo iniciar EMSRV, consulte el tema "Configuración y administración del servidor", en el archivo emsrv71.htm (emsrv70 para todos los idiomas que no sean el inglés), que encontrará en el directorio TeamServer\docs.

Los parámetros que ha proporcionado se utilizarán por omisión siempre que se inicie EMSRV. También puede alterar temporalmente estos parámetros o añadir otros nuevos si inicia EMSRV de forma manual desde el icono Servicios del Panel de control de Windows.

Configuración de EMSRV para Netware
Antes de instalar EMSRV en Netware, debe tener en cuenta las siguientes limitaciones:

• Cuando se utiliza EMSRV para NetWare, los nombres largos de archivo solo se pueden crear y ver en los volúmenes de NetWare a los que se haya añadido el espacio de nombres LONG u OS/2. El soporte de nombres largos de archivo es necesario para la característica de gestión de recursos almacenados empleada por VisualAge para Java, Versión 4.0.
• EMSRV para NetWare requiere que la pila TCP/IP NetWare (TCPIP.NLM) esté cargada y configurada en el servidor. Cuando se inicia EMSRV para NetWare, si TCPIP.NLM aún no está instalado, se cargará automáticamente. Los archivos NWSNUT.NLM, necesarios para la interfaz de usuario de EMSRV para NetWare, también se cargarán automáticamente.

Instalación de EMSRV en Netware
Para instalar el programa servidor de depósito EMSRV y un depósito compartido en NetWare, siga estos pasos:

1. Desde el directorio TeamServer\Netware, copie los siguientes archivos de programa en el directorio SYS:\SYSTEM del servidor:
   • emsrv.nlm
2. Extraiga lo siguiente del archivo ide.zip y colóquelo en el directorio deseado del servidor:
   • ivj.dat (archivo de depósito)
   • directorio ivj.dat.pr (directorio de recursos de proyecto)

   El archivo ide.zip está en el directorio ivj40\backup que se encuentra en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos).

Cuando inicie el servidor más adelante, especificará este subdirectorio como directorio de trabajo de EMSRV, utilizando el parámetro de inicio -W de EMSRV. EMSRV debe poseer plenos derechos para leer, escribir y buscar en todo el árbol de directorios en el directorio ivj.dat.pr. El directorio ivj.dat.pr siempre se debe copiar en el mismo directorio que ivj.dat; de lo contrario, no se podrá acceder a los recursos de proyecto.

Tal vez elija cambiar el nombre del archivo de depósito, dándole otro nombre como team1.dat, por ejemplo. Si cambia el nombre del depósito después de copiarlo en el servidor, tendrá que dar al directorio de recursos de proyecto un nombre que se corresponda con el del depósito. Por ejemplo, si cambia el nombre del depósito por team1.dat, debe cambiar el nombre del directorio de recursos de proyecto por team1.dat.pr.

Los miembros del equipo tendrán que especificar el nombre y la ubicación del archivo de depósito cuando instalen el código de cliente de VisualAge para Java.

1. Copie el archivo de contraseña de ejemplo, passwd.dat, del directorio TeamServer al mismo directorio en el que copió ivj.dat. 
2. Verifique que TCPIP.NLM de NetWare está cargado y correctamente enlazado a un adaptador de LAN. Para verificar el enlace, puede utilizar el programa de utilidad del mandato ping (por ejemplo, ping dirección IP/nombre de sistema principal) para comunicarse con el producto desde una estación de trabajo de la LAN.
3. Para asegurarse de que los nombres de sistema principal aparecerán en la salida de EMADMIN al consultar EMSRV, compruebe que el mecanismo de resolución se ha configurado correctamente para las búsquedas inversas en DNS. Asegúrese también de que el archivo RESOLV.CFG (que se encuentra en sys:\etc) está configurado correctamente. A continuación figura un ejemplo de cómo se configuraría un archivo: 
   domain javadev.com
   nameserver 192.168.73.150
4. Si desea instrucciones para iniciar el producto, consulte el tema "Configuración y administración del servidor", en el archivo emsrv71.htm (emsrv70 para todos los idiomas que no sean el inglés), que encontrará en el directorio TeamServer\docs.

C.2.3 Instalación de EMSRV para OS/2 Warp

Nota: OS/2 ha dejado de estar soportado como plataforma de desarrollo. En la Parte E encontrará los detalles.

Configuración de EMSRV para OS/2
Antes de instalar EMSRV en OS/2, debe tener en cuenta lo siguiente:

• Cuando se utiliza EMSRV para OS/2, los nombres largos de archivo se pueden crear y ver en los volúmenes HPFS. El soporte de nombres largos de archivo es necesario para la característica de gestión de recursos almacenados empleada por VisualAge para Java, Versión 4.0.

Instalación de EMSRV en OS/2 
Para instalar el programa servidor de depósito EMSRV y un depósito compartido en un servidor OS/2, siga estos pasos:

1. Copie estos tres archivos del directorio TeamServer en el directorio deseado de la máquina OS/2:
   • emsrv.exe
   • emadmin.exe
   • emclient.mod

   Coloque estos archivos en un subdirectorio que forme parte de la variable PATH o cree un subdirectorio y añádalo a variable PATH. Le sugerimos que los coloque en una ubicación que tenga una gran cantidad de espacio libre, porque el archivo emsrv.log se escribirá en el subdirectorio en el que coloque estos archivos.

2. Extraiga lo siguiente del archivo ide.zip y póngalo en el subdirectorio en el que ha colocado los archivos copiados en el paso 1:
   • ivj.dat (archivo de depósito)
   • directorio ivj.dat.pr (directorio de recursos de proyecto)

   El archivo ide.zip está en el directorio ivj40\backup que se encuentra en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos).

   Este subdirectorio es donde piensa almacenar los depósitos de código fuente compartido. Cuando inicie el servidor más adelante, especificará este subdirectorio como directorio de trabajo de EMSVR, utilizando el parámetro de inicio -W de EMSRV.

   EMSRV debe poseer plenos derechos para leer, escribir y buscar en todo el árbol de directorios en el directorio ivj.dat.pr. El directorio ivj.dat.pr siempre se debe copiar en el mismo directorio que ivj.dat; de lo contrario, no se podrá acceder a los recursos de proyecto.

   Tal vez elija cambiar el nombre del archivo de depósito, dándole otro nombre como team1.dat, por ejemplo. Si cambia el nombre del depósito después de copiarlo en el servidor, tendrá que dar al directorio de recursos de proyecto un nombre que se corresponda con el del depósito. Por ejemplo, si cambia el nombre del depósito por team1.dat, debe cambiar el nombre del directorio de recursos de proyecto por team1.dat.pr.

   Los miembros del equipo tendrán que especificar el nombre del archivo de depósito cuando instalen el código de cliente de VisualAge para Java.

3. Si desea habilitar la comprobación de contraseñas mediante el uso de un archivo passwd.dat, haga una copia del archivo passwd.dat que está en el directorio TeamServer y coloque la copia en el mismo directorio donde ha copiado el archivo ivj.dat. Si desea obtener más información sobre los tipos de comprobación de contraseña disponible, consulte el tema "Configuración y administración del servidor", en el archivo emsrv71.htm (emsrv70 para todos los idiomas, excepto el inglés), que encontrará en el directorio TeamServer\docs.
4. Verifique si TCP/IP está instalado y correctamente enlazado a un adaptador de LAN. Para verificar el enlace, puede utilizar el mandato ping (por ejemplo, ping dirección IP/nombre de sistema principal) para comunicarse con el servidor desde una estación de trabajo de la LAN.
5. Para iniciar el servidor, siga las instrucciones para iniciar EMSRV en OS/2 que figuran en el tema "Configuración y administración del servidor" del archivo emsrv71.htm (emsrv70.htm para todos los idiomas que no sean el inglés).

C.2.4 Instalación de EMSRV para AIX

Configuración de EMSRV para AIX
Antes de instalar EMSRV en AIX, debe tener en cuenta las siguientes características:

• En AIX, es necesario habilitar el soporte de archivos grandes para el volumen que alberga un depósito y para el usuario que inicia el proceso EMSRV.
• Cuando cree un sistema de archivos, asegúrese de que se utiliza el argumento '-o bf=true' con mkfs.
• Para establecer los límites para el usuario que inicia el proceso EMSRV, las opciones -Hf y -Sf del mandato ulimit deben tener argumentos que especifiquen el número de bloques de 512 bytes. Los mandatos siguientes deben ser adecuados para habilitar depósitos cuyo tamaño llegue hasta los 16 GB:
  
  ulimit -Hf 33554432
  ulimit -Sf unlimited
• La autenticación de EMSRV para AIX se implementa con la función authenticate() del sistema. Esto permite que un ejecutable EMSRV (emsrv) dé soporte a contraseñas replicadas y no replicadas, además de la autenticación DCE. El método de autenticación para cada usuario está establecido en el archivo /etc/security/user. 

Instalación de EMSRV en AIX
En los pasos que siguen, el "usuario de EMSRV" es el usuario que inicia el programa EMSRV.

Debe copiar en su máquina los siguientes archivos del directorio TeamServer:

• emsrv
• emadmin

Coloque estos archivos en un subdirectorio que forme parte de la variable PATH o cree un subdirectorio y añádalo a variable PATH. Le sugerimos que los coloque en una ubicación que tenga una gran cantidad de espacio libre, porque el archivo emsrv.log se escribirá en el subdirectorio en el que coloque estos archivos.

Siga estos pasos para configurar EMSRV en una máquina AIX:

1. El usuario de EMSRV o el administrador del sistema (root) reserva espacio en disco en donde almacenar los depósitos.
2. Se puede configurar un depósito inicial extrayendo lo siguiente del archivo ide.zip y poniéndolo en el espacio en disco reservado en el paso 1.
   • ivj.dat (archivo de depósito)
   • directorio ivj.dat.pr (directorio de recursos de proyecto)

   El archivo ide.zip está en el directorio ivj40\backup que se encuentra en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos).

   EMSRV debe poseer plenos derechos para leer, escribir y buscar en todo el árbol de directorios en el directorio ivj.dat.pr. El directorio ivj.dat.pr siempre se debe copiar en el mismo directorio que ivj.dat; de lo contrario, no se podrá acceder a los recursos de proyecto. Los directorios deben tener establecidos los bits rw y x (búsqueda) para el usuario de EMSRV.

3. Cambie el propietario del archivo para que pase a ser el usuario de EMSRV o el administrador del sistema. Si piensa tener más de un depósito, haga copias de ivj.dat utilizando distintos nombres, pero conserve la misma extensión (.dat). Si hace copias duplicadas del depósito, debe hacer copias duplicadas del directorio ivj.dat.pr y cambiarle el nombre para que coincida con el depósito al que está asociado. Por ejemplo, si hace una copia duplicada que se llama "team.dat", debe hacer un directorio de recursos de proyecto duplicado que se llame "team.dat.pr".
   El usuario de EMSRV o el administrador del sistema deben cambiar de directorio para ir a donde se almacenan los depósitos e iniciar el programa EMSRV utilizando los distintivos adecuados. Si desea obtener más información acerca de los distintivos de EMSRV, consulte el tema "Configuración y administración del servidor", en el archivo emsrv71.htm (emsrv70 para todos los idiomas, excepto el inglés), que encontrará en el directorio TeamServer\docs.
4. El usuario de EMSRV o el administrador del sistema indican a los miembros del equipo cuál es la ubicación y el nombre del depósito del equipo. Los miembros del equipo necesitarán esta información cuando instalen el código de cliente.
5. Para iniciar el servidor, siga las instrucciones que figuran en el tema "Configuración y administración del servidor" del archivo emsrv71.htm (emsrv70.htm para todos los idiomas que no sean el inglés).

En las plataformas UNIX, se requiere el acceso root para autenticar a los usuarios. Para ello, NO debe ser el usuario root quien inicie EMSRV. Si así se hiciera, quedaría comprometida la seguridad, ya que en ese caso EMSRV tendría pleno acceso a todos los sistemas de archivos.

Por el contrario, debe cambiar el propietario del ejecutable EMSRV por 'root' y establecer el bit SUID del ejecutable. Para ello, haga lo siguiente:

chown root emsrv
chmod u+s emsrv

EMSRV, cuando intenta autenticar un usuario, cambiará temporalmente la autorización del proceso EMSRV en ejecución para que pase a ser la autorización del propietario del ejecutable. Una vez llevada a cabo la autenticación, la autorización del proceso EMSRV en ejecución pasará a ser de nuevo la del usuario que inició EMSRV. Este mecanismo se produce por cada proceso (por cliente), para que así, mientras se esté autenticando un cliente, solo tenga acceso root temporal el proceso que sirve a ese cliente.

El acceso root es necesario para la autenticación sea cual sea la forma en la que EMSRV implemente realmente la autenticación. Las interfaces como PAM solo proporcionan una API común para permitir a las aplicaciones dar soporte a múltiples métodos de autenticación, si bien, deberá ser correcta la configuración específica de cada método de autenticación. 

C.2.5 EMSRV para HP-UX o Solaris

C.2.5.1 Configuración de EMSRV para HP-UX o Solaris
Antes de instalar EMSRV en Solaris o HP-UX, debe tener en cuenta estos requisitos:

Para Solaris

• En Solaris, los sistemas de archivos tienen automáticamente el soporte de archivos grandes, pero hay que usar el mandato ulimit con el fin de establecer límites para el usuario que inicia el proceso EMSRV. Las opciones -Hf y -Sf del mandato ulimit deben tener argumentos que especifiquen el número de bloques de 512 bytes. Los mandatos siguientes deben ser adecuados para habilitar depósitos cuyo tamaño llegue hasta los 16 GB:
  ulimit -Hf 33554432
  ulimit -Sf unlimited

• EMSRV para Solaris implementa la autenticación con PAM. PAM debe estar correctamente configurado en una máquina que ejecute EMSRV; de lo contrario, ni siquiera sería posible concluir EMSRV utilizando EMADMIN. El archivo /etc/pam.conf debe especificar EMSRV como servicio que utiliza PAM (se debe especificar como "emsrv", no como "EMSRV"). Junto con este release se incluye un archivo pam.conf de ejemplo.
• EMSRV solicita 4 bytes de memoria compartida. Los valores del sistema operativo definen los tamaños mínimo y máximo para los fragmentos de memoria compartida que puede solicitar un proceso. Si el valor máximo es menor que 4 bytes, o si el valor mínimo es mayor que 4 bytes, EMSRV no se ejecutará ni generará el archivo de anotaciones.

Para HP-UX 

• En HP-UX, es necesario habilitar el soporte de archivos grandes para el volumen que alberga un depósito y para el usuario que inicia el proceso EMSRV.
• Cuando cree un sistema de archivos, asegúrese de que se usa el argumento '-o largefiles' con newfs.
• Para establecer los límites para el usuario que inicia el proceso EMSRV, las opciones -Hf y -Sf del mandato ulimit deben tener argumentos que especifiquen el número de bloques de 512 bytes. Los mandatos siguientes deben ser adecuados para habilitar depósitos cuyo tamaño llegue hasta los 16 GB:
  
  ulimit -Hf 33554432
  ulimit -Sf unlimited

C.2.5.2 Instalación de EMSRV para HP-UX o Solaris
En los pasos que siguen, el "usuario de EMSRV" es el usuario que inicia el programa EMSRV.

Debe copiar en su máquina los siguientes archivos del directorio TeamServer:

Para HP-UX:

• emsrv 
• emsrv.shadow 
• emadmin

Para Solaris:

• emsrv 
• emadmin
• pam.conf

Coloque estos archivos en un subdirectorio que forme parte de la variable PATH o cree un subdirectorio y añádalo a variable PATH. Le sugerimos que los coloque en una ubicación que tenga una gran cantidad de espacio libre, porque el archivo emsrv.log se escribirá en el subdirectorio en el que coloque estos archivos.

Para configurar EMSRV en una máquina Solaris o HP-UX, siga estos pasos:

1. El usuario de EMSRV o el administrador del sistema (root) reserva espacio en disco en donde almacenar los depósitos.
2. Se puede configurar un depósito inicial extrayendo lo siguiente del archivo ide.zip y poniéndolo en el espacio en disco reservado en el paso 1.
   • ivj.dat (archivo de depósito)
   • directorio ivj.dat.pr (directorio de recursos de proyecto)

   El archivo ide.zip está en el directorio ivj40\backup que se encuentra en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos).

   EMSRV debe poseer plenos derechos para leer, escribir y buscar en todo el árbol de directorios de ivj.dat.pr. El directorio ivj.dat.pr siempre se debe copiar en el mismo directorio que ivj.dat; de lo contrario, no se podrá acceder a los recursos de proyecto. Los directorios deben tener establecidos los bits rw y x (búsqueda) para el usuario de EMSRV.

3. Cambie el propietario del archivo para que pase a ser el usuario de EMSRV o el administrador del sistema. Si piensa tener más de un depósito, haga copias de ivj.dat utilizando distintos nombres, pero conserve la misma extensión (.dat). Si hace copias duplicadas del depósito, debe hacer copias duplicadas del directorio ivj.dat.pr y cambiarle el nombre para que coincida con el depósito al que está asociado. Por ejemplo, si hace una copia duplicada que se llama "team.dat", debe hacer un directorio de recursos de proyecto duplicado que se llame "team.dat.pr".
   El usuario de EMSRV o el administrador del sistema deben cambiar de directorio para ir a donde se almacenan los depósitos e iniciar el programa EMSRV utilizando los distintivos adecuados. Si desea obtener más información acerca de los distintivos de EMSRV, consulte el tema "Configuración y administración del servidor", en el archivo emsrv71.htm (emsrv70 para todos los idiomas, excepto el inglés), que encontrará en el directorio TeamServer\docs.
4. El usuario de EMSRV o el administrador del sistema indican a los miembros del equipo cuál es la ubicación y el nombre del depósito del equipo. Los miembros del equipo necesitarán esta información cuando instalen el código de cliente.
5. Para iniciar el servidor, siga las instrucciones que figuran en el tema "Configuración y administración del servidor" del archivo emsrv71.htm (emsrv70.htm para todos los idiomas que no sean el inglés).

En las plataformas UNIX, se requiere el acceso root para autenticar a los usuarios. Para ello, NO debe ser el usuario root quien inicie EMSRV. Si así se hiciera, quedaría comprometida la seguridad, ya que en ese caso EMSRV tendría pleno acceso a todos los sistemas de archivos.

Por el contrario, debe cambiar el propietario del ejecutable EMSRV por 'root' y establecer el bit SUID del ejecutable. Para ello, haga lo siguiente:

chown root emsrv
chmod u+s emsrv

EMSRV, cuando intenta autenticar un usuario, cambiará temporalmente la autorización del proceso EMSRV en ejecución para que pase a ser la autorización del propietario del ejecutable. Una vez llevada a cabo la autenticación, la autorización del proceso EMSRV en ejecución pasará a ser de nuevo la del usuario que inició EMSRV. Este mecanismo se produce por cada proceso (por cliente), para que así, mientras se esté autenticando un cliente, solo tenga acceso root temporal el proceso que sirve a ese cliente.

El acceso root es necesario para la autenticación sea cual sea la forma en la que EMSRV implemente realmente la autenticación. Las interfaces como PAM solo proporcionan una API común para permitir a las aplicaciones dar soporte a múltiples métodos de autenticación, si bien, deberá ser correcta la configuración específica de cada método de autenticación. 

C.2.6 EMSRV para Linux

C.2.6.1 Configuración de EMSRV para Linux
Antes de instalar EMSRV en Linux, debe tener en cuenta esta información:

• EMSRV para Linux implementa la autenticación con PAM. Esto permite dar soporte a las contraseñas replicadas y a las no replicadas con un ejecutable EMSRV. Asimismo, Red Hat Linux 6.2 da soporte a las contraseñas MD5, y EMSRV también, a través de PAM.
• PAM debe estar correctamente configurado en una máquina que ejecute EMSRV; de lo contrario, ni siquiera sería posible concluir EMSRV utilizando EMADMIN. El archivo de configuración de PAM se ha de copiar en /etc/pam.d/emsrv. Junto con este release se incluye un archivo de configuración de PAM de ejemplo.

C.2.6.2 Instalación de EMSRV para Linux
En los pasos que siguen, el "usuario de EMSRV" es el usuario que inicia el programa EMSRV.

Debe copiar en su máquina los siguientes archivos del directorio TeamServer:

• emsrv 
• emadmin
• pam/emsrv

Coloque estos archivos en un subdirectorio que forme parte de la variable PATH o cree un subdirectorio y añádalo a variable PATH. Le sugerimos que los coloque en una ubicación que tenga una gran cantidad de espacio libre, porque el archivo emsrv.log se escribirá en el subdirectorio en el que coloque estos archivos.

Para configurar EMSRV en una máquina Linux, siga estos pasos:

1. El usuario de EMSRV o el administrador del sistema (root) reserva espacio en disco en donde almacenar los depósitos.
2. Se puede configurar un depósito inicial extrayendo lo siguiente del archivo ide.zip y poniéndolo en el espacio en disco reservado en el paso 1.
   • ivj.dat (archivo de depósito)
   • directorio ivj.dat.pr (directorio de recursos de proyecto)

   El archivo ide.zip está en el directorio ivj40\backup que se encuentra en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos).

   EMSRV debe poseer plenos derechos para leer, escribir y buscar en todo el árbol de directorios en el directorio ivj.dat.pr. El directorio ivj.dat.pr siempre se debe copiar en el mismo directorio que ivj.dat; de lo contrario, no se podrá acceder a los recursos de proyecto. Los directorios deben tener establecidos los bits rw y x (búsqueda) para el usuario de EMSRV.

3. Cambie el propietario del archivo para que pase a ser el usuario de EMSRV o el administrador del sistema. Si piensa tener más de un depósito, haga copias de ivj.dat utilizando distintos nombres, pero conserve la misma extensión (.dat). Si hace copias duplicadas del depósito, debe hacer copias duplicadas del directorio ivj.dat.pr y cambiarle el nombre para que coincida con el depósito al que está asociado. Por ejemplo, si hace una copia duplicada que se llama "team.dat", debe hacer un directorio de recursos de proyecto duplicado que se llame "team.dat.pr".
   El usuario de EMSRV o el administrador del sistema deben cambiar de directorio para ir a donde se almacenan los depósitos e iniciar el programa EMSRV utilizando los distintivos adecuados. Si desea obtener más información acerca de los distintivos de EMSRV, consulte el tema "Configuración y administración del servidor", en el archivo emsrv71.htm (emsrv70 para todos los idiomas, excepto el inglés), que encontrará en el directorio TeamServer\docs.
4. El usuario de EMSRV o el administrador del sistema indican a los miembros del equipo cuál es la ubicación y el nombre del depósito del equipo. Los miembros del equipo necesitarán esta información cuando instalen el código de cliente.
5. Para iniciar el servidor, siga las instrucciones que figuran en el tema "Configuración y administración del servidor" del archivo emsrv71.htm (emsrv70.htm para todos los idiomas que no sean el inglés).

En las plataformas UNIX, se requiere el acceso root para autenticar a los usuarios. Para ello, NO debe ser el usuario root quien inicie EMSRV. Si así se hiciera, quedaría comprometida la seguridad, ya que en ese caso EMSRV tendría pleno acceso a todos los sistemas de archivos.

Por el contrario, debe cambiar el propietario del ejecutable EMSRV por 'root' y establecer el bit SUID del ejecutable. Para ello, haga lo siguiente:

chown root emsrv
chmod u+s emsrv

EMSRV, cuando intenta autenticar un usuario, cambiará temporalmente la autorización del proceso EMSRV en ejecución para que pase a ser la autorización del propietario del ejecutable. Una vez llevada a cabo la autenticación, la autorización del proceso EMSRV en ejecución pasará a ser de nuevo la del usuario que inició EMSRV. Este mecanismo se produce por cada proceso (por cliente), para que así, mientras se esté autenticando un cliente, solo tenga acceso root temporal el proceso que sirve a ese cliente.

El acceso root es necesario para la autenticación sea cual sea la forma en la que EMSRV implemente realmente la autenticación. Las interfaces como PAM solo proporcionan una API común para permitir a las aplicaciones dar soporte a múltiples métodos de autenticación, si bien, deberá ser correcta la configuración específica de cada método de autenticación. 

C.3.0 Migración 

C.3.1 Migración desde la Versión 6.x o Versión 7.0 de EMSRV a la Versión 7.1

Si actualmente tiene instalada la Versión 6.x o la Versión 7.0 de EMSRV y desea instalar la Versión 7.1 de EMSRV, puede elegir entre desinstalar la versión 6.x/7.0 de EMSRV e instalar la Versión 7.1 o bien conservar la versión antigua de EMSRV e instalar EMSRV 7.1.

Debe instalar la Versión 7.1 para que funcione con VisualAge para Java, Versión 4.0. 

Para pasar de EMSRV, Versión 6.x/7.0, a EMSRV, Versión 7.1, siga estos pasos:

1. Haga una copia de seguridad del depósito.
2. Concluya EMSRV 6.x/7.0.
3. Instale EMSRV 7.1.
4. Inicie EMSRV 7.1. 

EMSRV 7.1 es compatible con EMSRV 6.x/7.0. Por ejemplo, si está trabajando en una edición anterior de VisualAge para Java (que emplea EMSRV 6.x/7.0), puede conectarse desde la versión anterior a un depósito compartido que se ejecute bajo EMSRV 7.1. 

C.4.0 Preparación para el desarrollo en equipo  

En este momento, ya ha instalado los programas del servidor de depósito y un depósito de código fuente compartido. Para terminar de configurar el entorno de desarrollo en equipo, debe iniciar el servidor, conectarse a él desde un cliente VisualAge para Java y añadir usuarios a la lista de usuarios del depósito.

Si ya ha instalado el cliente VisualAge para Java en una estación de trabajo, puede consultar la ayuda en línea para obtener más información acerca de cómo configurar el entorno de desarrollo en equipo. De lo contrario, consulte el team.pdf en el directorio pdf. El directorio pdf está situado en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos). Si no bajó el componente que contiene los PDF, no tendrá este directorio.

En las instrucciones que siguen, se presupone que el depósito compartido instalado en el servidor se llama ivj.dat. Al iniciar el programa servidor de depósito, el administrador debe proporcionar la vía de acceso del archivo ivj.dat como directorio de trabajo de EMSRV.

C.4.1 Preparación del servidor de equipo

Para que los desarrolladores en equipo puedan trabajar con el depósito compartido, es preciso que el administrador configure el servidor de VisualAge para Java y arranque el programa servidor de depósito EMSRV. Si algunos usuarios desean empezar a utilizar VisualAge para Java, Versión 4.0, antes de que esté listo el servidor, pueden hacer una primera instalación como usuarios autónomos y luego, más adelante, conectarse al depósito compartido.

C.4.2 Probar una conexión de cliente

Para confirmar que el servidor se ha iniciado satisfactoriamente, el administrador debe conectarse al depósito compartido desde un cliente VisualAge para Java, Enterprise Edition, Versión 4.0. Esta acción confirmará que la conexión TCP/IP del servidor funciona adecuadamente, que EMSRV se ha iniciado con los parámetros correctos y que el administrador conoce la información de servidor que se ha de proporcionar durante la instalación de cliente.

Para obtener información acerca de cómo conectarse a un depósito compartido, consulte "Conexión a un depósito compartido" en la ayuda en línea de VisualAge para Java o en el archivo team.pdf. El archivo team.pdf está en el directorio pdf. El directorio pdf está situado en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos). Si no bajó el componente que contiene los PDF, no tendrá este directorio.

C.4.3 Añadir usuarios a la lista de usuarios del depósito

Cuando un cliente se conecta por primera vez a un depósito compartido, se pide al usuario que proporcione un nombre de propietario de área de trabajo. El usuario no puede iniciar el IDE sin antes haber seleccionado un nombre válido de propietario de área de trabajo en la lista de usuarios del depósito.

Por omisión, VisualAge para Java, Versión 4.0, tiene un usuario llamado Administrador en la lista de usuarios del depósito. Cada usuario podría elegir inicialmente Administrador como nombre de propietario del área de trabajo; sin embargo, es altamente recomendable que cada usuario proporcione en seguida un nombre exclusivo para conectarse al servidor. En el entorno de desarrollo en equipo de VisualAge para Java, el control de cambios se basa en cometidos de usuario definidos, lo que implica que cada desarrollador debe tener una identificación exclusiva. Para satisfacer este objetivo, el administrador debe añadir todas las personas a la lista de usuarios del depósito. (El único usuario de VisualAge para Java que puede añadir a la lista los nombres de otros usuarios del depósito es el Administrador). El nombre exclusivo de cada usuario debe corresponder a un nombre de usuario del sistema si se utiliza la verificación de contraseña nativa.

Si desea información sobre cómo añadir usuarios a la lista del depósito, consulte el tema de equipo en la ayuda en línea de VisualAge para Java o bien el archivo team.pdf que está en el directorio pdf. El directorio pdf está situado en el CD de características adicionales de VisualAge para Java, Enterprise Edition. Si tiene una versión electrónica de VisualAge para Java, el directorio pdf estará en el directorio temporal (donde puso los componentes extraídos). Si no bajó el componente que contiene los PDF, no tendrá este directorio.

Ahora que el servidor está configurado y listo, los usuarios deben instalar los clientes de VisualAge para Java. La información sobre cómo instalar los clientes de equipo de VisualAge para Java está en la Parte B de esta guía.

C.5.0 Limitaciones y problemas conocidos (EMSRV) 

C.5.1 Rendimiento en conexiones de red de alta latencia y bajo ancho de banda

El protocolo empleado entre EMSRV y clientes EMSRV suele dar como resultado una tasa elevada de paquetes transmitidos al servidor. Ello se debe al hecho de que una gran parte del proceso se realiza en el cliente. La mayoría de las peticiones procesadas por EMSRV son peticiones de E/S (por ejemplo, peticiones de bloqueo de registro, de lectura y de escritura).

Como consecuencia de esta arquitectura, el rendimiento en el extremo del cliente es muy sensible a la latencia de la red. La latencia (que se mide por los tiempos de viaje de ida y vuelta o de paquete 'ping') que cabe esperar para que el rendimiento sea aceptable es de 5 ms. La latencia de LAN es en general menor que 1 ms, pero una conexión por WAN o una conexión por módem de marcación en una línea telefónica puede llegar a tener una latencia de hasta 500 ms. Incluso con las conexiones DSL, cable, frame relay o RDSI de alta velocidad, la latencia depende de la distancia entre los dos extremos.

En general, el rendimiento en una conexión por módem de marcación a través de una línea telefónica resulta inaceptable, ya que las conexiones de ese tipo suelen tener una latencia de 200 ms o más. Las conexiones de alta velocidad también dan un rendimiento inaceptable, a menos que la distancia entre el cliente y el servidor no supere algunos centenares de kilómetros.

El protocolo de EMSRV no necesita una actividad especialmente intensa de ancho de banda, pero la utilización del ancho de banda depende del número de clientes que empleen simultáneamente una conexión.

C.5.2 Limitaciones de la conexión TCP/IP

El límite por omisión de las conexiones de clientes con EMSRV es de 512. Este límite puede cambiarse utilizando la opción de línea de mandatos -M al iniciar EMSRV.

El número está limitado principalmente por la memoria, pero algunas pilas TCP/IP agotarán los sockets de corriente de datos antes de haberse alcanzado el límite de memoria. Este número suele ser superior a cien, pero varía con cada pila.

C.5.3 Detección de conexiones desactivadas inesperadamente

EMSRV utiliza un temporizador de mantenimiento de conexión (KEEPALIVE) TCP/IP para detectar las conexiones que se han desactivado inesperadamente cuando un cliente ha tenido una anomalía o ha rearrancado. Algunas pilas TCP/IP permiten que se cambie el tiempo de espera de KEEPALIVE. El valor por omisión suele ser de 120 minutos.

EMADMIN permite listar las conexiones e identificar una conexión que no haya interaccionado con el servidor durante largo tiempo en el momento de la última petición. En ese caso la conexión se puede cerrar mediante el mandato STOP y la opción -k de EMADMIN.

C.5.4 Intercambio de las distintas versiones de EMSRV y de los programas de utilidad de EMSRV

VisualAge para Java, Versión 4.0, incluye la versión 7.1 de EMSRV y la versión 7.0 de los programas de utilidad EMADMIN.

Deberá emplear EMADMIN 7.0 con EMSRV 7.1. EMADMIN 7.0 no funcionaría correctamente con los releases de EMSRV anteriores a 7.0.

C.5.5 Limitaciones de PAM

En las plataformas Linux y Solaris, la autenticación se implementa mediante PAM (módulos de autenticación de contraseñas). En teoría, aunque ello permitiría usar cualquier PAM (módulo) con EMSRV tan solo con cambiar el archivo de configuración de PAM relevante, no es posible hacerlo así en la práctica.

EMSRV no conversa con los clientes de una manera totalmente compatible con la arquitectura PAM. Como consecuencia, la autenticación de EMSRV solo funcionará cuando el módulo solicita inicialmente el texto de una contraseña (suministrada al principio por el cliente).

C.5.6 Las contraseñas contienen caracteres no ASCII no pueden utilizarse para autenticar con EMSRV 

Debido a un error en las bibliotecas de tiempo de ejecución de Microsoft C, cualquier contraseña que contenga caracteres no ASCII y que se especifique en respuesta a la solicitud:

'Entre la contraseña del usuario que inició EMSRV'

no se interpretará correctamente. La manera de soslayar este problema consiste en proporcionar la contraseña con la opción -p al ejecutar EMADMIN.

EMSRV para NetWare NLM utiliza NLM User Interface Developer Components (NWSNUT) de Novell. Al ejecutar en NetWare, los caracteres gráficos utilizados en los menús y las ventanas NWSNUT no están disponibles y aparecerán como caracteres corruptos. Esto no es un error de EMSRV NLM ni de NetWare, sino que es una limitación de la página de códigos Shift-JIS.

Cuando se utiliza EMADMIN 7.0 para copiar un depósito de VisualAge para Java 4.0, EMADMIN no copia el directorio de recursos de proyecto almacenado correspondiente. El directorio de recursos de proyecto almacenado se tiene que copiar manualmente.

Parte D. Información de migración específica de cada componente

Consulte la sección 18.0 para obtener información importante acerca de la migración de las clases Swing.

D.1.0 CICS Transaction Server (CICS TS)

Esta versión de VisualAge para Java no da soporte a CICS(R) Transaction Server. Las clases necesarias para dar soporte a la Versión 1.3 y anteriores de CICS TS no se han incluido en esta versión. Las aplicaciones CICS TS que intente migrar desde las versiones anteriores de VisualAge para Java no funcionarán en la Versión 4.0 y deben suprimirse del área de trabajo y del depósito de la Versión 4.0.

Si desea trabajar con CICS TS 1.3 o inferior, tendrá que seguir utilizando una versión más antigua (3.02 y anteriores) de VisualAge para Java. Por ahora, también debe utilizar una versión más antigua (3.02 y anteriores) de VisualAge para Java si desea emplear la interfaz JCICS o si necesita el soporte CICS para IIOP. No damos soporte a CICS Transactions Server porque está basado en JDK 1.1.x.

D.2.0 Data Access Beans

D.2.1. Migración desde la Versión 2.0 ó 3.0x de VisualAge para Java

Los beans de acceso a datos (Data Access Beans) utilizan los componentes y las interfaces de Swing. Toda aplicación desarrollada que emplee los beans se tendrá que migrar desde los paquetes Swing del antiguo JDK 1.1.x a los paquetes Swing del nuevo J2SDK v.1.2.2. Para ello, seleccione las clases y los paquetes implicados tras instalar VisualAge para Java, Versión 4.0, abra el SmartGuide Arreglar/Migrar y marque el recuadro de selección Incluir paquetes de JDK1.2 redenominados. Ello añadirá las correspondientes entradas De/A de Swing y le permitirá migrar automáticamente las referencias de Swing al SDK Java 2. Los errores que se produzcan mientras esté migrando aparecerán en la ventana Anotaciones.

Si desea más información sobre cómo migrar adecuadamente las aplicaciones, en el archivo de ayuda en línea del editor de composición visual hallará el tema "Directrices para arreglar/migrar referencias de clase o paquete" y, en el archivo de tarea relacionado, el tema "Reparar referencias de clase o paquete".

D.2.2. Migración desde la Versión 3.5 de VisualAge para Java

No es necesario que haga tareas adicionales para migrar los beans de acceso a datos (DAB) si ha hecho la migración de VisualAge para Java, Versión 3.5, ya que los beans de acceso a datos (DAB) de la Versión 3.5 utilizaban los paquetes Swing de J2SDK v.1.2.2.

D.3.0 Data Access Builder

Data Access Builder ya no se incluye en VisualAge para Java. Si desea seguir utilizando Data Access Builder, tendrá que continuar trabajando en una versión anterior de VisualAge para Java.

En VisualAge para Java, Versión 4.0, no se dispone de ninguna característica que reemplace directamente la funcionalidad que prestaba anteriormente Data Access Builder, pero existen tres componentes en VisualAge para Java que proporcionan una funcionalidad similar: Data Access Beans (que son los beans de acceso a datos), Persistence Builder y el entorno de desarrollo Enterprise JavaBeans. Cada característica ofrece un planteamiento diferente para crear clases de acceso a datos. 

No se puede migrar el código a VisualAge para Java, Versión 4.0, y reutilizarlo en cualquiera de estas herramientas. Tendrá que volver a crear sus aplicaciones si desea utilizarlas en la Versión 4.0. Utilice la característica que mejor se adapte a su interés principal en el desarrollo del código y a lo que desea que hagan sus aplicaciones.

Se proporciona, en forma de Apéndice de esta guía, una comparación de Data Access Builder, Data Access Beans y Persistence Builder. 

D.4.0 Entorno de desarrollo EJB(TM)

D.4.1 Migración de los beans enterprise de VisualAge para Java, Versión 2.0, Enterprise Update

Si ha creado beans enterprise en VisualAge para Java, Versión 2.0, Enterprise Update, y quiere usarlos en VisualAge para Java, Versión 4.0, deberá realizar las siguientes actividades en la versión actual de VisualAge para Java, Versión 2.0, Enterprise Update:

1. En el examinador de esquemas, guarde los esquemas que no se hayan guardado.
2. En el examinador de correlaciones, guarde las correlaciones que no se hayan guardado.
3. Si ha hecho cambios recientes en los esquemas o en las correlaciones desde la última vez que generó código desplegado, suprima el código desplegado y después regenérelo y pruébelo.
4. Cree una versión de los paquetes (incluidos los paquetes de esquemas y de correlaciones) y del proyecto; después, exporte el proyecto con formato .dat.

Para terminar de migrar el código de beans enterprise, vaya a VisualAge para Java, Versión 4.0, y siga los pasos del escenario 1 o del escenario 2 que figuran más abajo, en función de si está importando desde un depósito (opción recomendada) o desde un archivo JAR.

Escenario 1 - Importación desde un depósito
Si va a importar los beans desde un depósito, siga estos pasos:

1. Añada al área de trabajo los proyectos del depósito que contienen los beans enterprise, los esquemas y las correlaciones. Aparecerán iconos de error junto a algunas de las clases cargadas.
2. Cree una edición abierta de cada uno de los proyectos. Cree asimismo una edición abierta de los paquetes que contengan clases antiguas generadas.
3. Utilice el examinador de esquemas y el examinador de correlaciones para cargar en el área de trabajo todos los esquemas y todas las correlaciones disponibles; después, genere de nuevo las clases desplegadas.
4. Si no creó ni guardó un esquema y una correlación, cree un esquema y una correlación por omisión; luego, genere de nuevo el código desplegado.
5. Si tiene previsto trabajar solamente en la Versión 4.0, suprima las clases de cliente de prueba EJB que ya existan en la página Proyectos generada anteriormente con el entorno de desarrollo EJB de la Versión 2.0, Enterprise Update. Estas clases tendrán errores y no funcionarían en la Versión 4.0 porque el cliente de prueba EJB ya no emplea clases generadas (fíjese que las clases de cliente de prueba no aparecerán en el panel Tipos EJB de la página EJB antes de suprimirlas, por lo que tendrá que comprobar en la página Proyectos si existen clases para suprimir).

Puede hallar más información sobre cómo llevar a cabo estos pasos en la ayuda en línea de VisualAge para Java para el entorno de desarrollo EJB.

Escenario 2 - Importación desde un archivo JAR
Si exportó los beans enterprise a un archivo JAR, siga estos pasos:

1. En la página EJB, seleccione EJB > Importar beans enterprise para importar el archivo JAR al área de trabajo de VisualAge para Java, Versión 4.0.
2. Aparecerán iconos de error junto a muchas de las clases importadas, porque el archivo JAR no contendrá las correlaciones necesarias.
3. Genere de nuevo los esquemas, las correlaciones, las clases desplegadas y los clientes de prueba que tenga.
4. Si tiene previsto trabajar solamente en la Versión 4.0, suprima las clases de cliente de prueba EJB que ya existan en la página Proyectos generada anteriormente con el entorno de desarrollo EJB de la Versión 2.0, Enterprise Update. Estas clases tendrán errores y no funcionarían en la Versión 4.0 porque el cliente de prueba EJB ya no emplea clases generadas (fíjese que las clases de cliente de prueba no aparecerán en el panel Tipos EJB de la página EJB antes de suprimirlas, por lo que tendrá que comprobar en la página Proyectos si existen clases para suprimir).

Puede hallar más información sobre cómo llevar a cabo estos pasos en la ayuda en línea de VisualAge para Java para el entorno de desarrollo EJB.

D.4.2 Migración de beans enterprise de VisualAge para Java, Versión 3.0 ó 3.02

Si tiene un bean enterprise existente con código desplegado que se haya generado mediante VisualAge para Java, Versión 3.0 o Versión 3.02, y ahora quiere trabajar con el bean enterprise utilizando VisualAge para Java, Versión 4.0, deberá migrar el bean enterprise a la Versión 4.0 y luego suprimir y regenerar explícitamente el código desplegado.

Sin embargo, antes de migrar el código de bean enterprise a la Versión 4.0, tendrá que realizar estas actividades en la versión actual de VisualAge para Java (Versión 3.0 o Versión 3.02):

1. En el examinador de esquemas, guarde los esquemas que no se hayan guardado.
2. En el examinador de correlaciones, guarde las correlaciones que no se hayan guardado.
3. Si ha hecho cambios recientes en los esquemas o en las correlaciones desde la última vez que generó código desplegado, suprima el código desplegado y después regenérelo y pruébelo.
4. Cree una versión de los paquetes (incluidos los paquetes de esquemas y de correlaciones) y del proyecto; después, exporte el proyecto con formato .dat.

Para migrar el código de bean enterprise y luego regenerar el código desplegado, lleve a cabo estos pasos en VisualAge para Java, Versión 4.0, exactamente en el orden que se indica:

1. Importe el archivo de depósito de proyectos al área de trabajo.
2. Cree una edición abierta del proyecto. Cree asimismo una edición abierta de los paquetes que contengan el código desplegado que quiere suprimir.
3. En el entorno de trabajo, pulse la pestaña EJB.
4. En el panel Beans Enterprise, seleccione el bean enterprise o el grupo cuyo código desplegado desea suprimir.
5. Seleccione EJB > Suprimir.
6. Pulse Código desplegado para suprimir el código desplegado.
7. Migre las asociaciones (si las hubiera) siguiendo las instrucciones de la sección D.4.3 (si está migrando desde la Versión 3.0) o de la sección D.4.4 (si está migrando desde la Versión 3.02).
8. Asegúrese de que no hay ningún error en la clase bean ni en los padres de la clase bean.
9. Regenere los beans de acceso EJB (si los hubiera) siguiendo estos pasos:
   1. En la página EJB del entorno de trabajo, seleccione el bean enterprise asociado al bean de acceso que desea migrar.
   2. En el menú EJB, seleccione Añadir > Bean de acceso para abrir el SmartGuide Crear bean de acceso; después, pulse el botón Terminar. En el bean de acceso se realizarán automáticamente todos los cambios necesarios para la migración.
10. Regenere el código desplegado.
11. Si tiene previsto trabajar solamente en la Versión 4.0, suprima las clases de cliente de prueba EJB que ya existan en la página Proyectos generada anteriormente con el entorno de desarrollo EJB de la Versión 3.0 o 3.02. Estas clases tendrán errores y no funcionarían en la Versión 4.0 porque el cliente de prueba EJB ya no emplea clases generadas (fíjese que las clases de cliente de prueba no aparecerán en el panel Tipos EJB de la página EJB antes de suprimirlas, por lo que tendrá que comprobar en la página Proyectos si existen clases para suprimir).
12. Si creó anteriormente archivos JAR de cliente en VisualAge para Java, Versión 3.0, 3.02 ó 3.5, debe crearlos de nuevo en VisualAge para Java, Versión 4.0.

D.4.3 Migración de asociaciones EJB desde VisualAge para Java, Versión 3.0

Cuando se añade, edita o suprime una asociación de un grupo EJB creado en la Versión 3.0, VisualAge para Java convierte automáticamente todas las asociaciones del grupo EJB, dándoles el nuevo formato de asociación. Para completar el proceso de migración, realice estos cambios de forma manual:

• Añada una llamada a this._initLinks() en los métodos ejbCreate (todas las variaciones), ejbActivate y ejbLoad de la clase bean. Recuerde que también debe añadir esta llamada a todas las variaciones futuras de ejbCreate que se añadan a la clase bean.
• Añada una llamada a this._removeLinks() en el método ejbRemove de la clase bean.

Estos métodos no se convirtieron automáticamente debido a la alta probabilidad de que se hayan hecho modificaciones escritas a mano en estos métodos. VisualAge para Java añadirá las llamadas de forma automática cuando se creen beans nuevos en la Versión 4.0.

Si importa un bean de entidad CMP de la Versión 3.0, o más antiguo, a un grupo EJB cuyas asociaciones ya se han migrado y, después, añade un nuevo bean que sea heredero del bean de entidad CMP importado, la clase bean del nuevo bean visualizará símbolos X de color rojo en varios métodos. Ello se debe a que a la clase bean del bean importado le faltan los métodos _initLinks, _getLinks y _removeLinks. Deberá añadir a la clase bean del bean importado estos métodos a mano.   

Cuando esté listo para desplegar el código del bean enterprise en un servidor de aplicaciones de producción, debe tener presente que también ha de desplegar el archivo JAR de tiempo de ejecución que contiene el código de tiempo de ejecución necesario para las asociaciones y para los beans de acceso. Este archivo JAR debe desplegarse en el servidor de aplicaciones e incluirse en la vía de acceso de clases de dicho servidor de aplicaciones. En la ayuda en línea de entorno de desarrollo EJB hallará información adicional acerca del archivo JAR de tiempo de ejecución.

D.4.4 Migración de asociaciones EJB desde VisualAge para Java 3.02

Cuando abra por primera vez un grupo EJB cuyas asociaciones se hayan creado en la Versión 3.02 de VisualAge para Java, el grupo contendrá iconos de error junto a las clases de enlace generadas. Cuando se añade, edita o suprime una asociación en este tipo de grupo EJB, VisualAge para Java repara automáticamente las clases de enlace de todas las asociaciones del grupo EJB. Aunque no pretenda hacer cambios en la asociación, deberá seleccionar la asociación en el panel Propiedades de la página EJB, y seleccionar Editar en el menú emergente correspondiente para abrir el editor de asociaciones. Deberá pulsar Aceptar para completar el proceso de migración.

VisualAge para Java eliminará de forma automática algunos métodos relacionados con asociaciones y generados en la Versión 3.02 de VisualAge para Java. Los métodos que se eliminan son los que, dadas las características de la asociación, no funcionarían correctamente en la Versión 4.0. Por ejemplo, supongamos un cometido que forme parte de la clave primaria; en tal caso, el método set de ese cometido no sería válido. Ese método se habría generado automáticamente en la Versión 3.02, y no se puede generar en la Versión 4.0.

D.5.0 Enterprise Access Builder (EAB) y e-connectors  

D.5.1 Enterprise Access Builder

D.5.1.1 Nuevo soporte de conector
Ahora, Enterprise Access Builder da soporte al conector Common Connector Framework (CCF) y al conector de la arquitectura de conectores Java 2, Enterprise Edition (J2EE). En Enterprise Access Builder hay nuevas herramientas que migrarán los registros, los mandatos, los navegadores y los beans de sesión de EAB desde un formato CCF a un formato de arquitectura de conectores J2EE. Además, se han actualizado los siguientes SmartGuides y editores para reflejar el nuevo soporte de la arquitectura de conectores J2EE:

• SmartGuide de mandatos.
• Editor de mandatos.
• SmartGuide de bean de sesión.
• Editor de bean de sesión.

Hallará más información sobre el nuevo soporte para IBM Connectors and Tools para J2EE(TM) - Beta y los nuevos migradores de EAB en la ayuda en línea de Enterprise Access Builder.

D.5.1.2 Regeneración y edición de los registros y los mandatos
Si migra a la Versión 4.0 las aplicaciones EAB de una versión anterior de VisualAge para Java, tal vez le convenga regenerar los registros (objetos Record) y los mandatos (objetos Command). Si los regenera, estos objetos se ejecutarán mejor en la Versión 4.0. 

Anteriormente, si hubiera seleccionado "Direct" y "Shorten names", sin seleccionar "Inner classes", los nombres de los registros generados
a veces serían más grandes de lo necesario. Esto hacía que en ocasiones los nombres generados excedieran el límite de 255 caracteres para nombres de archivo en Windows. El SmartGuide Crear registro a partir de tipo de registro se ha optimizado para generar nombres tan cortos como sea posible cuando se seleccionen las opciones anteriores. Sin embargo, sus aplicaciones se pueden ver afectadas si se regenera con estas opciones, dado que los nombres de registro pueden cambiar.

Si el mandato EAB se creó en la Versión 2.0x, no podrá editarlo en el editor de mandatos. Sin embargo, sí podrá editarlo en el editor de composición visual. La versión actual del código de tiempo de ejecución es compatible con las versiones anteriores, por lo que puede ejecutar con ella los mandatos de la Versión 2.0x.

D.5.1.3 Despliegue de las aplicaciones
La Versión 4.0 es un release de transición para Enterprise Access Builder (EAB). La arquitectura Common Connector Framework (CCF), más antigua y que sirvió de base para EAB, se está transformando en la nueva arquitectura de conectores J2EE. La documentación de EAB explica esta transición y las diferencias que hay entre ellas. En este release están soportadas las dos arquitecturas. En la fase de despliegue, esta transición lleva implícitas algunas diferencias. Los detalles al respecto se encuentran en la sección de despliegue de la documentación de EAB. El párrafo que sigue es una simple visión general del despliegue.

En el caso de las aplicaciones existentes, puede seguir trabajando como lo ha hecho hasta ahora. Despliegue las aplicaciones con los archivos eab\runtime30\eablib.jar, ccf.jar, recjava.jar y con el archivo JAR que se necesita para el conector en el momento de la ejecución. En el caso de las aplicaciones nuevas a las que se hayan añadido algunos componentes relacionados con la arquitectura de conectores J2EE (como pueden ser registros y mandatos que hicieran servir la arquitectura J2EE), despliegue las aplicaciones con el archivo eab\runtime35\eablib.jar. Este archivo es bimodal, o sea, que da soporte a las dos arquitecturas. Además, necesitará otros archivos JAR que solo están relacionados con J2EE y que se especifican en la sección de la documentación EAB dedicada al despliegue.

D.5.2 E-Connectors

Esta sección facilita información sobre la migración de IMS Connect, CICS Connector y e-connector.

Importante: debido a una limitación en el soporte del sistema de archivos del CD-ROM (CDFS) en Windows 98, es posible que falle la instalación de determinados archivos de conectores de e-business del CD-ROM y que, en consecuencia, se visualicen uno o varios de los diálogos de error siguientes, dependiendo de los conectores seleccionados:

• Las copias de ENCINA VAJ.RUL DELCon* han fallado
• Las copias de ENCINA VAJ.RUL Deligh* han fallado
• ENCINA VAJ.RUL Drpc*
• ENCINA VAJ.RUL Transaction*
• La copia del archivo *.* de HOD VAJ.RUL ha fallado *.*

Los archivos que no se hayan instalado están almacenados en un archivo zip (econnfix.zip) ubicado en el directorio raíz del CD del producto. Si está intentando instalar VisualAge para Java en Windows 98 y recibe cualesquiera de los mensajes anteriores, debe descomprimir el archivo econnfix.zip en el directorio en el que se instaló el producto (por ejemplo, ejecutando el mandato unzip econnfix.zip -d c:\Archivos de programa\IBM\VisualAge para Java\ donde c:\Archivos de programa\IBM\VisualAge para Java\ es el directorio de instalación del producto). Una vez copiados estos archivos, los conectores funcionarán correctamente.

D.5.2.1 IMS Connect
El soporte para IMS TOC (IMS TCP/IP OTMA Connection) se suspenderá en marzo de 2001. Recomendamos a los usuarios que migren desde IMS TOC a IMS Connect, y que utilicen este último producto, en vez de IMS TOC.

IMS Connect es un producto IBM instalable en SMP y disponible por separado (no está incluido en VisualAge para Java) que se puede utilizar juntamente con IMS Connector de VisualAge para Java para acceder a IMS. Tras haber migrado desde IMS TOC a IMS Connect, se pueden seguir usando todos los programas de IMS Connector para Java; no es necesario cambiarlos ni actualizarlos.

D.5.2.2 CICS Connector
Se ha modificado el comportamiento del distintivo CICSELUW de la especificación ECIInteractionSpec para modelar correctamente la arquitectura de conectores CCF. En los releases anteriores, este distintivo tomaba por omisión el valor FALSE en el constructor y, estuviese o no presente un coordinador real, siempre determinaba si la LUW era ampliada.

En este release, el distintivo CICSELUW toma por omisión el valor TRUE en el constructor ECIInteractionSpec si está presente un coordinador CCF real (por ejemplo, JavaCoordinator). A menos que se haya establecido específicamente esta propiedad en el código antiguo de VisualAge para Java, ahora la propiedad CICSELUW del código antiguo tomará por omisión el valor TRUE, una vez que se haya migrado a VisualAge para Java, Versión 4.0.

Cuando no está presente ningún coordinador real, este distintivo se pasa por alto y todas las aplicaciones (las antiguas y las nuevas que se creen en VisualAge para Java, Versión 4.0) se comportarán como si el distintivo CICSELUW tuviese el valor FALSE. Por lo tanto, el hecho de establecer específicamente este distintivo no tendrá ningún efecto a menos que se emplee un coordinador real en el entorno.

D.5.2.3 Migración de e-connector
Si bien la mayoría de las versiones anteriores de VisualAge para Java pueden coexistir con la Versión 4.0.x, no se da soporte a la coexistencia de diferentes niveles de e-connector.

Migración desde VisualAge para Java, Versión 3.0x o Versión 3.5.x

Si tiene instalados e-connectors, debe ajustarse a uno de los dos siguientes escenarios de migración para migrar satisfactoriamente desde una versión 3.0x o 3.5.x de VisualAge para Java a la Versión 4.0.x.

La diferencia entre los dos escenarios de migración es la fase en la que se migran los conectores.

En el escenario 1, los conectores se migran durante el proceso de instalación inicial. Después de completar los pasos de este escenario, tendrá VisualAge para Java, Versión 3.0x o 3.5.x sin conectores coexistiendo con VisualAge para Java, Versión 4.0 con conectores.

En el escenario 2, los conectores se migran después del proceso de migración inicial. Después de completar los pasos de este escenario, tendrá VisualAge para Java, Versión 4.0 sin conectores coexistiendo con VisualAge para Java, Versión 3.0x o 3.5.x, con conectores. Posteriormente, puede desinstalar los conectores de la Versión 3.0x o 3.5.x e instalar los conectores de la Versión 4.0.

Escenario de migración 1

1. Cree una versión de todos los proyectos de la Versión 3.0x o 3.5.x que contienen conectores o código EAB.
2. Exporte estos proyectos y recursos relacionados a un directorio fuera del árbol de instalación de VisualAge para Java.
3. Elimine todos estos proyectos del área de trabajo 3.0x o 3.5.x.
4. Elimine todas las características de CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina(R), IMS(TM) y MQSeries(R) del área de trabajo.
5. Salga del IDE de la Versión 3.0x o 3.5.x.
6. Desinstale los conectores para VisualAge para Java, Versión 3.0x o 3.5.x, siguiendo estos pasos:
   1. En el menú Inicio de Windows, seleccione Inicio > Configuración > Panel de control.
   2. Pulse dos veces Agregar o quitar programas. Seleccione la pestaña Instalar o desinstalar.
   3. Seleccione IBM Connectors. Pulse Agregar o quitar.
   4. Confirme que desea desinstalar los conectores y los componentes relacionados con ellos.
   5. Pulse Aceptar en la ventana Quitar programas.

7. Para impedir que surjan conflictos y errores en las futuras instalaciones de conectores, las variables de entorno no deben contener ninguna referencia a los conectores eliminados. Para editar las variables de entorno:

   Windows NT y Windows 2000

   1. En el menú Inicio, seleccione Configuración > Panel de control.
   2. Pulse dos veces el icono Sistema. Seleccione la pestaña Entorno.
   3. En CLASSPATH, PATH y NLS PATH, suprima toda referencia a IBM Connectors o a IBM\Connectors.

   Windows 98

   1. Haga copia de seguridad del archivo c:\autoexec.bat
   2. En el indicador de mandatos, entre edit c:\ autoexec.bat 
   3. En las sentencias SET CLASSPATH, SET PATH y SET NLS PATH, suprima las referencias que se hagan a IBM Connectors o a IBM\Connectors.
8. Instale VisualAge para Java, Versión 4.0.
9. Añada las características deseadas de CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina, IMS y MQSeries al área de trabajo de la Versión 4.0.
10. Importe los proyectos al área de trabajo de la Versión 4.0 para terminar de migrar el código de 1.1.x. Si utiliza SAP R/3 Access Builder y Connector, vea la nota que hay al final de estos pasos. 
11. Puede desinstalar VisualAge para Java, Versión 3.0x o 3.5.x, después de haber migrado el código que desee conservar a VisualAge para Java 4.0. 

Access Builder y Connector para SAP R/3 también proporcionan algunas clases de utilidades (por ejemplo, LogonBean) basadas en Swing 1.0.3. Estas clases se sustituyen por clases basadas en Swing 1.1. Cuando se migra desde la Versión 3.0x o 3.5.x a la Versión 4.0, tendrá que migrar sus propias clases basadas en Swing 1.0.3 al nivel 1.1 para seguir utilizando las clases de utilidades proporcionadas por Access Builder y Connector para SAP R/3. Puede utilizar la herramienta Arreglar/Migrar del IDE para este proceso.

Escenario de migración 2

1. Instale VisualAge para Java, Versión 4.0, sin instalar Enterprise Access Builder para transacciones:
   1. Instale VisualAge para Java, Versión 4.0. Siga las instrucciones de la pantalla.
   2. En la página Tipo de configuración, seleccione Personalizada. Pulse Siguiente.
   3. Seleccione todos los componentes que desea instalar, pero no seleccione Access Builder para transacciones. Pulse Siguiente cuando haya terminado de seleccionar los componentes que desea instalar. Si ha vuelto a la pantalla de instalación después de intentar instalar Access Builder para transacciones y no desea instalar los conectores, quite la marca del recuadro de selección Access Builder para transacciones y pulse Siguiente.
   4. Siga las instrucciones que aparecen en pantalla para completar la instalación.
      Puede continuar trabajando con los conectores para VisualAge para Java, Versión 3.0x o 3.5.x.

Cuando desee instalar los conectores de VisualAge para Java, Versión 4.0, debe desinstalar la Versión 3.0x/3.5.x o  desinstalar los conectores de 3.0x/3.5.x siguiendo los pasos indicados en el escenario de migración 1. Una vez que haya desinstalado los conectores de la Versión 3.0x/3.5.x o VisualAge para Java, Versión 3.0x/3.5.x, podrá instalar los conectores para la Versión 4.0 siguiendo estos pasos:

1. Instale VisualAge para Java, Versión 4.0. Siga las instrucciones de la pantalla.
2. En la página Mantenimiento de programa, seleccione Modificar. Pulse Siguiente.
3. Seleccione Transaction Access Builder. Pulse Siguiente y siga las instrucciones de la pantalla para continuar instalando el componente.
4. Añada los conectores al IDE de VisualAge para Java. Consulte la ayuda en línea para obtener información acerca de cómo realizar esta tarea.

Migración desde VisualAge para Java, Versión 3.5 o Versión 3.5.3

Cuando se migra desde VisualAge para Java, Versión 3.5 ó 3.5.3 a VisualAge for Java, Versión 4.0, es necesario desinstalar IBM Connectors instalado con VisualAge para Java 3.5 ó 3.5.3 para asegurarse de que se instala la versión correcta de IBM Connectors con VisualAge para Java 4.0.

Si intenta instalar VisualAge para Java, Versión 4.0, antes de eliminar IBM Connectors de la Versión 3.5 ó 3.5.3, se visualiza un diálogo indicando que debe migrar primero todas las aplicaciones que utilicen IBM Connectors antes de continuar con la instalación de la Versión 4.0.

Para migrar las aplicaciones y desinstalar IBM Connectors de la Versión 3.5 ó 3.5.3, siga estos pasos.

1. Cree una versión de todos los proyectos de la Versión 3.5 ó 3.5.3 que contienen conectores o código EAB.
2. Exporte estos proyectos y recursos relacionados a un directorio fuera del árbol de instalación de VisualAge para Java.
3. Elimine todos estos proyectos del área de trabajo 3.5 ó 3.5.3.
4. Elimine todas las características de CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina, IMS y MQSeries del área de trabajo.
5. Salga del IDE de la Versión 3.5 ó 3.5.3.
6. Desinstale los conectores para VisualAge para Java, Versión 3.5 ó 3.5.3, siguiendo estos pasos:
   1. En el menú Inicio de Windows, seleccione Inicio > Valores > Panel de control.
   2. Pulse dos veces Agregar o quitar programas. Seleccione la pestaña Instalar o desinstalar.
   3. Seleccione IBM Connectors. Pulse Agregar o quitar.
   4. Confirme que desea desinstalar los conectores y los componentes relacionados con ellos.
   5. Pulse Aceptar en la ventana Quitar programas.

7. Para impedir que surjan conflictos y errores en las futuras instalaciones de conectores, las variables de entorno no deben contener ninguna referencia a los conectores eliminados. Para editar las variables de entorno:

   Windows NT y Windows 2000

   1. En el menú Inicio, seleccione Configuración > Panel de control.
   2. Pulse dos veces el icono Sistema. Seleccione la pestaña Entorno.
   3. En CLASSPATH, PATH y NLS PATH, suprima toda referencia a IBM Connectors o a IBM\Connectors.

   Windows 98

   1. Haga copia de seguridad del archivo c:\autoexec.bat
   2. En el indicador de mandatos, entre edit c:\ autoexec.bat 
   3. En las sentencias SET CLASSPATH, SET PATH y SET NLS PATH, suprima las referencias que se hagan a IBM Connectors o a IBM\Connectors.
8. Instale VisualAge para Java, Versión 4.0.
9. Añada las características deseadas de CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina, IMS y MQSeries al área de trabajo de la Versión 4.0.

Desinstalación de conectores

Windows NT y Windows 2000

1. En el menú Inicio, seleccione Configuración > Panel de control.
2. Pulse dos veces el icono Sistema. Seleccione la pestaña Entorno.
3. En CLASSPATH, PATH y NLS PATH, suprima toda referencia a IBM Connectors o a IBM\Connectors.

Windows 98

1. Haga copia de seguridad del archivo c:\autoexec.bat
2. En un indicador de mandatos, entre edit c:\ autoexec.bat 
3. En las sentencias SET CLASSPATH, SET PATH y SET NLS PATH, suprima las referencias que se hagan a IBM Connectors o a IBM\Connectors.

Solo para Windows 98: debe suprimir manualmente el directorio e-connectors (que, por omisión, es C:\IBM Connectors) después de desinstalar VisualAge para Java. 

D.6.0 Enterprise Toolkit para AS/400 (ET/400)

D.6.1 Migración desde la Versión 2.0 de VisualAge para Java

Las clases que se generaron utilizando Enterprise Toolkit para AS/400 con VisualAge para Java, Versión 2.0, no son compatibles con las clases Java generadas mediante Enterprise Toolkit para AS/400 con VisualAge para Java, Versión 4.0. La razón de esta incompatibilidad consiste en que las clases Java de ET/400 de la Versión 2.0 utilizadas en AWT (Abstract Windowing Toolkit) y las clases Java de ET/400 de la Versión 4.0 emplean Java 2 SDK Swing.

Sin embargo, las clases que se proporcionaron junto con la Versión 2.0 aún están en el paquete com.ibm.ivj.et400.util.awt, que se proporciona con VisualAge para Java, Versión 4.0. Si desea utilizar en VisualAge para Java, Versión 4.0, las clases que se generaron en la Versión 2.0, tendrá que cambiar las referencias de las clases de la Versión 2.0 del paquete com.ibm.ivj.et400.util por el paquete com.ibm.ivj.et400.util.awt. Este cambio lo podrá hacer si utiliza el SmartGuide Arreglar/Migrar proporcionado junto con VisualAge para Java. Los errores que se produzcan mientras esté migrando aparecerán en la ventana Anotaciones. Consulte la ayuda en línea para obtener información acerca de cómo utilizar este SmartGuide.

D.6.2 Migración desde la Versión 3.0 ó 3.02 de VisualAge para Java

Si ha generado clases Java utilizando el SmartGuide Convertir archivo de pantalla de ET/400 con VisualAge para Java, Versión 3.0 ó 3.02, estas clases no serán compatibles con las clases Java generadas utilizando el SmartGuide Convertir archivo de pantalla de ET/400 de VisualAge para Java, Versión 4.0. 

El motivo de esta incompatibilidad es que el código generado en las Versiones 3.0 y 3.02 emplea clases obsoletas, como las clases AS400SVisualTextField y Subfile, mientras que el código generado en la Versión 4.0 emplea beans JFormatted. Aún podrá encontrar todas las clases obsoletas en el paquete com.ibm.ivj.et400.util, que se incluye en VisualAge para Java, Versión 4.0. Si desea usar las clases generadas en las Versiones 3.0 ó 3.02, tendrá que emplear la herramienta Arreglar/Migrar para convertir todas las clases migradas de tal manera que hagan referencia a los nombres del nuevo paquete Java 2 SDK Swing. Para ello, seleccione las clases implicadas, abra la herramienta Arreglar/Migrar y marque el recuadro de selección Incluir paquetes de JDK 1.2 redenominados. Ello hará migrar automáticamente las referencias Swing al Java 2 SDK. Consulte la ayuda en línea para obtener más información acerca de esta tarea. Los errores que se produzcan mientras esté migrando aparecerán en la ventana Anotaciones.

El SmartGuide Crear subarchivo no se incluye junto con VisualAge para Java, Versión 4.0. Se ha sustituido por los beans DFU y por el bean JFormattedTable, que son más potentes. Si desea continuar utilizando el SmartGuide Crear subarchivo para generar código, tendrá que seguir trabajando con una versión anterior (3.02 o inferior) de VisualAge para Java. Todo el código que se genere mediante el SmartGuide Crear subarchivo en las Versiones 3.0 ó 3.02 se puede migrar a la Versión 4.0, ya que las clases necesarias para el código generado aún están soportadas y se encuentran en el paquete com.ibm.ivj.et400.util Debe seguir los mismos pasos que se documentan en el párrafo anterior si desea migrar su código. 

D.7.0 Enterprise Toolkit para OS/390 (ET/390)

La versión de ET/390 que debe utilizar para desarrollar aplicaciones de OS/390 depende del nivel de SDK que esté disponible en los sistemas OS/390 o en las aplicaciones de middleware, y del nivel de SDK soportado por VisualAge para Java (incluido ET/390).

En los sistemas OS/390 y en las aplicaciones de middleware, están disponibles dos niveles de SDK, como se indica en esta tabla:

En VisualAge para Java, las distintas versiones del producto dan soporte a distintos niveles de SDK, como se indica en esta tabla:

Las siguientes secciones explican los tipos de aplicaciones de OS/390 que se pueden desarrollar con las distintas versiones de ET/390.

VisualAge para Java, Versiones 3.5, 3.5.3 y 4.0

ET/390 en VisualAge para Java, Versiones 3.5, 3.5.3 y 4.0, está destinado principalmente a los siguientes tipos de aplicaciones:

• Aplicaciones interpretadas que se ejecutan en WebSphere Application Server, Versión 3.0, con SDK 1.1.8. En este entorno, podrá crear, exportar, ejecutar y depurar sus aplicaciones.
• Aplicaciones interpretadas autónomas que se ejecutan en OS/390 con SDK 1.3.0. En este entorno, podrá crear, exportar y ejecutar sus aplicaciones.

En el caso de las aplicaciones interpretadas que se ejecutan en WebSphere Application Server, Versión 3.0, debe crear sus clases de aplicación para que funcionen con las API Java en el nivel de SDK 1.1.8. Una vez creadas, puede exportar las clases a una unidad montada en NFS para que estén disponibles en el sistema OS/390. Luego, puede ejecutar y depurar la aplicación pulsando los elementos de menú Ejecutar main y Depurar main en el IDE de VisualAge para Java.

En el caso de las aplicaciones interpretadas autónomas que se ejecutan en el sistema OS/390, debe crear sus clases de aplicación para que funcionen con las API Java en el nivel de SDK 1.3.0. Una vez creadas, puede exportar las clases a una unidad montada en NFS para que estén disponibles en el sistema OS/390. Luego, puede ejecutar la aplicación pulsando el elemento de menú Ejecutar main en el IDE de VisualAge para Java.

En la ayuda en línea de ET/390 hallará los detalles de cómo construir, exportar, ejecutar y depurar aplicaciones interpretadas.

VisualAge para Java, Versión 3.02

ET/390 en VisualAge para Java, Versión 3.0.2, está destinado principalmente a los siguientes tipos de aplicaciones:

• Transacciones compiladas e interpretadas que se ejecutan en CICS Transaction Server, Versión 1.3, con SDK 1.1.8 
• Procedimientos almacenados compilados que se ejecutan en DB2 Universal Database, Versiones 5 y 6, con SDK 1.1.8
• Aplicaciones interpretadas autónomas que se ejecutan en OS/390 con SDK 1.1.8

D.8.0 Enterprise Toolkit para estaciones de trabajo (ET/WS)

Enterprise Toolkit para estaciones de trabajo (ET/WS) y el compilador de alto rendimiento (HPJ) no se han incluido en este release de VisualAge para Java. Si aún quiere utilizar Enterprise Toolkit para estaciones de trabajo, tendrá que seguir trabajando en una versión anterior (3.02 0 inferior) de VisualAge para Java.

En VisualAge para Java, Versión 4.0, no se dispone de ninguna nueva característica que reemplace la funcionalidad que presentaba ET/WS. Podría encontrar una funcionalidad similar a la de ET/WS en el compilador "Just-in-time", que forma parte de la máquina virtual Java. La máquina virtual Java se incluye junto con IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9.

El compilador JIT toma el bytecode, lo compila en código de ejecución directa y luego ejecuta los programas. El bytecode se conserva y sigue siendo portable; sin embargo, el código (tras haber sido compilado por JIT) se ejecuta con mayor rapidez. Si desea más información, puede visitar el sitio web de Sun(TM), en http://java.sun.com.

D.9.0 Control de versiones externo 

Si migra VisualAge para Java desde la Versión 3.5 a la Versión 4.0, podrá seguir utilizando la herramienta Control de versiones externo en los proyectos con los que la estaba utilizando en la versión 3.5. Si al principio no aparecen los iconos de la herramienta Control de versiones externo, realice la acción Herramientas > Control de versiones externo > Renovar proyecto y entonces aparecerán.

Puede ser que necesite reiniciar la API de acceso remoto a herramientas, que se hace desde el diálogo Opciones. Seleccione Ventanas > Opción para abrir el diálogo Opciones. Seleccione la API de acceso remoto a herramientas y pulse el botón API de acceso remoto a herramientas para iniciarla.

D.10.0 Entorno de desarrollo IDL

Si ha estado utilizando el compilador IDL a Java proporcionado por la característica IBM Component Broker Series o la característica CICS IIOP Server Support, tendrá que definir manualmente la serie de invocación del compilador IDL a Java en estos diálogos:

La página Compilación IDL a Java del diálogo Opciones (a la que se accede desde el menú Ventana). Modifique la serie en el campo Mandato.

El diálogo Cambiar opciones de compilación IDL a Java. En la página IDL, seleccione IDL > Cambiar opciones de compilación. Modifique la serie del campo Mandato.

Si desea más información sobre cómo modificar la serie y abrir la página IDL, consulte la documentación en línea del entorno de desarrollo IDL.

Consulte la sección 1.0 de la Parte D para obtener información acerca del soporte CICS IIOP.

D.11.0 Entorno de desarrollo integrado

El nivel de JDK ha cambiado desde la Versión 3.5 (ahora es JDK 1.2.2 PTF 9).

Si ha modificado la biblioteca de clases Java de VisualAge para Java, Versión 3.5, sustituyendo paquetes o clases de la biblioteca o añadiendo paquetes y clases a la biblioteca, esas modificaciones no se reproducirán automáticamente en la biblioteca de clases Java de la Versión 4.0 después de la migración; tendrá que volver a modificar manualmente la biblioteca de clases Java. 

La biblioteca de clases Java era completamente de solo lectura en VisualAge para Java antes de la Versión 3.5.

D.12.0 Entorno de desarrollo JSP/Servlet

Si está migrando desde una versión anterior de VisualAge para Java a VisualAge para Java, Versión 4.0, los dos archivos siguientes serán sustituidos por las nuevas versiones y se perderán los cambios que haya realizado en ellos:

• ide\project_resources\IBM WebSphere Test Environment\hosts\default_host\default_app\servlets\default_app.webapp
• ide\project_resources\IBM WebSphere Test Environment\properties\default.servlet_engine

Puede realizar copias de seguridad de estos archivos antes de migrar a la Versión 4.0 y añadir los cambios a las nuevas versiones de los archivos una vez terminada la migración a VisualAge para Java, Versión 4.0. No debe copiar simplemente las versiones antiguas de los archivos sobre las versiones nuevas porque estas últimas contienen  información que no está en los archivos antiguos.

D.13.0 El asistente en la migración para ActiveX

El asistente en la migración para ActiveX no se incluye en este release de VisualAge para Java. Puede migrar el código creado con el asistente de migración en las versiones anteriores (3.02 o inferior) de VisualAge para Java a la Versión 4.0, siguiendo los pasos generales de migración que se indican en la Parte B. No hay ninguna característica nueva en VisualAge para Java, Versión 4.0, que sustituya a esa funcionalidad proporcionada anteriormente por el asistente de migración para ActiveX. 

D.14.0 Persistence Builder  

Nota: no es necesario aplicar el FixPak 3.5.1 ni el FixPak 3.5.2 de Persistence Builder (disponible en VADD) a VisualAge para Java, Versión 4.0. Estos arreglos ya se han incorporado en el código de la Versión 4.0.

Debe utilizar VisualAge para Java con el fin de generar de nuevo el código de los releases anteriores de Persistence Builder.

D.14.1 Actualización específica desde la Versión 2.0

Las siguientes cuestiones de migración son especialmente indicadas para usted si va a actualizar desde VisualAge para Java, Versión 2.0:

1. Cree una versión de todos los proyectos pertenecientes a las aplicaciones de Persistence Builder.
2. Cuando haya migrado el código a VisualAge para Java, Versión 4.0, añada sus proyectos al área de trabajo de la Versión 4.0. Encontrará problemas relacionados con las clases de servicio, porque determinados conversores ya no se incluyen en VisualAge para Java. Para solucionar estos problemas, genere las "Interfaces y clases de servicio de datos" para su modelo de objeto, y los problemas los resolverán los servicios de generación de código. 
3. La superclase para conversores se ha desplazado al proyecto: VisualAge Persistence Common Runtime. Es preciso cambiar la superclase de sus compositores por: com.ibm.vap.converters.VapAbstractConverter.
4. La superclase de compositor también se ha desplazado a un nuevo proyecto. Tendrá que cambiar la superclase de sus compositores por: com.ibm.vap.composers.VapAttributeComposer

Para obtener más información acerca de cómo realizar estos pasos, consulte la documentación en línea para Persistence Builder.

D.14.2 Actualización desde todas las versiones anteriores (incluyendo la Versión 2.0) 

Cuando se cargan modelos, correlaciones o esquemas disponibles desde los examinadores de modelos, cambia el aspecto interno de los metadatos. Entonces no se pueden cargar de manera fiable los metadatos en un área de trabajo cuyo nivel de release sea inferior a la Versión 4.0. El modelo, la correlación o el esquema aparecerá como desechable (dirty). Guarde el modelo, la correlación o el esquema.

Nota: la siguiente información solo es aplicable si se va a migrar desde la Versión 2.0 ó 3.0x de VisualAge para Java. No es aplicable si se está migrando desde la Versión 3.5.

Las clases creadas en releases anteriores para consultas personalizadas tendrán errores. La infraestructura de consulta personalizada lanza ahora un objeto Throwable, a fin de permitirle que capture las excepciones que aparecen cuando se llama a la consulta personalizada. Como resultado, todas las consultas personalizadas preexistentes aparecerán en el IDE como si contuviesen un error no resuelto (con una X en rojo), ya que no manejan la excepción lanzada. Para corregir esta situación, lance la excepción desde su consulta personalizada o capture la excepción.

Encontrará más información acerca de cómo solucionar errores en la ayuda en línea de VisualAge para Java.

Cambios en el soporte de tiempo de ejecución 
Ha cambiado el nombre del proyecto que contiene los paquetes javax prerrequisitos de la unidad ejecutable Persistence Builder. Debido a esto, tal vez sea necesario que vuelva a calcular la vía de acceso del proyecto para los elementos del programa que utilizan Persistence Builder, de la siguiente forma:

1. Seleccione la clase.
2. En el menú Seleccionado o en el menú emergente de la clase seleccione Ejecutar > Comprobar vía de acceso de clases.
3. Pulse el botón Calcular ahora junto al recuadro de selección Vía de acceso de proyecto.
4. Para guardar el valor que ha vuelto a calcular para la vía de acceso, seleccione el recuadro de selección Guardar en el depósito (como valor por omisión). Si guarda el valor, se creará una nueva edición de la clase.
5. Seleccione Aceptar.

D.15.0 RMI Access Builder

RMI Access Builder no está incluido junto con VisualAge para Java, Versión 4.0. Puede importar sus antiguas clases generadas y sus antiguos proyectos de biblioteca de tiempo de ejecución generados al área de trabajo de la Versión 4.0, pero no podrá ejecutar el gestor de invocación de objetos remotos (Remote Object Invocation Manager) ya que no está incluido. Debe estar familiarizado con el nuevo modelo de seguridad de la plataforma Java 2 y con la manera en que sus limitaciones pueden afectar a las aplicaciones de RMI Access Builder.

Añadir la biblioteca de tiempo de ejecución de RMI Access Builder al área de trabajo
Debe importar la biblioteca de tiempo de ejecución de RMI Access Builder de la Versión 3.0x de VisualAge para Java y añadirla al área de trabajo. Sin ella, no puede ejecutar sus aplicaciones de RMI Access Builder en VisualAge para Java, Versión 4.0.

1. Seleccione Archivo > Importar. 
2. Marque el botón de selección Archivo jar.
3. Entre la vía de acceso y el nombre de la unidad ejecutable, que es x:\IBMJava\eab\runtime\ivjrmi.zip, siendo x:\IBMJava\ el directorio de instalación de la Versión 3.0x.
4. Marque el recuadro de selección .class. Si el recuadro de selección de recursos está marcado, quite la marca. 
5. En el campo Proyecto, teclee IBM Enterprise RMI Access Builder Library.
6. Pulse Terminar. 
7. Si el proyecto IBM Enterprise RMI Access Builder Libary aún no existe, se le pedirá que lo cree.
8. Asegúrese de que el proyecto se ha añadido al área de trabajo. Si no aparece en el área de trabajo, vaya al Explorador del depósito y selecciónelo para añadirlo.

Migración de las aplicaciones de RMI Access Builder
Si las aplicaciones RMI todavía no están en el depósito de la Versión 4.0, siga estos pasos para importarlas al área de trabajo.

1. Cree una versión de sus clases y proyectos de biblioteca de tiempo de ejecución de RMI Access Builder en su versión antigua de VisualAge para Java. Si lo desea, puede mantener las clases simplemente como clases .java.
2. Impórtelas al IDE de VisualAge para Java, Versión 4.0, siguiendo estos pasos:
   • En el entorno de trabajo, seleccione Archivo > Importar.
   • Seleccione el botón de selección Directorio o Depósito.
   • Escriba el nombre del directorio o depósito en el que ha almacenado sus aplicaciones.
   • Seleccione el tipo de archivos que desea importar e impórtelos. 
   • Si todavía no lo ha hecho, copie todos los recursos de proyecto asociados a su proyecto RMI en el directorio de recursos de proyecto de la Versión 4.0. Cree una edición abierta del proyecto y haga una versión de él. En la Versión 4.0 de VisualAge para Java, se crea automáticamente una versión de sus recursos de proyecto cuando crea la versión del proyecto que los contiene.

Si desea ejecutar alguno de sus objetos de servidor, primero tendrá que crear una línea principal de servidor. Por ejemplo, si tiene un proxy de servidor del lado del servidor: Reverse1S y ServerObj2S, puede escribir una línea principal de servidor para crear una instancia de los objetos de servidor:

import...;
public class Servermain {
    public static void main(String arg[]) {
        try{
            Reverse1S myserver = new Reverse1S();
            ServerOvj2S obj2 = new ServerObj2S();
}
catch (Exception e) {
    e.printStackTrace();
    }
System.out.print ln("Server Objects Started.");
    }
}

Asimismo, debido a unas restricciones de seguridad más estrictas tendrá que definir un archivo de política para los servidores y los clientes. Por ejemplo, puede tener un archivo de política llamado "Mi política":

grant {
//Otorgar todos los permisos
permission java.security.AllPermission;
};

O bien puede tener una política que permita a todo el mundo estar a la escucha en puertos sin privilegios:

grant { 
// permite a todos estar a la escucha en puertos sin privilegios
permission java.net.SocketPermission "localhost:1024-", "listen";
permission java.net.SocketPermission "localhost:1024-", "resolve"; 
permission java.net.SocketPermission "pathfinder:1000-4000", "listen";
permission java.net.SocketPermission "pathfinder:1000-4000", "connect";
permission java.net.SocketPermission "pathfinder:1000-4000", "resolve";
};

donde pathfinder es el nombre de máquina del usuario.

Cuando lance su cliente, tendrá que ejecutar un mandato similar al siguiente para lanzar el cliente de forma adecuada:

java-Djava.security.policy=<myPolicy.file> 

Por ejemplo, si ejecuta main() dentro del IDE especificará java.security.policy= en la sección Propiedades cuando seleccione el elemento de menú "ejecutar con".

Debe mantener su código en la versión anterior de VisualAge para Java con el fin de poder continuar desarrollándolo o regenerándolo.

D.16.0 Editor de composición visual

Debe utilizar la herramienta de migración del IDE para reparar los metadatos de los compuestos visuales. Consulte el tema de la ayuda en línea titulado "Directrices de arreglar/migrar para referencias de clase o paquete" a fin de obtener información sobre cómo reparar referencias rotas de clases o paquetes debido a la migración de clases a J2SDK v.1.2.2 o a la redenominación de elementos de programa definidos por usuario.

VisualAge para Java no hace un seguimiento de las dependencias entre las clases que se migran. Las clases a las que se hace referencia en una clase y que todavía no se han migrado pueden tener problemas con la inicialización de clase o su introspección puede ser incorrecta.

Los errores que se produzcan mientras esté migrando aparecerán en la ventana Anotaciones. Por ejemplo, supongamos que aparece el siguiente mensaje en la ventana Anotaciones mientras migra una clase llamada Sample.Samp:

Migrando la clase: Sample.Samp

No ha podido migrarse la Clase:<Paquete>X::Y

Sample.Samp hace referencia a X::Y; VisualAge para Java ha encontrado problemas al cargar la clase Y. Y no se ha migrado todavía, o falta (en el Editor de composición visual, la clase Y aparece como una clase de problema). Para arreglar esto, primero migre Y o, si falta Y, busque una clase que la sustituya. En casos extremos, tal vez tenga que abrir Samp o Y en la versión anterior de VisualAge para Java y restablecer beans o propiedades para que la migración pueda continuar.

En algunos casos, al abrir la clase en VCE se abre el diálogo Resolver referencias de clase. Este diálogo muestra las clases de problema que existen en VCE. La columna de referencia de clase no resuelta en el diálogo especifica la clase que VisualAge para Java utilizó como sustituto temporal. Aparece de la siguiente forma:

com.ibm.uvm.abt.edit.DeletedClassView(X)

La X que aparece entre paréntesis es el nombre de la clase de problema. Es probable que la X se migrase correctamente después de la clase actual. Para arreglar esto, seleccione la fila que se va a arreglar y pulse el botón Sustituir. En el diálogo "Elegir una clase válida", seleccione la clase X como clase de sustitución. Haga esto para todas las clases no resueltas y después pulse Aceptar.

D.17.0 Servlet Builder y el lanzador de servlets

Servlet Builder y el lanzador de servlets no se incluyen junto con VisualAge para Java, Versión 4.0. En http://www.ibm.com/vadd está disponible un archivo JAR de la unidad ejecutable de Servlet Builder que es compatible con la Versión 4.0. Siga el enlace "Bajar". 

En VisualAge para Java, Versión 4.0, no hay ninguna característica nueva que reemplace directamente la funcionalidad que anteriormente proporcionaba el lanzador de servlets. Para probar sus servlets, puede lanzarlos de manera explícita entrando el URL en un navegador web, o escribiendo páginas HTML o JSP para invocarlos. Para desarrollar nuevos servlets puede utilizar el nuevo SmartGuide Servlets, que también creará una página HTML que lanzará el servlet.

Dispone de dos opciones para utilizar el archivo de tiempo de ejecución:

• No importe su aplicación a VisualAge para Java, Versión 4.0; por el contrario, actualícela a J2SDK v1.2.2 utilizando un programa de utilidad de migración, compílela y despliéguela en WebSphere Application Server. Esta opción se explica en el escenario 1.
• Importe su aplicación a VisualAge para Java, Versión 4.0, actualícela a J2SDK v1.2.2 utilizando el SmartGuide Arreglar/Migrar, modifíquela manualmente, compílela en el Entorno de prueba de unidad WebSphere, expórtela y despliéguela en WebSphere Application Server. Esta opción se explica en el escenario 2.

Escenario 1

En este escenario, edite el código en la edición anterior de VisualAge para Java, utilizando Servlet Builder antes de exportarlo. 

1. Exporte el código de su aplicación de la versión anterior de VisualAge para Java a un directorio o depósito que esté fuera del árbol de instalación. 
2. Utilice un programa de utilidad como, por ejemplo, "Utility+ JDK Standard Edition" de WoodenChair, para migrar el código java (redenomine paquetes, maneje los cambios en las dependencias, etc.) a J2SDK v1.2.2. Para obtener más información acerca de este producto y sus posibilidades, vaya al sitio web de WoodenChair: http://www.woodenchair.com/
3. Compile cada archivo de clase .java y los archivos JAR utilizando J2SDK v1.2.2. El archivo JAR de la unidad ejecutable Servlet Builder 4.0 debe estar en la vía de acceso de clases de compilación. 
4. Despliegue su código en WebSphere Application Server. El archivo JAR de la unidad ejecutable de Servlet Builder 4.0 debe estar en la vía de acceso de clases del servidor o en el directorio raíz de documentos de WebSphere Application Server.
5. Si tiene que efectuar modificaciones adicionales, regrese al paso 1. Repita los demás pasos según convenga.

Escenario 2

En este escenario, edite el código de Servlet Builder dentro de VisualAge para Java, probándolo en el entorno de prueba de unidad WebSphere.

Siga estos pasos:

1. Importe el archivo JAR de la unidad ejecutable de Servlet Builder 4.0 a VisualAge para Java, Versión 4.0.
2. Importe el proyecto con el que desea trabajar al área de trabajo de VisualAge para Java, Versión 4.0.
3. Utilice el SmartGuide Arreglar/Migrar para reparar las referencias rotas del código.
4. Modifique manualmente el código tal como desee, y compílelo y pruébelo dentro del Entorno de prueba de unidad WebSphere.
5. Exporte el proyecto a un archivo JAR.
6. Despliegue su código en WebSphere Application Server. El archivo JAR de la unidad ejecutable de Servlet Builder 4.0 debe estar en la vía de acceso de clases del servidor o en el directorio raíz de documentos de WebSphere Application Server.

Encontrará más información sobre cómo llevar a cabo estos pasos en la ayuda en línea de VisualAge para Java.

La característica Servlet Builder, que estaba disponible en releases anteriores de VisualAge para Java, creó servlets que generaban directamente una interfaz de usuario HTML. Esta posibilidad es útil para el desarrollo rápido de aplicaciones, pero tiene la desventaja de que combina la lógica comercial de la aplicación con su interfaz de usuario. Si se desea efectuar un cambio en la interfaz de usuario, es preciso modificar el servlet. Para que el mantenimiento sea más sencillo, sería preferible utilizar la tecnología de JavaServer Pages (JSP) (TM) para separar la interfaz de usuario de la lógica comercial.

Una página JSP es una plantilla HTML que incluye contenido generado dinámicamente. Las páginas JSP se pueden modificar utilizando herramientas de edición HTML como, por ejemplo, la característica PageDesigner de IBM WebSphere Studio. En el modelo de programación de WebSphere de IBM, todavía se utilizan servlets para la interacción web, pero delegan la lógica comercial a los beans Java y la interfaz de usuario a JSP. En este modelo de programación, los servlets y beans se desarrollan utilizando herramientas Java, y las páginas JSP, utilizando herramientas HTLM.

Esta separación de la lógica comercial y la interfaz de usuario permite asignar responsabilidades de desarrollo a los miembros del equipo que tienen los conocimientos y herramientas adecuados, y representa un mantenimiento más sencillo.

De acuerdo con el modelo de programación de WebSphere, la función que proporcionaba Servlet Builder se ha reemplazado por herramientas Java en VisualAge para Java y por herramientas HTML en WebSphere Studio. VisualAge para Java, Versión 4.0, proporciona un nuevo SmartGuide (asistente) que sirve de orientación en la tarea de crear aplicaciones web que siguen el modelo WebSphere. Puede utilizar el SmartGuide Crear servlets para generar un servlet que invoque un bean para la lógica comercial y una página JSP para la interfaz de usuario. El SmartGuide también genera un formato HTML que se puede utilizar para probar el servlet. El servlet se puede probar inmediatamente en el Entorno de prueba de WebSphere de VisualAge para Java, y luego pulirse en el IDE. Los archivos JSP y HTML se pueden editar adicionalmente con WebSphere Studio o cualquier otra herramienta HTML.

El SmartGuide Crear servlets se basa en el modelo de asistente JavaBean de WebSphere Studio. También incluye características adicionales que requieren los programadores de Java. Si ya utiliza WebSphere Studio para el desarrollo HTML, verá que el SmartGuide simplifica el flujo de trabajo entre esa herramienta y VisualAge para Java. Los pasos de desarrollo son los siguientes:

1. Cree un bean Java para la lógica comercial de la aplicación.
2. Ejecute el SmartGuide para generar el servlet, JSP y el formato HTML.
3. Pruebe el servlet en VisualAge para Java
4. Continúe desarrollando el servlet en VisualAge para Java.
5. Pula los archivos JSP y HTML en WebSphere Studio o herramienta equivalente. 

D.18.0 Clases Swing

Las clases Swing están en un paquete diferente en J2SDK v1.2.2 y en JDK v1.1.x. Si tiene que actualizar referencias a las clases Swing, puede utilizar el SmartGuide Arreglar/Migrar.

Para migrar las aplicaciones es preciso seleccionar las clases y los paquetes afectados, abrir el SmartGuide Arreglar/Migrar (pulsando el paquete o la clase con el botón derecho del ratón y luego seleccionando Reorganizar > Arreglar/Migrar) y marcar el recuadro de selección Incluir paquetes redenominados de JDK1.2 para migrar automáticamente las referencias Swing a J2SDK v1.2.2.Así se añadirán las entradas De/A adecuadas para Swing. Los errores que se produzcan mientras esté migrando se aparecerán en la ventana Anotaciones. 

Consulte los siguientes temas de ayuda en línea: "Directrices de Arreglar/migrar para referencias de clase o paquete" y "Reparación de referencias de clase o paquete"; en ellos hallará información acerca de cómo migrar adecuadamente sus aplicaciones.  

Es posible que no pueda utilizar el editor de composición visual para migrar todas las propiedades Swing de JDK 1.1.7 a Java 2 debido a cambios de serialización entre las versiones 1.03 y 1.1.1 de Swing. Tras haber migrado el código a VisualAge para Java, Versión 4.0, tal vez no pueda abrir algunas clases de aplicación Swing en el VCE. Esto solo ocurrirá cuando haya utilizado la hoja de propiedades del VCE para establecer las propiedades de un Javabean en un objeto Swing.

Para evitar que se produzca este problema, siga estos pasos:

1. Vuelva a abrir la clase en la versión anterior de VisualAge para Java (en el VCE).
2. En la hoja de propiedades de la clase, pulse el botón Restablecer. Se abre una ventana que lista todas las propiedades del bean que ha modificado. Las propiedades que se hayan establecido en los objetos Swing deben restablecerse en sus valores originales.
3. Guarde la clase y vuelva a importarla al IDE de la Versión 4.0.

D.19.0 XMI Toolkit  

Para obtener información acerca de cómo migrar desde la versión Beta 1.2 de XMI Toolkit, consulte las notas de release de XMI Toolkit.

Si ha utilizado un release que no sea la Versión 3.5 de XML Toolkit (por ejemplo, un avance tecnológico, un release alphaWorks o una versión Beta anterior), debe desinstalarlo y eliminar las actualizaciones de entorno realizadas durante la instalación antes de utilizar este release de XMI Toolkit. Las instrucciones de instalación solo se proporcionan para el Release 1.2.

Los archivos zip y XMI generados a partir de los releases Beta 1.2 y pre-Beta 1.2 no son compatibles con ningún release 3.5 ni 3.5.x del XMI Toolkit.

Parte E: Información general

E.1.0 Manejar los recursos de un proyecto y la gestión de los recursos

En la Versión 4.0 de VisualAge para Java se puede crear una versión de los archivos de recursos del proyecto y liberarlos. Consulte la ayuda en línea del IDE y del equipo para obtener más información acerca de esta nueva característica.

Si ha migrado proyectos desde la Versión 2.0 ó 3.0x de VisualAge para Java a la Versión 4.0 de VisualAge para Java, puede seguir estos pasos después de completar el proceso de migración. No es necesario que los realice inmediatamente después de finalizar la migración, pero mientras no lo haga, no se creará una versión de sus recursos de proyecto en el depósito.
Nota: no es preciso que siga estos pasos si ha migrado los proyectos desde la Versión 3.5.

1. Asegúrese de que ha copiado todos los recursos de proyecto antiguos en el directorio de recursos de proyecto de la Versión 4.0.
2. Añada los proyectos al área de trabajo desde el depósito.
3. Cree una nueva edición abierta de cada proyecto. No puede añadir recursos nuevos al proyecto hasta que haya creado una edición abierta del mismo.
4. Cree la versión del proyecto, con lo que se liberarán todos los recursos. 

Si tiene previsto trabajar en un entorno en equipo con la edición Enterprise de VisualAge para Java, debe utilizar EMSRV, Versión 7.1. 

E.2.0 Migración desde OS/2 y AIX

OS/2 y AIX no están soportados como plataformas de desarrollo para VisualAge para Java, Versión 4.0. Solo puede instalar VisualAge para Java, Versión 4.0 como cliente en Windows NT, Windows 98 y Windows 2000. Si desea utilizar la Versión 4.0 con su depósito de OS/2 y AIX, debe conectarse a ese depósito desde el IDE de la Versión 4.0. Consulte la ayuda en línea para obtener información acerca de cómo realizar esta tarea. 

Si ha escrito código específico de plataforma, tendrá que volver a escribirlo para que funcione en Windows.

Dos escenarios 

Nota: no se puede tener AIX y Windows en una misma máquina, por lo que los pasos del escenario 1 solo son aplicables para OS/2.

Escenario 1

El depósito ivj.dat de OS/2 está en la misma máquina que el cliente Windows:

1. Haga copia de seguridad del archivo ivj.dat antiguo. El depósito se restaurará más adelante, cuando haya instalado Windows 98, Windows NT o Windows 2000 y VisualAge para Java, Versión 4.0. Si el depósito reside en una partición FAT gestionada por OS/2 y piensa instalar Windows 98/NT/2000 en la misma máquina y conservar la partición FAT, no es necesario que haga copia de seguridad del depósito. Sin embargo, le recomendamos que haga copia de seguridad del depósito por si surgen problemas al instalar Windows. 
2. Instale Windows 98, Windows NT o Windows 2000. Si su máquina está ejecutando OS/2, podrá instalar Windows en esa misma máquina con la opción de arranque dual y así conservar la instalación de OS/2 existente.
3. Instale VisualAge para Java, Versión 4.0. 
4. Restaure el depósito en una partición existente en un disco duro local al que pueda acceder la nueva instalación de Windows. Si el depósito residía anteriormente en una partición FAT gestionada por OS/2 y la partición existe todavía, no será necesario restaurar el depósito. 
5. Conéctese al depósito antiguo (Enterprise) o importe desde el depósito antiguo (Professional). Debe volver a copiar todos los recursos de proyecto antiguos en el directorio de recursos de proyecto de la Versión 4.0.

Escenario 2

Si el depósito ivj.dat de OS/2 o AIX está en una máquina que no es el cliente Windows:

1. La máquina OS/2 o AIX debe estar ejecutando el programa de depósito de EMSRV (Versión 7.1) proporcionado con VisualAge para Java, Versión 4.0. Puede conectarse a depósitos que se utilizaron con la Versión 3.02 o una versión anterior de VisualAge para Java, pero debe tener instalada la Versión 7.1 de EMSRV para poder conectarse a un depósito antiguo desde la Versión 4.0.
2. El cliente Windows, en el que se está ejecutando VisualAge para Java, Versión 4.0, se conecta al servidor OS/2 o AIX según sea necesario. Debe volver a copiar todos los recursos de proyecto antiguos en el directorio de recursos de proyecto de la Versión 4.0.

E.3.0 Nuevas restricciones de seguridad en J2SDK v1.2.2  

Debido a un cambio realizado en la política de seguridad para los applets que se ejecutan en la plataforma Java 2 v1.2.2, los applets ya no pueden acceder a los recursos locales. 

Varios ejemplos que estaban disponibles en versiones anteriores de VisualAge para Java no se incluyen en VisualAge para Java, Versión 4.0, debido a esta restricción. Asimismo, algunos de los ejemplos incluidos solo se pueden ejecutar como aplicaciones; de lo contrario, no funcionarían adecuadamente. En la documentación en línea hallará instrucciones para ejecutar debidamente los ejemplos.

Puede cambiar las políticas de seguridad por omisión creando su propio archivo java.policy y lanzando el visor de applets con el siguiente parámetro: -Djava.security.policy=unURL

siendo unURL la ubicación de su nuevo archivo de políticas. Para obtener información detallada acerca de la seguridad general en Java, vaya a http://java.sun.com/security. Para obtener información específica acerca de la seguridad en Java 2 y la sintaxis del archivo de políticas, vaya a http://java.sun.com/products/jdk/1.2/docs/guide/security

E.4.0 Nueva herramienta de control de versiones externo (sustituye a la herramienta SCM externo)

El Control de versiones externo permite conectarse a proveedores de gestión externa de código fuente (SCM) como, por ejemplo, ClearCase, PVCS Version Manager, TeamConnection(TM) y SourceSafe(TM) desde VisualAge para Java. Con esta herramienta se pueden añadir clases al proveedor SCM, reservar y anular la reserva de las clases y los archivos de recursos en el sistema SCM, e importar la versión de una clase cuya reserva se ha anulado más recientemente desde el sistema SCM.

Esta herramienta sustituye a la antigua herramienta SCM externo y proporciona una mayor funcionalidad.

E. 5.0 Trabajar con los ORB de terceros en VisualAge para Java

Puede trabajar con los Object Request Brokers (ORB) de terceros en VisualAge para Java si son compatibles con J2SDK v1.2.2. Para poder trabajar con ellos, primero debe importar las clases de ORB al IDE.

Cuando importe clases Java al IDE, puede añadir clases de extensión de ORB a las bibliotecas de clases Java. También puede sustituir algunas de las clases de extensión de ORB que se encuentran en las bibliotecas de clases Java existentes, siempre que no formen parte de las clases fundamentales de J2SDK v1.2.2.

Encontrará un artículo que explica con mayor detalle cómo trabajar con los ORB de terceros en la Versión 3.5.x, en el sitio Web cuyo URL es:

http://www.ibm.com/software/vadd/Data/Document2175

Este artículo proporciona información exhaustiva acerca de cómo desarrollar aplicaciones CORBA (Common Object Request Broker Architecture) y ORB en VisualAge para Java.

Algunas clases de la biblioteca de clases Java se pueden sustituir al importar un ORB de terceros a VisualAge para Java. El parche 2 para la Versión 3.5 arregla un defecto que permitía importar erróneamente algunas clases inmutables (aquellas contenidas en paquetes inmutables) a VisualAge para Java. Tras aplicar el parche 2 a VisualAge para Java, Versión 3.5, puede ser que reciba avisos nuevos o adicionales en la ventana Anotaciones al importar un ORB de terceros. Estos avisos se producen porque no se pueden importar clases inmutables a VisualAge para Java una vez aplicado el parche 2; sin embargo, puede hacer caso omiso de ellos.

E.6.0 Contenido del CD de características adicionales

El CD de características adicionales de VisualAge para Java contiene:

• IBM Connectors and Tools para J2EE(TM) - Beta
• Servidor de equipo
• Unidades ejecutables distribuibles
• IBM Developer Kit 1.2.2
• Merant DataDirect SequeLink Java Edition, Versión 5.1, para Oracle y Microsoft SQLServer
• Distributed Debugger (depurador distribuido)
• Avances tecnológicos
  • IBM Stored Procedure Integration Tool para Enterprise JavaBeans
  • Puente XMI
• Documentación imprimible
• Guía para la resolución de problemas del sistema de ayuda
• Copia de seguridad y recursos del depósito

La Guía para la instalación y la migración y el README del producto están tanto en el CD de características adicionales como en el CD principal del producto.

Nota: el CD de características adicionales se incluye solamente con VisualAge para Java, Enterprise Edition. Sin embargo, los siguientes elementos se incluyen junto con VisualAge para Java, Professional Edition, en el CD del producto:

• Unidades ejecutables distribuibles
• IBM Developer Kit 1.2.2
• Distributed Debugger (depurador distribuido)
• Documentación imprimible
• Guía para la resolución de problemas del sistema de ayuda
• Copia de seguridad y recursos del depósito

La Guía para la instalación y la migración y el README del producto están en el CD del producto de VisualAge para Java, Professional Edition.

IBM J2EE Connectors and Tools para J2EE(TM) - Beta

Este release de VisualAge para Java incluye una versión beta de varios componentes de la plataforma Java 2, Enterprise Edition (J2EE) que no han sido oficialmente entregados por Sun Microsystems, Inc. Son los siguientes:

• J2EE Connector para CICS
• J2EE Connector para SAP R/3 
• J2EE Connector para PeopleSoft 
• J2EE Connector para J.D. Edwards OneWorld
• J2EE Connector para Oracle Applications/Financials
• J2EE Connector para IMS (disponible en http://www.ibm.com/vadd)
• J2EE Connector para HOD (disponible en http://www.ibm.com/vadd)
• Herramientas para importar estructuras de datos que están en servidores de aplicaciones JD Edwards, PeopleSoft y Oracle
• Herramientas para generar registros en conformidad con J2EE
• Herramientas para crear y editar mandatos en conformidad con J2EE
• Herramientas para crear y editar beans de sesión EAB en conformidad con J2EE
• Herramientas para migrar aplicaciones EAB existentes a la arquitectura basada en J2EE. Estas herramientas migran registros, objetos Mandatos y objetos Navegadores. 

Los componentes beta están en el subdirectorio extras\BetaJ2EEConnectors. Si desea usar estos componentes beta, las instrucciones para instalarlos están en el archivo README que se encuentra en el subdirectorio BetaJ2EEConnectors.

Nota: los componentes enviados con VisualAge para Java, Versión 4.0 sólo están soportados en Windows NT y Windows 2000. No todos los archivos de tiempo de ejecución J2EE están soportados en Windows 2000. Si desea más información sobre los componentes J2EE, consulte la ayuda en línea y las notas de release de Enterprise Access Beans.

Servidor de equipo (EMSRV) 

El directorio TeamServer situado en el CD de características adicionales contiene el programa servidor del depósito EMSRV y el archivo "Configuración y administración del servidor" (emsrv71.htm o emsrv70.htm para los idiomas distintos del inglés). En la Parte C hallará instrucciones para instalar EMSRV y el archivo "Configuración y administración del servidor" (situado en TeamServer\docs), donde hay información sobre cómo iniciar el servidor. 

Unidades ejecutables distribuibles

Al exportar y desplegar un applet o una aplicación construida con VisualAge para Java, también tendrá que desplegar la biblioteca de tiempo de ejecución correspondiente a las características con las que creó el código, si las hubiera, y poner el archivo JAR o el archivo Zip desplegado de tiempo de ejecución en la vía de acceso de clases.

En general, los archivos JAR están comprimidos y se emplean cuando se ejecutan applets desde un servidor. Los archivos Zip no están comprimidos y se deben colocar en la vía de acceso de clases (CLASSPATH) de la máquina de despliegue para ejecutar las aplicaciones localmente.

Las bibliotecas de tiempo de ejecución de VisualAge para Java están en los directorios extras/runtime30 y extras/runtime35. En función de qué características de VisualAge para Java se hayan instalado, se proporcionan algunas o la totalidad de las bibliotecas de tiempo de ejecución en el directorio eab/runtime35 o runtime30 de la imagen de instalación. Nota: las bibliotecas de tiempo de ejecución J2EE no se incluyen en el CD de características adicionales. Los archivos de tiempo de ejecución correspondientes a los conectores J2EE estarán en eab\runtime 35 y en IBM Connectors\classes después de que haya instalado los componentes de la versión beta.  

En la ayuda en línea hallará más información sobre cómo instalar y utilizar las bibliotecas de tiempo de ejecución.

IBM Developer Kit 1.2.2 (para Windows)

IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9, que está en el directorio IBM Developer Kit, es un entorno de desarrollo Java que le ayudará a desarrollar applets y aplicaciones Java autónomas que están en conformidad con la especificación Java puro al 100%.

Incluye herramientas para desarrollar applets y aplicaciones Java, entre ellas: 

Compilador Java 

Convierte el código fuente Java en bytecodes Java, que después se puede ejecutar con el intérprete Java.

Bibliotecas de clases Java 

Proporcionan todas las clases Java estándar, que permiten a las aplicaciones Java crear y ampliar los objetos Java existentes. 

Visor de applets Java 

Proporciona una manera de ejecutar un applet desde el indicador de mandatos. 

Generador de documentación Java 

Genera la documentación de la interfaz de programación de aplicaciones (API) del Toolkit a partir de programas Java debidamente comentados. 

Para instalar IBM Developer Kit, ejecute install.exe desde el directorio IBM Developer Kit. Si desea más información sobre IBM Developer Kit, consulte el archivo README que está en el directorio IBM Developer Kit.

Merant DataDirect SequeLink Java Edition, Versión 5.1, para Oracle y Microsoft SQLServer

VisualAge para Java, Versión 4.0, soporta el controlador DataDirect SequeLink Java Edition, Versión 5.1, de Merant para el acceso a las bases de datos Microsoft SQL Server y Oracle.

Nota: el servidor Merant DataDirect SequeLink Java Edition, Versión 5.1, que se entrega con VisualAge para Java, Versión 4.0, solo está soportado en Windows NT y en Windows 2000.

SequeLink es un componente de acceso a datos de middleware que proporciona conectividad de datos para los estándares JDBC más recientes en una gran variedad de bases de datos como Oracle, Microsoft SQL Server y también para datos de mainframe. El componente cliente de SequeLink es independiente de base de datos; por lo tanto, no es necesario hacer cambios si se añaden nuevas bases de datos a la infraestructura. Se incluye un cliente de marca SequeLink junto con el entorno de prueba WebSphere.

Nota: debido a que el cliente SequeLink es de marca, solo se puede comunicar con el servidor Merant DataDirect SequeLink Java Edition, Versión 5.1, mientras se utiliza el cliente juntamente con el entorno de prueba WebSphere o WebSphere Application Server. El servidor Merant DataDirect SequeLink Java Edition, Versión 5.1, no se entrega con licencia para todo uso; no se le puede utilizar para ninguna otra finalidad que no sea para trabajar con el cliente Sequelink de marca. Si tiene un servidor Merant DataDirect SequeLink Java Edition, Versión 5.1, con licencia para todo uso, el cliente Sequelink de marca también funcionará con él.

El correspondiente servidor SequeLink está disponible como instalación sin clave (es decir, no se le pedirá una clave de registro cuando lo instale). El servidor se puede instalar desde el subdirectorio Merant\SequeLinkServer del CD de características adicionales.

La manera de instalar y configurar el controlador varía en función del componente con el que tiene previsto utilizarlo. En las siguientes notas de release se facilita información de instalación y configuración específica (incluida la información sobre cómo configurar el cliente SequeLink que se entrega junto con el entorno de prueba WebSphere):

• Enterprise JavaBeans (EJB)
• Persistence Builder
• Data Access Beans

Distributed Debugger

Si piensa depurar clases que se hayan desarrollado fuera del IDE de VisualAge para Java, o depurar programas que se ejecuten en una máquina aparte, debe instalar el depurador distribuido (Distributed Debugger).

Distributed Debugger está soportado en estos sistemas operativos: Windows, AIX, OS/2, HP-UX, Solaris, Linux y Linux/390. Todos los archivos del depurador están en el directorio Debugger del CD de características adicionales. En la Parte B, sección 2.1.1.1. hallará instrucciones de instalación.  

Avances tecnológicos

El CD de características adicionales contiene dos avances tecnológicos: IBM Stored Procedure Integration Tool para Enterprise JavaBeans y el puente XMI.

IBM Stored Procedure Integration Tool para Enterprise JavaBeans

IBM Stored Procedure Integration Tool para Enterprise JavaBeans (herramienta de integración de SP para los EJB) permite mejorar los EJB de sesión sin estado, ya que añade métodos que llaman a procedimientos almacenados de base de datos. Con el SmartGuide Crear método de llamada a procedimiento almacenado, podrá definir sus métodos y luego generar el nuevo método en el bean de sesión sin estado.

Si utiliza la herramienta de integración de SP para los EJB, podrá aprovechar al máximo la lógica comercial contenida en los procedimientos almacenados existentes dentro de un entorno EJB. Gracias a ello, podrá minimizar los esfuerzos que supone el desarrollo de EJB y evitar la aparición de lógica comercial redundante en el servidor EJB y en el sistema de gestión de bases de datos (DBMS). Además, puesto que los procedimientos almacenados pueden ayudar a reducir el tráfico de red entre el servidor EJB y el DBMS, podrá mejorar el rendimiento de las aplicaciones en fase de producción.

La herramienta de integración de SP para los EJB está en el subdirectorio extras\spt. En el archivo EJB_SPTool.PDF, situado en el directorio spt, hallará más información sobre cómo instalar y utilizar este avance tecnológico. Tras instalar la herramienta de integración SP para beans EJB, el archivo EJB_SPTool.PDF también se encontrará en el directorio siguiente: x:\ibmvjava\ide\tools\com-ibm-ivj-sptools donde x:\ibmvjava es el directorio de instalación del producto.

Puente XMI

El puente XMI es un avance tecnológico destinado a Persistence Builder y a los Enterprise JavaBeans y que le permite importar un archivo modelo de Rational Rose o un documento XMI a un modelo de Persistence Builder o a un grupo EJB.

El puente XMI está en el directorio extras\xmib. Para poder trabajar con el puente XMI, primero debe añadir XMI Toolkit al área de trabajo. En el archivo README, situado en el directorio xmib, hallará más información sobre cómo instalar y utilizar este avance tecnológico.

Documentación imprimible

Parte de la ayuda en línea se ha agrupado en documentos PDF que puede ver e imprimir utilizando Adobe Acrobat Reader (disponible en http://www.adobe.com/). No todos los PDF están disponibles en todos los idiomas. Los archivos PDF están disponibles en el directorio pdf.

En el Índice de PDF (en la guía Cómo empezar) hallará información sobre lo que contiene cada archivo PDF.

Guía para la resolución de problemas del sistema de ayuda

En la Guía para la resolución de problemas del sistema de ayuda hallará información sobre cómo recuperar el sistema en caso de que se produzcan anomalías en la ayuda. Esta guía está en el directorio Troubleshoot, en el CD de características adicionales, y está disponible en todos los idiomas.

Depósitos y recursos

El directorio ivj40 contiene dos archivos zip: ide.zip y wte_resources.zip. El archivo ide.zip contiene una copia del depósito (ivj.dat), el directorio de recursos del proyecto (ivj.dat.pr) y el archivo del área de trabajo (ide.icx). En el archivo wte_resources.zip hay una copia de seguridad de los recursos de proyecto de la característica WTE.

Apéndice A: Comparación de los componentes de acceso a datos 

A continuación se proporciona una comparación de Data Access Builder, Data Access Beans y Persistence Builder. Se incluye una breve descripción del entorno de desarrollo EJB, pero este componente no se incluye en la comparación.

La característica Data Access Beans (beans de acceso a datos) ofrece una manera rápida de acceder a datos relacionales visualmente. La idea es que esta característica se utilice con aplicaciones en las que no es necesario un modelo de objeto reutilizable. Se puede utilizar los beans de acceso a datos (DAB) para ayudarle a crear aplicaciones visuales que necesitan una vista directa de las tablas que hay dentro de la base de datos destino. También puede incorporar los beans de acceso a datos (DAB) a su código de forma manual.

El entorno de desarrollo EJB permite desarrollar beans que implementan las especificaciones de programación Enterprise JavaBeans (EJB) de Sun Microsystems. El entorno de desarrollo EJB proporciona todo el soporte necesario de tiempo de ejecución para IBM WebSphere Application Server. Un comprobador de coherencia incremental garantiza que los beans enterprise se ajusten a la especificación de programación de EJB e indica si es necesario hacer cambios para arreglar las incoherencias. Consulte la ayuda en línea para obtener más información acerca del entorno de desarrollo EJB.

Persistence Builder proporciona soporte de persistencia escalable para modelos de objeto y es un primer paso hacia EJB para muchos clientes. Las aplicaciones creadas con Persistence Builder pueden centrarse en el modelo óptimo de objeto reutilizable y correlacionarlo rápidamente con todas las bases de datos relacionales soportadas. Persistence Builder da soporte a la correlación de abajo arriba (Esquema a Objeto), y de arriba a abajo (Objeto a Esquema). Esta característica correlaciona objetos, y relaciones entre objetos, con los datos almacenados en bases de datos relacionales.

El resto de este documento describe las diferencias que hay entre las características de acceso a datos - Data Access Beans, Data Access Builder y Persistence Builder.

Los detalles de la implementación de cada característica no se incluyen. La documentación en línea explica la funcionalidad adicional que ofrecen Persistence Builder y los beans de acceso a datos (DAB), como son las relaciones, los componentes de la paleta visual y la posibilidad transaccional avanzada, así como el SmartGuide SQL Assist.

La lista de funciones fundamentales que se enumera a continuación representa una visión general de las principales posibilidades de Data Access Builder. Cada componente ha implementado las funciones fundamentales de diferente forma.

Parte 1: Características de correlación de objeto a relacional

Correlación de esquema de base de datos a objeto

• Sección 1.0 - Utilización de tablas y vistas 
• Sección 2.0 - Utilización de consultas personalizadas 
• Sección 3.0 - Utilización de procedimientos almacenados 

Generación de código

• Sección 4.0 - CRUD Soporte de procedimientos almacenados y operaciones sobre objetos
• Sección 5.0 - Soporte de consultas personalizadas

Parte 2: Características de tiempo de ejecución

• Sección 1.0 - Soporte de Almacén de datos/Transaccional
• Sección 2.0 - API Soporte LOB
• Sección 3.0 - Formularios rápidos
• Sección 4.0 - Soporte de Fecha/Hora/Indicación de la hora actual 
• Sección 5.0 - Soporte de cursor 
• Sección 6.0 - Ejecución asíncrona Cuestiones de concurrencia

Parte 3: Características de los beans de acceso a datos (DAB)

Las implementaciones de las funciones se explican en las siguientes páginas. Todas las funciones de Data Access Builder y Persistence Builder se comparan consecutivamente, mientras que las funciones comparables de los beans de acceso a datos (DAB) (para la correlación) se enumeran al final de esta sección.

Parte 1: Características de correlación de objeto a relacional

Correlación de esquema a objeto de base de datos

1.0 Correlación de esquema a objeto de base de datos utilizando tablas y vistas

Data Access Builder

Nota: todos los pasos de Data Access Builder deben realizarse en una versión anterior (3.02 o anterior) de VisualAge para Java que incluya Data Access Builder. 

En el SmartGuide Correlacionar esquema, seleccione la conexión DB2 u ODBC, y luego marque el botón de selección Seleccionar tablas o vista de base de datos. Pulse Siguiente. Se abre la siguiente página, que muestra una lista de tablas:

Seleccione las tablas con las que desea trabajar y pulse Terminar. Se crearán correlaciones de 1 objeto a 1 objeto entre estas tablas y los objetos resultantes. La ventana de Data Access Builder muestra la columna para la correlación de atributos que se ha producido automáticamente.

Persistence Builder

En el examinador de esquemas, seleccione Esquemas > Importar esquema desde base de datos. Escriba la información de conexión. Se abre el diálogo Seleccionar tablas.

Seleccione las tablas o vistas deseadas y pulse Aceptar. El examinados de esquemas ahora contiene el nuevo esquema y enumera sus tablas, columnas y claves.

Seleccione Esquemas > Generar modelo desde esquema. Se genera un modelo comercial simple de uno a uno.

2.0 Correlación de esquema de base de datos a objeto utilizando consultas personalizadas

Data Access Builder

Entre su consulta y pulse Terminar. El ejemplo anterior muestra una consulta de unión de dos tablas. Las consultas con valores de parámetro también están soportadas.

El objeto resultante contiene los atributos de ambas tablas tal como se muestra a continuación:

Persistence Builder

1. Importe el esquema utilizando el examinador de esquemas.
2. Abra el examinador de modelos y cree el modelo de objeto con el que se correlacionarán las tablas.
3. Cuando el modelo esté completo, abra el examinador de correlaciones y cree una nueva correlación de almacén de datos. Seleccione el esquema y el modelo ya creados.
4. Seleccione una clase de modelo y añada una correlación de clusters seleccionando Nueva correlación de tabla > Añadir correlación de clusters sin herencia.
5. Para añadir más tablas de unión, seleccione el elemento de menú Nueva correlación de tabla > Añadir correlación de tabla secundaria. Cuando las tablas se hayan añadido, correlacione los atributos individuales abriendo el editor de correlación de propiedades en cada correlación de tabla.
   
6. Correlacione cada atributo con las columnas de las tablas, dejando las demás columnas de las tablas sin correlacionar. El examinador de correlaciones mostrará las correlaciones de propiedades que corresponden a cada tabla en el cuarto panel.

3.0 Correlación de esquema de base de datos a objeto utilizando procedimientos almacenados

Data Access Builder

En el SmartGuide Correlacionar esquema, seleccione la conexión DB2 u ODBC y luego marque el botón de selección Conjunto de resultados de procedimientos almacenados. Se abre la página Procedimiento almacenado, que muestra una lista de los procedimientos almacenados. Entre un nombre para la correlación, seleccione el procedimiento almacenado y pulse Terminar.

El objeto resultante contiene los atributos correlacionados con las columnas de resultado del procedimiento almacenado. Las consultas o los procedimientos almacenados para las operaciones CRUD no están predefinidos para este tipo de correlación.

Persistence Builder

Persistence Builder no tiene herramientas que den soporte a la correlación de procedimientos almacenados. Puede generar un "Esquema de apéndices", que crea clases de servicio de esqueleto en las que debe suministrar el código de soporte. El método all-instances puede aparecer de la siguiente forma:

/**
* Devolver una especificación de consulta para la consulta llamada allInstances
* @return java.util.Vector
*/

public java.util.Vector allInstancesQuery() {
   Vector aSpecArray = new Vector();
     DatabaseCompoundType aCompoundType;
        DatabaseQuerySpec spec = new DatabaseCallableQuerySpec("{call getAllEmp ()}");
      aCompoundType = new DatabaseCompoundType();
        aCompoundType.addField((DatabaseTypeField)(new                              com.ibm.ivj.db.base.DatabaseDecimalField("COMM")).setAttributes(9,2,3,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("EMPNO")).setAttributes(4,0,4,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseDecimalField("SAL")).setAttributes(9,2,3,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("DEPTNO")).setAttributes(2,0,4,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseStringField("ENAME")).setAttributes(10,0,12,false));

((DatabaseSelectQuerySpec)spec).setOutputShape(aCompoundType);

aSpecArray.addElement(spec);
return aSpecArray;
}

4.0 Operaciones CRUD sobre objetos

Data Access Builder

Las operaciones CRUD básicas (crear, recuperar, actualizar y suprimir) se generan automáticamente con correlaciones de una tabla a un objeto. Si utiliza consultas personalizadas o procedimientos almacenados, estas consultas faltarán y deberá definirlas manualmente utilizando la herramienta Data Access Builder. Un ejemplo sería una consulta de unión que define un objeto Cliente.

1. En la ventana Data Access Builder, desde el menú emergente de un bean, seleccione Métodos. Añada un nuevo método llamado addCustomer1.

2. Escriba la siguiente sentencia SQL:

INSERT INTO TPF.CUSTOMER (
CUSNO,
FIRSTNAME,
MIDINIT,
LASTNAME,
HOMEPHONE,
HOMEADDR,
WORKPHONE,
BILLADDR,
BRANCHNO,
OPEN DATE)
VALUES (?, ?, ?, ?, ?, ?, ?,?, ? ,?)

Después de que Data Access Builder valide la consulta, debe correlacionar los parámetros individualmente utilizando la página Parámetro.

También tiene que definir la consulta addCustomer2 para la inserción de la segunda tabla de unión CUSTDATA. El usuario maneja la sincronización de las dos consultas para esta función atómica.

Persistence Builder

Persistence Builder generará todas las operaciones CRUD cuando se haya creado una correlación entre el esquema y el modelo definidos. En el caso de que haya uniones de varias tablas se genera cada consulta de tabla y el motor de servicio gestiona estas operaciones como una unidad atómica.

Los procedimientos almacenados todavía no están soportados en las herramientas, pero se pueden generar y ampliar "Esquemas de apéndices". A continuación se muestra un ejemplo de una inserción de consulta de procedimiento almacenado.

/**
*Devolver una especificación de consulta para la consulta llamada insert
* @return java.util.Vector
* @param args java.util.Vector
* @param anInjector com.ibm.vap.Persistence.BOInjector 

public java.util.Vector insertQuery(java.util.Vector args,com.ibm.vap.Persistence.BOInjector anInjector) {
    Vector aSpecArray = new Vector();
DatabaseCompoundType aCompoundType;
   

 DatabaseQuerySpec spec = new DatabaseCallableQuerySpec("{call     

    insertEmp (?,?,?,?)}");

Vector stringArgs;
a CompoundType = new DatabaseCompoundType();

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("EMPNO")).setAttributes(4,0,4,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseDecimalField("SAL")).setAttributes(9,2,3,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("DEPTNO")).setAttributes(2,0,4,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseStringField("ENAME")).setAttributes(10,0,12,false));

StringArgs = new Vector();
stringArgs.addElement("EMPNO");
stringArgs.addElement("SAL");
stringArgs.addElement("DEPTNO");
stringArgs.addElement("ENAME");

spec.setInputShape(aCompoundType);
spec.setInputValues(args);
spec.setInputNamesWithDuplicates(stringArgs);
   aSpecArray.addElement(spec);
        return aSpecArray;

5.0 Soporte de consulta personalizada

Data Access Builder

Las consultas personalizadas de Data Access Builder se definen de la misma manera que las consultas CRUD. El usuario añade la consulta nombrada y utiliza la página Parámetro si es necesario. La consulta resultante aparecerá como un método en la clase BusinessObjectMgr.

Data Access Builder también proporciona otros métodos para definir consultas personalizadas, como la sustitución de Predicado SQL.

TheEmpMgr.select('WHERE WORKDEPT = 'E11');

Persistence Builder

Existen dos opciones para añadir consultas personalizadas en Persistence Builder. Se pueden definir colecciones ligeras a nivel de clase utilizando el editor de clases. La siguiente página permite buscar y filtrar en la clase especificada.

Las consultas de colección ligera se suelen utilizar en diálogos o listas de búsquedas para llegar hasta el objeto comercial adecuado. Los métodos resultantes devuelven vectores de "Objetos de datos" que se pueden utilizar para recuperar el correspondiente objeto comercial persistente.

A continuación proporcionamos un ejemplo de código que utiliza la colección ligera generada que acabamos de mostrar:

VapCourseHomeImpl aHome = VapCourseHomeImpl.singleton();
    VapDepartmentKey aKey = new VapDepartmentKey("Sales"); 
VapLiteCollection liteCollection = aHome.getByDepartmentLiteCollection(aKey); 

Enumeration enum = liteCollection.elements();
VapCourseDataObject aDO;
VapCourse aCourse; 

while (enum.hasMoreElements()) {

    aDO = (VapCourseDataObject)enum.nextElement(); 
   aCourse = aHome.find(aDO.getNumber()); 
   //Fetching fully hydrated EJBObject
   }

Persistence Builder también proporciona una infraestructura de consulta personalizada, que se puede utilizar para definir diversas operaciones en una clase comercial. Estas consultas devolverán objetos comerciales plenamente funcionales.

A continuación se proporciona un ejemplo de una clase Student (estudiante) con una consulta personalizada "retrieveStudentsOver21". La clase Local (Home) para estudiantes tiene el siguiente método:

public Vector retrieveStudentsOver21() throws java.rmi.RemoteException,     
com.ibm.vap.common.VapReadFailureException {
    return customQuery("studentsOver21Query");
}

QueryPool para estudiantes contiene los correspondientes métodos para el servicio personalizado:

/* Devolver una especificación de consulta para la consulta llamada studentsOver21
 @return java.util.Vector */

public java.util.Vector studentsOver21Query() {
    Vector aSpecArray = new Vector();
    aSpecArray.addElement(new DatabaseSelectQuerySpec(studentsOver21SqlString()));
          return aSpecArray;

}

/* Devolver la serie SQL para la consulta llamada studentsOver21Query
  @return java.lang.String */

public java.lang.String studentsOver21SqlString() {

return "SELECT T1.SNAME, T1.SNO, T1.SADVFNO, T1.SBDATE, T1.SADDR, T1.SPHNO, T1.SMAJ, T1.SIQ FROM SPARKY.STUDENT T1 WHERE T1.SBDATE <= (CURRENT DATE - 00210000.)";
}

Este método se ejecuta desde la clase local (home) y tiene un comportamiento de colocación en antememoria de objetos similar al del método All-instances. Para obtener más información acerca de este método, consulte la ayuda en línea de Persistence Builder.

Parte 2: Características de tiempo de ejecución

1.0 Posibilidad de almacén de datos/transaccional

Data Access Builder

Los almacenes de datos de Data Access Builder se pueden configurar en numerosos niveles de aplicación:

• El almacén de datos de aplicación se utiliza como almacén de datos por omisión y todas las clases comerciales generadas pueden utilizarlo si no se ha definido ninguno.
• El almacén de datos de clase por omisión especifica a nivel de clase lo que utilizan las instancias como almacén de datos.
• El almacén de datos del objeto especifica el almacén de datos al nivel de instancia.

Los almacenes de datos de Data Access Builder tienen un modelo transaccional plano; en otras palabras, si se necesitan múltiples transacciones para aplicar una función comercial, será necesario activar un almacén de datos que represente cada transacción.

He aquí un escenario sencillo con un modelo de Empleado y Departamento:

EmployeeDatastore anEmpDS = new EmployeeDatastore().connect();
DepartmentDatastore aDeptDS = new DepartmentDatastore().connect();

Employee anEmp = new Employee();
Department aDept = new Department();

// Realizar acciones en anEmp y aDept

if (Cambios de Employee aplicados por usuario)
anEmpDS.commit()
else
anEmpDS.rollback();
aDeptDS.commit();

Persistence Builder

En VisualAge para Java, Versión 4.0, Persistence Builder tiene la opción de utilizar la agrupación de conexiones de WebSphere utilizando el nombre de JNDI para hacer una búsqueda en el origen de datos. Esta opción está disponible cuando se generan las clases de servicio.

En Persistence Builder solo se requieren múltiples almacenes de datos cuando se utilizan bases de datos diferentes para acceder a los datos de modelo. Se da soporte a múltiples transacciones anidadas por almacén de datos. Las transacciones no intervienen, puesto que están en Data Access Builder. Las transacciones de usuario se controlan mediante los objetos transacción que tienen vistas en los objetos comerciales de la aplicación.

He aquí un fragmento de código que muestra la misma posibilidad transaccional en el ejemplo de Data Access Builder.

DB2Datastore aDS = DB2Datastore.singleton().activate();
Transaction empTransaction = Transaction.begin();
Employee anEmp = EmployeeHomeImpl.create("EmpNum1");
Transaction deptTransaction = Transaction.begin();
Department aDept = DepartmentHomeImpl.create("DeptNum1");

// Realizar algunas acciones en anEmp y aDept, reanudando siempre la transacción adecuada antes de efectuar cambios en el BO correspondiente.

if (Cambios de Employee aplicados por usuario)
    empTransaction.commit();
else
    empTransaction.rollback();
deptTransaction.commit();

Es importante observar que, en Persistence Builder, no se ejecuta SQL hasta que se compromete una transacción. El estado transaccional de los objetos se mantiene internamente hasta que se produce un compromiso o una retrotracción de manera explícita.

2.0 Soporte de API

Los métodos generados en los objetos comerciales resultantes y sus objetos acompañantes de gestión son ligeramente distintos en las tres infraestructuras. La siguiente tabla muestra las clases y los métodos utilizados para cada función.

(*) Las operaciones de actualización son implícitas al alterar los valores en un objeto comercial; si la transacción activa se compromete, los cambios se sincronizarán con el almacén de datos emitiendo las sentencias de actualización adecuadas.

(**) La sección Soporte de cursor muestra soluciones alternativas.

Soporte de LOB

3.0 Formatos rápidos (características RAD)

4.0 Soporte de Fecha/Hora/Indicación de hora "actual"

Las herramientas de Data Access Builder permiten al usuario especificar "current" (actual) en los datos de tipo fecha/hora, lo que genera la SQL adecuada. Persistence Builder y los beans de acceso a datos (DAB) no dan soporte a esta característica en sus herramientas, pero el código SQL se puede añadir manualmente.

5.0 Soporte de cursor

Data Access Builder da soporte a las funciones de cursor en los conjuntos de resultados, como updateCurrent() o deleteCurrent().

Persistence Builder no da soporte actualmente a estas operaciones. Una buena alternativa en este caso sería utilizar la característica Data Access Beans (beans de acceso a datos).

Los beans de acceso a datos (Data Access Beans) dan soporte a las funciones de cursor con el componente visual DBNavigator que gestiona la posición del cursor. A continuación se proporciona una descripción de todas las características de cursor:

• Soporte de antememoria para conjuntos de resultados.
• Acceso directo a fila específica en antememoria.
• Desplazamiento de avance y retroceso.
• Soporte para grandes conjuntos de resultados con opciones especificadas por usuario.

JDBC v1.0 no da soporte al desplazamiento de retroceso en un conjunto de resultados JDBC. El bean Select mantiene una antememoria del conjunto de resultados que permite desplazarse por él, así como acceder directamente a una fila específica. El bean Select tiene propiedades que permiten controlar el tamaño de la antememoria. Se puede llevar todo el conjunto de resultados a la antememoria (es el valor por omisión) o llevar solo un paquete cada vez. El tamaño y el número de paquetes lo controla el usuario.

• Proporciona soporte de actualización/inserción/supresión para el conjunto de resultados

Cuando se ha obtenido un conjunto de resultados, el bean Select proporciona métodos para actualizar, suprimir o insertar filas en él. El usuario no tiene que escribir código SQL nuevo para realizar estas funciones.

Data Access Builder da soporte a la operación asíncrona proporcionando interfaces ejecutables en sus clases generadas.

Persistence Builder también proporciona interfaces ejecutables para cada operación CRUD y una para las consultas personalizadas. El objeto de servicio de cada clase comercial tiene el método runAsynch(), que determina el tipo de ejecución para esa clase.

Los beans de acceso de datos (DAB) dan soporte a la ejecución asíncrona mediante la herramienta DBNavigator, que engendra instancias ejecutables de "DBAction".

Cuestiones de concurrencia (niveles de bloqueo/aislamiento)

Data Access Builder tiene una API para establecer el nivel de aislamiento de base de datos en la clase setTransactionIsolation(int) del almacén de datos generado.

Persistence Builder mantiene sus propias transacciones y da soporte a los siguientes niveles de aislamiento internamente.

• Lectura repetible no de bloqueo
• Lectura irrepetible no de bloqueo
• Lectura repetible de bloqueo
• Lectura irrepetible de bloqueo.

La Transacción especifica el nivel de aislamiento de Lectura repetible o Lectura irrepetible. La implementación de servicio de la clase comercial (Business) especifica la implementación de bloqueo o no de bloqueo. Consulte la ayuda en línea de Persistence Builder para conocer más detalles acerca de las diferencias entre los niveles.

Los beans de acceso a datos (DAB) tienen una API para establecer el nivel de aislamiento de base de datos. Esto puede hacerse especificando el nivel de aislamiento deseado cuando se suministra la información de conexión mediante el editor de propiedades personalizado o mediante el método DatabaseConnection.setTransactionIsolation().

Parte 3: Características de los beans de acceso a datos (DAB)

La correlación para DAB tiene lugar entre las tablas y los beans Select. Esta correlación entre una tabla y un bean Select no es 1:1 y, por consiguiente, el bean Select no representa la tabla. Sin embargo, los beans Select pueden resultar muy útiles para trabajar con la fila actual y con un conjunto de resultados. Se pueden crear uno o dos beans Select que se pueden utilizar para hacer operaciones básicas de programación de base de datos en una tabla. Por lo tanto, si se utiliza DAX para operaciones de base de datos como las consultas, la lectura, la escritura, la actualización y la supresión de una forma sencilla y directa, DAB puede ser un buen sustituto para DAX.

Es posible interaccionar con las bases de datos estableciendo la propiedad query (que consta de información de conexión e información de consulta SQL) de un bean Select. La información de conexión que contiene la propiedad query la puede utilizar más de un bean Select. Se pueden incorporar beans Select al código visualmente, utilizando el Editor de composición visual, o manualmente. 

A continuación se proporciona un resumen general de cómo crear un bean Select para trabajar con la fila actual de una tabla de cliente. Consulte la ayuda en línea para obtener información más detallada acerca de cómo realizar estos pasos:

1. Abra una clase en VCE, cree un bean Select y abra el editor de propiedades de consulta.  
2. Entre la información de conexión necesaria y genere una clase de acceso a base de datos.
3. Especifique la clase de acceso a base de datos. Abra el SmartGuide SQL Assist.

   

4. Al seleccionar la tabla de cliente y especificar la condición de que el número de cliente (cusno) es exactamente igual al parámetro CUSTNUM se genera un bean Select para el cliente. La clase de acceso a base de datos para este bean Select será similar a la siguiente:

   

Con este bean Select se pueden realizar operaciones básicas de base de datos (lectura, escritura, actualización y supresión) en una fila de la tabla de cliente (cuando se especifica el número de cliente).  

Creación de un segundo bean Select

Se puede crear otro bean Select para trabajar con un conjunto de resultados (es decir, efectuar una consulta de base de datos) llevando a cabo el mismo procedimiento y no especificando ninguna condición. Este segundo bean Select permitirá aprovechar las ventajas de la funcionalidad del conjunto de resultados de DAB. La clase de acceso a base de datos (DatabaseAccess) para este bean Select será similar a la siguiente:

Beans Select y consultas personalizadas

DAB proporciona un potente soporte para crear beans Select que utilizan consultas personalizadas. Tal como se muestra a continuación, el SmartGuide SQL Assist puede ayudarle a crear una consulta de unión, especificar condiciones para una consulta, seleccionar columnas, ordenar columnas y correlacionar campos.

Beans de acceso a datos (DAB) y procedimientos almacenados

El bean Procedure Call (llamada a procedimiento) permite trabajar con procedimientos almacenados. El proceso de crear un bean Procedure Call es muy similar al de crear un bean Select. El SmartGuide para procedimientos almacenados enumera los procedimientos almacenados disponibles, tal como se muestra a continuación.

Para obtener más información acerca de cómo utilizar el bean Procedure Call consulte la ayuda en línea de los beans de acceso a datos (DAB).

Copyright y avisos

© Copyright IBM Corp. 1997, 2001. Reservados todos los derechos.

Nota sobre los derechos restringidos de los usuarios del Gobierno de EE. UU. -- Utilización, reproducción o divulgación restringida por el GSA ADP Schedule Contract.

Esta información se ha desarrollado para los productos y los servicios que se ofrecen en Estados Unidos. Es posible que IBM no ofrezca en otros países los productos, los servicios o las características que se describen en este documento. Consulte con el representante local de IBM para obtener información acerca de los productos y servicios que actualmente están disponibles en su zona. Las referencias hechas a productos, programas o servicios de IBM no pretenden afirmar ni dar a entender que únicamente puedan utilizarse dichos productos, programas o servicios de IBM. Puede utilizarse en su lugar cualquier otro producto, programa o servicio funcionalmente equivalente que no vulnere ninguno de los derechos de propiedad intelectual de IBM. No obstante, es responsabilidad del usuario evaluar y verificar el funcionamiento de cualquier producto, programa o servicio que no sea de IBM.

El párrafo siguiente no puede aplicarse en el Reino Unido ni en cualquier otro país en el que tales disposiciones sean incompatibles con la legislación local:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL", SIN GARANTÍA DE NINGUNA CLASE, EXPLÍCITA O IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN, COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunas legislaciones no contemplan la limitación de responsabilidad de las garantías, ni implícitas ni explícitas, en determinadas transacciones, por lo que cabe la posibilidad de que esta declaración no se aplique en su caso. Esta información puede contener imprecisiones técnicas o errores tipográficos. Periódicamente, se efectúan cambios en la información incluida en este documento; estos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras y/o cambios en los productos y/o programas descritos en esta publicación en cualquier momento y sin previo aviso.

Cualquier referencia hecha en esta información a sitios web que no sean de IBM se proporciona únicamente para su comodidad y no debe considerarse en modo alguno como promoción de esos sitios web.

Los materiales de estos sitios web no forman parte de los materiales de IBM para este producto y el uso que se haga de estos sitios web es de la entera responsabilidad del usuario. IBM puede utilizar o distribuir la información que usted le suministre del modo que IBM considere conveniente sin incurrir por ello en ninguna obligación para con usted. IBM proporciona el programa bajo licencia descrito en este documento, así como todo el material bajo licencia disponible, según los términos del Acuerdo de Cliente de IBM, del Acuerdo Internacional de Programas bajo Licencia de IBM o de cualquier otro acuerdo equivalente entre ambas partes.

IBM, AIX, AS/400, DB2, OS/390, OS/400, RS/6000, S/390, VisualAge y WebSphere son marcas registradas de IBM Corporation en Estados Unidos y/o en otros países.

Lotus, Lotus Notes y Domino son marcas registradas de Lotus Development Corporation en Estados Unidos y/o en otros países. Java y todas las marcas y logotipos basados en Java son marcas registradas de Sun Microsystems, Inc., en Estados Unidos y/o en otros países. Microsoft, Windows y Windows NT son marcas registradas de Microsoft Corporation en Estados Unidos y/o en otros países. Intel y Pentium son marcas registradas de Intel Corporation en Estados Unidos y/o en otros países. Los demás nombres de compañías, productos y servicios pueden ser marcas registradas o de servicio de otras empresas.