Im pdf-Verzeichnis steht ebenfalls eine PDF-Version dieses Handbuchs zur Verfügung. Das pdf-Verzeichnis befindet sich auf der Produkt-CD von VisualAge für Java, Professional Edition sowie auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition.
Wo finde ich weitere Informationen zu VisualAge für Java?
Diese Datei enthält keine detaillierten Informationen über die spezifischen Komponenten und Elemente von VisualAge für Java. Diese Informationen finden Sie in den Release-Hinweisen zum Produkt. Wählen Sie hierzu Start > Programme > IBM VisualAge for Java für Windows V4.0 > Release-Hinweise aus. Für alle anderen Sprachen können die Release-Hinweise auf der Produkt-CD (nach der Installation) und im Web unter http://www.ibm.com/vadd. abgerufen werden.
Diese Datei enthält keine Informationen zur Verwendung von VisualAge für Java. Diese Informationen finden Sie im Handbuch "Erste Schritte" und in der Online-Hilfe. Ein Teil der Online-Hilfe liegt in PDF-Dokumenten vor, die Sie mit Hilfe von Adobe Acrobat Reader anzeigen und drucken können (Adobe Acrobat Reader kann unter folgender Adresse kostenlos heruntergeladen werden: http://www.adobe.com/). Nicht für jede Sprache steht auch eine landessprachliche PDF-Version zur Verfügung. Die PDF-Dateien stehen im Verzeichnis 'pdf' zur Verfügung. Das pdf-Verzeichnis befindet sich auf der Produkt-CD von VisualAge für Java, Professional Edition sowie auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben. Wenn Sie nicht das Archiv heruntergeladen haben, das die PDF-Dateien enthält, steht dieses Verzeichnis jedoch nicht zur Verfügung.
Der PDF-Index (im Handbuch "Erste Schritte") enthält Informationen über den Inhalt der einzelnen PDF-Dateien. Die Online-Hilfe enthält ebenfalls den Abschnitt "Web-Ressourcen", über den Links zu VisualAge-Ressourcen bereitgestellt werden, die im Internet verfügbar sind.
Die Web-Site VisualAge Developer Domain (VADD) bietet technische Artikel, Lerntexte, Beispiele und FAQs, sowie den einfachen Zugriff auf Unterstützung und Produktaktualisierungen für VisualAge für Java. Auf dieser Site können Sie die Entwicklungs-Tools von VisualAge für Java herunterladen sowie wiederverwendbare Beans, Assistenten und Toolkits, um Ihre Applet- und Servlet-Entwicklung zu ergänzen. Siehe http://www.ibm.com/vadd. Sie können diese Site ebenfalls zum Anfordern von Funktionen verwenden, die in neuen Releases von VisualAge für Java implementiert werden.
Wenn Sie bereits Ihre Registrierung für VisualAge Developers Domain durchgeführt haben, müssen Sie diese nicht erneut durchführen. Sie können Ihre momentane ID und und Ihr Kennwort dazu verwenden, aktuelle Informationen und Codeaktualisierungen zu erhalten. Wenn Sie ein Erstbenutzer sind, enthält die Box (oder das Media-Kit), welche(s) Sie erhalten haben, eine Subskriptionsnummer. Haben Sie VisualAge für Java gekauft und keine Subskriptionsnummer erhalten, wenden Sie sich an Ihren IBM(R) Vertriebsbeauftragten.
Die Home-Page für VisualAge für Java hat folgende Adresse: http://www.ibm.com/software/ad/vajava
Teil A: VisualAge für Java, Professional Edition
1.0 Voraussetzungen
2.0 Installation
2.1 Installation von VisualAge für
Java, Version 4.0
2.2 Installation zusätzlicher Komponenten
nach der Erstinstallation
2.3 Installation
für Windows(R) 2000
2.4 Installation des IBM Developer Kit, Java Technology Edition, v1.2.2
3.0 Migration von
einer früheren Version von VisualAge für Java
3.1 Migration von VisualAge für
Java Version 3.5 oder Version 3.5.3
3.2 Migration von Version
2.0, 3.0x oder 3.0x Early Adopters von VisualAge für Java
4.0 Bekannte Probleme und Einschränkungen
4.1 Bekannte Probleme
und Einschränkungen bei der Installation
4.2 Bekannte Probleme
und Einschränkungen bei der Deinstallation
Teil B: VisualAge für Java, Enterprise Edition
1.0 Voraussetzungen
1.1 Allgemeine
Voraussetzungen
1.2
Komponentenspezifische Voraussetzungen
2.0 Installation
2.1 Installation von VisualAge für
Java, Version 4.0
2.2 Installation zusätzlicher Komponenten
nach der Erstinstallation
2.3 Installation der VisualAge
für Java-Team-Clients
2.4 Installation eines Clients, der
ein Standalone-Repository hat
2.5 Installation und Benutzerhinweise
für Windows(R) 2000
2.6 Installation des IBM Developer Kit, Java Technology
Edition, v1.2.2
3.0 Migration von einer
früheren Version von VisualAge of Java
3.1 Migration eines
gemeinsam benutzten Repository von einer früheren Version von VisualAge für Java
4.0 Bekannte Probleme und Einschränkungen
4.1 Bekannte Probleme
und Einschränkungen bei der Installation
4.2 Bekannte Probleme und Einschränkungen
bei der Deinstallation
Teil C: Team-Repository-Server (EMSRV)
1.0 Voraussetzungen
1.1 Unterstützte Plattformen
1.2 TCP/IP
1.3 Erforderliche Novell-Patches
zur Ausführung von EMSRV auf NetWare 4.x
1.4 Erforderliches Solaris-Patch
zur Ausführung von EMSRV auf Solaris
1.5 Unterstützte
Dateisysteme
2.0 Installation
2.1 Installation von EMSRV für Windows(R)
2.1.1 Installation von EMSRV als einen Dienst in der
Windows-Registrierung
2.2 Installation von EMSRV für
NetWare
2.3 Installation von
EMSRV für OS/2 (R) Warp
2.4 Installation von EMSRV für AIX
2.5 Installation von EMSRV für
HP-UX/Solaris(TM)
2.6 Installation von EMSRV für Linux
3.0 Migration
3.1 Migration von Version 6.x/7.0 von EMSRV auf Version 7.1
4.0 Vorbereitungen für die Entwicklung im Team
4.1 Vorbereitungen für den
Team-Server
4.2 Testen einer
Client-Verbindung
4.3 Hinzufügen
von Benutzern zur Repository-Benutzerliste
5.0 Einschränkungen und bekannte Probleme
5.1 Leistungen auf Netzwerken mit geringer Bandbreite und hoher Latenz
5.2 Einschränkungen bei der TCP/IP-Verbindung
5.3 Feststellen von unerwartet
unterbrochenen Verbindungen
5.4 Wechsel zwischen
verschiedenen Versionen von EMSRV- und EMSRV-Utilities
5.5 PAM-Einschränkungen
5.6 Kennwörter mit
nicht-ASCII-Zeichen können nicht zur Authentifizierung in EMSRV verwendet werden
5.7 Bei Ausführung in der japanischen NetWare-Version werden Menüs und
Fenster mit 'zerschossenen Zeichen' angezeigt
5.8 EMADMIN
kopiert das Verzeichnis der gespeicherten Ressourcen nicht
Teil D: Komponentenspezifische Migrationsinformationen
1.0 CICS(R) Transaction Server * +
2.0 Data Access Beans für den Zugriff auf Daten
3.0 Data Access Builder * +
4.0 EJB(TM)-Entwicklungsumgebung+
5.0 Enterprise Access Builder und e-Konnektoren +
6.0 Enterprise Toolkit für AS/400(R) +
7.0 Enterprise Toolkit für
OS/390(R) +
8.0 Enterprise Toolkit für Workstations
* +
9.0 Externe Versionskontrolle
10.0 IDL-Entwicklungsumgebung +
11.0 Integrierte Entwicklungsumgebung (Integrated Development Environment - IDE)
12.0 EJB-Entwicklungsumgebung (EJB Development Environment)
13.0 Migrationsunterstützung (Migration Assistant) *
14.0 Persistence Builder +
15.0 RMI Access Builder * +
16.0 Visual Composition Editor
17.0 Servlet Builder und Servlet
Launcher * +
18.0 Swing-Klassen
19.0 XMI Toolkit +
* Diese Komponenten werden in VisualAge für Java, Version 4.0 nicht unterstützt.
+ Nur Enterprise Edition
Teil E: Allgemeine Informationen
1.0 Arbeiten mit Projektressourcen
und Ressourcenverwaltung
2.0 Migration von OS/2 und AIX
3.0 Neue Sicherheitseinschränkungen
in J2SDK v.1.2.2
4.0 Neues Tool zur externen
Versionssteuerung (ersetzt externes SCM-Tool)
5.0 Arbeiten mit ORBs (Object Request Broker)
anderer Hersteller in VisualAge für Java
6.0 Inhalt der CD für zusätzliche Funktionen (Additional Features)
Anhänge
Anhang A: Ein Vergleich der Komponenten für den Datenzugriff
Bei dieser Edition von VisualAge für Java, Version 4.0 sind die folgenden Hardware- und Softwarevoraussetzungen zu beachten:
Wenn Sie den Websphere Application Server gleichzeitig mit DB2(R) und VisualAge für Java ausführen wollen, benötigen Sie mindestens 512 MB.
* Hinweis: VisualAge für Java unterstützt die Logitech-Scroll-Maus nicht. Jede Logitech-Maus mit Treibern, die den Verschiebevorgang erneut der Maus zuordnen, verursacht einen Systemfehler, wenn sie zum Verschieben verwendet wird.
Dieser Abschnitt enthält Informationen zur Installation von VisualAge für Java, Version 4.0 Wichtig: Wenn Sie von einer früheren Version von VisualAge für Java migrieren, lesen Sie den Abschnitt 3.0 bevor Sie Version 4.0 installieren. Spezielle Informationen für das Installieren unter Windows 2000 finden Sie in Abschnitt 2.3.
Beachten Sie bitte ebenfalls die Informationen zu neuesten Meldungen und Einschränkungen in der README, die Sie im Verzeichnis README der Produkt-CD finden.
A.2.1 Installation von VisualAge für Java, Version 4.0
Überprüfen Sie folgende Punkte, bevor Sie das Produkt installieren:
Wenn Sie VisualAge für Java unter der Windows Millennium Edition installieren wollen, werden Sie dazu aufgefordert, Ihren Umgebungsspeicherbereich zu erhöhen. die nachfolgend beschriebenen Schritte müssen vor der Installation ausgeführt werden; andernfalls funktioniert das Hilfesystem von VisualAge für Java nicht korrekt. Führen Sie die folgenden Schritte aus, um den Umgebungsspeicherbereich zu erhöhen:
A.2.1.1 Installation von VisualAge für Java, Version 4.0, von der Produkt-CD
Installation ohne Benutzerinteraktion
Um VisualAge für Java, Version 4.0, ohne Benutzerinteraktion zu installieren,
setzen Sie im Verzeichnis ivj40\setup den folgenden Befehl ab:
setup /s /v/qn
VisualAge für Java wird automatisch im Standardverzeichnis c:\Programme\IBM\VisualAge for Java installiert.
Um eine Installation ohne Benutzerinteraktion in ein anderes Verzeichnis zu starten (beispielsweise in d:\IBMVJava40), setzen Sie im Verzeichnis ivj40\setup den folgenden Befehl ab:
setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"
wobei d:\IBMVJava40 das Verzeichnis ist, in das Sie VisualAge installieren wollen.
A.2.1.1.1 Installation des Distributed Debugger von der Produkt-CD
Wenn Sie beabsichtigen,
Klassen zu debuggen, die nicht in der VisualAge für Java IDE erstellt wurden oder Programme
zu debuggen, die auf einer anderen Maschine ausgeführt werden, müssen Sie den Distributed Debugger
installieren. Der Distributed
Debugger wird auf den folgenden Betriebssystemen unterstützt: Windows,
AIX, OS/2, HP-UX, Solaris, Linux und Linux/390. Installationsanweisungen für jedes einzelne Betriebssystem
werden nachfolgend gegeben. Alle Dateien des Distributed Debugger
befinden sich auf der im Debugger-Verzeichnis.
Distributed Debugger für Windows
Distributed Debugger für OS/2
Befolgen Sie die Anweisungen in der Datei README_install.txt, die sich im Unterverzeichnis Debugger\OS2 auf der Produkt-CD befindet.Distributed Debugger für HP-UX
Voraussetzung:
Java Version 1.3 ist für die Installation und für Java-Debugging erforderlich.
Distributed Debugger für Linux
Geben Sie als Root-Benutzer den folgenden Befehl ein, um den Debugger zu installieren: rpm -Uvh DERJPICL-9-1.i386.rpmDistributed Debugger für Linux/390
Geben Sie als Root-Benutzer den folgenden Befehl ein, um den Debugger zu installieren: rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger für OS/390
Installation der elektronischen Version von VisualAge für Java, Version 4.0
Um die Downloadzeiten zu reduzieren, wurde die elektronische Version von
VisualAge für Java, Professional Edition für Windows, Version 4.0 in verschiedene
Programmteile bzw. 'Archivpakete' unterteilt.
A.2.1.2.1 IDE
Für die integrierte Entwicklungsumgebung stehen neun herunterladbare Archive zur Verfügung.
Alle neun Pakete sind selbstextrahierende Archive. Sie müssen die ersten beiden installieren; die
übrigen sind optional. Nachstehend finden Sie eine Liste mit dem jeweiligen Inhalt der einzelnen
Archive.
Nachdem Sie die ersten beiden Archive sowie die gewünschten optionalen Dateien heruntergeladen haben, entpacken Sie bitte alle selbstextrahierenden Archive in dasselbe temporäre Verzeichnis. Nach dem Entpacken wechseln Sie in dieses temporäre Verzeichnis und führen Sie setup.exe aus. Befolgen Sie die Anweisungen auf dem Bildschirm und starten Sie die IDE.
Wenn Sie in einer anderen Landessprache als Englisch arbeiten wollen, müssen Sie darauf achten, die korrekten Archive herunterzuladen und das selbstentpackende Archiv für die gewünschte Sprache auszuführen, bevor Sie setup.exe ausführen. Nach der Installation von VisualAge für Java können Sie weder eine Sprache ändern noch hinzufügen.
Wenn Sie mit einem elektronischen Image von VisualAge für Java arbeiten, können Sie den Dialog Hinzufügen/Entfernen (Start -> Einstellungen -> Systemsteuerung -> Programme hinzufügen/entfernen) nicht verwenden, um zusätzliche VisualAge für Java-Komponenten nach der ersten Installation zu installieren. Wenn Sie dies dennoch tun, erhalten Sie eine Fehlernachricht und können keine zusätzlichen Komponenten installieren. Sie müssen setup.exe von dem Pfad aus ausführen, in dem Sie die heruntergeladenen Teile extrahiert haben, damit alle zusätzlichen Komponenten VisualAge für Java hinzugefügt werden können.
Die einzelnen Archive haben jeweils den folgenden Inhalt:
A.2.1.2.2 Distributed Debugger
Für jede vom Distributed Debugger unterstützte Zielplattform steht ein separat
herunterladbares Paket zur Verfügung. Wenn Sie beabsichtigen,
Klassen zu debuggen, die nicht in der VisualAge für Java IDE erstellt wurden oder Programme
zu debuggen, die auf einer anderen Maschine ausgeführt werden, müssen Sie den Distributed Debugger
herunterladen und installieren.
Installationsanweisungen für jedes einzelne Betriebssystem
werden nachfolgend gegeben.
Sie finden diese Anweisungen sowie Informationen zur
Lizenzvereinbarung auch in der Datei 'readme.txt', die in jeder Komponente enthalten ist.
VisualAge for Java - Distributed Debugger for Windows enthält die Benutzerschnittstelle und die Debug-Engine für Windows. Dieses Paket ist ein selbstextrahierendes Archiv. Führen Sie folgende Schritte aus, um es zu installieren:
VisualAge for Java - Distributed Debugger für HP-UX enthält die Debug-Engine für HP-UX.
Voraussetzung:
Java Version 1.3 ist für die Installation und für Java-Debugging erforderlich.
Um dieses Paket zu installieren, entpacken Sie die Datei und befolgen Sie die folgenden Anweisungen.
VisualAge for Java - Distributed Debugger für Linux enthält die Debug-Engine für Linux. Um dieses Paket zu installieren, entpacken Sie die Datei und installieren Sie den Debugger, indem Sie die folgenden Anweisungen befolgen.
Geben Sie als Root-Benutzer den folgenden Befehl ein: rpm -Uvh DERJPICL-9-1.i386.rpmVisualAge for Java - Distributed Debugger für Linux/390 enthält die Debug-Engine für Linux/390. Um dieses Paket zu installieren, entpacken Sie die Datei und installieren Sie den Debugger, indem Sie die folgenden Anweisungen befolgen.
Geben Sie als Root-Benutzer den folgenden Befehl ein: rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger für OS/390
A.2.1.2.3 IBM Developer Kit 1.2.2
VisualAge for Java - IBM Developer Kit 1.2.2 enthält das IBM Developer Kit, Java Technology
Edition, v 1.2.2, PTF 9, für die Windows-Plattform. Dies ist ein selbst extrahierendes Archiv.
Um es zu installieren, führen Sie die Exe-Datei aus. Nach dem
Extrahieren wird automatisch das Installationsprogramm aufgerufen.
Befolgen Sie die darin gegebenen Anweisungen.
A.2.2 Installation zusätzlicher Komponenten nach der Erstinstallation
Wenn Sie nach der Erstinstallation weitere Komponenten von VisualAge für Java installieren möchten, legen Sie einfach die Produkt-CD in Ihr CD-Laufwerk ein und wählen Sie VisualAge für Java installieren aus. Wählen Sie anschließend in der Programmpflegeanzeige Modifizieren aus. Ist autorun auf Ihrem System inaktiviert, führen Sie setup.exe vom Stammverzeichnis des CD-Laufwerks aus. Wenn Sie eine elektronische Version von VisualAge für Java haben, müssen Sie setup.exe ebenfalls manuell ausführen und anhand derselben Schritte vorgehen.
Alle Komponenten werden im Fenster Features bearbeiten aufgelistet, wobei ihr jeweiliger Installationsstatus erkennbar ist. Ein rotes 'X' bedeutet, dass die Komponente derzeit nicht installiert ist. Diese Komponenten können Sie zur nachträglichen Installation auswählen. Wählen Sie keine Komponenten aus, die nicht mit einem roten 'X' markiert sind; sie sind bereits installiert.
Sie können kein zweites Exemplar von VisualAge für Java, Version 4.0, installieren. Sie können die Installationssprache nicht ändern, ohne das Produkt zuerst zu deinstallieren.
A.2.3 Installationsvoraussetzungen für Windows 2000
Dieses Release von VisualAge für Java für to bietet Toleranzunterstützung (gemäß der Definition von Microsoft) für Windows 2000.
Das Standardinstallationsverzeichnis lautet <Programme>\IBM\VisualAge for Java. Unter Windows 2000 kann die Installation unter <Programme> standardmäßig nur von Administratoren und Hauptbenutzern ausgeführt werden. Normale Benutzer (ohne spezielle Berechtigungen) können nicht in diese Position schreiben.
Aufgrund des derzeitigen Designs von VisualAge für Java müssen bei Installation des Produkts an diese Position und für den Fall, dass es von einem normalen Benutzer verwendet werden soll, die Sicherheitseinstellungen für das Verzeichnis IBM oder IBM\VisualAge for Java unter <Programme> geändert werden, damit das Produkt von normalen Benutzern verwendet werden kann. Werden diese Änderungen nicht vorgenommen, kann es beim Start der IDE zu Fehlern kommen.
A.2.4 Installation des IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9
Wenn Sie VisualAge für Java von der Produkt-CD installiert haben, führen Sie im Verzeichnis 'IBM Developer Kit' die Datei install.exe aus, um IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9 zu installieren. Dieses Verzeichnis befindet sich auf der Produkt-CD. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Komponenten entpackt haben. Sie brauchen die Datei install.exe jedoch nicht auszuführen, da das Installationsprogramm nach der Extraktion aus dem heruntergeladenen IBM Developer Kit-Archiv automatisch gestartet wird.
Ausführliche Informationen zum IBM Developer Kit finden Sie in der README-Datei im Verzeichnis 'IBM Developer Kit'.
Lesen Sie erst die komponentenspezifischen und allgemeinen Migrationsinformationen in Teil D und Teil E, bevor Sie mit dem Migrationsprozess beginnen.
Sie können automatisch von Version 3.5 oder Version 3.5.3 migrieren. Version 4.0 wird über Version 3.5 oder Version 3.5.3 installiert. Im Abschnitt 3.1 finden Sie Informationen zur Migration von VisualAge für Java, Version 3.5 oder Version 3.5.3.
Sie müssen manuell von Version 3.0x, Early Adopters migrieren. Im Abschnitt 3.2 sind Informationen zur Migration von VisualAge für Java, 3.0x, Early Adopters enthalten.
Wenn Sie gegenwärtig VisualAge für Java, Version 2.0, 3.0 oder 3.02 mit JDK 1.1.x-Unterstützung verwenden, ist eine automatische Migration auf VisualAge für Java, Version 4.0 nicht möglich. Diese Versionen von VisualAge für Java können mit VisualAge für Java, Version 4.0 zusammen existieren. Im Abschnitt 3.2 weiter unten finden Sie Informationen zur Migration Ihres Repository-Inhalts und Ihrer Ressourcendateien von VisualAge für Java, Version 2.0 oder 3.0x.
Bitte beachten Sie, dass eine Migration von VisualAge für Java, Version 3.5, Entry Enterprise Edition, oder VisualAge für Java, Version 3.5 oder Version 3.5.3, Enterprise Edition auf VisualAge für Java, Version 4.0, Professional Edition nicht möglich ist. Sie müssen auf Version 4.0, Enterprise Edition, migrieren.
Hinweis: Wenn Sie von VisualAge für Java, Version 3.5 oder Version 3.5.3 auf Version 4.0 migrieren, kann es passieren, dass der Installationsprozess "hängt". Dies hat seinen Grund darin, dass die Funktion "DoCosting" (die die 3.5-Versionen oder die 3.5.3-Versionen von Dateien mit den 4.0-Versionen von Dateien vergleicht) bis zu drei Minuten zur Ausführung benötigen kann, was wiederum den Eindruck erweckt, als ob der Installationsprozess "hängt" und inaktiv sei.
A.3.1 Migration von Version 3.5 oder von Version 3.5.3
Die Migration von VisualAge für Java, Version 3.0 oder Version 3.5.3 erfolgt automatisch. Das Installationsprogramm der Version 4.0 führt ein automatisches Upgrade eines installierten Exemplars von Version 3.5 oder Version 3.5.3 des Produkts auf Version 4.0 durch.
Automatische Migration
Wenn die Installation fehlschlägt, müssen Sie Ihre Benutzerdaten manuell migrieren. Sie müssen die Benutzerdaten auch dann manuell migrieren, wenn die IDE nicht gestartet werden kann oder wenn die IDE beim Migrieren Ihrer Benutzerdaten einen Fehler feststellt.
Manuelle Migration
A.3.2 Migration von Version 2.0, 3.0x oder 3.0x Early Adopters von VisualAge für Java
Sie können den Inhalt Ihres Repositorys und Ihre Ressourcendateien manuell von Version 2.0, Version 3.0x, 3.0x, Early Adopters von VisualAge für Java migrieren. Informationen zum Reparieren von unterbrochenen Referenzen finden Sie in der Online-Hilfe im Abschnitt "Klassen- oder Paketreferenzen reparieren".
Sie müssen Version 2.0 or 3.0x or 3.0x, Early Adopters jedoch nicht deinstallieren; eine Koexistenz mit VisualAge für Java, Version 3.5.3 ist möglich.
Führen Sie alle nachstehend aufgeführten Schritte aus, bevor Sie Version 2.0, 3.0x oder 3.0x, Early Adopters, deinstallieren, wenn Sie Ihr Repository und Ihre Ressourcendateien aus Version 2.0, 3.0x oder 3.0x Early Adopters Environment for Java 2 Platform, Standard Edition, in Version 4.0 importieren wollen. Wenn Sie Version 2.0, 3.0x or 3.0x, Early Adopters, nicht deinstallieren, müssen Sie die Schritte 2, 3, 4 und 8 nicht ausführen, jedoch alle anderen Schritte.
Beachten Sie bitte ebenfalls die Informationen zu neuesten Meldungen und Einschränkungen in der README, die Sie im Verzeichnis README der CD finden.
A.4.1 Bekannte Probleme und Einschränkungen bei der Installation
Nachfolgend sind einige Punkte aufgelistet, die Sie bei der Installation beachten sollten:
A.4.1.1 Einschränkungen bei Festplatten
A.4.1.2 Benutzerberechtigung
A.4.1.3 TCP/IP-Voraussetzungen
Diese Konfigurationsoptionen gelten für alle TCP/IP-Adapter, auch dann, wenn die Optionen nur für diesen einen Adapter geändert wurden. Sie können nicht sowohl eine LAN-Konfiguration als auch eine Wahlkonfiguration verwenden, ohne zuvor eine Neukonfigurierung durchgeführt zu haben.
Die TCP/IP-Wahlnetzwerkeigenschaften für Ihre(n) Internet-Service-Provider (ISP) müssen so konfiguriert sein, wie dies durch den jeweiligen ISP dokumentiert ist. Die TCP/IP-Wahlnetzwerkeigenschaften setzen die TCP/IP-Eigenschaften außer Kraft, die für den Wahl-Adapter über das Symbol 'Netzwerk' in der Systemsteuerung von Windows 98 oder Windows 2000 konfiguriert wurden. Dieses außer Kraft Setzen erfolgt jedoch nur, wenn die TCP/IP-Eigenschaften für den Wahl-Adapter wie oben beschrieben konfiguriert sind. Sie dürfen den DNS in den TCP/IP-Eigenschaften des Wahl-Adapters nicht aktivieren; weiterhin dürfen Sie nicht eine IP-Adresse in den TCP/IP-Eigenschaften des Wahl-Adapters angeben, da in diesem Fall ein Konflikt mit der Konfiguration des Wahlnetzwerks für den ISP auftritt.
Unter Windows NT 4.0 können beide der oben beschriebenen TCP/IP-Konfigurationen verwendet werden. Wenn Sie VisualAge für Java auf einer eigenständigen Maschine ausführen, können Sie auch den Microsoft Loopback Adapter ohne die beiden anderen Adapter ausführen.
A.4.1.4 Shell-Erweiterung (Windows NT)
Wenn Sie eine Nachricht erhalten, die besagt, dass das Installationsprogramm eine "Shell-Erweiterung" für Windows NT festgestellt hat, kann die Installation nicht fortgesetzt werden. Führen Sie in diesem Fall die folgenden Schritte aus:
A.4.1.5 Wiederherstellung nach fehlgeschlagener Installation
Wenn Ihre Installation fehlschlägt, müssen Sie alle bereits installierten Dateien der Version 4.0 löschen. Wenn das Verzeichnis, in das Sie VisualAge für Java installieren wollten, leer ist, wurde der Installationsvorgang rückgängig gemacht und wurden alle bereits installierten Dateien entfernt. Wenn Sie möchten, können Sie das leere Verzeichnis löschen, dies ist jedoch nicht notwendig. Falls dieses Verzeichnis jedoch Dateien enthält, müssen Sie den Installationsprozess erneut starten. Er wird in einem Wartungsmodus geöffnet, und Sie müssen zunächst angeben, dass die teilweise Installation von Version 4.0 entfernt werden soll, bevor Sie das Produkt erneut installieren können.
Darüber hinaus müssen Sie auch den folgenden Eintrag in der Windows Registry löschen:
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows
Gehen Sie dabei wie folgt vor:
Wenn vor dem Fehlschlagen der Installation bereits NetQuestion-Dateien installiert wurden, müssen Sie diese ebenfalls löschen.
IMNINSTSRV=C:\imnnq_nt
Je nachdem, auf welchem Laufwerk Sie VisualAge für Java installiert haben und welches Betriebssystem Sie verwenden, kann sich NetQuestion an einer anderen Verzeichnisposition befinden. Ist die Variable eingestellt (das heißt, wird eine Position angegeben, an der NetQuestion installiert ist), arbeiten Sie mit Schritt 2 weiter.
Wenn Sie eine Fehlernachricht erhalten wie "Environment variable imninstsrv not defined" (Umgebungsvariable 'imninstsrv' ist nicht definiert), dann wurden entweder keine NetQuestion-Dateien installiert oder die Installation von NetQuestion wurde nicht erfolgreich beendet. In diesem Fall wählen Sie Start > Suchen > Dateien/Ordner aus, und suchen Sie auf Ihrem System nach der Datei vahelp.cfg. Finden Sie diese Datei in Verzeichnissen, deren Name mit "imnnq" beginnt (beispielsweise 'imnnq_NT' oder 'imnnq_98'), löschen Sie diese. Sie brauchen die Schritte 2 und 3 nicht auszuführen.
Dadurch werden alle von VisualAge für Java installierten NetQuestion-Dateien entfernt. NetQuestion-Dateien von anderen Produkten (beispielsweise DB2) sind davon nicht betroffen.
Erstellen Sie Sicherungskopien Ihres Repositorys und Ihrer Ressourcendateien, falls Sie dies noch nicht getan haben. Weitere Informationen und Anweisungen hierzu finden Sie in Teil A, Abschnitt 3.1.
Nachdem Sie diese Schritte ausgeführt haben, führen Sie einen Warmstart durch und installieren Sie das Produkt erneut. Falls die Hilfefunktion nach der erneuten Installation von VisualAge für Java fehlschlägt, lesen Sie das Handbuch zur Fehlerbehebung, das weitere Informationen dazu enthält, wie Fehler der Hilfefunktion behoben werden können. Das Handbuch zur Fehlerbehebung (trshoot.htm) befindet sich auf der Produkt-CD von VisualAge für Java, Professional Edition sowie auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Nach der Installation von VisualAge für Java, befindet sich dieses Handbuch ebenfalls im Verzeichnis X:\IBMVJava, wobei X:\IBMVJava Ihr Installationsverzeichnis von VisualAge für Java ist.
A.4.1.6 Windows-Installer-Fehler
Nachfolgend finden Sie eine Liste der Windows-Installer-Fehler, die Sie bei der Installation beachten sollten:
Fehler 1603 (nur Windows NT 4.0)
Wenn beim Installieren von VisualAge für Java die Fehlernachricht 1603 angezeigt wird, bedeutet dies, dass Windows Installer nicht initialisiert wurde und die Installation nicht fortgesetzt werden kann.
Bestimmte Produkte (wie beispielsweise VisualCafe von Symantec) installieren automatisch eine Datei namens sfc.dll, wenn sie auf einer Windows-Plattform installiert werden. Diese Datei wird nur unter Windows 2000 verwendet, wo sie von Windows Installer zur Sicherheitsverarbeitung aufgerufen wird.
Befindet sich eine Datei mit diesem Namen im Pfad (PATH) unter Windows NT 4.0, so wird Windows Installer versuchen, diese Datei zu laden, obwohl 'sfc.dll' nur auf Windows 2000 angewandt werden kann. Windows Installer schlägt dann fehl.
Führen Sie folgende Schritte aus, um dieses Problem zu umgehen:
Fehler 'Fatal LoadLibrary()'
Der Fehler 'Fatal LoadLibrary()' tritt auf, weil mindestens ein Installations-Kernel (IKernels) von VisualAge für Java von Windows Installer nicht ordnungsgemäß registriert wurde. Um dieses Problem zu umgehen, müssen Sie das Verzeichnis 'InstallShield', in dem sich die IKernel-Dateien befinden, löschen und VisualAge für Java anschließend anhand der folgenden Schritte erneut installieren:
Fehler 1631 oder Interner Fehler 2755 (nur Windows NT 4.0)
Wenn Sie VisualAge für Java unter Windows NT 4.0 installieren, erhalten Sie unter Umständen eine der folgenden Fehlernachrichten:
Falls Sie eine dieser Fehlernachrichten erhalten, liegen unter Umständen Registrierungsschlüssel mit Nullwerten vor. Wenn Sie die Installation von VisualAge für Java starten, versucht die Datei 'userenv.dll', verschiedene Registrierungsschlüssel syntaktisch zu analysieren, und wenn in den Schlüsseln Nullwerte vorliegen, schlägt die Installation mit einer der oben genannten Fehlernachrichten fehl.
Um dieses Problem zu umgehen, sollten Sie vor dem Installieren von VisualAge für Java entweder die Umgebungsvariablen mit Nullwerten entfernen oder diese modifizieren (d. h., den Wert von Null in einen gültigen Wert ändern). Nach dem Installieren von VisualAge für Java können Sie die Variablen auf ihre ursprünglichen Werte zurücksetzen.
Achtung: Das Entfernen oder Ändern von Variablen mit Nullwerten sollte mit Vorsicht erfolgen. Vor dem Entfernen oder Ändern der Variablen sollten mögliche Auswirkungen dieser Aktionen in Betracht gezogen werden.
Interne Fehler 2381, 1303, 1310, 1313 (nur Windows NT)
Wenn Sie versuchen, VisualAge für Java zu installieren, und eine oder alle der folgenden Bedingungen zutrifft bzw. zutreffen:
erhalten Sie möglicherweise eine oder mehrere der folgenden Fehlernachrichten:
Dieses Problem tritt Berichten zufolge dann auf, wenn für die folgenden Ordner lediglich Leseberechtigungen vorliegen:
\Programme\IBM\VisualAge for Java
\WinNT\Installer
Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie über die erforderlichen Berechtigungen für Ihre Laufwerke bzw. Verzeichnisse verfügen. Gehen Sie dazu folgendermaßen vor:
Interner Fehler 2735 Engine-Start
Wenn Sie den Fehler 2735 erhalten, führen Sie folgende Schritte aus, um das Problem zu umgehen:
Fehler 1606/Interner Fehler 2707
Wenn Sie die folgende Fehlernachricht erhalten, ist der Wert für die Registrierungsdatei der allgemeinen Verwaltungs-Tools (Common Administrative Tools) möglicherweise nicht korrekt:
Fehler 1606. Could not access network location \Profiles\AllUsers\StartMenu\Programs\Administrative Tools\. (Zugriff auf Netzposition \Profiles\AllUsers\StartMenu\Programs\Administrative Tools\ war nicht möglich.)
Interner Fehler 2707. INSTALLDIR.
Bevor Sie VisualAge für Java installieren können, müssen Sie den Wert der Registrierungsdatei der Common Administrative Tools editieren. Gehen Sie dazu folgendermaßen vor:
A.4.2 Bekannte Probleme und Einschränkungen bei der Deinstallation
Nachfolgend sind einige Punkte aufgelistet, die Sie bei der Deinstallation von VisualAge für Java beachten sollten:
A.4.2.1 Plattenspeicherplatz
Auf Ihrem Windows-Systemlaufwerk müssen mindestens 2 MB an freiem Speicherplatz verfügbar sein; außerdem muss die Umgebungsvariable TEMP bzw. TMP auf ein gültiges temporäres Verzeichnis verweisen, auf dem mindestens 5 MB Speicherplatz frei sind.
A.4.2.2 Den Distributed Debugger deinstallieren
Wenn Sie den Distributed Debugger als Teil Ihrer VisualAge für Java-Installation, installiert haben, sollten Sie VisualAge für Java deinstallieren, bevor Sie den Distributed Debugger deinstallieren. Nachdem Sie VisualAge für Java deinstalliert haben, können Sie mit der Deinstallation des Distributed Debugger beginnen. Wechseln Sie dazu in das Installationsverzeichnis des Debuggers und führen Sie das Deinstallationsprogramm aus.
Wenn es Ihnen nach der Deinstallation von VisualAge für Java nicht gelingt, den Distributed Debugger zu deinstallieren, müssen Sie den folgenden Registrierungsschlüssel löschen:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
Versuchen Sie anschließend erneut, den Debugger zu deinstallieren. Sie dürfen diese und die folgenden SCHRITTE NICHT AUSFÜHREN, wenn Sie den Distributed Debugger mit anderen Produkten verwenden. Nach dem Löschen des Registrierungsschlüssels können Sie den Debugger nicht mehr nutzen.
Führen Sie die folgenden Schritte aus:
Setzen Sie darüber hinaus den Wert des folgenden Registrierungsschlüssels auf 1:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount
A.4.2.3 Umgebungsvariablen (Windows 98)
Beim Deinstallieren von VisualAge für Java unter Windows 98 können einige Umgebungseinträge in der Datei autoexec.bat zurückbleiben. Normalerweise verursachen diese "Eintragsreste" keine Probleme; wenn Sie das Produkt jedoch mehrmals deinstallieren und anschließend erneut installieren, können zwei Probleme auftreten. Zum einen können sich gegenseitig ausschließende Pfadanweisungen auftreten, so dass die Online-Hilfefunktion nicht mehr funktioniert oder die zulässige Länge für die Pfadanweisungen kann überschritten werden, wodurch das Produkt nicht mehr erfolgreich erneut installiert werden kann.
Gehen Sie folgendermaßen vor, um diese Probleme zu lösen:
A.4.2.4 NetQuestion deinstallieren
Es ist möglich, dass NetQuestion bei der Deinstallation von VisualAge für Java nicht mit deinstalliert wird. Wenn NetQuestion nicht vollständig deinstalliert ist und Sie später versuchen, das Produkt erneut zu installieren, könnten Probleme auftreten.
Gehen Sie wie folgt vor, um die von VisualAge für Java installierten NetQuestion-Dateien zu entfernen. NetQuestion-Dateien von anderen Produkten (beispielsweise DB2) sind davon nicht betroffen.
IMNINSTSRV=C:\imnnq_nt
Je nachdem, auf welchem Laufwerk Sie VisualAge für Java installiert haben und welches Betriebssystem Sie verwenden, kann sich NetQuestion an einer anderen Verzeichnisposition befinden. Wenn Sie eine Fehlernachricht erhalten wie "Environment variable imninstsrv not defined" (Umgebungsvariable 'imninstsrv' ist nicht definiert), dann wurden alle NetQuestion-Dateien deinstalliert.
Dadurch werden alle von VisualAge für Java installierten NetQuestion-Dateien entfernt.
Wenn Sie VisualAge für Java zu einem späteren Zeitpunkt erneut installieren und die Hilfefunktion dann fehlschlägt, lesen Sie das Handbuch zur Fehlerbehebung, das weitere Informationen dazu enthält, wie Fehler der Hilfefunktion behoben werden können. Das Handbuch zur Fehlerbehebung (trshoot.htm) befindet sich auf der Produkt-CD von VisualAge für Java, Professional Edition sowie auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Nach der Installation von VisualAge für Java, befindet sich dieses Handbuch ebenfalls im Verzeichnis X:\IBMVJava, wobei X:\IBMVJava Ihr Installationsverzeichnis von VisualAge für Java ist.
B.1.1 Allgemeine Voraussetzungen
Bei dieser Edition von VisualAge für Java, Version 4.0 sind die folgenden Hardware- und Softwarevoraussetzungen zu beachten:
Wenn Sie den Websphere Application Server gleichzeitig mit DB2 und VisualAge für Java ausführen wollen, benötigen Sie mindestens 512 MB.
Wenn Sie in einer Team-Umgebung arbeiten, müssen Sie EMSRV, Version 7.1 verwenden. Informationen dazu, wie Sie von Version 6.x oder 7.0 zu Version 7.1 wechseln können, finden Sie in Teil C.
* Hinweis: VisualAge für Java unterstützt die Logitech-Scroll-Maus nicht. Jede Logitech-Maus mit Treibern, die den Verschiebevorgang erneut der Maus zuordnen, verursacht einen Systemfehler, wenn sie zum Verschieben verwendet wird.
B.1.2 Komponentenspezifische Voraussetzungen
Für einige Komponenten sind bestimmte Voraussetzungen nötig:
Auf Workstations ist der NFS Maestro Client für Windows NT oder Windows 2000 erforderlich. Für den NFS Client für Windows NT müssen Sie das HFS-Verzeichnis, in das Klassendateien exportiert werden, binär anhängen.
- IMS Connect V1.1 und IMS Version 7 (empfohlen) oder
- IMS Connect V1.1 und IMS Version 5.1 oder 6.1
Dieser Abschnitt enthält Informationen über das Installieren von VisualAge für Java, Version 4.0. Wichtig: Wenn Sie von einer früheren Version von VisualAge für Java migrieren, lesen Sie den Abschnitt 3.0 weiter unten, bevor Sie VisualAge für Java, Version 4.0 installieren. Spezielle Informationen für das Installieren unter Windows 2000 finden Sie in Abschnitt 2.5.
Beachten Sie bitte ebenfalls die Informationen zu neuesten Meldungen und Einschränkungen in der README, die Sie im Stammverzeichnis der Produkt-CD finden.
Wichtig: Aufgrund einer Einschränkung in der Unterstützung des CDFS (CD-ROM File System, CD-Rom-Dateisystem) unter Windows 98, kann die Installation bestimmter e-Business-Konnektoren-Dateien von der CD-ROM fehlschlagen, und eine oder mehrere der folgenden Fehlerdialoge können angezeigt werden (abhängig von den ausgewählten Konnektoren):
Alle Dateien, die nicht installiert wurden, werden in einer Zip-Datei (econnfix.zip) gespeichert, die sich im Stammverzeichnis der Produkt-CD befindet. Wenn Sie versuchen, VisualAge für Java unter Windows 98 zu installieren und eine der o.g. Fehlernachrichten erhalten, müssen Sie econnfix.zip in das Verzeichnis entzippen, in dem das Produkt installiert wurde (beispielsweise, indem Sie den Befehl unzip econnfix.zip -d c:\Programme\IBM\VisualAge for Java\ ausführen - hierbei ist c:\Programme\IBM\VisualAge for Java\ Ihr Produkt Installationsverzeichnis). Wenn sich diese Dateien danach in der korrekten Lokation befinden, funktionieren die Konnektoren korrekt.
B.2.1 Installation von VisualAge für Java, Version 4.0, Enterprise Edition
Überprüfen Sie folgende Punkte, bevor Sie das Produkt installieren:
Wenn Sie VisualAge für Java unter der Windows Millennium Edition installieren wollen, werden Sie dazu aufgefordert, Ihren Umgebungsspeicherbereich zu erhöhen. die nachfolgend beschriebenen Schritte müssen vor der Installation ausgeführt werden; andernfalls funktioniert das Hilfesystem von VisualAge für Java nicht korrekt. Führen Sie die folgenden Schritte aus, um den Umgebungsspeicherbereich zu erhöhen:
Sie müssen die folgenden Anweisungen ausführen, unabhängig davon, ob Sie die Team-Clients von VisualAge für Java oder einen Client mit einem lokalen Repository installieren. Weitere Informationen zur Installation eines Team-Clients entnehmen Sie bitte Abschnitt 2.3. Informationen zur Installation eines lokalen Repositorys finden Sie in Abschnitt 2.4.
B.2.1.1 Installation von VisualAge für Java, Version 4.0, von der Produkt-CD
Installation ohne Benutzerinteraktion
Um VisualAge für Java, Version 4.0, ohne Benutzerinteraktion zu installieren,
setzen Sie im Verzeichnis ivj40\setup den folgenden Befehl ab:
setup /s /v/qn
VisualAge für Java wird automatisch im Standardverzeichnis c:\Programme\IBM\VisualAge for Java installiert.
Um eine Installation ohne Benutzerinteraktion in ein anderes Verzeichnis zu starten (beispielsweise in d:\IBMVJava40), setzen Sie im Verzeichnis ivj40\setup den folgenden Befehl ab:
setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"
wobei d:\IBMVJava40 das Verzeichnis ist, in das Sie VisualAge installieren wollen.
Hinweis: Wenn Sie VisualAge für Java ohne Benutzerinteraktion installieren, besteht nicht die Möglichkeit, eine Verbindung zu einem gemeinsam benutzten Repository herzustellen. Bei der Installation ohne Benutzerinteraktion kann lediglich eine Verbindung zu einem lokalen Repository hergestellt werden. Wenn Sie die Installation ohne Benutzerinteraktion verwenden und dennoch in einer Team-Umgebung arbeiten wollen, müssen Sie eine lokale Installation vornehmen und anschließend eine Verbindung zum gewünschten gemeinsam benutzten Repository herstellen, nachdem Sie das Produkt installiert und IDE gestartet haben. Schlagen Sie in der Datei team.pdf im pdf-Verzeichnis nach; dort finden Sie Anweisungen, wie in einer lokalen Installation installiert, jedoch mit einer Team-Umgebung gearbeitet wird. Das pdf-Verzeichnis befindet sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben. Wenn Sie nicht das Archiv heruntergeladen haben, das die PDF-Dateien enthält, steht dieses Verzeichnis jedoch nicht zur Verfügung.
B.2.1.1.1 Installation des Distributed Debugger von der Produkt-CD
Wenn Sie beabsichtigen,
Klassen zu debuggen, die nicht in der VisualAge für Java IDE erstellt wurden oder Programme
zu debuggen, die auf einer anderen Maschine ausgeführt werden, müssen Sie den Distributed Debugger
installieren. Der Distributed
Debugger wird auf den folgenden Betriebssystemen unterstützt: Windows,
AIX, OS/2, HP-UX, Solaris, Linux und Linux/390. Installationsanweisungen für jedes einzelne Betriebssystem
werden nachfolgend gegeben. Alle Dateien des Distributed Debugger
befinden sich auf der CD für die zusätzlichen Funktionen (Additional Features).
Distributed Debugger für Windows
Distributed Debugger für OS/2
Befolgen Sie die Anweisungen in der Datei README_install.txt, die sich im Unterverzeichnis Debugger\OS2 auf der CD für die zusätzlichen Funktionen (Additional Features) befindet.Distributed Debugger für HP-UX
Voraussetzung:
Java Version 1.3 ist für die Installation und für Java-Debugging erforderlich.
Distributed Debugger für Linux
Geben Sie als Root-Benutzer den folgenden Befehl ein, um den Debugger zu installieren: rpm -Uvh DERJPICL-9-1.i386.rpmDistributed Debugger für Linux/390
Geben Sie als Root-Benutzer den folgenden Befehl ein, um den Debugger zu installieren: rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger für OS/390
B.2.1.1.2 Installation der Beta-Version von J2EE-Komponenten
Dieses Release von VisualAge für Java beinhaltet eine Beta-Version von mehreren
Komponenten der Java 2 Platform, Enterprise Edition (J2EE (TM)). Sun
Microsystems Inc. hat dieses J2EE-Komponenten noch nicht offiziell
freigegeben. Im besonderen
enthält dieses Release von VisualAge für Java eine Beta-Version der folgenden
J2EE-Komponenten:
Die Beta-Komponenten befinden sich im Unterverzeichnis extras\BetaJ2EEConnectors auf der CD für zusätzliche Funktionen (Additional Features). Wenn Sie diese Beta-Komponenten installieren wollen, lesen Sie die README-Datei im Unterverzeichnis BetaJ2EEConnectors, das Installationsanweisungen für die Komponenten enthält.
B.2.1.2 Installation der elektronischen Version von VisualAge für Java, Version 4.0
Um die Downloadzeiten zu reduzieren, wurde die elektronische Version von
VisualAge für Java, Enterprise Edition für Windows, Version 4.0 in verschiedene
Programmteile bzw. 'Archivpakete' unterteilt.
B.2.1.2.1 IDE
Für die integrierte Entwicklungsumgebung stehen vierzehn herunterladbare Archive zur Verfügung.
Alle vierzehn Pakete sind selbstextrahierende Archive. Sie müssen die ersten beiden installieren; die
übrigen sind optional. Nachstehend finden Sie eine Liste mit dem jeweiligen Inhalt der einzelnen
Archive.
Nachdem Sie die ersten beiden Archive sowie die gewünschten optionalen Dateien heruntergeladen haben, entpacken Sie bitte alle selbstextrahierenden Archive in dasselbe temporäre Verzeichnis. Nach dem Entpacken wechseln Sie in dieses temporäre Verzeichnis und führen Sie setup.exe aus. Befolgen Sie die Anweisungen auf dem Bildschirm und starten Sie die IDE.
Wenn Sie in einer anderen Landessprache als Englisch arbeiten wollen, müssen Sie darauf achten, die korrekten Archive herunterzuladen und das selbstentpackende Archiv für die gewünschte Sprache auszuführen, bevor Sie setup.exe ausführen. Nach der Installation von VisualAge für Java können Sie weder eine Sprache ändern noch hinzufügen.
Wenn Sie mit einem elektronischen Image von VisualAge für Java arbeiten, können Sie den Dialog Hinzufügen/Entfernen (Start -> Einstellungen -> Systemsteuerung -> Programme hinzufügen/entfernen) nicht verwenden, um zusätzliche VisualAge für Java-Komponenten nach der ersten Installation zu installieren. Wenn Sie dies dennoch tun, erhalten Sie eine Fehlernachricht und können keine zusätzlichen Komponenten installieren. Sie müssen setup.exe von dem Pfad aus ausführen, in dem Sie die heruntergeladenen Teile extrahiert haben, damit alle zusätzlichen Komponenten VisualAge für Java hinzugefügt werden können.
Die einzelnen Archive haben jeweils den folgenden Inhalt:
B.2.1.2.2. Distributed Debugger
Für jede vom Distributed Debugger unterstützte Zielplattform steht ein separat
herunterladbares Paket zur Verfügung. Wenn Sie beabsichtigen,
Klassen zu debuggen, die nicht in der VisualAge für Java IDE erstellt wurden oder Programme
zu debuggen, die auf einer anderen Maschine ausgeführt werden, müssen Sie den Distributed Debugger
herunterladen und installieren.
Installationsanweisungen für jedes einzelne Betriebssystem
werden nachfolgend gegeben. Sie finden diese Anweisungen sowie Informationen zur Lizenzvereinbarung auch in der Datei 'readme-1st.txt', die in jeder Komponente enthalten ist.
VisualAge for Java - Distributed Debugger for Windows enthält die Benutzerschnittstelle und die Debug-Engine für Windows. Dieses Paket ist ein selbstextrahierendes Archiv. Führen Sie folgende Schritte aus, um es zu installieren:
VisualAge for Java - Distributed Debugger for OS/2 enthält die Debug-Engine für OS/2. Um sie zu installieren, befolgen Sie die Anweisungen in der Datei README_install.txt (die Bestandteil von Distributed Debugger für OS/2 ist).
VisualAge for Java - Distributed Debugger für HP-UX enthält die Debug-Engine für HP-UX.
Voraussetzung:
Java Version 1.3 ist für die Installation und für Java-Debugging erforderlich.
Um dieses Paket zu installieren, entpacken Sie die Datei und befolgen Sie die folgenden Anweisungen.
VisualAge for Java - Distributed Debugger für Linux enthält die Debug-Engine für Linux. Um dieses Paket zu installieren, entpacken Sie die Datei und installieren Sie den Debugger, indem Sie die folgenden Anweisungen befolgen.
Geben Sie als Root-Benutzer den folgenden Befehl ein: rpm -Uvh DERJPICL-9-1.i386.rpmVisualAge for Java - Distributed Debugger für Linux/390 enthält die Debug-Engine für Linux/390. Um dieses Paket zu installieren, entpacken Sie die Datei und installieren Sie den Debugger, indem Sie die folgenden Anweisungen befolgen.
Geben Sie als Root-Benutzer den folgenden Befehl ein: rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger für OS/390
B.2.1.2.3 EMSRV (Team-Server)
VisualAge for Java - EMSRV 7.1 enthält das Repository-Server-Programm für die
Team-Entwicklungsumgebung. Ein einzelnes Archiv enthält den Server-Code für Windows, AIX, OS/2, NetWare,
HP-UX, Linux und Solaris in ZIP-Format. Um dieses Paket zu installieren, entpacken Sie die
Datei und und befolgen Sie die in instmigr.htm enthaltenen Anweisungen.
B.2.1.2.4 IBM Developer Kit 1.2.2
VisualAge for Java - IBM Developer Kit 1.2.2 enthält das IBM Developer Kit, Java Technology
Edition, v 1.2.2, PTF 9, für die Windows-Plattform. Dies ist ein selbst extrahierendes Archiv.
Um es zu installieren, führen Sie die Exe-Datei aus. Nach dem Extrahieren wird automatisch
das Installationsprogramm aufgerufen. Befolgen Sie die darin gegebenen Anweisungen.
B.2.2 Installation zusätzlicher Komponenten nach der Erstinstallation
Wenn Sie nach der Erstinstallation weitere Komponenten von VisualAge für Java installieren möchten, legen Sie einfach die Produkt-CD in Ihr CD-Laufwerk ein und wählen Sie VisualAge für Java installieren aus. Wählen Sie anschließend in der Programmpflegeanzeige Modifizieren aus. Ist autorun auf Ihrem System inaktiviert, führen Sie setup.exe vom Stammverzeichnis des CD-Laufwerks aus. Wenn Sie eine elektronische Version von VisualAge für Java haben, müssen Sie setup.exe ebenfalls manuell ausführen und anhand derselben Schritte vorgehen.
Alle Komponenten werden im Fenster Features bearbeiten aufgelistet, wobei ihr jeweiliger Installationsstatus erkennbar ist. Ein rotes 'X' bedeutet, dass die Komponente derzeit nicht installiert ist. Diese Komponenten können Sie zur nachträglichen Installation auswählen. Wählen Sie keine Komponenten aus, die nicht mit einem roten 'X' markiert sind; sie sind bereits installiert.
Sie können kein zweites Exemplar von VisualAge für Java, Version 4.0, installieren. Sie können die Installationssprache nicht ändern, ohne das Produkt zuerst zu deinstallieren.
B.2.3 Installation der VisualAge für Java Team-Clients
Bevor die einzelnen Mitglieder des Entwicklungs-Teams diese Schritte ausführen können, muss der EMSRV-Administrator den Server eingerichtet und gestartet, die Client-Verbindung getestet und Team-Entwickler zur Repository-Benutzerliste hinzugefügt haben. Informationen dazu, wie Sie diese Schritte ausführen können, finden Sie in Teil C dieses Handbuchs. In Teil C wird ebenfalls beschrieben, wie ein Team-Repository migriert werden kann.
In den folgenden Anweisungen wird davon ausgegangen, dass das gemeinsam benutzte Repository, das auf dem Server installiert ist, den Namen ivj.dat hat. Auf Ihrem Server muss EMSRV, Version 7.1 installiert sein. Wenn Sie versuchen, eine Verbindung zu einer früheren Version von EMSRV herzustellen, kann eine Fehlernachricht angezeigt werden.
B.2.4 Installation eines Clients, der ein Standalone-Repository hat
Sie möchten möglicherweise ein eigenes Quellencode-Repository von VisualAge für Java auf Ihrer Workstation einrichten, das Sie verwenden können, wenn Sie nicht mit einem gemeinsam benutzten Repository verbunden sind. Geben Sie in diesem Fall beim Installieren von VisualAge für Java, Version 4.0 auf Ihrer Workstation an, dass sich Ihr Repository auf Ihrer lokalen Maschine und nicht auf dem Server befinden soll. Das Installationsprogramm wird anschließend ein Repository für Sie erstellen.
Informationen dazu, wie Sie das gemeinsam benutzte Repository auf dem Team-Server verwenden können, finden Sie in der Online-Hilfe oder der Datei team.pdf. Die Datei team.pdf befindet sich im pdf-Verzeichnis Das pdf-Verzeichnis befindet sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben. Wenn Sie nicht das Archiv heruntergeladen haben, das die PDF-Dateien enthält, steht dieses Verzeichnis jedoch nicht zur Verfügung.
B.2.5 Installation und Benutzerhinweise für Windows 2000
Dieses Release von VisualAge für Java bietet weiterhin Toleranzunterstützung (gemäß der Definition von Microsoft) für Windows 2000.
Das Standardinstallationsverzeichnis lautet <Programme>\IBM\VisualAge for Java. Unter Windows 2000 kann die Installation unter <Programme> standardmäßig nur von Administratoren und Hauptbenutzern ausgeführt werden. Normale Benutzer (ohne spezielle Berechtigungen) können nicht in diese Position schreiben.
Aufgrund des derzeitigen Designs von VisualAge für Java müssen bei Installation des Produkts an diese Position und für den Fall, dass es von einem normalen Benutzer verwendet werden soll, die Sicherheitseinstellungen für das Verzeichnis IBM oder IBM\VisualAge for Java unter <Programme> geändert werden, damit das Produkt von normalen Benutzern verwendet werden kann. Werden diese Änderungen nicht vorgenommen, kann es beim Start der IDE oder bei der Verwendung einiger Java-Tools in der IDE zu Fehlern kommen.
Die Server-Liste für das AS/400 Enterprise Toolkit ist nun in der Datei "<Programme>\IBM\shared files\fvdctcp.txt" enthalten. Auch diese Position ist geschützt, so dass normale Benutzer nicht in dieses Verzeichnis schreiben können. Wenn ein Benutzer ohne ausreichende Berechtigung versucht, die Server-Liste über einen der Knöpfe zum Hinzufügen/Ändern der Server-Liste im SmartGuide 'AS/400' zu ändern oder zu ersetzen, schlägt die Erstellung oder Aktualisierung dieser Datei mit einem 'io error' in ihrem Java-Code fehl, der eventuell in der Protokolldatei oder im Fenster der Konsole angezeigt wird.
Der Systemadministrator muss entscheiden, ob er normalen Benutzern Schreibzugriff auf dieses Verzeichnis gewähren oder den Schreibschutz beibehalten und die Datei manuell laden möchte, damit Benutzer ohne ausreichende Berechtigung diese Datei nicht aktualisieren können.
B.2.6 Installation des IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9
Wenn Sie VisualAge für Java von der Produkt-CD installiert haben, führen Sie im Verzeichnis 'IBM Developer Kit' die Datei install.exe aus, um IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9 zu installieren. Dieses Verzeichnis befindet sich auf der CD für zusätzliche Funktionen (Additional Features). Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie dieses Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Komponenten extrahiert haben. Sie brauchen die Datei 'install.exe' jedoch nicht auszuführen, da das Installationsprogramm nach dem Entpacken aus dem heruntergeladenen IBM Developer Kit-Archiv automatisch gestartet wird.
Ausführliche Informationen zum IBM Developer Kit finden Sie in der README-Datei im Verzeichnis 'IBM Developer Kit'.
Lesen Sie erst die komponentenspezifischen und allgemeinen Migrationsinformationen in Teil D und Teil E, bevor Sie mit dem Migrationsprozess beginnen.
Das VisualAge für Java, Version 4.0-Upgrade führt Repository-Aktualisierungen während der Installation aus, um die Systemklassenbibliotheken im Repository auf die korrekte Stufe zu bringen. Dies erfordert, dass das Repository für Lese/Schreibzugriff während dieses Upgrades zur Verfügung steht. Während dieser Operation wird kein Benutzercode geändert.
Wenn Sie von einer früheren Version von VisualAge für Java, Enterprise Edition, migrieren und in einer eigenständigen Umgebung (nicht in einer Team-Umgebung) arbeiten und auch weiterhin in einer eigenständigen Umgebung arbeiten werden, befolgen Sie die entsprechenden Migrationsanweisungen für die Professional Edition in Teil A dieses Dokuments.
Hinweis: Wenn Sie von VisualAge für Java, Version 3.5 oder Version 3.5.3 auf Version 4.0 migrieren, kann es passieren, dass der Installationsprozess "hängt". Dies hat seinen Grund darin, dass die Funktion "DoCosting" (die die 3.5-Versionen von Dateien mit den 4.0-Versionen von Dateien vergleicht) bis zu drei Minuten zur Ausführung benötigen kann, was wiederum den Eindruck erweckt, als ob der Installationsprozess "hängt" und inaktiv sei.
Wenn Sie von einer Team-Umgebung oder in eine Team-Umgebung migrieren wollen, beachten Sie zunächst die folgenden Punkte, bevor Sie mit dem Migrationsprozess beginnen:
Die zur Migration erforderlichen Schritte hängen von Ihrer Situation und den Antworten auf die vorstehenden Fragen ab.
Das folgende Migrationsszenario ist eines der kompliziertesten. In diesem Szenario sind mehr als ein gemeinsam benutztes Repository und N Entwickler mit lokalen Repositories der Version 3.5 oder der Version 3.5.3 zu berücksichtigen. Sie wollen das neue Repository der Version 4.0 verwenden und ebenfalls alle Daten in den alten, gemeinsam benutzten Repositories beibehalten.
Hinweis: In diesem Szenario werden nur lokale Repositories der Version 3.5 oder der version 3.5.3 (Java 2) einbezogen, keine lokalen JDK 1.1.x-Repositories. Wenn Sie Informationen aus lokalen JDK 1.1.x-Repositories in das Repository der Version 4.0 importieren wollen, müssen Sie anhand der Anweisungen in Abschnitt 3.2 des Teils A vorgehen.
Der Migrationsprozess ist nun abgeschlossen, und die Benutzer können nach Wunsch zwischen einem lokalen und einem gemeinsam benutzten Repository hin- und herschalten. Hinweis: Wenn Sie von einer Team-Umgebung auf eine lokale Umgebung migrieren, müssen Sie Ihre Projekte manuell aus Ihrem alten gemeinsam benutzten Repository in das neue lokale Repository exportieren. Wenn Sie daneben ebenfalls ein altes lokales Repository haben, müssen Sie auch aus diesem Repository alle Projekte, die Sie weiter verwenden wollen, manuell in das neue lokale Repository der Version 4.0 importieren.
B.3.1 Migration eines gemeinsam benutzten Repository von einer früheren Version von VisualAge für Java
Bevor Sie die folgenden Schritte ausführen können, müssen Sie ein Upgrade auf EMSRV 7.1 vornehmen. Die entsprechenden Anweisungen hierzu finden Sie unter C.3.1.
Sie können das gemeinsam benutzte Repository Ihrer Version 2.0 oder 3.0x (basierend auf JDK 1.1) oder 3.0x, Early Adopters der 3.5 (basierend auf JDK 1.2) aktualisieren, so dass es mit VisualAge für Java, Version 4.0 verwendet werden kann. In den nachfolgenden Schritten führt der Team-Administrator eine Komplettinstallation von VisualAge für Java, Version 4.0 durch, einschließlich eines lokalen Repositorys. Der Administrator exportiert anschließend den gesamten Inhalt des lokalen Repositorys in alle gemeinsam benutzten Repositories.
Um ein vorhandenes Repository zu aktualisieren, dass es mit VisualAge für Java, Version 4.0, verwendet werden kann, führen Sie die folgenden Schritte aus:
Alle Projekte werden in Ihr gemeinsam benutztes Repository exportiert. Ihre Projektressourcendateien werden ebenfalls exportiert. Wenn das Repository, in das Sie exportieren, den Namen sample.dat hat, werden Ihre Projektressourcen in einen Ordner des Namens sample.dat.pr exportiert.
Beachten Sie bitte ebenfalls die Informationen zu neuesten Meldungen und bekannten Einschränkungen in der README, die Sie im Verzeichnis README der CD finden.
B.4.1 Bekannte Probleme und Einschränkungen bei der Installation
Nachfolgend sind einige Punkte aufgelistet, die Sie bei der Installation von VisualAge für Java beachten sollten:
B.4.1.1 Einschränkungen bei Festplatten
B.4.1.2 Benutzerberechtigung
B.4.1.3 TCP/IP-Voraussetzungen
Diese Konfigurationsoptionen gelten für alle TCP/IP-Adapter, auch dann, wenn die Optionen nur für diesen einen Adapter geändert wurden. Sie können nicht sowohl eine LAN-Konfiguration als auch eine Wahlkonfiguration verwenden, ohne zuvor eine Neukonfigurierung durchgeführt zu haben.
Die TCP/IP-Wahlnetzwerkeigenschaften für Ihre(n) Internet-Service-Provider (ISP) müssen so konfiguriert sein, wie dies durch den jeweiligen ISP dokumentiert ist. Die TCP/IP-Wahlnetzwerkeigenschaften setzen die TCP/IP-Eigenschaften außer Kraft, die für den Wahl-Adapter über das Symbol 'Netzwerk' in der Systemsteuerung von Windows 98 oder Windows 2000 konfiguriert wurden. Dieses außer Kraft Setzen erfolgt jedoch nur, wenn die TCP/IP-Eigenschaften für den Wahl-Adapter wie oben beschrieben konfiguriert sind. Sie dürfen den DNS in den TCP/IP-Eigenschaften des Wahl-Adapters nicht aktivieren; weiterhin dürfen Sie nicht eine IP-Adresse in den TCP/IP-Eigenschaften des Wahl-Adapters angeben, da in diesem Fall ein Konflikt mit der Konfiguration des Wahlnetzwerks für den ISP auftritt.
Unter Windows NT 4.0 können beide der oben beschriebenen TCP/IP-Konfigurationen verwendet werden. Wenn Sie VisualAge für Java auf einer eigenständigen Maschine ausführen, können Sie auch den Microsoft Loopback Adapter ohne die beiden anderen Adapter ausführen.
B.4.1.4 Shell-Erweiterung (Windows NT)
Wenn Sie eine Nachricht erhalten, die besagt, dass das Installationsprogramm eine "Shell-Erweiterung" für Windows NT festgestellt hat, kann die Installation nicht fortgesetzt werden. Führen Sie in diesem Fall die folgenden Schritte aus:
B.4.1.5 Wiederherstellung nach fehlgeschlagener Installation
Wenn Ihre Installation fehlschlägt, müssen Sie alle bereits installierten Dateien der Version 4.0 löschen. Wenn das Verzeichnis, in das Sie VisualAge für Java installieren wollten, leer ist, wurde der Installationsvorgang rückgängig gemacht und wurden alle bereits installierten Dateien entfernt. Wenn Sie möchten, können Sie das leere Verzeichnis löschen, dies ist jedoch nicht notwendig. Falls dieses Verzeichnis jedoch Dateien enthält, müssen Sie den Installationsprozess erneut starten. Er wird in einem Wartungsmodus geöffnet, und Sie müssen zunächst angeben, dass die teilweise Installation von Version 4.0 entfernt werden soll, bevor Sie das Produkt erneut installieren können.
Darüber hinaus müssen Sie auch den folgenden Eintrag in der Windows Registry löschen:
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows
Gehen Sie dabei wie folgt vor:
Wenn vor dem Fehlschlagen der Installation bereits NetQuestion-Dateien installiert wurden, müssen Sie diese ebenfalls löschen.
IMNINSTSRV=C:\imnnq_nt
Je nachdem, auf welchem Laufwerk Sie VisualAge für Java installiert haben und welches Betriebssystem Sie verwenden, kann sich NetQuestion an einer anderen Verzeichnisposition befinden. Ist die Variable eingestellt (das heißt, wird eine Position angegeben, an der NetQuestion installiert ist), arbeiten Sie mit Schritt 2 weiter.
Wenn Sie eine Fehlernachricht erhalten wie "Environment variable imninstsrv not defined" (Umgebungsvariable 'imninstsrv' ist nicht definiert), dann wurden entweder keine NetQuestion-Dateien installiert oder die Installation von NetQuestion wurde nicht erfolgreich beendet. In diesem Fall wählen Sie Start > Suchen > Dateien/Ordner aus, und suchen Sie auf Ihrem System nach der Datei 'vahelp.cfg'. Finden Sie diese Datei in Verzeichnissen, deren Name mit "imnnq" beginnt (beispielsweise 'imnnq_NT' oder 'imnnq_98'), löschen Sie diese. Sie brauchen die Schritte 2 und 3 nicht auszuführen.
Dadurch werden alle von VisualAge für Java installierten NetQuestion-Dateien entfernt. NetQuestion-Dateien von anderen Produkten (beispielsweise DB2) sind davon nicht betroffen.
Erstellen Sie Sicherungskopien Ihres Repositorys und Ihrer Ressourcendateien, falls Sie dies noch nicht getan haben. Weitere Informationen und Anweisungen hierzu finden Sie in Teil B, Abschnitt 3.0.
Wenn Sie diese Schritte ausgeführt haben, Führen Sie einen Warmstart Ihres Systems durch und installieren Sie das Produkt erneut. Falls die Hilfefunktion nach der erneuten Installation von VisualAge für Java fehlschlägt, lesen Sie das Handbuch zur Fehlerbehebung, das weitere Informationen dazu enthält, wie Fehler der Hilfefunktion behoben werden können. Das Handbuch zur Fehlerbehebung (trshoot.htm) befindet sich auf der Produkt-CD von VisualAge für Java, Professional Edition sowie auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Nach der Installation von VisualAge für Java, befindet sich dieses Handbuch ebenfalls im Verzeichnis X:\IBMVJava, wobei X:\IBMVJava Ihr Installationsverzeichnis von VisualAge für Java ist.
B.4.1.6 CICS Transaction Gateway
Wenn eine Version von CICS Transaction Gateway auf Ihrer Maschine installiert ist während Sie VisualAge für Java installieren, wird VisualAge für Java diese Version verwenden, anstatt eine eigene zu installieren.
A.4.1.6 Windows-Installer-Fehler
Nachfolgend finden Sie eine Liste der Windows-Installer-Fehler, die Sie bei der Installation beachten sollten:
Fehler 1603 (nur Windows NT 4.0)
Wenn beim Installieren von VisualAge für Java die Fehlernachricht 1603 angezeigt wird, bedeutet dies, dass Windows Installer nicht initialisiert wurde und die Installation nicht fortgesetzt werden kann.
Bestimmte Produkte (wie beispielsweise VisualCafe von Symantec) installieren automatisch eine Datei namens sfc.dll, wenn sie auf einer Windows-Plattform installiert werden. Diese Datei wird jedoch nur unter Windows 2000 verwendet, wo sie von Windows Installer zur Sicherheitsverarbeitung aufgerufen wird.
Befindet sich eine Datei mit diesem Namen im Pfad (PATH) unter Windows NT 4.0, so wird Windows Installer versuchen, diese Datei zu laden, obwohl 'sfc.dll' nur auf Windows 2000 angewandt werden kann. Windows Installer schlägt dann fehl.
Führen Sie folgende Schritte aus, um dieses Problem zu umgehen:
Fehler 'Fatal LoadLibrary()'
Der Fehler 'Fatal LoadLibrary()' tritt auf, weil mindestens ein Installations-Kernel (IKernels) von VisualAge für Java von Windows Installer nicht ordnungsgemäß registriert wurde. Um dieses Problem zu umgehen, müssen Sie das Verzeichnis 'InstallShield', in dem sich die IKernel-Dateien befinden, löschen und VisualAge für Java anschließend anhand der folgenden Schritte erneut installieren:
Fehler 1631 oder Interner Fehler 2755 (nur Windows NT 4.0)
Wenn Sie VisualAge für Java unter Windows NT 4.0 installieren, erhalten Sie unter Umständen eine der folgenden Fehlernachrichten:
Falls Sie eine dieser Fehlernachrichten erhalten, liegen unter Umständen Registrierungsschlüssel mit Nullwerten vor. Wenn Sie die Installation von VisualAge für Java starten, versucht die Datei 'userenv.dll', verschiedene Registrierungsschlüssel syntaktisch zu analysieren, und wenn in den Schlüsseln Nullwerte vorliegen, schlägt die Installation mit einer der oben genannten Fehlernachrichten fehl.
Um dieses Problem zu umgehen, sollten Sie vor dem Installieren von VisualAge für Java entweder die Umgebungsvariablen mit Nullwerten entfernen oder diese modifizieren (d. h., den Wert von Null in einen gültigen Wert ändern). Nach dem Installieren von VisualAge für Java können Sie die Variablen auf ihre ursprünglichen Werte zurücksetzen.
Achtung: Das Entfernen oder Ändern von Variablen mit Nullwerten sollte mit Vorsicht erfolgen. Vor dem Entfernen oder Ändern der Variablen sollten mögliche Auswirkungen dieser Aktionen in Betracht gezogen werden.
Interne Fehler 2381, 1303, 1310, 1313 (nur Windows NT)
Wenn Sie versuchen, VisualAge für Java zu installieren, und eine oder alle der folgenden Bedingungen zutrifft bzw. zutreffen:
erhalten Sie möglicherweise eine oder mehrere der folgenden Fehlernachrichten:
Dieses Problem tritt Berichten zufolge dann auf, wenn für die folgenden Ordner lediglich Leseberechtigungen vorliegen:
\Programme\IBM\VisualAge for Java
\WinNT\Installer
Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie über die erforderlichen Berechtigungen für Ihre Laufwerke bzw. Verzeichnisse verfügen. Gehen Sie dazu folgendermaßen vor:
Interner Fehler 2735 Engine-Start
Wenn Sie den Fehler 2735 erhalten, führen Sie folgende Schritte aus, um das Problem zu umgehen:
Fehler 1606/Interner Fehler 2707
Wenn Sie die folgende Fehlernachricht erhalten, ist der Wert für die Registrierungsdatei der allgemeinen Verwaltungs-Tools (Common Administrative Tools) möglicherweise nicht korrekt:
Fehler 1606. Could not access network location \Profiles\AllUsers\StartMenu\Programs\Administrative Tools\. (Zugriff auf Netzposition \Profiles\AllUsers\StartMenu\Programs\Administrative Tools\ war nicht möglich.)
Interner Fehler 2707. INSTALLDIR.
Bevor Sie VisualAge für Java installieren können, müssen Sie den Wert der Registrierungsdatei der Common Administrative Tools editieren. Gehen Sie dazu folgendermaßen vor:
B.4.2 Bekannte Einschränkungen und Probleme bei der Deinstallation
Nachfolgend sind einige Punkte aufgelistet, die Sie bei der Deinstallation beachten sollten:
B.4.2.1 Plattenspeicherplatz
Auf Ihrem Windows-Systemlaufwerk müssen mindestens 2 MB an freiem Speicherplatz verfügbar sein; außerdem muss die Umgebungsvariable TEMP bzw. TMP auf ein gültiges temporäres Verzeichnis verweisen, auf dem mindestens 5 MB Speicherplatz frei sind.
B.4.2.2 Den Distributed Debugger deinstallieren
Wenn Sie den Distributed Debugger als Teil Ihrer VisualAge für Java-Installation, installiert haben, sollten Sie VisualAge für Java deinstallieren, BEVOR Sie den Distributed Debugger deinstallieren. Nachdem Sie VisualAge für Java deinstalliert haben, können Sie mit der Deinstallation des Distributed Debugger beginnen. Wechseln Sie dazu in das Installationsverzeichnis des Debuggers und führen Sie das Deinstallationsprogramm aus.
Wenn es Ihnen nach der Deinstallation von VisualAge für Java nicht gelingt, den Distributed Debugger zu deinstallieren, müssen Sie den folgenden Registrierungsschlüssel löschen:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
Versuchen Sie anschließend erneut, den Debugger zu deinstallieren. Sie dürfen diese und die folgenden SCHRITTE NICHT AUSFÜHREN, wenn Sie den Distributed Debugger mit anderen Produkten verwenden. Nach dem Löschen des Registrierungsschlüssels können Sie den Debugger nicht mehr nutzen.
Führen Sie die folgenden Schritte aus:
Setzen Sie darüber hinaus den Wert des folgenden Registrierungsschlüssels auf 1:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount
B.4.2.3 Umgebungsvariablen (Windows 98)
Beim Deinstallieren von VisualAge für Java unter Windows 98 können einige Umgebungseinträge in der Datei autoexec.bat zurückbleiben. Normalerweise verursachen diese "Eintragsreste" keine Probleme; wenn Sie das Produkt jedoch mehrmals deinstallieren und anschließend erneut installieren, können zwei Probleme auftreten. Zum einen können sich gegenseitig ausschließende Pfadanweisungen auftreten, so dass die Online-Hilfefunktion nicht mehr funktioniert, oder die zulässige Länge für die Pfadanweisungen kann überschritten werden, wodurch das Produkt nicht mehr erfolgreich erneut installiert werden kann.
Gehen Sie folgendermaßen vor, um diese Probleme zu lösen:
B.4.2.4 NetQuestion deinstallieren
Es ist möglich, dass NetQuestion bei der Deinstallation von VisualAge für Java nicht mit deinstalliert wird. Wenn NetQuestion nicht vollständig deinstalliert ist und Sie später versuchen, das Produkt erneut zu installieren, könnten Probleme auftreten.
Gehen Sie wie folgt vor, um die von VisualAge für Java installierten NetQuestion-Dateien zu entfernen. NetQuestion-Dateien von anderen Produkten (beispielsweise DB2) sind davon nicht betroffen.
IMNINSTSRV=C:\imnnq_nt
Je nachdem, auf welchem Laufwerk Sie VisualAge für Java installiert haben und welches Betriebssystem Sie verwenden, kann sich NetQuestion an einer anderen Verzeichnisposition befinden. Wenn Sie eine Fehlernachricht erhalten wie "Environment variable imninstsrv not defined" (Umgebungsvariable 'imninstsrv' ist nicht definiert), dann wurden alle NetQuestion-Dateien deinstalliert.
Dadurch werden alle von VisualAge für Java installierten NetQuestion-Dateien entfernt.
Wenn Sie VisualAge für Java zu einem späteren Zeitpunkt erneut installieren und die Hilfefunktion dann fehlschlägt, lesen Sie das Handbuch zur Fehlerbehebung, das weitere Informationen dazu enthält, wie Fehler der Hilfefunktion behoben werden können. Das Handbuch zur Fehlerbehebung (trshoot.htm) befindet sich auf der Produkt-CD von VisualAge für Java, Professional Edition sowie auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Nach der Installation von VisualAge für Java, befindet sich dieses Handbuch ebenfalls im Verzeichnis X:\IBMVJava, wobei X:\IBMVJava Ihr Installationsverzeichnis von VisualAge für Java ist.
Wenn Sie in einer Team-Umgebung mit der Enterprise Edition von VisualAge für Java arbeiten wollen, müssen Sie EMSRV, Version 7.1 verwenden.
Alle EMSRV-Dateien befinden sich auf der CD für zusätzliche Funktionen (Additional Features).
Bitte lesen Sie zuerst den Abschnitt "Bekannte Probleme und Einschränkungen" am Ende des Teils C, bevor Sie EMSRV installieren.
C.1.1 Unterstützte Plattformen
Der EMSRV-Server wird auf den folgenden Betriebssystemplattformen unterstützt:
* Hinweis: HP-UX wird lediglich auf 700-Class-Workstations unterstützt. HP-UX 10.2 wurde auf einer HP-UX 9000/715/60-Maschine und auf einer HP-UX 9000/782/200+-Maschine getestet. Da 800-Class-(Server)-Maschinen verschiedene Architekturen haben und verschiedene Binaries erfordern, wird EMSRV nicht auf 800-Class-Maschinen unterstützt.
+ Informationen zum Abrufen dieses Patches finden Sie unter C.1.4.
IBM bietet für EMSRV keine Unterstützung mehr unter Netware 4.11 oder Netware 5.0, EMSRV kann jedoch auf dieser Plattform ausgeführt werden, wenn CLIBAUX.NLM vor EMSRV.NLM geladen wird. CLIBAUX.NLM ist im Lieferumfang des Novell Support Pack 8a enthalten, ist jedoch auch separat von Novell in der Datei CLIBAUX1.EXE erhältlich, die Sie unter folgender Adresse finden:
http://support.novell.com/cgi-bin/search/download?/pub/updates/nw/nw42/clibaux1.exe
Zurückziehen der Unterstützung für SMP-Hardware
** WICHTIGER HINWEIS: Die Ausführung von EMSRV-Releases für Windows NT/2000 auf einer Maschine mit mehr als einem Prozessor kann zur Beschädigung von Repositories führen.
EMSRV wird nicht mehr auf Windows NT/2000-Servern unterstützt, die auf SMP-Hardware ausgeführt werden (das heißt auf Maschinen mit mehr als einem Prozessor). Die Entscheidung, die Unterstützung für SMP-Hardware zu entfernen, beruht auf der Häufigkeit der Berichte über Repository-Beschädigungen im Zusammenhang mit Windows-Servern und SMP-Hardware. Für alle anderen Betriebssysteme unterstützt EMSRV auch weiterhin SMP-Hardware.
IBM HAFTET NICHT FÜR SCHÄDEN, DIE IHNEN MÖGLICHERWEISE DURCH DIE VERWENDUNG VON EMSRV AUF EINEM AUF SMP-HARDWARE AUSGEFÜHRTEN WINDOWS NT/2000-SERVER ENTSTEHEN, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF SCHÄDEN, DIE SIE AUF DER GRUNDLAGE VON FORDERUNGEN DRITTER GELTEND MACHEN. UNTER KEINEN UMSTÄNDEN HAFTEN IBM, IHRE LIEFERANTEN, VERTRETER UND MITARBEITER FÜR IRGENDWELCHE MITTELBAREN SCHÄDEN, BESONDEREN SCHADENSFOLGEN, TATSÄCHLICHEN SCHÄDEN ZUZÜGLICH ZIVILSTRAFEN UND ÜBERNORMAL HOHE SCHÄDEN, DIE MÖGLICHERWEISE AUS DER VERWENDUNG VON EMSRV AUF EINEM AUF SMP-HARDWARE AUSGEFÜHRTEN WINDOWS NT/2000-SERVER ENTSTEHEN.
Wenn Sie EMSRV auf einem Server verwenden wollen, der auf SMP-Hardware ausgeführt wird, müssen Sie Parameter -mp verwenden, wenn Sie EMSRV starten. Dadurch wird die Überprüfung hinsichtlich SMP-Hardware umgangen. Infolge dieser Vorgehensweise wird EMSRV auf einer nicht unterstützten Plattform ausgeführt, und Sie übernehmen die volle Verantwortung (IBM ÜBERNIMMT KEINERLEI VERANTWORTUNG ODER HAFTUNG IRGENDWELCHER ART), wenn Repositorys daraufhin beschädigt werden.
EMSRV nutzt keine zusätzlichen Prozessoren, da es sich bei EMSRV um einen Eingabe/Ausgabe-gebundenen Prozess und nicht um einen Prozessor-gebundenen Prozess handelt. Infolge dessen wird die Leistung von EMSRV nicht durch die Anzahl der Prozessoren auf Ihrem Server beeinflusst.
C.1.2 TCP/IP
TCP/IP muss auf Ihrem Server installiert und konfiguriert sein.
C.1.3 Erforderliche Novell-Patches zur Ausführung von EMSRV
Es wird empfohlen, dass Sie sich die NetWare Minimum Patch List besorgen und anwenden. Diese Patch-Dateien sind unter folgender Adresse verfügbar: http://support.novell.com/misc/patlst.htm. Sie müssen die entsprechenden Patches für die von Ihnen verwendete Version von NetWare auswählen und anwenden.
C.1.4 Erforderliches Patch zur Ausführung von EMSRV auf Solaris
Die Solaris-Implementierung Version 2.6 von PAM enthält einen Programmfehler, der bewirkt, dass EMSRV nicht korrekt funktioniert. Wenn Sie EMSRV auf Solaris Version 2.6 verwenden, müssen Sie Patch 106257-05 anwenden. Dieses Patch finden Sie an folgender Adresse:
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F106257&zone_32=PAM
Bei dem speziellen Programmfehler, der mit diesem Patch behoben wird, handelt es sich um folgendes:
Member 4092227 pam_conv appdata_ptr wird nicht wie dokumentiert an die Funktion conv() weitergegeben.
Wenn Sie mit Version 7.0 von Solaris arbeiten, ist dieses Patch nicht erforderlich.
C.1.5 Unterstützte Dateisysteme
EMSRV wurde auf den folgenden Dateisystemen getestet und für sie zertifiziert:
NetWare
OS/2
Windows NT und Windows 2000
Solaris
HP-UX
AIX
Linux
EMSRV unterstützt nur lokal angehängte Dateisysteme.
Dieser Kapitel enthält Anweisungen zur Installation des EMSRV-Repository-Server-Programms und eines gemeinsam benutzten Repositorys. Anweisungen zum Starten des Servers sind im Abschnitt "Server-Einrichtung und -Verwaltung" in der Datei emsrv71.htm (emsrv70.htm für alle Sprachen außer Englisch), enthalten, die sich im Verzeichnis TeamServer\docs befindet.
C.2.1 Installation von EMSRV für Windows(R)
EMSRV für Windows einrichten
Vor der Installation von EMSRV unter Windows sind folgende Dinge zu Dateitypen
zu beachten:
EMSRV unter Windows installieren
Führen Sie folgende Schritte aus, um das Repository-Server-Programm EMSRV und ein gemeinsam benutztes
Repository auf einem Windows NT-Server oder einem Windows 2000-Server zu installieren:
Die Datei ide.zip file befindet sich im Verzeichnis ivj40\backup, das sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition befindet. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben.
Dieses Verzeichnis sollte das Verzeichnis sein, in dem Sie gemeinsam benutzte Quellencode-Repositories speichern wollen. Wenn Sie später den Server starten, geben Sie dieses Unterverzeichnis mit Hilfe des EMSRV-Startparameters -W als EMSRV-Arbeitsverzeichnis an.
EMSRV muss vollen Lese-, Schreib- und Suchzugriff auf die gesamte Verzeichnisstruktur in ivj.dat.pr haben. ivj.dat.pr sollte immer in dasselbe Verzeichnis kopiert werden wie ivj.dat, da Sie andernfalls nicht auf Ihre Projektressourcen zugreifen können.
Sie können die Repository-Datei beispielsweise in team1.dat umbenennen. Wenn Sie das Repository umbenennen, nachdem Sie es auf den Server kopiert haben, müssen Sie das Projektressourcenverzeichnis ebenfalls entsprechend umbenennen. Wenn Sie das Repository beispielsweise in team1.dat umbenennen, müssen Sie das Projektressourcenverzeichnis in team1.dat.pr umbenennen.
Die Team-Mitglieder müssen den Dateinamen des Repositorys angeben, wenn sie den VisualAge für Java-Client-Code installieren. Außerdem müssen die Mitglieder den Pfad auf der Server-Maschine angeben.
Sie können EMSRV in der Windows Registry installieren, wenn Sie EMSRV später als Dienst anstatt von einer Eingabeaufforderung starten möchten. Das Installieren von EMSRV als Dienst bietet zwei Vorteile:
Tipp: Wenn EMSRV als Dienst gestartet wird, ist das Windows NT- bzw. Windows 2000-Verzeichnis system32\ das standardmäßige EMSRV-Arbeitsverzeichnis. Es wird empfohlen, dass Sie diesen Standard ändern, indem Sie den Parameter -W verwenden, wenn Sie EMSRV als einen Dienst in der Windows NT oder Windows 2000 Registry installieren.
Wichtig: EMSRV wird nicht mehr auf Windows NT/2000-Servern unterstützt, die auf SMP-Hardware ausgeführt werden (das heißt auf Maschinen mit mehr als einem Prozessor). Die Entscheidung, die Unterstützung für SMP-Hardware zu entfernen, beruht auf der Häufigkeit der Berichte über Repository-Beschädigungen im Zusammenhang mit Windows-Servern und SMP-Hardware. EMSRV unterstützt weiterhin SMP-Hardware für alle anderen Betriebssysteme.
IBM HAFTET NICHT FÜR SCHÄDEN, DIE IHNEN MÖGLICHERWEISE DURCH DIE VERWENDUNG VON EMSRV AUF EINEM AUF SMP-HARDWARE AUSGEFÜHRTEN WINDOWS NT/2000-SERVER ENTSTEHEN, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF SCHÄDEN, DIE SIE AUF DER GRUNDLAGE VON FORDERUNGEN DRITTER GELTEND MACHEN. UNTER KEINEN UMSTÄNDEN HAFTEN IBM, IHRE LIEFERANTEN, VERTRETER UND MITARBEITER FÜR IRGENDWELCHE MITTELBAREN SCHÄDEN, BESONDEREN SCHADENSFOLGEN, TATSÄCHLICHEN SCHÄDEN ZUZÜGLICH ZIVILSTRAFEN UND ÜBERNORMAL HOHE SCHÄDEN, DIE MÖGLICHERWEISE AUS DER VERWENDUNG VON EMSRV AUF EINEM AUF SMP-HARDWARE AUSGEFÜHRTEN WINDOWS NT/2000-SERVER ENTSTEHEN.
Wenn Sie EMSRV als einen Windows NT/2000-Dienst installieren und starten wollen, der auf SMP-Hardware ausgeführt wird, müssen Sie den Dienst mit dem Parameter -mp installieren. Dadurch wird die Überprüfung hinsichtlich SMP-Hardware umgangen. Infolge dieser Vorgehensweise wird EMSRV auf einer nicht unterstützten Plattform ausgeführt, und Sie übernehmen die volle Verantwortung (IBM ÜBERNIMMT KEINERLEI VERANTWORTUNG ODER HAFTUNG IRGENDWELCHER ART), wenn Repositorys daraufhin beschädigt werden.
Wenn Sie den Service nicht mit dem Parameter -mp installieren, wird der Service nicht gestartet, und es wird die folgende Fehlernachricht ausgegeben:
Could not start the EMSRV service on \\host (Der EMSRV-Service konnte auf \\host nicht gestartet werden.)
Fehler 2140: An internal Windows NT error occurred. (Ein interner Windows NT-Fehler trat auf.)
Wenn Sie erneut versuchen, EMSRV als Service zu installieren (beispielsweise, um den Parameter -mp hinzuzufügen), wird der Service zwar erfolgreich installiert, es wird jedoch die folgende Fehlernachricht ausgegeben:
Message file emsrvmsg.dll, could not be copied to C:\WINNT\System32\emsrvmsg.dll (Nachrichtendatei 'emsrvmsg.dll' konnte nicht nach C:\WINNT\System32\emsrvmsg.dll kopiert werden.)
--- OS-Fehler 1224: The requested operation could not be performed on a file with a user mapped section open. Make sure the DLL is in the same directory as EMSRV.EXE. (Die angeforderte Operation konnte nicht für eine Datei mit einem offenen zugeordneten Benutzerabschnitt ausgeführt werden. Stellen Sie sicher, dass sich die DLL in demselben Verzeichnis wie EMSRV.EXE befindet.)
Sie können diese Fehlernachricht ignorieren, da die DLL bei der vorherigen Installation des Services bereits installiert worden war.
Führen Sie folgende Schritte aus, um EMSRV als Dienst zu installieren:
Weitere Informationen zum Staren vom EMSRV sind im Abschnitt "Server-Einrichtung und -Verwaltung" in der Datei emsrv70.htm (emsrv70.htm für alle Sprachen außer Englisch), enthalten, die sich im Verzeichnis TeamServer\docs befindet.
Die von Ihnen angegebenen Parameter werden standardmäßig bei jedem Starten von EMSRV verwendet. Sie können diese Parameter auch außer Kraft setzen oder neue Parameter hinzufügen, wenn Sie EMSRV manuell vom Symbol Dienste in der Windows-Systemsteuerung starten.
C.2.2 Installation von EMSRV für NetWareEMSRV für Netware einrichten
Vor der Installation von EMSRV unter Netware sind folgende Einschränkungen zu beachten:
EMSRV unter Netware installieren
Führen Sie folgende Schritte aus, um das Repository-Server-Programm
EMSRV und ein gemeinsam benutztes Repository unter NetWare zu installieren:
Die Datei ide.zip file befindet sich im Verzeichnis ivj40\backup, das sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition befindet. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben.
Wenn Sie später den Server starten, geben Sie dieses Unterverzeichnis mit Hilfe des EMSRV-Startparameters -W als EMSRV-Arbeitsverzeichnis an. EMSRV muss vollen Lese-, Schreib- und Suchzugriff auf die gesamte Verzeichnisstruktur in ivj.dat.pr haben. ivj.dat.pr sollte immer in dasselbe Verzeichnis kopiert werden wie ivj.dat, da Sie andernfalls nicht auf Ihre Projektressourcen zugreifen können.
Sie können die Repository-Datei beispielsweise in team1.dat umbenennen. Wenn Sie das Repository umbenennen, nachdem Sie es auf den Server kopiert haben, müssen Sie das Projektressourcenverzeichnis ebenfalls entsprechend umbenennen. Wenn Sie das Repository beispielsweise in team1.dat umbenennen, müssen Sie das Projektressourcenverzeichnis in team1.dat.pr umbenennen.
Die Team-Mitglieder müssen den Dateinamen und die Dateiposition des Repositorys angeben, wenn sie den VisualAge für Java-Client-Code installieren.
C.2.3 Installation von EMSRV für OS/2 Warp
Hinweis: OS/2 wird nicht länger als Entwicklungsplattform unterstützt. Ausführliche Informationen hierzu finden Sie in Teil E.
EMSRV für OS/2 einrichten
Vor der Installation von EMSRV unter OS/2 ist Folgendes zu beachten:
EMSRV unter OS/2 installieren
Führen Sie folgende Schritte aus, um das
Repository-Server-Programm EMSRV und ein gemeinsam benutztes
Repository unter OS/2 zu installieren:
Stellen Sie diese Dateien in ein Unterverzeichnis, das Bestandteil Ihres Pfads (PATH) ist, oder erstellen Sie ein Unterverzeichnis und fügen Sie dieses Ihrem PATH hinzu. Es empfiehlt sich, diese Dateien an eine Position zu stellen, die über ausreichend freien Speicherplatz verfügt, da die Datei emsrv.log in das Unterverzeichnis geschrieben wird, in das Sie diese Dateien stellen.
Die Datei ide.zip file befindet sich im Verzeichnis ivj40\backup, das sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition befindet. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben.
Dieses Verzeichnis sollte das Unterverzeichnis sein, in dem Sie gemeinsam benutzte Quellencode-Repositories speichern wollen. Wenn Sie später den Server starten, geben Sie dieses Unterverzeichnis mit Hilfe des EMSRV-Startparameters -W als EMSRV-Arbeitsverzeichnis an.
EMSRV muss vollen Lese-, Schreib- und Suchzugriff auf die gesamte Verzeichnisstruktur in ivj.dat.pr haben. ivj.dat.pr sollte immer in dasselbe Verzeichnis kopiert werden wie ivj.dat, da Sie andernfalls nicht auf Ihre Projektressourcen zugreifen können.
Sie können die Repository-Datei beispielsweise in team1.dat umbenennen. Wenn Sie das Repository umbenennen, nachdem Sie es auf den Server kopiert haben, müssen Sie das Projektressourcenverzeichnis ebenfalls entsprechend umbenennen. Wenn Sie das Repository beispielsweise in team1.dat umbenennen, müssen Sie das Projektressourcenverzeichnis in team1.dat.pr umbenennen.
Die Team-Mitglieder müssen den Dateinamen des Repositorys angeben, wenn sie den VisualAge für Java-Client-Code installieren.
C.2.4 Installation von EMSRV für AIX
EMSRV für AIX einrichten
Vor der Installation von EMSRV unter AIX sind folgende Besonderheiten zu beachten:
EMSRV unter AIX installieren
In den folgenden Schritten bezieht sich "EMSRV-Benutzer"
auf den Benutzer, der das Programm EMSRV startet.
Sie müssen die folgenden Dateien aus dem TeamServer-Verzeichnis auf Ihre Maschine kopieren:
Stellen Sie diese Dateien in ein Unterverzeichnis, das Bestandteil Ihres Pfads (PATH) ist, oder erstellen Sie ein Unterverzeichnis und fügen Sie dieses Ihrem PATH hinzu. Es empfiehlt sich, diese Dateien an eine Position zu stellen, die über ausreichend freien Speicherplatz verfügt, da die Datei emsrv.log in das Unterverzeichnis geschrieben wird, in das Sie diese Dateien stellen.
Führen Sie die folgenden Schritte aus, um EMSRV auf einer AIX-Maschine einzurichten:
Die Datei ide.zip file befindet sich im Verzeichnis ivj40\backup, das sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition befindet. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben.
EMSRV muss vollen Lese-, Schreib- und Suchzugriff auf die gesamte Verzeichnisstruktur in ivj.dat.pr haben. ivj.dat.pr sollte immer in dasselbe Verzeichnis kopiert werden wie ivj.dat, da Sie andernfalls nicht auf Ihre Projektressourcen zugreifen können. In den Verzeichnissen müssen rw- und x- (Such-) Bits für den EMSRV-Benutzer definiert sein.
Auf UNIX-Plattformen ist zur Authentifizierung von Benutzern Root-Zugriff erforderlich. EMSRV muss vom Root-Benutzer NICHT gestartet werden, um dies auszuführen. Wird EMSRV gestartet, würde die Sicherheit verletzt, da EMSRV uneingeschränkten Zugriff auf alle Dateisysteme erhielte.
Sie sollten stattdessen den Eigner der EMSRV-Executable in 'root' ändern und das SUID-Bit der Executable aktivieren. Gehen Sie dazu folgendermaßen vor:
chown root emsrv
chmod u+s emsrv
Wenn EMSRV versucht, einen Benutzer zu authentifizieren, wird es vorübergehend die Berechtigung des aktiven EMSRV-Prozesses in die Berechtigung des Eigners der Executable ändern. Nach der Authentifizierung wird die Berechtigung wieder in die des Benutzers geändert, der EMSRV gestartet hat. Dies betrifft jeweils nur den Prozess bzw. den Client, d. h. während der Authentifizierung eines Clients hat nur der Prozess, der den Client bedient, vorübergehenden Root-Zugriff.
Der Root-Zugriff ist für die Authentifizierung erforderlich, unabhängig davon, wie EMSRV die Authentifizierung tatsächlich implementiert. Schnittstellen wie PAM stellen nur eine allgemeine API bereit, die es Anwendungen ermöglicht, verschiedene Authentifizierungsmethoden zu unterstützen. Die jeweilige methodenspezifische Konfiguration muss weiterhin korrekt sein.
C.2.5 EMSRV für HP-UX oder Solaris
C.2.5.1 EMSRV für HP-UX oder Solaris einrichten
Bevor Sie EMSRV unter Solaris oder HP-UX installieren, sind folgende Voraussetzungen zu beachten:
Für Solaris
Für HP-UX
C.2.5.2 EMSRV für HP-UX oder Solaris installieren
In den folgenden Schritten bezieht sich "EMSRV-Benutzer"
auf den Benutzer, der das Programm EMSRV startet.
Sie müssen die folgenden Dateien aus dem TeamServer-Verzeichnis auf Ihre Maschine kopieren:
Für HP-UX:
Für Solaris:
Stellen Sie diese Dateien in ein Unterverzeichnis, das Bestandteil Ihres Pfads (PATH) ist, oder erstellen Sie ein Unterverzeichnis und fügen Sie dieses Ihrem PATH hinzu. Es empfiehlt sich, diese Dateien an eine Position zu stellen, die über ausreichend freien Speicherplatz verfügt, da die Datei emsrv.log in das Unterverzeichnis geschrieben wird, in das Sie diese Dateien stellen.
Führen Sie die folgenden Schritte aus, um EMSRV auf einer Solaris- oder HP-UX-Maschine einzurichten:
Die Datei ide.zip file befindet sich im Verzeichnis ivj40\backup, das sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition befindet. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben.
EMSRV muss vollen Lese-, Schreib- und Suchzugriff auf die gesamte Verzeichnisstruktur in ivj.dat.pr haben. ivj.dat.pr sollte immer in dasselbe Verzeichnis kopiert werden wie ivj.dat, da Sie andernfalls nicht auf Ihre Projektressourcen zugreifen können. In den Verzeichnissen müssen rw- und x- (Such-) Bits für den EMSRV-Benutzer definiert sein.
Auf UNIX-Plattformen ist zur Authentifizierung von Benutzern Root-Zugriff erforderlich. EMSRV muss vom Root-Benutzer NICHT gestartet werden, um dies auszuführen. Wird EMSRV gestartet, würde die Sicherheit verletzt, da EMSRV uneingeschränkten Zugriff auf alle Dateisysteme erhielte.
Sie sollten stattdessen den Eigner der EMSRV-Executable in 'root' ändern und das SUID-Bit der Executable aktivieren. Gehen Sie dazu folgendermaßen vor:
chown root emsrv
chmod u+s emsrv
Wenn EMSRV versucht, einen Benutzer zu authentifizieren, wird es vorübergehend die Berechtigung des aktiven EMSRV-Prozesses in die Berechtigung des Eigners der Executable ändern. Nach der Authentifizierung wird die Berechtigung wieder in die des Benutzers geändert, der EMSRV gestartet hat. Dies betrifft jeweils nur den Prozess bzw. den Client, d. h. während der Authentifizierung eines Clients hat nur der Prozess, der den Client bedient, vorübergehenden Root-Zugriff.
Der Root-Zugriff ist für die Authentifizierung erforderlich, unabhängig davon, wie EMSRV die Authentifizierung tatsächlich implementiert. Schnittstellen wie PAM stellen nur eine allgemeine API bereit, die es Anwendungen ermöglicht, verschiedene Authentifizierungsmethoden zu unterstützen. Die jeweilige methodenspezifische Konfiguration muss weiterhin korrekt sein.
C.2.6 EMSRV für Linux
C.2.6.1 EMSRV für Linux einrichten
Vor der Installation von EMSRV unter Linux sind folgende Informationen zu beachten:
C.2.6.2 Installation von EMSRV für Linux
In den folgenden Schritten bezieht sich "EMSRV-Benutzer"
auf den Benutzer, der das Programm EMSRV startet.
Sie müssen die folgenden Dateien aus dem TeamServer-Verzeichnis auf Ihre Maschine kopieren:
Stellen Sie diese Dateien in ein Unterverzeichnis, das Bestandteil Ihres Pfads (PATH) ist, oder erstellen Sie ein Unterverzeichnis und fügen Sie dieses Ihrem PATH hinzu. Es empfiehlt sich, diese Dateien an eine Position zu stellen, die über ausreichend freien Speicherplatz verfügt, da die Datei emsrv.log in das Unterverzeichnis geschrieben wird, in das Sie diese Dateien stellen.
Führen Sie die folgenden Schritte aus, um EMSRV auf einer Linux-Maschine einzurichten:
Die Datei ide.zip file befindet sich im Verzeichnis ivj40\backup, das sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition befindet. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben.
EMSRV muss vollen Lese-, Schreib- und Suchzugriff auf die gesamte Verzeichnisstruktur in ivj.dat.pr haben. ivj.dat.pr sollte immer in dasselbe Verzeichnis kopiert werden wie ivj.dat, da Sie andernfalls nicht auf Ihre Projektressourcen zugreifen können. In den Verzeichnissen müssen rw- und x- (Such-) Bits für den EMSRV-Benutzer definiert sein.
Auf UNIX-Plattformen ist zur Authentifizierung von Benutzern Root-Zugriff erforderlich. EMSRV muss vom Root-Benutzer NICHT gestartet werden, um dies auszuführen. Wird EMSRV gestartet, würde die Sicherheit verletzt, da EMSRV uneingeschränkten Zugriff auf alle Dateisysteme erhielte.
Sie sollten stattdessen den Eigner der EMSRV-Executable in 'root' ändern und das SUID-Bit der Executable aktivieren. Gehen Sie dazu folgendermaßen vor:
chown root emsrv
chmod u+s emsrv
Wenn EMSRV versucht, einen Benutzer zu authentifizieren, wird es vorübergehend die Berechtigung des aktiven EMSRV-Prozesses in die Berechtigung des Eigners der Executable ändern. Nach der Authentifizierung wird die Berechtigung wieder in die des Benutzers geändert, der EMSRV gestartet hat. Dies betrifft jeweils nur den Prozess bzw. den Client, d. h. während der Authentifizierung eines Clients hat nur der Prozess, der den Client bedient, vorübergehenden Root-Zugriff.
Der Root-Zugriff ist für die Authentifizierung erforderlich, unabhängig davon, wie EMSRV die Authentifizierung tatsächlich implementiert. Schnittstellen wie PAM stellen nur eine allgemeine API bereit, die es Anwendungen ermöglicht, verschiedene Authentifizierungsmethoden zu unterstützen. Die jeweilige methodenspezifische Konfiguration muss weiterhin korrekt sein.
C.3.1 Migration von Version 6.x von EMSRV auf Version 7.1
Wenn Sie bisher Version 6.x oder Version 7.0 von EMSRV verwendet haben und nun Version 7.1 von EMSRV installieren wollen, können Sie Version 6.x/7.0 deinstallieren oder in Koexistenz mit Version 7.1 beibehalten.
Um mit VisualAge für Java, Version 4.0, arbeiten zu können, müssen Sie Version 7.0 von EMSRV installieren.
Um von EMSRV, Version 6.x/7.0 auf EMSRV, Version 7.1 zu migrieren, führen Sie die folgenden Schritte aus:
EMSRV 7.1 ist mit EMSRV 6.x/7.0 kompatibel. Wenn Sie beispielsweise in einer früheren Version von VisualAge für Java arbeiten, die EMSRV 6.x/7.0 verwendet, können Sie von dieser Version eine Verbindung zu einem Repository herstellen, das unter EMSRV 7.1 ausgeführt wird.
Zu diesem Zeitpunkt haben Sie bereits die Repository-Server-Programme und das Repository mit gemeinsam benutztem Quellencode installiert. Um die Einrichtung der Team-Entwicklungsumgebung abzuschließen, müssen Sie den Server starten und eine Verbindung zu ihm vom VisualAge für Java-Client herstellen. Anschließend müssen Sie zur Repository-Liste Benutzer hinzufügen.
Wenn Sie den VisualAge für Java-Client bereits auf einer Workstation installiert haben, können Sie in der Online-Hilfe weitere Informationen zur Einrichtung der Team-Entwicklungsumgebung nachlesen. Sie finden diese Informationen jedoch auch in der Datei team.pdf im pdf-Verzeichnis. Das pdf-Verzeichnis befindet sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben. Wenn Sie nicht das Archiv heruntergeladen haben, das die PDF-Dateien enthält, steht dieses Verzeichnis jedoch nicht zur Verfügung.
In den folgenden Anweisungen wird davon ausgegangen, dass das gemeinsam benutzte Repository, das auf dem Server installiert ist, den Namen ivj.dat hat. Beim Starten des Repository-Server-Programms muss der Administrator darauf achten, dass er die richtigen Pfadinformationen für ivj.dat als EMSRV-Arbeitsverzeichnis angibt.
C.4.1 Vorbereitungen für den Team-Server
Bevor Team-Entwickler mit dem gemeinsam benutzten Repository arbeiten können, muss der Administrator den VisualAge für Java-Server installieren und das EMSRV-Repository-Server-Programm starten. Falls einige Entwickler VisualAge für Java, Version 4.0 verwenden möchten, bevor der Server bereit ist, können Sie die Installation zunächst als eigenständige Benutzer durchführen und später eine Verbindung zum gemeinsam benutzten Repository herstellen.
C.4.2 Testen einer Client-Verbindung
Um sicherzustellen, dass der Server erfolgreich gestartet wurde, sollte der Administrator von einem Client von VisualAge für Java, Enterprise Edition, Version 4.0 eine Verbindung zum gemeinsam benutzten Repository herstellen. Diese Aktion bestätigt, dass die TCP/IP-Verbindung des Servers richtig funktioniert, dass EMSRV mit den richtigen Parametern gestartet wurde und dass dem Administrator bekannt ist, welche Server-Informationen während der Client-Installation angegeben werden müssen.
Informationen zum Herstellen einer Verbindung zu einem gemeinsam benutzten Repository sind im Abschnitt "Herstellen einer Verbindung zu einem gemeinsam benutzten Repository" in der Online-Hilfe von VisualAge für Java oder in der Datei team.pdf enthalten. Die Datei team.pdf befindet sich im pdf-Verzeichnis auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben. Wenn Sie nicht das Archiv heruntergeladen haben, das die PDF-Dateien enthält, steht dieses Verzeichnis jedoch nicht zur Verfügung.
C.4.3 Hinzufügen von Benutzern zur Repository-Benutzerliste
Wenn ein Client zum erstenmal eine Verbindung zum gemeinsam benutzten Repository herstellt, wird der Benutzer aufgefordert, den Namen des Eigners eines Arbeitsbereichs anzugeben. Der Benutzer kann die IDE nicht starten, ohne zuvor einen gültigen Eignernamen des Arbeitsbereichs aus einer Liste mit Repository-Benutzern auszuwählen.
Standardmäßig ist in der Repository-Benutzerliste von VisualAge für Java, Version 4.0 ein Benutzer namens Administrator enthalten. Jeder Benutzer kann anfangs Administrator als Eignernamen des Arbeitsbereichs auswählen. Wir empfehlen jedem Benutzer jedoch dringend, für die Verbindungsherstellung mit dem Server von Anfang an einen eindeutigen Namen anzugeben. In der VisualAge für Java-Team-Entwicklungsumgebung basiert die Änderungssteuerung auf definierten Benutzeraufgabenbereichen. Dies bedeutet, dass jeder Entwickler eindeutig identifiziert sein sollte. Um dieses Ziel zu erreichen, muss der Administrator jeden Entwickler zur Liste der Repository-Benutzer hinzufügen. (Der einzige VisualAge für Java-Benutzer, der andere Namen zu einer Repository-Benutzerliste hinzufügen kann, ist der Administrator.) Der jedem Benutzer zugeordnete eindeutige Name muss mit einem Systembenutzernamen übereinstimmen, wenn die native Kennwortüberprüfung verwendet wird.
Informationen zum Hinzufügen von Benutzern zur Repository-Liste finden Sie in der Team-Online-Hilfe von VisualAge für Java oder in der Datei team.pdf. Das pdf-Verzeichnis befindet sich auf der CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java, Enterprise Edition. Falls Sie eine elektronische Version von VisualAge für Java haben, finden Sie das Verzeichnis in Ihrem temporären Verzeichnis, in das Sie Ihre Archivpakete entpackt haben. Wenn Sie nicht das Archiv heruntergeladen haben, das die PDF-Dateien enthält, steht dieses Verzeichnis jedoch nicht zur Verfügung.
Der Server ist nun eingerichtet und betriebsbereit; die Benutzer müssen nun mit der Installation ihrer VisualAge für Java-Clients fortfahren. Informationen zur Installation der VisualAge für Java-Team-Clients finden Sie in Teil B dieses Handbuchs.
C.5.1 Leistungen auf Netzwerken mit geringer Bandbreite und hoher Latenz
Das für die Kommunikation zwischen EMSRV-Clients und EMSRV verwendete Protokoll führt im Allgemeinen zu einer hohen Rate an Paketen, die an den Server übertragen werden. Dies liegt daran, dass ein Großteil der Verarbeitung am Client erfolgt. Bei den meisten der von EMSRV verarbeiteten Anforderungen handelt es sich um E/A-Anforderungen (beispielsweise um Satzsperren sowie Lese- und Schreibanforderungen).
Aufgrund dieser Architektur hängt die Leistung am Client-Ende sehr stark von der Latenzzeit des Netzes ab. Eine Latenzzeit (gemessen an den Umlauf- und 'ping'-Paketzeiten) von weniger als 5 ms führt erwartungsgemäß zu einer akzeptablen Leistung. Die LAN-Latenzzeit beträgt im Allgemeinen weniger als 1 ms, doch bei WAN-Verbindungen oder Modemwahlverbindungen über eine Telefonleitung können Latenzzeiten von bis zu 500 ms auftreten. Selbst bei Hochgeschwindigkeits-DSL-, Kabel-, Frame Relay- oder ISDN-Verbindungen ist die Latenzzeit eine Funktion der Distanz zwischen zwei Endpunkten.
Im Allgemeinen bieten Modemwahlverbindungen über eine Telefonleitung nur eine inakzeptable Leistung, da Verbindungen dieser Art normalerweise eine Latenzzeit von 200 ms oder mehr haben. Hochgeschwindigkeitsverbindungen bieten ebenfalls nur eine inakzeptable Leistung, es sei denn, die Distanz zwischen Client und Server beträgt höchstens einige hundert Kilometer.
Das EMSRV-Protokoll ist nicht besonders bandbreitenintensiv, doch die Verwendung von Bandbreiten ist eine Funktion der Anzahl der Clients, die eine Verbindung gleichzeitig verwenden.
C.5.2 Einschränkungen bei der TCP/IP-Verbindung
Die Standardbegrenzung für Client-Verbindungen zu EMSRV ist 512. Diese Begrenzung kann über die Befehlszeilenoption -M geändert werden, wenn Sie EMSRV starten.
Die Zahl wird hauptsächlich vom Hauptspeicher beansprucht; einigen TCP/IP-Stapelspeichern gehen jedoch die Datenstrom-Sockets aus, bevor diese Speichergrenze erreicht ist. In der Regel ist diese Zahl höher als Hundert, sie variiert jedoch bei jedem Stack.
C.5.3 Feststellen von unerwartet unterbrochenen Verbindungen
EMSRV verwendet den TCP/IP KEEPALIVE-Timer, um Verbindungen festzustellen, die unerwartet unterbrochen wurden, wenn ein Client abgestürzt ist oder neu gestartet wurde. Bei einigen TCP/IP-Stacks kann das KEEPALIVE-Zeitlimit geändert werden. Die Standardeinstellung ist in der Regel 120 Minuten.
EMADMIN kann verwendet werden, um die Verbindungen aufzulisten und eine Verbindung zu identifizieren, die mit dem Server zum Zeitpunkt der letzten Anforderung lange nicht interagiert hat. Eine solche Verbindung kann anschließend mit dem Befehl EMADMIN STOP und der Option -k geschlossen werden.
C.5.4 Wechsel zwischen verschiedenen Versionen von EMSRV- und EMSRV-Utilities
VisualAge für Java, Version 4.0, umfasst Version 7.1 des Dienstprogramms EMSRV und Version 7.0 des Dienstprogramms EMADMIN.
Sie müssen EMADMIN 7.0 mit EMSRV 7.1 verwenden. EMADMIN 7.0 funktioniert nicht einwandfrei mit früheren Versionen von EMSRV.
C.5.5 PAM-Einschränkungen
Auf Linux- und Solaris-Plattformen wird die Authentifizierung mit Hilfe von PAM (Password Authentication Modules) implementiert. Auch wenn dies theoretisch bei einfacher Änderung der entsprechenden PAM-Konfigurationsdatei die Verwendung beliebiger PAM mit EMSRV erlauben würde, ist dies in der Praxis jedoch nicht möglich.
EMSRV kann mit Clients nicht in einer Weise kommunizieren, die völlig kompatibel mit der PAM-Architektur wäre. Daher funktioniert die EMSRV-Authentifizierung nur, wenn das Modul zu Beginn ein Text-Kennwort anfordert (das ebenfalls zu Beginn vom Client bereitgestellt wird).
C.5.6 Kennwörter mit nicht-ASCII-Zeichen können nicht zur Authentifizierung in EMSRV verwendet werden
Aufgrund eines Programmfehlers in den Microsoft C-Laufzeitbibliotheken werden alle Kennwörter, die nicht-ASCII-Zeichen enthalten und auf die Aufforderung:
'Geben Sie das Kennwort des Benutzers ein, der EMSRV startete'
hin eingegeben werden, nicht korrekt interpretiert. Um dieses Problem zu umgehen, geben Sie das Kennwort mit der Option -p ein, wenn Sie EMADMIN ausführen.
C.5.7 Bei Ausführung in der japanischen NetWare-Version werden Menüs und Fenster mit 'zerschossenen Zeichen' angezeigtEMSRV für NetWare NLM verwendet NLM User Interface Developer Components (NWSNUT) von Novell. Bei der Ausführung unter Japanese NetWare stehen Grafikzeichen in NWSNUT-Menüs und -Fenstern nicht zur Verfügung und werden als beschädigte Zeichen angezeigt. Dies ist kein Programmfehler in EMSRV NLM oder NetWare, sondern eine Einschränkung der Shift-JIS-Codepage.
C.5.8 EMADMIN kopiert das Verzeichnis der gespeicherten Ressourcen nichtWenn EMADMIN 7.0 zum Kopieren eines Repositorys von VisualAge für Java 4.0 verwendet wird, wird dabei nicht das zugehörige Verzeichnis der gespeicherten Projektressourcen kopiert. Sie müssen das Verzeichnis der gespeicherten Projektressourcen manuell kopieren.
Bitte entnehmen Sie die zur Migration von Swing-Klassen wichtigen Informationen dem Abschnitt 18.0.
Diese Version von VisualAge für Java bietet keine Unterstützung für den CICS(R) Transaction Server. Die für die Unterstützung von CICS TS 1.3 (und frühere Versionen) erforderlichen Klassen sind nicht im Lieferumfang dieser Version enthalten. Alle CICS TS-Anwendungen, die Sie von früheren Versionen von VisualAge für Java zu migrieren versuchen, werden in Version 4.0 nicht funktionieren und sollten aus Ihrem Arbeitsbereich und Repository der Version 4.0 gelöscht werden.
Wenn Sie mit CICS TS 1.3 oder früheren Versionen arbeiten wollen, müssen Sie weiterhin eine ältere Version (3.02 und früher) von VisualAge für Java und nicht 3.5 verwenden. Wenn Sie die JCICS-Schnittstelle verwenden wollen oder Unterstützung für IIOP benötigen, müssen Sie bis auf weiteres ebenfalls eine ältere Version (3.02 und früher) von VisualAge für Java benutzen. Der CICS Transaction Server wird nicht unterstützt, da er auf JDK 1.1.x basiert.
D.2.1. Migration von Version 2.0 oder 3.0x von VisualAge für Java
Data Access Beans verwenden Swing-Komponenten und -Schnittstellen. Alle entwickelten Anwendungen, die diese Beans verwenden, müssen von den alten JDK 1.1.x Swing-Paketen auf die neuen J2SDK v.1.2.2. Swing-Pakete migriert werden. Wählen Sie hierzu die betroffenen Klassen und Pakete nach der Installation von VisualAge für Java, Version 4.0, aus und öffnen Sie den SmartGuide Fix installieren/Migrieren. Wählen Sie das Markierungsfeld Umbenannte JDK1.2-Pakete aufnehmen aus. Dadurch werden die entsprechenden Von/Zu-Einträge für Swing hinzugefügt und können Sie automatisch Swing-Referenzen auf den Java 2 SDK migrieren. Alle während der Migration auftretenden Fehler werden im Protokollfenster angezeigt.
Weitere Informationen dazu, wie Sie Ihre Anwendungen korrekt migrieren, finden Sie in der Online-Hilfedatei "Richtlinien für Klassen- oder Paketreferenzen berichtigen/migrieren" des Visual Composition Editors und in der zugehörigen Aufgabendatei "Klassen- oder Paketreferenzen reparieren".
D.2.2. Migration von Version 3.5 von VisualAge für Java
Wenn Sie von VisualAge für Java, Version 3.5 migriert haben, brauchen Sie keine zusätzlichen Schritte zur Migration Ihrer Data Access Beans auszuführen, da Data Access Beans in Version 3.5 die Swing-Pakete von J2SDK v.1.2.2 verwendet haben.
Der Data Access Builder ist nicht mehr in VisualAge für Java enthalten. Wenn Sie den Data Access Builder weiter verwenden wollen, müssen Sie weiterhin mit einer früheren Version von VisualAge für Java arbeiten.
In VisualAge für Java, Version 4.0 ist kein neues Feature enthalten, das die bisher vom Data Access Builder bereitgestellte Funktionalität direkt ersetzt. Es sind jedoch drei Komponenten in VisualAge für Java vorhanden (Data Access Beans, Persistence Builder und die EJB-Entwicklungsumgebung), die eine ähnliche Funktionalität bieten. Jede dieser Komponenten bietet einen unterschiedlichen Ansatz zum Erstellen von Datenzugriffsklassen.
Sie können Ihren Code nicht auf VisualAge für Java, Version 3.5.3, migrieren, um ihn in einem dieser Tools zu verwenden. Sie müssen Ihre Anwendungen neu erstellen, wenn Sie sie in Version 4.0 verwenden wollen. Verwenden Sie das Feature, das Ihren wesentlichsten Ansprüchen bei der Code-Entwicklung und den jeweiligen Aufgaben der Anwendungen genügt.
Einen Vergleich zwischen dem Data Access Builder, Data Access Beans und dem Persistence Builder finden Sie im Anhang dieses Handbuchs.
D.4.1 Migration von Enterprise-Beans von VisualAge für Java, Version 2.0, Enterprise Update
Wenn Sie Enterprise-Beans in VisualAge für Java, Version 2.0, Enterprise Update erstellt haben und diese in VisualAge für Java, Version 4.0 weiterverwenden wollen, müssen Sie die folgenden Schritte in Ihrer aktuellen Version von VisualAge für Java, Version 2.0, Enterprise Update ausführen:
Um das Migrieren Ihres Enterprise-Bean-Codes in VisualAge für Java, Version 4.0 abzuschließen, befolgen Sie entweder die nachstehend beschriebenen Schritte in Szenario 1 oder Szenario 2 beschriebenen Schritte - je nach dem, ob Sie aus einem Repository (empfohlen) oder aus einer JAR-Datei importieren.
Szenario 1 - Import aus einem Repository
Wenn Sie Ihre Beans aus einem Repository importieren, führen Sie die folgenden Schritte
aus:
Weitere Informationen zum Ausführen dieser Schritte finden Sie in der VisualAge für Java Online-Hilfe für die EJB-Entwicklungsumgebung.
Szenario 2 - Import aus einer JAR-Datei
Wenn Sie Ihre Enterprise-Beans in eine JAR-Datei exportiert hatten, führen Sie die
folgenden Schritte aus:
Weitere Informationen zum Ausführen dieser Schritte finden Sie in der VisualAge für Java Online-Hilfe für die EJB-Entwicklungsumgebung.
D.4.2 Migration von Enterprise-Beans von VisualAge für Java, Version 3.0 oder 3.02
Wenn eine Ihrer vorhandenen Enterprise-Beans implementierten Code enthält, der entweder m it VisualAge für Java, Version 3.0 oder Version 3.02, generiert wurde, und wenn Sie nun mit der Enterprise-Bean unter VisualAge für Java, Version 4.0. arbeiten wollen, müssen Sie die Enterprise-Bean auf Version 4.0 migrieren und anschließend den implementierten Code explizit löschen und erneut generieren.
Bevor Sie den Enterprise-Bean-Code jedoch auf Version 4.0 migrieren können, müssen Sie die folgenden Schritte in Ihrer aktuellen Version von VisualAge für Java (Version 3.0 oder Version 3.02) ausführen:
Um den Enterprise-Bean-Code zu migrieren und den implementierten Code anschließend erneut zu generieren, führen Sie die folgenden Schritte in VisualAge für Java, Version 4.0, genau in der angegebenen Reihenfolge aus:
D.4.3 Migration von EJB-Zuordnungen von VisualAge für Java, Version 3.0
Wenn Sie eine Zuordnung in einer EJB-Gruppe hinzufügen, bearbeiten oder löschen, die mit VAJ Version 3.0 erstellt wurde, wandelt VisualAge für Java automatisch alle Zuordnungen in der EJB-Gruppe in das neue Zuordnungsformat um. Um den Migrationsprozess abzuschließen, nehmen Sie manuell die folgenden Änderungen vor:
Diese Methoden werden nicht automatisch umgewandelt, da es sehr wahrscheinlich ist, dass sie handgeschriebene Änderungen enthalten. VisualAge für Java fügt die Aufrufe automatisch hinzu wenn in Version 4.0 neue Beans erstellt werden.
Wenn Sie eine in Version 3.0 (oder früher) erstellte CMP-Entitäts-Bean in eine EJB-Gruppe importieren, deren Zuordnungen bereits migriert wurden, und wenn Sie danach eine neue Bean hinzufügen, die von der importierten CMP-Entitäts-Bean (Eigenschaften) erbt, wird in der Bean-Klasse der neuen Bean neben einigen Methoden ein rotes X angezeigt. Der Grund dafür ist, dass in der Bean-Klasse der importierten Bean die Methoden _initLinks, _getLinks und _removeLinks fehlen. Sie müssen diese Methoden manuell in die Bean-Klasse der importierten Bean einfügen.
Wenn Sie bereit sind, Ihren Enterprise-Bean-Code für einen Produktionsanwendungs-Server zu implementieren, sollten Sie sicherstellen, dass Sie ebenfalls die Laufzeit-JAR-Datei implementieren, die den von den Associations- und Access-Beans benötigten Laufzeit-Code enthält. Diese JAR-Datei sollte auf Ihrem Anwendungs-Server implementiert und in den Klassenpfad des Anwendungs-Servers aufgenommen werden. Zusätzliche Informationen zur Laufzeit-JAR-Datei finden Sie in der Online-Hilfe zur EJB-Entwicklungsumgebung.
D.4.4 Migration von EJB-Zuordnungen von VisualAge für Java 3.02
Wenn Sie zum ersten Mal eine EJB-Gruppe öffnen, die in VisualAge für Java, Version 3.02, erstellte Zuordnungen enthält, werden in der Gruppe neben generierten Verbindungsklassen Fehlersymbole angezeigt. Wenn Sie in einer dieser EJB-Gruppen eine Zuordnung hinzufügen, bearbeiten oder löschen, repariert VisualAge für Java automatisch alle Verbindungsklassen für alle Zuordnungen in der EJB-Gruppe. Auch wenn Sie an der Zuordnung keine Änderungen vornehmen wollen, müssen Sie nun zunächst die Zuordnung im Teilfenster Eigenschaften der Seite EJB auswählen und in ihrem Kontextmenü Editieren auswählen, um den Zuordnungseditor aufzurufen. Klicken Sie dann auf OK, um den Migrationsprozess abzuschließen.
VisualAge für Java wird automatisch einige zuordnungsbezogenen Methoden entfernen, die in VisualAge für Java 3.02 erstellt wurden. Es werden nur solche Methoden entfernt, die angesichts der Merkmale der Zuordnung in Version 4.0 nicht korrekt funktionieren würden. Wenn beispielsweise der Primärschlüssel einen Aufgabenbereich enthält, ist die für diesen Aufgabenbereich definierte Methode ungültig. Diese Methode wäre in Version 3.02 automatisch generiert worden und kann in Version 4.0 nicht generiert werden.
D.5.1 Enterprise Access Builder
D.5.1.1 Neue Unterstützung von Konnektoren
Der Enterprise Access Builder unterstützt jetzt Konnektoren sowohl von Common Connector Framework (CCF)
als auch von Java 2, Enterprise Edition (J2EE) Connector Architecture. Der Enterprise Access Builder verfügt über neue Tools, mit denen EAB-Sätze, -Befehle, -Navigatoren und Sitzungs-Beans von einem CCF-Format auf ein Format von J2EE Connector Architecture migriert werden können. Darüber hinaus wurden die folgenden SmartGuides
und Editoren aktualisiert, um die neue Unterstützung für J2EE Connector Architecture widerzuspiegeln:
Weitere Informationen zur neuen Unterstützung für IBM Connectors und Tools für J2EE(TM) - Beta und die neuen EAB-Migratoren enthält die Online-Hilfe von Enterprise Access Builder.
D.5.1.2 Sätze und Befehle erneut generieren und bearbeiten
Wenn Sie EAB-Anwendungen aus einer früheren Version von VisualAge für Java auf Version 4.0 migrieren
wollen, empfiehlt es sich, dass Sie Ihre Datensätze und Befehle erneut generieren. Dies erhöht
ihre Leistung in Version 4.0.
Bislang waren, wenn Sie "Direkt" und "Namen verkürzen", aber nicht
"Innere Klassen" ausgewählt haben, die Namen generierter Datensätze
gelegentlich länger als nötig. Dies führte gelegentlich dazu, dass
Namen generiert wurden, die die Windows-Begrenzung für Dateinamen von 255 überschritten. Der
SmartGuide 'Satz aus Satztyp erstellen' wurde optimiert, so dass bei Auswahl der
obigen Optionen jetzt möglichst kurze Datensätze generiert werden. Allerdings
kann sich die erneute Generierung mit diesen Optionen auf Ihre Anwendungen auswirken,
da sich Datensatznamen ändern können.
Wenn Ihr EAB-Befehl in Version 2.0x erstellt wurde, können Sie ihn nicht im Befehlseditor bearbeiten. Sie können Ihn jedoch im Visual Composition Editor bearbeiten. Die aktuelle Version der Laufzeit ist abwärts kompatibel, so dass Sie Befehle aus Version 2.0x damit ausführen können.
D.5.1.3 Anwendungen implementieren
Version 4.0 ist ein Übergang-Release für Enterprise Access Builder (EAB). Die ältere CCF-Architektur (Common Connector Framework), auf der EAB basierte, wird in die neue J2EE Connector-Architektur versetzt. Die EAB-Dokumentation behandelt diesen Übergang und die Unterschiede zwischen den Architekturen. In diesem Release werden beide Architekturen unterstützt. Für die Implementierung bedeutet dies, dass es einige Unterschiede gibt. Ausführliche Informationen hierzu enthält der Abschnitt zur Implementierung in der EAB-Dokumentation. Der folgende Abschnitt bietet eine einfache Übersicht über die Implementierung.
Im Hinblick auf bestehende Anwendungen können Sie weiterarbeiten wie bisher. Implementieren Sie Ihre Anwendung mit eab\runtime30\eablib.jar, ccf.jar, recjava.jar und den JAR-Dateien, die Ihr Konnektor bei Laufzeit benötigt. Bei neuen Anwendungen, denen einige Komponenten der J2EE Connector-Architektur hinzugefügt wurden (wie beispielsweise Datensätze und Befehle, die die J2EE-Architektur verwenden), implementieren Sie Ihre Anwendungen mit eab\runtime35\eablib.jar. Die Datei ist bimodal, d. h. sie unterstützt beide Architekturen. Außerdem benötigen Sie andere JAR-Dateien, die nur mit J2EE in Zusammenhang stehen. Diese Dateien werden im Abschnitt zur Implementierung in der EAB-Dokumentation angegeben.
D.5.2 E-Konnektoren
Der folgende Abschnitt enthält Informationen über die Migration von IMS Connect, CICS Connector und E-Konnektoren.
Wichtig: Aufgrund einer Einschränkung in der Unterstützung des CDFS (CD-ROM File System, CD-Rom-Dateisystem) unter Windows 98, kann die Installation bestimmter e-Business-Konnektoren-Dateien von der CD-ROM fehlschlagen, und eine oder mehrere der folgenden Fehlerdialoge können angezeigt werden (abhängig von den ausgewählten Konnektoren):
Alle Dateien, die nicht installiert wurden, werden in einer Zip-Datei (econnfix.zip) gespeichert, die sich im Stammverzeichnis der Produkt-CD befindet. Wenn Sie versuchen, VisualAge für Java unter Windows 98 zu installieren und eine der o.g. Fehlernachrichten erhalten, müssen Sie econnfix.zip in das Verzeichnis entzippen, in dem das Produkt installiert wurde (beispielsweise, indem Sie den Befehl unzip econnfix.zip -d c:\Programme\IBM\VisualAge for Java\ ausführen - hierbei ist c:\Programme\IBM\VisualAge for Java\ Ihr Produkt Installationsverzeichnis). Wenn sich diese Dateien danach in der korrekten Lokation befinden, funktionieren die Konnektoren korrekt.
D.5.2.1 IMS Connect
Die Unterstützung für IMS TCP/IP OTMA Connection (IMS TOC) läuft
im März 2001 aus. Benutzern wird empfohlen, von IMS TOC auf IMS
Connect zu migrieren und IMS Connect anstelle von IMS TOC zu verwenden.
IMS Connect ist ein getrennt erhältliches (nicht in VisualAge für Java enthaltenes) SMP-installierbares IBM Produkt, das zusammen mit VisualAge für Java IMS Connector für den Zugriff auf IMS verwendet werden kann. Nach der Migration von IMS TOC auf IMS Connect können Sie Ihre IMS Connector für Java-Programme weiterhin verwenden, ohne sie ändern oder aktualisieren zu müssen.
D.5.2.2 CICS Connector
Das Verhalten der Markierung CICSELUW im Konstruktor ECIInteractionSpec wurde geändert, um die CCF Connector-Architektur korrekt nachzubilden. In früheren Releases nahm diese Markierung standardmäßig den Wert FALSE im Konstruktor an und überprüfte stets, ob
die LUW erweitert war oder nicht, unabhängig davon, ob ein echter Koordinator vorhanden war oder nicht.
In diesem Release nimmt die Markierung CICSELUW standardmäßig den Wert TRUE im Konstruktor ECIInteractionSpec an, wenn ein echter CCF-Koordinator (beispielsweise JavaCoordinator) vorhanden ist. Sofern Sie diese Eigenschaft in Ihrem alten VisualAge für Java-Code nicht spezifisch definiert haben, wird die Eigenschaft CICSELUW in Ihrem alten Code jetzt standardmäßig den Wert TRUE annehmen, nachdem Sie ihn auf VisualAge für Java, Version 4.0 migriert haben.
Wenn kein echter Koordinator vorhanden ist, wird diese Markierung ignoriert, und alle Ihre Anwendungen (sowohl die alten als auch die neuen, die Sie in VisualAge für Java, Version 4.0 erstellen) verhalten sich, als ob die Markierung CICSELUW den Wert FALSE hat. Daher hat die explizite Einstellung dieser Markierung keine Auswirkungen, es sei denn, Sie implementieren einen echten Co-Koordinator in Ihrer Umgebung.
D.5.2.3 Migration von E-Konnektoren
Während die Koexistenz von früheren Versionen von VisualAge für Java mit Version 4.0
möglich ist, gibt es für die Koexistenz verschiedener e-Konnektor-Stufen keine
Unterstützung.
Migration von VisualAge für Java, Version 3.0x oder Version 3.5.x
Wenn Sie e-Konnektoren installiert haben, müssen Sie nach einem der folgenden Szenarien vorgehen, um erfolgreich von einer Version 3.0x oder Version 3.5.x von VisualAge für Java auf Version 4.0 zu migrieren.
Der Unterschied zwischen den beiden Migrationsszenarien liegt im Zeitpunkt, zu dem die Konnektoren migriert werden.
In Szenario 1 werden die Konnektoren während der Installation von Version 3.5 migriert. Nachdem Sie die Schritte in diesem Szenario ausgeführt haben, verfügen Sie über VisualAge für Java Version 3.0x oder 3.5.x ohne Konnektoren in Koexistenz mit VisualAge für Java, Version 4.0, mit Konnektoren.
In Szenario 2, werden die Konnektoren nach dem allgemeinen Migrationsprozess migriert. Nachdem Sie die Schritte in diesem Szenario ausgeführt haben, verfügen Sie über VisualAge für Java Version 4.0 ohne Konnektoren in Koexistenz mit VisualAge für Java, Version 3.0x oder 3.5.x0, mit Konnektoren. Sie können zu einem späteren Zeitpunkt die Konnektoren der Version 3.0x oder der Version 3.5.x deinstallieren und die Konnektoren der Version 4.0 installieren.
Migrationsszenario 1
Um Fehler und Konflikte mit zukünftigen Installationen von Konnektoren zu vermeiden, dürfen die Umgebungsvariablen keine Referenzen auf die entfernten Konnektoren enthalten. Um Umgebungsvariablen zu bearbeiten, gehen Sie folgendermaßen vor:
Windows NT und Windows 2000
Windows 98
Der Access Builder und der Konnektor für SAP R/3 stellen ebenfalls einige Utility-Klassen (beispielsweise LogonBean) bereit, die auf Swing 1.0.3 basieren. Diese Klassen werden durch Klassen ersetzt, die auf Swing 1.1 basieren. Wenn Sie von Version 3.0x oder Version 3.5.x auf Version 4.0 migrieren, müssen Sie Ihre auf Swing 1.0.3 basierenden Klassen auf die Stufe von 1.1 migrieren, so dass Sie die von Access Builder und dem Konnektor für SAP R/3 bereitgestellten Utility-Klassen weiter verwenden können. Für diesen Prozess können Sie den SmartGuide Fix installieren/Migrieren verwenden.
Migrationsszenario 2
Wenn Sie die Konnektoren von VisualAge für Java, Version 4.0, installieren wollen, müssen Sie entweder Version 3.0x/3.5.x deinstallieren oder die Konnektoren der Version 3.0x/3.5.x deinstallieren. Gehen Sie dazu anhand der Schritte im Migrationsszenario 1 vor. Nachdem Sie die Konnektoren der Version 3.0x/3.5.x oder VisualAge für Java, Version 3.0x/3.5.x, deinstalliert haben, können Sie die Konnektoren für Version 4.0 installieren. Gehen Sie dazu folgendermaßen vor:
Migration von VisualAge für Java, Version 3.5 oder Version 3.5.3
Wenn Sie von VisualAge für Java, Version 3.5 oder 3.5.3 auf VisualAge für Java, Version 4.0 migrieren, müssen Sie mit VisualAge für Java 3.5 oder 3.5.3 installierten IBM Konnektoren zunächst deinstalliert werden, um sicherzustellen, dass die korrekte Version der IBM Konnektoren mit VisualAge für Java 4.0 installiert wird.
Wenn Sie versuchen, VisualAge für Java, Version 4.0 zu installieren, bevor Sie die IBM Konnektoren der Version 3.5 oder 3.5.3 entfernen, wird ein Dialogfenster angezeigt in dem Ihnen mitgeteilt wird, dass Sie zunächst alle Anwendungen migrieren müssen, die IBM Konnektoren verwenden; erst dann können Sie mit der Installation der Version 4.0 fortfahren.
Um alle Ihre Anwendungen zu migrieren und die IBM Konnektoren der Version 3.5 oder 3.5.3 zu deinstallieren, führen Sie die folgenden Schritte aus.
Um Fehler und Konflikte mit zukünftigen Installationen von Konnektoren zu vermeiden, dürfen die Umgebungsvariablen keine Referenzen auf die entfernten Konnektoren enthalten. Um Umgebungsvariablen zu bearbeiten, gehen Sie folgendermaßen vor:
Windows NT und Windows 2000
Windows 98
Konnektoren deinstallieren
Wenn Sie VisualAge für Java, Version 4.0, deinstallieren, werden die Konnektoren automatisch deinstalliert. Um Fehler und Konflikte mit zukünftigen Installationen von Konnektoren zu vermeiden, dürfen die Umgebungsvariablen keine Referenzen auf die entfernten Konnektoren enthalten. Führen Sie die entsprechenden nachfolgenden Schritte aus, um Umgebungsvariablen zu bearbeiten:Windows NT und Windows 2000
Windows 98
Nur Windows 98: Sie müssen das Verzeichnis der e-Konnektoren (standardmäßig:C:\IBM Connectors) ggf. manuell löschen, nachdem Sie VisualAge für Java deinstalliert haben.
D.6.1 Migration von Version 2.0 von VisualAge für Java
Klassen, die mit dem Enterprise Toolkit für AS/400 in VisualAge für Java, Version 2.0, generiert wurden, sind nicht mit Java-Klassen kompatibel, die mit dem Enterprise Toolkit für AS/400 in VisualAge für Java, Version 4.0, erstellt wurden. Der Grund für die Inkompatibilität liegt darin, dass die mit Version 2.0 ET/400 erstellten Java-Klassen das Abstract Windowing Toolkit (AWT) verwendeten und dass die mit Version 4.0 ET/400 erstellten Java-Klassen Java 2 SDK Swing verwenden.
Die in Version 2.0 breitgestellten Klassen sind jedoch weiterhin im Paket com.ibm.ivj.et400.util.awt vorhanden, das in VisualAge für Java, Version 4.0, enthalten ist. Wenn Sie die in Version 2.0 generierten Klassen in VisualAge für Java, Version 4.0, verwenden wollen, müssen Sie alle in diesen Klassen vorhandenen Referenzen auf das Paket com.ibm.ivj.et400.util in Referenzen auf com.ibm.ivj.et400.util.awt ändern. Sie können hierzu den SmartGuide Fix installieren/Migrieren verwenden. Alle Fehler, die während der Migration auftreten, werden im Protokollfenster aufgeführt. Weitere Informationen und Anweisungen dazu, wie Sie den SmartGuide verwenden können, finden Sie in der Online-Hilfe.
D.6.2 Migration von Version 3.0 oder 3.02 von VisualAge für Java
Klassen, die mit dem SmartGuide ET/400-Anzeigedatei konvertieren in VisualAge für Java, Version 3.0 oder 3.02, erstellt wurden, sind nicht mit Java-Klassen kompatibel, die mit dem gleichen SmartGuide in VisualAge für Java, Version 4.0, generiert wurden.
Der Grund für die Inkompatibilität liegt darin, dass der in Version 3.0 und 3.02 generierte Code mittlerweile 'ausrangierte' Klassen verwendet, wie AS400SVisualTextField nebst Unterdateiklassen, während der in Version 4.0 generierte Code JFormatted-Beans verwendet. Alle herabgestuften Klassen sind weiterhin im Paket com.ibm.ivj.et400.util vorhanden, das in VisualAge für Java, Version 4.0, enthalten ist. Wenn Sie die in Version 3.0 oder 3.02 generierten Klassen verwenden wollen, müssen Sie mit dem SmartGuide Fix installieren/Migrieren alle migrierten Klassen umwandeln, so das sie auf die neuen Java 2 SDK Swing-Paketnamen verweisen. Öffnen Sie hierfür den SmartGuide und wählen Sie das Markierungsfeld Umbenannte JDK 1.2-Pakete aufnehmen aus. Hierdurch werden Swing-Referenzen automatisch in Referenzen auf das Java 2 SDK migriert. Weitere Informationen und Anweisungen hierzu finden Sie in der Online-Hilfe. Alle Fehler, die während der Migration auftreten, werden im Protokollfenster aufgeführt.
Der SmartGuide Unterdatei erstellen ist in VisualAge für Java, Version 4.0, nicht mehr enthalten. Er wurde durch die leistungsfähigeren DFU- und JFormattedTable-Beans ersetzt. Wenn Sie weiterhin mit dem SmartGuide Unterdatei erstellen Code generieren wollen, müssen Sie weiter mit einer früheren Version (3.02 oder früher) von VisualAge für Java arbeiten. Sie können allen Code, den Sie mit dem SmartGuide Unterdatei erstellen in Version 3.0 oder 3.02 generiert haben, auf Version 4.0 migrieren, da die für den generierten Code benötigten Klassen weiter unterstützt werden. Diese Klassen befinden sich im Paket com.ibm.ivj.et400.util. Zum Migrieren Ihres Codes müssen Sie die gleichen Schritte ausführen, wie im vorstehenden Abschnitt beschrieben.
Die Version von ET/390, die Sie zum Entwickeln von OS/390-Anwendungen verwenden sollten, hängt vom SDK-Level ab, der auf OS/390-System- oder Middleware-Anwendungen verfügbar ist, sowie vom SDK-Level, der von VisualAge für Java (einschließlich ET/390) unterstützt wird.
Auf OS/390-System- und Middleware-Anwendungen stehen zwei SDK-Levels zur Verfügung, wie die nachfolgende Tabelle zeigt:
System- oder Middleware-Anwendung | SDK-Level |
---|---|
OS/390 | SDK 1.1.8, 1.3.0 |
WebSphere Application Server, Version 3.0 | SDK 1.1.8 |
CICS Transaction Server, Version 1.3 | SDK 1.1.8 für interpretierte und kompilierte Transaktionen |
DB2 Universal Database, Versionen 5 und 6 | SDK 1.1.8 nur füe kompilierte gespeicherte Prozeduren (Compiled Stored Procedures) |
In VisualAge für Java unterstützen verschiedene Produktversionen unterschiedliche SDK-Levels, wie die nachfolgende Tabelle zeigt:
VisualAge für Java | SDK-Level |
---|---|
Versionen 3.5, 3.5.3 und 4.0 | SDK 1.2.2 |
Version 3.02 | SDK 1.1.8 |
Die folgenden Abschnitte beschreiben die Typen von OS/390-Anwendungen, die Sie mit den verschiedenen Versionen von ET/390 entwickeln können.
VisualAge für Java, Versionen 3.5, 3.5.3 und 4.0
ET/390 in VisualAge für Java, Versionen 3.5, 3.5.3 und 4.0, ist hauptsächlich auf die folgenden Anwendungstypen ausgerichtet:
Für interpretierte Anwendungen unter WebSphere Application Server, Version 3.0, müssen Sie Ihre Anwendungsklassen so erstellen, dass sie mit den Java APIs auf SDK-Level 1.1.8 zusammenarbeiten. Nachdem Sie die Klassen erstellt haben, können Sie sie auf ein für NFS angehängtes Laufwerk exportieren und somit auf dem OS/390-System verfügbar machen. Anschließend können Sie Ihre Anwendung ausführen und debuggen, indem Sie in der IDE von VisualAge für Java die Menüpunkte main ausführen und main debuggen anklicken.
Für eigenständige interpretierte Anwendungen auf dem OS/390-System müssen Sie Ihre Anwendungsklassen so erstellen, dass sie mit den Java APIs auf SDK-Level 1.3.0 zusammenarbeiten. Nachdem Sie die Klassen erstellt haben, können Sie sie auf ein für NFS angehängtes Laufwerk exportieren und somit auf dem OS/390-System verfügbar machen. Anschließend können Sie Ihre Anwendung ausführen, indem Sie in der IDE von VisualAge für Java den Menüpunkt Run main anklicken.
Die Onlinehilfefunktion für ET/390 enthält ausführliche Informationen zum Erstellen, Exportieren, Ausführen und Debuggen von interpretierten Anwendungen.
VisualAge für Java, Version 3.02
ET/390 in VisualAge für Java, Version 3.0.2, ist hauptsächlich auf die folgenden Anwendungstypen ausgerichtet:
Der Enterprise Toolkit für Workstations (ET/WS) und der High-Performance-Compiler (HPJ) sind in diesem Release von VisualAge für Java nicht enthalten. Wenn Sie weiterhin das Enterprise Toolkit für Workstations verwenden wollen, müssen Sie weiter mit einer früheren Version (3.02 oder früher) von VisualAge für Java arbeiten.
In VisualAge für Java, Version 4.0 ist kein neues Feature enthalten, das die bisher von ET/WS bereitgestellte Funktionalität direkt ersetzt. Der in der virtuellen Java-Maschine (JVM) enthaltene "Just-in-time"-Compiler bietet jedoch ähnliche Funktionalität. Die virtuelle Java-Maschine ist enthalten im IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9.
Der JIT-Compiler kompiliert Bytecode direkt in ausführbaren Code und führt anschließend die Programme aus. Der Bytecode wird beibehalten und ist weiterhin portierbar, der Code wird jedoch (nach der Kompilierung durch den JIT) schneller ausgeführt. Weitere Informationen finden Sie auf der Web-Site von Sun(TM) unter http://java.sun.com.
Wenn Sie von VisualAge für Java, Version 3.5 auf Version 4.0 migrieren, können Sie External Version Control weiterhin für Projekte verwenden, die Sie bereits in Version 3.5 mit External Version Control verwendet haben. Wenn die External Version Control-Symbole zunächst nicht angezeigt werden, führen Sie die Aktion Tools > External Version Control > Projekt aktualisieren aus. Anschließend sollten die Symbole angezeigt werden.
Unter Umständen müssen Sie die Anwendungsprogrammierschnittstelle für den Fernzugriff auf Tools (Remote Access to Tools API) erneut starten. Hierzu können Sie den Dialog 'Optionen' verwenden. Wählen Sie Windows > Option aus, um den Dialog 'Optionen' zu öffnen. Wählen Sie Remote Access to Tools API aus, und klicken Sie den Knopf Remote Access to Tools API an, um die Anwendungsprogrammierschnittstelle zu starten.
Wenn Sie den IDL-zu-Java-Compiler verwendet haben, der von IBM Component Broker Series oder dem CICS IIOP Server Support-Feature bereitgestellt wurde, müssen Sie die Aufrufzeichenfolge für den IDL-zu-Java-Compiler in den folgenden Dialogfenstern manuell ändern:
Auf der Seite für IDL-zu-Java-Kompilierung im Dialog Optionen (aufrufbar über das Menü Fenster). Ändern Sie die Zeichenfolge im Feld Befehl.
Im Dialogfenster Kompilieroptionen für IDL-zu-Java ändern. Wählen Sie auf der Seite 'IDL' IDL > Kompilieroptionen ändern... aus. Ändern Sie die Zeichenfolge im Feld Befehl.
Weitere Informationen zum Ändern der Zeichenfolge und zum Öffnen der Seite 'IDL' finden Sie in der Online-Dokumentation der IDL-Entwicklungsumgebung.
Informationen zur Unterstützung von CICS IIOP entnehmen Sie bitte Abschnitt 1.0 in Teil D.
Die JDK-Stufe wurde ab Version 3.5 geändert und lautet jetzt JDK 1.2.2 PTF 9.
Wenn Sie die Java-Klassenbibliothek von VisualAge für Java, Version 3.5 durch Ersetzen oder Hinzufügen von Paketen oder Klassen geändert haben, werden diese Änderungen nach der Migration nicht automatisch in der Java-Klassenbibliothek der Version 4.0 übernommen. Sie müssen die Java-Klassenbibliothek erneut manuell ändern.
In VisualAge für Java vor Version 3.5 bestand auf die Java-Klassenbibliothek ausschließlich Lesezugriff.
Wenn Sie von einer früheren Version von VisualAge für Java auf VisualAge für Java, Version 4.0 migrieren, werden die folgenden beiden Dateien durch neuere Versionen überschrieben, und alle Änderungen, die Sie an diesen beiden Dateien vorgenommen haben, gehen verloren:
Es empfiehlt sich, Sicherungskopien dieser beiden Dateien anzulegen, bevor Sie auf Version 4.0 migrieren, und dann die alten Änderungen den neuen Versionen der Dateien nach Beendigung der Migration auf VisualAge für Java, Version 4.0 hinzuzufügen. Sie dürfen die alten Versionen der Dateien nicht einfach über die neuen Versionen kopieren, da die neuen Versionen Informationen enthalten, die sich nicht in den alten Versionen dieser Dateien befinden.
In diesem Release von VisualAge für Java ist kein Migrationsassistent für ActiveX enthalten. Code, den Sie in früheren Versionen (3.02 oder früher) von VisualAge für Java mit dem Migrationsassistent erstellt haben, können Sie auf Version 4.0 migrieren, indem Sie die in Teil B beschriebenen allgemeinen Migrationsschritte ausführen. In VisualAge für Java, Version 4.0 ist kein neues Feature enthalten, das die bisher vom Migrationsassistent für ActiveX bereitgestellte Funktionalität ersetzt.
Hinweis: Persistence Builder FixPak 3.5.1 oder FixPak 3.5.2 (verfügbar über VADD) braucht auf VisualAge für Java, Version 4.0 nicht angewendet zu werden. Diese Korrekturen (Fixes) wurden bereits in den Code der Version 4.0 integriert.
Sie müssen mit VisualAge für Java jeden Code von früheren Releases des Persistence Builder erneut generieren.
D.14.1 Spezielles Upgrade von Version 2.0
Wenn Sie ein Upgrade von VisualAge für Java, Version 2.0, durchführen, müssen Sie Folgendes beachten bzw. ausführen:
Weitere Informationen zum Ausführen dieser Schritte finden Sie in der Online-Dokumentation für den Persistence Builder.
D.14.2 Migration von allen früheren Versionen (einschließlich Version 2.0)
Wenn Sie verfügbare Modelle, Zuordnungen oder Schemas aus den Browsern laden, wird der Inhalt der Metadaten geändert. Sie können die Metadaten dann nicht zuverlässig in einen Arbeitsbereich laden, der sich auf einem niedrigeren Release-Stand als Version 4.0 befindet. Das Modell, die Zuordnung oder das Schema werden nicht korrekt dargestellt. Sichern Sie das Modell, die Zuordnung oder das Schema.
Hinweis: Die folgenden Informationen gelten nur, wenn Sie von VisualAge für Java, Version 2.0 oder 3.0x migrieren. Falls Sie von Version 3.5 migrieren, gelten diese Informationen nicht.
Klassen, die in früheren Releases für angepaßte Abfragen erstellt wurden, enthalten Fehler. Das angepaßte Abfragegerüst gibt jetzt ein Throwable-Objekt aus, um Ihnen zu ermöglichen, Ausnahmebedingungen abzufangen, die beim Aufruf von angepaßten Abfragen ausgegeben werden. Als Ergebnis werden alle bereits bestehenden angepaßten Abfragen in der IDE mit dem Hinweis angezeigt, dass sie einen unaufgelösten Fehler enthalten (durch ein rotes X angezeigt), da sie die ausgegebene Ausnahmebedingung nicht bearbeiten. Um dies zu korrigieren, geben Sie die Ausnahmebedingung von Ihrer angepaßten Abfrage aus oder fangen Sie die Ausnahmebedingung ab.
Weitere Informationen zur Fehlerbehandlung finden Sie in der Online-Hilfe von VisualAge für Java.
Änderungen an der Laufzeitunterstützung
Der Name des Projekts, das die Javax-Pakete mit den Laufzeitvoraussetzungen
für den Persistence Builder enthält, wurde geändert. Dadurch ist es
möglicherweise erforderlich, dass Sie den Projektpfad für Programmelemente,
die den Persistence Builder verwenden, wie folgt neu ermitteln:
Der RMI Access Builder ist nicht im Lieferumfang von VisualAge für Java, Version 4.0, enthalten. Sie können Ihre alten generierten Klassen und Laufzeitbibliothekprojekte in den Arbeitsbereich der Version 4.0 importieren, Sie können jedoch nicht den Remote Object Invocation Manager (ROIM) ausführen, da er nicht im Lieferumfang enthalten ist. Sie sollten mit der neuen Java 2 Platform vertraut sein und wissen, wie sich dessen Einschränkungen möglicherweise auf Ihre RMI Access Builder-Anwendungen auswirken.
Die RMI Access Builder-Laufzeit dem Arbeitsbereich hinzufügen
Sie müssen die RMI Access Builder-Laufzeit aus VisualAge für Java, Version
3.0x importieren und Ihrem Arbeitsbereich hinzufügen. Ohne diese Laufzeit können Sie Ihre RMI Access Builder-Anwendungen
in VisualAge für Java, Version 4.0 nicht ausführen.
Migration Ihrer RMI Access Builder-Anwendungen
Wenn sich Ihre RMI-Anwendungen nicht bereits im Repository der Version 4.0 befinden,
führen Sie die folgenden Schritte aus, um sie in den Arbeitsbereich zu importieren.
Wenn Sie eines Ihrer Server-Objekte ausführen wollen, müssen Sie zuerst einen Server-Hauptanschluss erstellen. Wenn Sie beispielsweise einen server-seitigen Server-Proxy haben (Reverse1S und ServerObj2S), können Sie einen Server-Hauptanschluss (Server main) schreiben, um die Server-Objekte zu instantialisieren:
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.");
}
}
Aufgrund strengerer Sicherheitsbestimmungen müssen Sie ebenfalls eine Richtliniendatei für Server und Clients schreiben. Angenommen, Sie haben eine Richtliniendatei des Namens "My policy":
grant {
//Alle Berechtigungen erteilen
permission java.security.AllPermission;
};
Sie könnten ebenfalls eine Richtliniendatei haben, die es jedem ermöglicht, an nicht privilegierten Anschlüssen empfangsbereit zu sein:
grant {
// ermöglicht es jedem, an nicht privilegierten Anschlüssen empfangsbereit zu sein
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";
};
wobei pathfinder der Name der Maschine des Benutzers ist.
Um Ihren Client ordnungsgemäß zu starten, müssen Sie einen Befehl ähnlich dem folgenden absetzen:
java-Djava.security.policy=<myPolicy.file>
Wenn Sie beispielsweise main() in der IDE ausführen, würden Sie im Abschnitt für Eigenschaften java.security.policy= angeben, wenn Sie den Menüpunkt "Ausführen mit" auswählen.
Sie sollten Ihren Code in Ihrer früheren Version von VisualAge für Java beibehalten, so dass Sie ihn weiterentwickeln oder erneut generieren können.
Um Metadaten für visuell zusammengesetzte Beans zu reparieren, müssen Sie das IDE-Migrations-Tool verwenden. In der Online-Hilfedatei "Richtlinien für Klassen- oder Paketreferenzen berichtigen/migrieren" finden Sie weitere Informationen dazu, wie Sie Referenzen auf Klassen oder Pakete reparieren können, die durch das Migrieren von Klassen auf J2SDK v.1.2.2 oder durch das Umbenennen benutzerdefinierter Programmelemente unterbrochen wurden.
VisualAge für Java beachtet keine Abhängigkeiten zwischen Klassen, die migriert werden. Klassen, auf die in einer Klasse verwiesen wird und die noch nicht migriert wurden, können bei der Klasseninitialisierung oder in sich selbst Probleme haben.
Alle Fehler, die während der Migration auftreten, werden im Protokollfenster aufgeführt. Angenommen, im Protokollfenster wird die folgende Nachricht angezeigt, während Sie eine Klasse des Namens Sample.Samp migrieren:
Migrating class: Sample.Samp
Could not migrate Class:<Pkg>X::Y
Sample.Samp enthält eine Referenz auf X::Y; VisualAge für Java hat beim Laden der Klasse Y Fehler festgestellt. Entweder wurde Y noch nicht migriert oder Y fehlt völlig. (Im Visual Composition Editor würde Y als eine 'Problem-Klasse' angezeigt.) Um diese Probleme zu beheben, migrieren Sie Y. Falls Y fehlt, stellen Sie eine 'Ersatzklasse' für Y. Falls dies keine Lösung bewirkt, müssen Sie Samp oder Y in Ihrer früheren Version von VisualAge für Java öffnen und Beans oder Eigenschaften neu definieren, damit die Migration fortgesetzt werden kann.
In einigen Fällen wird beim Öffnen der Klasse im VCE der Dialog Klassenreferenzen auflösen aufgerufen. In diesem Dialog werden die im VCE vorhandenen 'Problemklassen' aufgelistet. In der Spalte Nicht aufgelöste Klassenreferenz wird die Klasse angegeben, die VisualAge für Java als temporären Ersatz verwendete. Dies sieht folgendermaßen aus:
com.ibm.uvm.abt.edit.DeletedClassView(X)
Das X in Klammern steht für den Namen der Problemklasse. Es ist wahrscheinlich, dass X nach der aktuellen Klasse korrekt migriert wurde. Um das Problem zu beheben, wählen Sie die zu korrigierende Zeile aus und klicken Sie den Knopf Ersetzen an. Wählen Sie im Dialogfenster Eine gültige Klasse auswählen die Klasse X als Ersatzklasse aus. Verfahren Sie ebenso mit allen anderen unaufgelösten Klassen, und klicken Sie OK an.
Der Servlet Builder und der Servlet Launcher sind nicht im Lieferumfang von VisualAge für Java, Version 4.0, enthalten. Es steht jedoch eine mit Version 4.0 kompatible Servlet Builder Laufzeit-JAR-Datei zur Verfügung, und zwar unter http://www.ibm.com/vadd. Folgen Sie der "Download"-Verknüpfung.
In VisualAge für Java, Version 4.0 ist kein neues Feature enthalten, das die bisher vom Servlet Launcher bereitgestellte Funktionalität direkt ersetzt. Um Ihre Servlets zu testen, können Sie sie entweder durch Eingeben der URL in einem Web-Browser aufrufen, oder Sie können HTML- oder JSP-Seiten schreiben, mit denen die Servlets aufgerufen werden. Sie können den neuen Servlet-SmartGuide zum Entwickeln neuer Servlets verwenden, wobei jeweils eine HTML-Seite erstellt wird, die das neue Servlet aufruft.
Sie können die Laufzeit-Datei auf zwei Weisen einsetzen:
Szenario 1
In diesem Szenario bearbeiten Sie den Code in Ihrer früheren Version von VisualAge für Java mit dem Servlet Builder, bevor Sie ihn exportieren.
Szenario 2
In diesem Szenario bearbeiten Sie Ihren Servlet Builder-Code in VisualAge für Java und testen Sie ihn in der WebSphere Unit-Testumgebung.
Führen Sie die folgenden Schritte aus:
Weitere Informationen zum Ausführen dieser Schritte finden Sie in der Online-Hilfe von VisualAge für Java.
Der in früheren Versionen von VisualAge für Java enthaltene Servlet Builder erstellte Servlets, die direkt eine HTML-Benutzerschnittstelle generierten. Diese Fähigkeit ist für eine schnelle Anwendungsentwicklung nützlich, sie hat jedoch den Nachteil, dass sie die Geschäftslogik der Anwendung mit seiner Benutzerschnittstelle kombiniert. Wenn eine Änderung an der Benutzerschnittstelle gewünscht wird, muss das Servlet bearbeitet werden. Um die Verwaltung zu vereinfachen, empfiehlt es sich, die JavaServer Pages (TM) (JSP)-Technologie zu verwenden, um die Benutzerschnittstelle von der Geschäftslogik zu trennen.
Eine JSP-Seite ist eine HTML-Schablone mit dynamisch generiertem Inhalt. Eine JSP-Seite kann mit HTML-Editier-Tools wie dem PageDesigner in IBM WebSphere Studio bearbeitet werden. Im WebSphere-Programmierungsmodell von IBM werden Servlets immer noch zur Web-Interaktion verwendet, sie delegieren die Geschäftslogik jedoch an Java-Beans und die Benutzerschnittstelle an JSP. In diesem Programmierungsmodell werden Servlets und Beans mit Java-Tools entwickelt und JSP-Seiten mit Hilfe von HTML-Tools.
Diese Trennung von Geschäftslogik und Benutzerschnittstelle ermöglicht es, den Team-Mitgliedern gezielt entsprechend Ihren Fähigkeiten und vorhandenen Tools Zuständigkeiten bei der Entwicklung zuzuordnen, und sie vereinfacht die Verwaltung.
In Übereinstimmung mit dem WebSphere-Programmierungsmodell wurde die vom Servlet Builder gebotene Funktionalität in VisualAge für Java durch Java-Tools und in WebSphere Studio durch HTML-Tools ersetzt. VisualAge für Java, Version 4.0, stellt einen neuen SmartGuide (Assistent) bereit, den Sie zum Erstellen von Web-Anwendungen verwenden können, die dem WebSphere-Modell entsprechen. Mit dem SmartGuide Servlet erstellen können Sie ein Servlet erstellen, das eine Bean für die Geschäftslogik und eine JSP-Seite für die Benutzerschnittstelle aufruft. Der SmartGuide generiert ebenfalls ein HTML-Formular, mit dem Sie das Servlet testen können. Das Servlet kann sofort in der WebSphere-Testumgebung von VisualAge für Java gestestet werden und anschließend in der IDE weiter angepaßt werden. Die JSP- und HTML-Dateien können in WebSphere Studio oder einem HTML-Tool weiter angepaßt werden.
Der SmartGuide Servlet erstellen baut auf dem JavaBean-Assistent in WebSphere Studio auf. Er enthält daneben weitere Funktionen, die von Java-Programmierern benötigt werden. Wenn Sie für Ihre HTML-Entwicklung bereits WebSphere Studio verwenden, werden Sie feststellen, dass der SmartGuide den Arbeitsablauf zwischen WebSphere und VisualAge für Java vereinfacht. Bei der Entwicklung führen Sie folgende Schritte aus:
Die Swing-Klassen befinden sich in J2SDK v1.2.2 in einem anderen Paket, als in JDK v1.1.x. Zum Aktualisieren von Referenzen auf die Swing-Klassen können Sie den SmartGuide Fix installieren/Migrieren verwenden.
Um Ihre Anwendungen zu migrieren, müssen Sie die betreffenden Klassen und Pakete auswählen, den SmartGuide 'Fix installieren/Migrieren' öffnen (indem Sie mit der rechten Maustaste auf das Paket bzw. die Klasse klicken und anschließend die Optionen Neu organisieren -> Fix installieren/Migrieren auswählen) und das Markierungsfeld Umbenannte JDK1.2-Pakete aufnehmen auswählen, um Swing-Referenzen automatisch auf J2SDK v1.2.2 zu migrieren. Hierdurch werden die entsprechenden Von/Zu-Einträge für Swing hinzugefügt. Alle Fehler, die während der Migration auftreten, werden im Protokollfenster aufgeführt.
Weitere Informationen dazu, wie Sie Ihre Anwendungen korrekt migrieren, finden Sie in der Online-Hilfedatei "Richtlinien für Klassen- oder Paketreferenzen berichtigen/migrieren" des Visual Composition Editors und in der zugehörigen Aufgabendatei "Klassen- oder Paketreferenzen reparieren".
Sie werden mit dem Visual Composition Editor vermutlich nicht alle Swing-Eigenschaften von JDK 1.1.7 auf Java 2 migrieren können, da zwischen Version 1.03 und 1.1.1 von Swing serielle Änderungen vorgenommen wurden. Nachdem Sie Ihren Code auf VisualAge für Java, Version 4.0, migriert haben, werden Sie einige Swing-Anwendungsklassen wahrscheinlich nicht im VCE öffnen können. Dies gilt nur für die Fälle, in denen Sie über die Seite für Eigenschaften im VCE die Eigenschaften einer Java-Bean in ein Swing-Objekt geändert haben.
Führen Sie folgende Schritte aus, um dieses Problem zu umgehen:
- Öffnen Sie die Klassen erneut im VCE Ihrer früheren Version von VisualAge für Java.
- Klicken Sie auf der Seite der Eigenschaften der Klasse den Knopf Zurücksetzen an. Es wird ein Fenster eingeblendet, in dem alle Bean-Eigenschaften aufgeführt sind, die Sie geändert haben. Sie sollten allen Eigenschaften, die in Swing-Objekte geändert wurden, wieder ihre Standardeinstellung geben.
- Speichern Sie die Klasse und importieren Sie sie erneut in Version 4.0 IDE.
Informationen zum Migrieren von Beta-Version 1.2 des XMI Toolkit entnehmen Sie bitte den Release-Hinweisen für das XMI Toolkit
Wenn Sie ein anderes Release des XMI Toolkit als Version 3.5 verwendet haben (beispielsweise ein Technical Preview, ein alphaWorks-Release oder eine frühere Beta-Version), sollten Sie diese Version deinstallieren und die während der damaligen Installation erfolgten Umgebungs-Updates entfernen, bevor Sie dieses neue Release von XMI Toolkit verwenden. Es stehen lediglich für das Release 1.2 Migrationsanweisungen zur Verfügung.
Generierte ZIP-Dateien und XMI-Dateien aus dem Beta-Release 1.2 und dem Vor-Beta-Release 1.2 sind mit keinem der 3.5- oder 3.5.x-Releases des XMI Toolkit kompatibel.
In Version 4.0 von VisualAge für Java können Sie Ihre Projektressourcendateien versionieren und freigeben. Weitere Informationen zu dieser neuen Funktion finden Sie in der IDE- und Team-Online-Hilfe.
Wenn Sie Projekte von Version 2.0 oder 3.0x von VisualAge für Java auf Version 4.0 migriert haben,
können Sie nach Beenden des Migrationsprozesses die nachstehend beschriebenen Schritte ausführen,
um Ihre Projektressourcendateien zu versionieren und freizugeben. Sie müssen diese Schritte nicht
im direkten Anschluss an die Migration durchführen; Ihre Projektressourcen bleiben dann allerdings
so lange im Repository ohne Version.
Hinweis: Wenn Sie Ihre Projekte von Version 3.5 migriert haben, brauchen Sie diese Schritte nicht auszuführen.
Wenn Sie in einer Team-Umgebung mit der Enterprise Edition von VisualAge für Java arbeiten wollen, müssen Sie EMSRV, Version 7.1 verwenden.
OS/2 und AIX werden nicht als Entwicklungsplattformen für VisualAge für Java, Version 4.0, unterstützt. Sie können VisualAge für Java, Version 4.0, nur unter Windows NT, Windows 98 und Windows 2000 als Client installieren. Wenn Sie Version 4.0 mit Ihrem OS/2- bzw. AIX-Repository verwenden wollen, müssen Sie von der IDE der Version 4.0 aus eine Verbindung zu dem Repository herstellen. Weitere Informationen und Anweisungen hierzu finden Sie in der Online-Hilfe.
Wenn Sie plattformspezifischen Code geschrieben haben, müssen Sie ihn umschreiben, so dass er unter Windows funktioniert.
Zwei Szenarien
Hinweis: AIX und Windows können nicht auf derselben Maschine installiert werden, sodass die Schritte in Szenario 1 nur für OS/2 gelten.
Szenario 1
Wenn Ihr OS/2-Repository ivj.dat sich auf derselben Maschine, wie der Windows-Client befindet:
Szenario 2
Ihr OS/2- oder AIX-Repository ivj.dat befindet sich auf einer anderen Maschine, als der Windows-Client:
Aufgrund einer Änderung in den Sicherheitsrichtlinien für Applets, die auf der Java 2 Platform v1.2.2 ausgeführt werden, können Applets nicht mehr auf lokale Ressourcen zugreifen.
Aufgrund dieser Einschränkung sind einige Beispiele, die in früheren Versionen von VisualAge für Java enthalten waren, in VisualAge für Java, Version 4.0, nicht mehr vorhanden. Außerdem können einige der mitgelieferten Beispiele nur noch als Anwendungen ausgeführt werden, da sie andernfalls nicht korrekt funktionieren. Informationen zum korrekten Ausführen von Beispielen entnehmen Sie bitte der Online-Hilfe.
Sie können die Sicherheitsstandardrichtlinien ändern, indem Sie Ihre eigene java.policy-Datei erstellen und den AppletViewer mit den folgenden Parametern starten: -Djava.security.policy=someURL
wobei someURL die Position Ihrer neuen Richtliniendatei ist. Weitere Informationen zur allgemeinen Sicherheit in Java finden Sie unter http://java.sun.com/security. Spezielle Informationen zur Sicherheit in Java2 und zur Syntax der Richtliniendatei finden Sie unter http://java.sun.com/products/jdk/1.2/docs/guide/security.
Das Tool zur externen Versionssteuerung (External Version Control) ermöglicht es Ihnen, von VisualAge für Java aus eine Verbindung zu externen SCM (Source Code Management)-Providern wie ClearCase, PVCS Version Manager, TeamConnection und SourceSafe herzustellen. Mit diesem Tool können Sie Ihrem SCM-Provider Klassen hinzufügen, den Zugriff auf Klassen und Ressourcendateien im SCM-System freigeben oder einschränken (Check-in / Check-out) und die neueste freigegebene Version einer Klasse aus dem SCM-System importieren.
Dieses Tool ersetzt das alte externe SCM-Tool und bietet eine erweiterte Funktionalität.
Sie können in VisualAge für Java mit ORBs (Object Request Brokers) anderer Hersteller arbeiten, wenn diese mit J2SDK v1.2.2 kompatibel sind. Sie müssen die ORB-Klassen in die IDE importieren, bevor Sie mit ihnen arbeiten können.
Wenn Sie Java-Klassen in die IDE importieren, können Sie die ORB-Erweiterungsklassen den Java-Klassenbibliotheken hinzufügen. Sie können ebenfalls einige der vorhandenen ORB-Erweiterungsklassen in den Java-Klassenbibliotheken ersetzen, sofern sie nicht Teil der J2SDK v1.2.2-Kernklassen sind.
Einen Artikel mit ausführlicheren Informationen zum Arbeiten mit ORBs anderer Hersteller in Version 3.5.x finden Sie im Web unter:
http://www.ibm.com/software/vadd/Data/Document2175
Dieser Artikel enthält ausführliche Informationen über die Entwicklung von CORBA- (Common Object Request Broker Architecture) und ORB-Anwendungen in VisualAge für Java.
Bestimmte Klassen der Java-Klassenbibliothek werden unter Umständen ersetzt, wenn der ORB eines anderen Herstellers in VisualAge für Java importiert wird. Patch 2 für Version 3.5 korrigiert einen Programmfehler, der es Ihnen fälschlicherweise ermöglichte, bestimmte unveränderliche Klassen (solche, die in veränderlichen Paketen enthalten sind) in VisualAge für Java zu importieren. Nach der Anwendung von Patch 2 auf VisualAge für Java, Version 3.5 erhalten Sie möglicherweise neue oder zusätzliche Warnungen im Protokollfenster, wenn Sie den ORB eines anderen Herstellers importieren. Diese Warnungen werden deshalb angezeigt, weil Sie nach Anwendung von Patch 2 keine unveränderlichen Klassen in VisualAge für Java importieren können. Diese Warnungen können jedoch ignoriert werden.
Die CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java enthält Folgendes:
Das Installations- und Migrationshandbuch und die Produkt-README befinden sich beide auf der CD mit den zusätzlichen Funktionen (Additional Features) und der Hauptprodukt-CD.
Hinweis: Die CD für zusätzliche Funktionen (Additional Features) wird nur mit VisualAge für Java, Enterprise Edition, geliefert. Die folgenden Komponenten stehen jedoch auch für VisualAge für Java, Professional Edition, auf der Produkt-CD zur Verfügung:
Das Installations- und Migrationshandbuch und die Produkt-README befinden sich beide auf der Produkt-CD für VisualAge für Java, Professional Edition.
IBM J2EE Connectors und Tools für J2EE(TM) - Beta
Dieses Release von VisualAge für Java beinhaltet eine Beta-Version von mehreren Komponenten der Java 2 Platform, Enterprise Edition (J2EE), die von der Sun Microsystems Inc. offiziell nicht freigegeben wurden. Es handelt sich um folgende Komponenten:
Die Beta-Komponenten befinden sich im Unterverzeichnis extras\BetaJ2EEConnectors. Wenn Sie diese Beta-Komponenten installieren wollen, lesen Sie die README-Datei im Unterverzeichnis BetaJ2EEConnectors, das Installationsanweisungen für die Komponenten enthält.
Hinweis: Die mit VisualAge für Java, Version 4.0 gelieferten Komponenten werden nur von Windows NT und Windows 2000 unterstützt. Nicht alle J2EE-Runtime-Dateien werden unter Windows 2000 unterstützt. Weitere Informationen zu den J2EE-Komponenten finden Sie in der Onlinehilfe zu Enterprise Access Beans und in den Release-Hinweisen.
Team-Server (EMSRV)
Das TeamServer-Verzeichnis auf der der CD für zusätzliche Funktionen (Additional Features) enthält das EMSRV-Repository-Server-Programm und die Datei "Server-Einrichtung und -Verwaltung" (emsrv71.htm oder emsrv70.htm für alle Sprachen außer Englisch). Teil C enthält Anweisungen zum Installieren von EMSRV, und die Datei "Server setup and administration" (Server-Konfiguration und -Verwaltung) unter TeamServer\docs enthält Informationen zum Starten des Servers.
Distributable Run-Times
Wenn Sie ein mit VisualAge für Java erstelltes Applet bzw. Anwendung exportieren und implementieren, müssen Sie auch die Laufzeitbibliothek für die Funktionen implementieren (falls vorhanden), mit denen Sie den Code erstellt haben, und die implementierte Laufzeit-JAR-Datei oder -Zip-Datei in Ihren Klassenpfad stellen.
Im Allgemeinen werden die JAR-Dateien komprimiert und beim Ausführen von Applets von einem Server aus verwendet. Die Zip-Dateien sind nicht komprimiert und sollten in den Klassenpfad (CLASSPATH) der Implementierungsmaschine gestellt werden, um Anwendungen lokal auszuführen.
Die Laufzeitbibliotheken (Runtime Libraries) von VisualAge für Java sind in den Verzeichnissen 'extras/runtime30' und 'extras/runtime35' enthalten. In Abhängigkeit von den installierten Funktionen von VisualAge für Java werden einige oder alle Laufzeitbibliotheken auch im Verzeichnis 'eab/runtime35' oder 'runtime30' zur Verfügung gestellt. Hinweis: Die J2EE-Laufzeitbibliotheken sind auf der CD mit den zusätzlichen Funktionen (Additional Features) nicht enthalten. Die Laufzeitdateien für die J2EE-Konnektoren befinden sich in eab\runtime 35 und IBM Connectors\classes nachdem Sie die Beta-Komponenten installiert haben.
Die Onlinehilfe enthält weitere Informationen zum Installieren und zur Verwendung von Laufzeitbibliotheken.
IBM Developer Kit 1.2.2 (für Windows)
Das IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9 im Verzeichnis 'IBM Developer Kit' ist eine Java-Entwicklungsumgebung, die Sie bei der Entwicklung von Standalone-Java-Anwendungen und -Applets unterstützt, die der 100%igen Pure Java-Spezifikation entsprechen.
Es enthält Tools für die Entwicklung von Java-Anwendungen und -Applets wie beispielsweise:
Um das IBM Developer Kit zu installieren, führen Sie die Datei 'install.exe' im Verzeichnis 'IBM Developer Kit'. Weitere Informationen über das IBM Developer Kit enthält die README-Datei im Verzeichnis 'IBM Developer Kit'.
Merant DataDirect SequeLink Java Edition Version 5.1 für Oracle und Microsoft SQLServer
VisualAge für Java, Version 4.0 unterstützt den Treiber von Merant DataDirect SequeLink Java Edition Version 5.1 für Microsoft SQL Server und Oracle-Datenbankzugriff.
Hinweis: Der Merant DataDirect SequeLink Java Edition Version 5.1-Server, der mit VisualAge für Java, Version 4.0, geliefert wird, wird nur von Windows NT und Windows 2000 unterstützt.
SequeLink ist eine Middleware-Komponente für Datenzugriff, die Datenkonnektivität für die neuesten JDBC-Standards für eine Reihe von Datenbanken wie Oracle, Microsoft SQL-Server und auch Großrechnerdaten zur Verfügung stellt. Die SequeLink-Client-Komponente ist von Datenbanken unabhängig. Daher sind keine Änderungen erforderlich, wenn der Infrastruktur neue Datenbanken hinzugefügt werden. Ein SequeLink-Marken-Client wird mit der WebSphere-Testumgebung geliefert.
Hinweis: Da es sich bei dem SequeLink-Client um ein Markenprodukt handelt, können Sie nur mit dem Merant DataDirect SequeLink Java Edition Version 5.1-Server kommunizieren, während Sie den Client zusammen mit der WebSphere-Testumgebung oder dem WebSphere-Anwendungsserver verwenden. Der Merant DataDirect SequeLink Java Edition Version 5.1-Server ist kein vollständig lizenzierter Server. Sie können ihn ausschließlich für die Arbeit mit dem Sequelink-Marken-Server verwenden. Wenn Sie über einen vollständig lizenzierten Merant DataDirect SequeLink Java Edition Version 5.1-Server verfügen, können Sie diesen auch zusammen mit dem Sequelink-Marken-Client verwenden.
Der entsprechende SequeLink-Server ist als Installation ohne Schlüssel verfügbar, das heißt, Sie werden bei der Installation nicht zur Eingabe eines Registrierungsschlüssels aufgefordert. Der Server kann über das Unterverzeichnis 'Merant\SequeLinkServer' auf der CD für zusätzliche Funktionen (Additional Features) installiert werden.
Die Konfiguration und Installation der Treiber hängt von der Komponente ab, mit der Sie sie verwenden wollen. Die folgenden Release-Hinweise enthalten spezifische Informationen zur Installation und Konfiguration (einschließlich Informationen zur Konfiguration des SequeLink-Clients, der mit der WebSphere-Testumgebung geliefert wird).
Distributed Debugger
Wenn Sie Klassen debuggen wollen, die außerhalb der VisualAge für Java-IDE entwickelt wurden, oder Programme, die auf einer eigenen Maschine ausgeführt werden, sollten Sie den Distributed Debugger installieren.
Der Distributed Debugger wird auf den folgenden Betriebssystemen unterstützt: Windows, AIX, OS/2, HP-UX, Solaris, Linux und Linux/390. Alle Debugger-Dateien stehen im Verzeichnis 'Debugger' auf der CD für zusätzliche Funktionen (Additional Features). Die Installationsanweisungen sind in Teil B, Abschnitt 2.1.1.1. enthalten.
Technologische Vorabinformationen (Technology Previews)
Die CD für zusätzliche Funktionen (Additional Features) enthält zwei technologische Vorabinformationen (Technology Previews): IBM Stored Procedure Integration Tool for Enterprise JavaBeans und XMI Bridge.
IBM Stored Procedure Integration Tool for Enterprise JavaBeans
Sie können das IBM Stored Procedure Integration Tool for Enterprise JavaBeans (SP-Integrations-Tools für EJBs) verwenden, um Ihre Sitzungs-EJBs ohne Status zu erweitern, indem Sie Methoden für den Aufruf von gespeicherten Datenbankprozeduren hinzufügen. Mit dem SmartGuide "Gespeicherte Prozeduren für Aufrufmethoden erstellen" können Sie Ihre Methoden definieren und dann die neue Methode in Ihrer Sitzung-Bean ohne Status generieren.
Mit dem SP-Integrations-Tool für EJBs können Sie die Geschäftslogik nutzen, die in Ihren bestehenden gespeicherten Prozeduren innerhalb der EJB-Umgebung enthalten ist. Sie können den EJB-Entwicklungsaufwand minimieren und redundante Geschäftslogik auf Ihrem EJB-Server und in Ihrem Datenbankverwaltungssystem (DBMS) vermeiden. Da gespeicherte Prozeduren den Datenaustausch auf dem Netz zwischen dem EJB-Server und dem DBMS reduzieren können, haben Sie außerdem die Möglichkeit, die Leistung Ihrer Produktionsanwendungen zu verbessern.
Das SP-Integrations-Tool für EJBs steht im Unterverzeichnis 'extras\spt'. Die Datei 'EJB_SPTool.PDF' im Verzeichnis 'spt' enthält weitere Informationen zum Installieren und zur Verwendung der technologischen Vorabinformationen. Nachdem Sie das SP-Integrations-Tool für EJBs installiert haben, befindet sich die Datei EJB_SPTool.PDF ebenfalls im folgenden Verzeichnis: x:\ibmvjava\ide\tools\com-ibm-ivj-sptools. Hierbei ist x:\ibmvjava Ihr Produktinstallationsverzeichnis.
XMI Bridge
Die XMI-Brückenfunktion (XMI Bridge) ist eine technologische Vorabinformation für den Persistence Builder und die Enterprise Java Beans. Mit XMI Bridge können Sie eine Rational Rose-Modelldatei oder ein XMI-Dokument in ein Persistence Builder-Modell oder eine EJB-Gruppe importieren.
XMI Bridge steht im Verzeichnis 'extras\xmib'. Bevor Sie mit XMI Bridge arbeiten können, müssen Sie das XMI Toolkit dem Arbeitsbereich hinzufügen. Die README-Datei im Verzeichnis 'xmib' enthält weitere Informationen zum Installieren und zur Verwendung der technologischen Vorabinformationen.
Druckbare Dokumentation
Ein Teil der Online-Hilfe liegt in PDF-Dokumenten vor, die Sie mit Hilfe von Adobe Acrobat Reader anzeigen und drucken können (Adobe Acrobat Reader kann unter folgender Adresse kostenlos heruntergeladen werden: http://www.adobe.com/). Nicht für jede Sprache steht auch eine landessprachliche PDF-Version zur Verfügung. Die PDF-Dateien stehen im Verzeichnis 'pdf' zur Verfügung.
Der PDF-Index (im Handbuch "Erste Schritte") enthält Informationen über den Inhalt der einzelnen PDF-Dateien.
Handbuch zur Fehlerbehebung im Hilfesystem
Das Handbuch zur Fehlerbehebung im Hilfesystem enthält Informationen zur Behebung von Hilfefehlern. Das Handbuch befindet sich im Verzeichnis 'Troubleshoot' auf der CD für zusätzliche Funktionen (Additional Features) und steht in allen Sprachen zur Verfügung.
Repository und Ressourcen
Das Verzeichnis 'ivj40' enthält zwei .zip-Dateien: 'ide.zip' und 'wte_resources.zip'. Die Datei 'ide.zip' enthält eine Kopie des Repositorys (ivj.dat), das Projektressourcenverzeichnis (ivj.dat.pr) und die Arbeitsbereichsdatei (ide.icx). Die Datei 'wte_resources.zip' enthält eine Sicherungskopie der Projektressourcen für die WTE-Funktion.
Nachstehend finden Sie einen Vergleich zwischen dem Data Access Builder, Data Access Beans und dem Persistence Builder. Es wird ebenfalls eine kurze Beschreibung der EJB-Entwicklungsumgebung gegeben, diese Komponente wird jedoch nicht in den Vergleich einbezogen.
Das Feature Data Access Beans bietet schnellen visuellen Zugriff auf relationale Daten. Es ist für die Verwendung mit Anwendungen gedacht, für die kein wiederverwendbares Objektmodell erforderlich ist. Mit Hilfe der Data Access Beans können Sie visuelle Anwendungen erstellen, die eine direkte Sicht auf die Zieldatenbank benötigen. Sie können die Datenzugriffs-Beans auch manuell in Ihren Code einbinden.
In der EJB-Entwicklungsumgebung
können Sie Beans entwickeln, die die Programmierungsspezifikationen der Enterprise JavaBeans (EJB)
von von Sun Microsystems implementieren. Die EJB-Entwicklungsumgebung stellt die komplette erforderliche
Laufzeitumgebung für den IBM WebSphere Application Server zur
Verfügung. Eine schrittweise Konsistenzprüfung gewährleistet, dass
Enterprise-Beans der EJB-Programmierungsspezifikation entsprechen. Falls zur Behebung von Inkonsistenzen
Korrekturen notwendig sind, wird dies angezeigt. Weitere Informationen zur EJB-Entwicklungsumgebung
finden Sie in der Online-Hilfe.
Der Persistence Builder bietet skalierbare Permanenzunterstützung für
Objekt-Modelle und stellt für viele Kunden den Einstieg in EJB dar. Mit dem Persistence Builder erstellte Anwendungen konzentrieren sich auf das optimale,
wiederverwendbare Objekt-Modell und ordnen es auf schnelle Weise beliebigen unterstützten
relationalen Datenbanken zu. Persistence Builder unterstützt Zuordnungen sowohl des Typs
'Bottom-up' (Schema-zu-Objekt), als auch des Typs Top-down (Objekt-zu Schema).
Dieses Feature ordnet Objekte und Beziehungen zwischen Objekten Daten in relationalen
Datenbanken zu.
In diesem Anhang dieses Dokuments werden die Unterschiede zwischen den drei Datenzugriffskomponenten Data Access Beans, Data Access Builder und Persistence Builder beschrieben.
Die Einzelheiten der jeweiligen Implementierung werden hier nicht behandelt. In der Online-Dokumentation wird die von Persistence Builder und Data Access Beans gebotene zusätzliche Funktionalität beschrieben, wie Abhängigkeiten, Elemente der visuellen Palette, erweiterte Transaktionsfähigkeiten sowie der SmartGuide SQL-Assistent.
Die nachfolgende Liste der Kernfunktionen bietet einen Überblick über das wesentliche Leistungsspektrum des Data Access Builders. Jede Kernfunktion wurde von jeder der drei Komponenten auf verschiedene Weise implementiert.
Teil 1: Features für die Zuordnung Objekt-zu-Relational
Zuordnung Datenbankschema-zu-Objekt
Code-Generierung
Teil 2: Laufzeit-Features
Part 3: Data Access Beans-Funktionen
Im Folgenden werden die Implementierungen der Funktionen erläutert. Die Funktionen von Data Access Builder und Persistence Builder werden nacheinander verglichen, die entsprechenden Funktionen der Data Access Beans (für Zuordnungen) werden am Ende dieses Abschnitts aufgelistet.
Zuordnung Datenbankschema-zu-Objekt
1.0 Zuordnung Datenbankschema-zu-Objekt unter Verwendung von Tabellen und Sichten
Im Data Access Builder
Hinweis: Alle den Data Access Builder betreffenden Schritte müssen in einer früheren Version (3.02 oder früher) von VisualAge für Java ausgeführt werden, die den Data Access Builder enthält.
Wählen Sie im SmartGuide Schemazuordnung die DB2- oder ODBC-Verbindung aus und wählen Sie anschließend den Radioknopf Datenbanktabellen oder -sichten auswählen aus. Klicken Sie Weiter an. Es wird die nächste Seite aufgerufen, die eine Liste mit Tabellen enthält:
Wählen Sie die Tabellen aus, mit denen Sie arbeiten wollen, und klicken Sie Fertigstellen an. Zwischen diesen Tabellen und den resultierenden Objekten werden 1-zu-1-Objektzuordnungen erstellt. Im Fenster des Data Access Builders wird die automatisch erstellte Spalte-zu-Attribut-Zuordnung angezeigt.
Im Persistence Builder
Wählen Sie im Schema-Browser Schemas > Schema aus Datenbank importieren aus. Geben Sie die Verbindungsinformationen ein. Daraufhin wird der Dialog Tabellen auswählen angezeigt.
Wählen Sie die gewünschten Tabellen oder Sichten aus und klicken Sie OK an. Der Schema-Browser enthält nun das neue Schema und listet dessen Tabellen, Spalten und Schlüssel auf.
Wählen Sie Schemas > Modell aus Schema generieren aus. Hierdurch wird ein einfaches 1-zu-1-Geschäftsmodell erstellt.
2.0 Zuordnung Datenbankschema-zu-Objekt unter Verwendung von angepaßten Abfragen
Im Data Access Builder
Wählen Sie im SmartGuide Schemazuordnung die DB2- oder ODBC-Verbindung aus und wählen Sie anschließend den Radioknopf SQL-Anweisung eingeben aus. Klicken Sie Weiter an. Wählen Sie die Tabellen aus, mit denen Sie arbeiten wollen, und klicken Sie Weiter an. Die folgende Seite wird geöffnet:Geben Sie Ihre Abfrage ein und klicken Sie Fertigstellen an. Das obenstehende Beispiel zeigt eine Verknüpfungsabfrage für zwei Tabellen. Abfragen mit Parameterwerten werden ebenfalls unterstützt.
Das resultierende Objekt enthält die Attribute aus beiden Tabellen, so wie nachstehend gezeigt:
Im Persistence Builder
Mit dem Persistence Builder können Sie Zuordnung der Verknüpfungsabfrage durch manuelles Zuordnen des Schemas vornehmen.3.0 Zuordnung Datenbankschema-zu-Objekt unter Verwendung von gespeicherten Prozeduren
Im Data Access Builder
Wählen Sie im SmartGuide Schemazuordnung die DB2- oder ODBC-Verbindung aus und wählen Sie anschließend den Radioknopf Ergebnismenge für gespeicherte Prozedur aus. Die Seite Gespeicherte Prozedur wird geöffnet, die eine Liste mit gespeicherten Prozeduren enthält. Geben Sie einen Namen für die Zuordnung ein, wählen Sie die gespeicherte Prozedur aus und klicken Sie auf Fertigstellen.
Das resultierende Objekt enthält Attribute, die den Ergebnisspalten der gespeicherten Prozeduren zugeordnet werden. Für diesen Typ der Zuordnung sind die Abfragen oder gespeicherten Prozeduren für die CRUD-Operationen nicht vordefiniert.
Im Persistence Builder
Der Persistence Builder enthält keine Tools, die Unterstützung für die Zuordnung gespeicherter Prozeduren bieten. Sie können ein "Stub-Schema" generieren, das Skeleton-Service-Klassen erstellt, wobei Sie den Unterstützungscode selbst bereitstellen müssen. Die Methode allInstances kann etwa folgendermaßen aussehen:
/**
* Return a query spec for the query called
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;
}
Code-Generierung
4.0 CRUD-Operationen gegen Objekte
Data Access Builder
Die CRUD-Basisoperationen (Create, Retrieve, Update und Delete) werden bei einer 1 Tabelle-zu-1 Objekt-Zuordnung automatisch generiert. Wenn Sie angepaßte Abfragen oder gespeicherte Prozeduren verwenden, fehlen diese Abfragen und Sie müssen sie manuell mit dem Data Access Builder definieren. Ein Beispiel hierfür wäre eine Verknüpfungsabfrage, die ein Objekt 'Customer' definiert.
Geben Sie die folgende SQL-Anweisung ein:
INSERT
INTO TPF.CUSTOMER (
CUSNO,
FIRSTNAME,
MIDINIT,
LASTNAME,
HOMEPHONE,
HOMEADDR,
WORKPHONE,
BILLADDR,
BRANCHNO,
OPEN DATE)
VALUES (?, ?, ?, ?, ?, ?, ?,?, ? ,?)
Nachdem der Data Access Builder die Abfrage ausgewertet hat, müssen Sie die Parameter mit Hilfe der Seite Parameter einzeln zuordnen.
Zum Einfügen der zweiten Verknüpfungstabelle CUSTDATA müssen Sie ebenfalls die Abfrage addCustomer2 definieren. Die Synchronisation der beiden Abfragen für diese Funktion muss vom Benutzer vorgenommen werden.
Persistence Builder
Der Persistence Builder generiert alle CRUD-Operationen sobald zwischen dem definierten Schema und Modell eine Zuordnung erstellt wurde. In Fall der Verknüpfung mehrerer Tabellen wird jede Tabellenabfrage generiert und die Service-Engine verwaltet diese Operationen als eigenständige Einheiten.
In den Tools wird noch keine Unterstützung für gespeicherte Prozeduren geboten, es können jedoch "Stub-Schemas" generiert und erweitert werden. Nachstehend ist ein Beispiel für eine gespeicherte Abfrageprozedur für 'insert' aufgeführt:
/**
*Return a query spec for the query called 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 Unterstützung für angepaßte Abfragen
Im Data Access Builder
Im Data Access Builder werden angepaßte Abfragen auf die gleiche Weise definiert wie CRUD-Abfragen. Der Benutzer fügt die benannte Abfrage hinzu und verwendet nach Bedarf dabei die Seite Parameter. Die resultierende Abfrage wird als Methode in der Klasse BusinessObjectMgr angezeigt.
Der Data Access Builder stellt ebenfalls weitere Möglichkeiten zum Definieren von Abfragen bereit, wie SQL-Prädikat-Ersetzung.
TheEmpMgr.select('WHERE WORKDEPT = 'E11');
Im Persistence Builder
Im Persistence Builder gibt es zwei Möglichkeiten, um angepaßte Abfragen hinzuzufügen. Lite-Collections können auf Klassenebene mit dem Klasseneditor definiert werden. Die folgende Seite wird für Such- und Filteroperationen gegen die angegebene Klasse verwendet.
Lite-Collection-Abfragen werden allgemein in Suchlisten oder Dialogen verwendet, um zum entsprechenden Business-Objekt 'vorzudringen'. Die Ergebnismethoden geben Vektoren von "Datenobjekten" zurück, die zum Abfragen der zugehörigen permanenten Business-Objekte verwendet werden können.
Nachstehend ist ein Beispiel aufgeführt, in dem die oben gezeigte generierte Lite-Collection verwendet wird:
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
}
Der Persistence Builder stellt ebenfalls ein Gerüst für angepaßte Abfragen bereit, mit dem verschiedene Operationen gegen eine Business-Klasse definiert werden können. Diese Abfragen geben voll funktionsfähige Business-Objekte zurück.
Nachstehend ist ein Beispiel über eine Klasse 'student' mit einer angepaßten Abfrage "retrieveStudentsOver21" aufgeführt. Die Home-Klasse für 'students' hat die folgende Methode:
public Vector retrieveStudentsOver21() throws
java.rmi.RemoteException,
com.ibm.vap.common.VapReadFailureException {
return customQuery("studentsOver21Query");
}
Der Abfrage-Pool für Studenten enthält die zugehörigen Methoden für den angepaßten Service:
/* Return a query spec for the query called studentsOver21
@return
java.util.Vector */
public java.util.Vector studentsOver21Query() {
Vector aSpecArray = new Vector();
aSpecArray.addElement(new DatabaseSelectQuerySpec(studentsOver21SqlString()));
return aSpecArray;
}
/* Return the SQL string for the query called 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.)";
}
Diese Methode wird von der Home-Klasse ausgeführt und hat das gleiche Caching-Verhalten wie die Methode allInstances. Weitere Informationen zu dieser Methode sind in der Online-Hilfe für den Persistence Builder enthalten.
Unterstützung für Datensammlungen (DataStore) und Transaktionen
Im Data Access Builder
Datensammlungen können im Data Access Builder auf verschiedenen Anwendungsebenen konfiguriert werden:
Die Datensammlungen des Data Access Builders folgen einem unstrukturiertes Transaktionsmodell, d. h., wenn mehrere Transaktionen zur Anwendung einer Business-Funktion nötig sind, müsste stellvertretend für jede Transaktion eine Datensammlung aktiviert werden.
Nachstehend folgt ein einfaches Beispiel eines Employee- und Department-Modells (d. i. Mitarbeiter/Abteilung):
EmployeeDatastore anEmpDS = new EmployeeDatastore().connect();
DepartmentDatastore aDeptDS = new DepartmentDatastore().connect();
Employee anEmp = new Employee();
Department aDept = new Department();
// Perform actions on anEmp and aDept
if (User Applied Employee Changes)
anEmpDS.commit()
else
anEmpDS.rollback();
aDeptDS.commit();
Persistence Builder
In VisualAge für Java, Version 4.0, kann der Persistence Builder den WebSphere-Verbindungs-Pool nutzen, indem er den JNDI-Namen für die Suche in der Datenquelle verwendet. Diese Option ist verfügbar, wenn die Service-Klassen generiert werden.
Im Persistence Builder sind nur dann mehrere Datensammlungen erforderlich, wenn für den Zugriff auf Modelldaten verschiedene Datenbanken verwendet werden. Pro Datensammlung werden mehrere verschachtelte Transaktionen unterstützt. Transaktionen sind bislang noch nicht in der Art und Weise implementiert, wie im Data Access Builder. Benutzertransaktionen werden von Transaktionsobjekten gesteuert, die Einblick in die Business-Objekte der Anwendung haben.
Nachstehend finden Sie einen Codeausschnitt, der im Data Access Builder die gleiche Transaktionsfunktionalität bietet.
DB2Datastore aDS = DB2Datastore.singleton().activate();
Transaction empTransaction = Transaction.begin();
Employee anEmp = EmployeeHomeImpl.create("EmpNum1");
Transaction deptTransaction = Transaction.begin();
Department aDept = DepartmentHomeImpl.create("DeptNum1");// Do some actions on anEmp and aDept, always resuming the appropriate transaction before making changes to the corresponding BO.
if (User Applied Employee Changes)
empTransaction.commit();
else
empTransaction.rollback();
deptTransaction.commit();
Es ist wichtig zu beachten, dass bis zur Festschreibung einer Transaktion im Persistence Builder kein SQL ausgeführt wird. Der Transaktionsstatus von Objekten wird intern beibehalten, bis eine ausdrückliche ROLLBACK- oder COMMIT-Operation ausgeführt wird.
2.0 API-Unterstützung
Die für die resultierenden Business-Objekte und ihre begleitenden Verwaltungs-Objekte generierten Methoden sind in den drei Datenzugriffsgerüsten jeweils leicht unterschiedlich. Die folgende Tabelle zeigt die Klassen und Methoden, die für jede Funktion verwendet werden.
|
Data Access Builder |
Persistence Builder |
Data Access Beans |
Create |
aBusinessObject.add(); |
aBusinessObjectHome.create(); |
aSelectBean.newRow(); |
Retrieve |
aBusinessObject.retrieve(); |
aBusinessObjectHome.find (aKey); |
aSelectBean.setParameter ("Spaltenname", Wert); aSelectBean.execute(); |
Retrieve all | aBusinessObjectMgr.select(); | aBusinessObjectHome.allInstances(); | aSelectBean.execute(); |
Update | aBusinessObject.update(); | (*) | Not supported |
Delete | aBusinessObject.delete(); | aBusinessObject.remove(); | Not supported |
Delete current | aBusinessObject.deleteCurrent(); | Not supported (**) | aSelectBean.deleteRow(); |
Update current | aBusinessObject.updateCurrent(); | Not supported (**) | aSelectBean.updateRow(); |
Commit | aBusinessObjectDS.commit(); | currentTransaction.commit(); | aSelectBean.commit(); |
Rollback | aBusinessObjectDS.rollback(); | currentTransaction.rollback(); | aSelectBean.rollback(); |
Activate | aBusinessObjectDS.connect(); | aDataStore.activate(); | aSelectBean.connect(); |
Reset | ABusinessObjectDS.disconnect(); | aDataStore.reset(); | aSelectBean.disconnect(); |
Code-Beispiel: Einen Mitarbeiter suchen und dessen Telefonnummer ändern |
|||
Employee anEmp = |
EmployeeHome aHome = EmployeeHome.singleton(); Employee anEmp = anEmp.setPhoneno("555-9988"); |
Retrieve all employees: aSelectBean.execute();
positionToEmployee
aSelectBean. aSelectBean.updateRow();
aSelectBean.commit();
Retrieve result set with
aSelectBean.setParameter
aSelectBean.commit(); |
(*)Aktualisierungsoperationen werden durch Änderung der Werte eines Business-Objekts implementiert, wenn die aktive Transaktion festgeschrieben wird. Die Änderungen werden mit der Datensammlung synchronisiert, indem die entsprechenden Update-Anweisungen abgesetzt werden.
(**)Der Abschnitt zur Cursor-Unterstützung enthält Alternativlösungen.
LOB-Unterstützung
Data Access Builder |
Persistence Builder |
Data Access Beans |
Der Data Access Builder enthält eine Klasse namens DAIOStream, die zum Abrufen von LOBs. aus der Datenbank verwendet werden kann, ohne dass das gesamte Objekt in den Speicher gestellt wird. |
Der Persistence Builder bietet derzeit keine Unterstützung für das Streaming von LOBs. LOB-Objekte werden in den Speicher gestellt. |
DAB unterstützt JDBC 2.0 LOB-Datentypen. Wenn Sie einen JDBC 2.0-Treiber zum Abrufen eines LOBs verwenden, können Sie wählen, ob Sie das gesamte LOB oder nur die LOB-Position in den Speicher abrufen wollen. |
3.0 Schnellformulare (RAD-Features)
Data Access Builder |
Persistence Builder |
Data Access Beans |
Das Schnellformular-Feature des Data Access Builders bietet eine schnelle Möglichkeit, um Beispiele anzuzeigen; es verwendet dabei zur Darstellung des bereitgestellten Modells bekannte AWT-Komponenten. |
Eine Sammlung visueller Komponenten im VCE soll helfen, die Komplexität der visuellen Programmierung zu vereinfachen. Diese Komponenten stellen Transaktionsklassen dar, die es dem Benutzer erleichtern, Arbeitseinheiten visuell voneinander zu trennen. |
Version 4.0 enthält einen Datenbankanwendungs-Assistenten, der eine Anwendung generiert, die zur Darstellung der Spalten einer Tabelle, die mit einer Select-Bean abgerufen wurde, Swing-Komponenten verwendet. Um auf schnelle Weise eine angepaßte UI auf der Basis der Eigenschaften einer Select-Bean zu erstellen, können Sie auch die Standardfunktionen der Schnellformulare im VCE verwenden. |
4.0 4.0 Unterstützung für aktuelle(s) Datum/Zeit/Zeitmarke
Mit den Tools des Data Access Builders kann ein Benutzer für die Datum- und Zeittypen "current" (aktuell) angeben, wodurch die entsprechende SQL generiert wird. Der Persistence Builder und die Data Access Beans ünterstützen dies nicht in ihren Tools, die entsprechende SQL kann jedoch manuell hinzugefügt werden.
5.0 Cursor-Unterstützung
Data Access Builder untersützt Cursorfunktionen in Ergebnismengen, wie updateCurrent() oder deleteCurrent().
Der Persistence Builder unterstützt solche Operationen derzeit nicht. Sie können in diesem Fall jedoch als gute Alternative die Data Access Beans verwenden.
Data Access Beans unterstützen Cursorfunktionen, wobei die visuelle Komponente des DBNavigator die Cursorposition verwaltet. Es können folgende Cursor-Features genutzt werden:
JDBC v1.0 bietet keine Unterstützung für rückwärts Blättern in JDBC-Ergebnismengen. Die Select-Bean behält eine Cache-Version der Ergebnismenge bei, die es Ihnen ermöglicht, in der Ergebnismenge zu blättern und direkt auf eine bestimmte Zeile zuzugreifen. Die Größe des Cache kann über die Eigenschaften der Select-Bean eingestellt werden. Sie können die gesamte Ergebnismenge in den Cache stellen (dies ist die Standardeinstellung), oder nacheinander einzelne Pakete in den Cache stellen. Die Größe und Anzahl der Pakete können vom Benutzer bestimmt werden.
Sobald eine Ergebnismenge abgerufen wurde, stellt die Select-Bean Methoden bereit, mit denen Zeilen in der Ergebnismenge aktualisiert, gelöscht oder eingefügt werden können. Der Benutzer muss keine neue SQL schreiben, um diese Aktionen ausführen zu können.
6.0 Asynchrone Ausführung
Der Data Access Builder unterstützt asynchrone Operationen, indem er für seine generierten Klassen ausführbare Schnittstellen bereitstellt.
Der Persistence Builder stellt ebenfalls für jede CRUD-Operation und für angepaßte Abfragen eine ausführbare Schnittstelle bereit. Das Service-Objekt für jede Business-Klasse enthält die Methode runAsynch(), die den Ausführungstyp für diese Klasse bestimmt.
Die Data Access Beans unterstützen asynchrone Ausführung über das DBNavigator-Tool, das ausführbare "DBAction"-Exemplare erzeugt.
Hinweise zu gemeinsamem Zugriff (Sperr-/Isolationsstufen)
Der Data Access Builder enthält eine API, mit der die Isolationsstufe der Datenbank für die generierte Datensammlungs-Klasse setTransactionIsolation(int) festgelegt werden kann.
Der Persistence Builder verwaltet seine eigenen Transaktionen und bietet interne Unterstützung für die folgenden Isolationsstufen.
Die Transaktion gibt entweder die Isolationsstufe Repeatable Read oder Unrepeatable Read an. Die Service-Implementierung für die Business-Klasse gibt entweder sperrende oder nicht sperrende Implementierung an. Weitere Informationen zu den Unterschieden zwischen den Stufen sind in der Online-Hilfe für den Persistence Builder enthalten.
Die Data Access Beans verfügen über eine API, mit der die Isolationsstufe der Datenbank festgelegt werden kann. Sie können dies tun, indem Sie die gewünschte Isolationsstufe beim Bereitstellen der Verbindungsinformationen über den Eigenschaftseditor oder mittels der Methode DatabaseConnection.setTransactionIsolation() angeben.
Die Zuordnung für Data Access Beans (DAB) wird zwischen Tabellen und Select-Beans vorgenommen. Diese Zuordnung zwischen einer Tabelle und einer Select-Bean ist keine 1:1-Zuordnung, so dass die Select-Bean die Tabelle nicht repräsentiert. Select-Beans können jedoch sehr nützlich für das Arbeiten mit der aktuellen Zeile und einer Ergebnismenge sein. Sie können eine oder zwei Select-Beans erstellen, mit denen Sie Basisoperationen zur Datenbankprogrammierung in einer Tabelle durchführen können. Wenn Sie also DAX für Datenbankoperationen wie Abfragen, Lesen, Schreiben, Aktualisieren und Löschen verwenden, bieten die Data Access Beans eine ebenso einfache und direkte Alternative.
Sie können mit Datenbanken interagieren, indem Sie die Eigenschaft query (die aus Verbindungsinformationen und SQL-Abfrageinformationen besteht) einer Select-Bean definieren. Die in der Eigenschaft query enthaltenen Verbindungsinformationen können von mehr als einer Select-Bean verwendet werden. Sie können Select-Beans entweder manuell oder visuell mit dem Visual Composition Editor in Ihren Code integrieren.
Nachstehend wird eine allgemeine Anleitung zum Erstellen einer Select-Bean gegeben, die mit der aktuellen Zeile einer Kundentabelle arbeiten soll. Ausführlichere Informationen zum Ausführen dieser Schritte finden Sie in der Online-Hilfe:
Mit dieser Select-Bean können Sie Datenbankbasisoperationen (lesen, schreiben, aktualisieren und löschen) für eine Zeile in der Kundentabelle ausführen (wenn die Kundennummer angegeben wurde).
Erstellen einer zweiten Select-Bean
Sie können eine zweite Select-Bean erstellen, um mit einer Ergebnismenge zu arbeiten (d. h. um eine Datenbankabfrage auszuführen). Führen Sie dazu dieselbe Prozedur erneut durch, geben Sie allerdings nun keine Bedingungen an. Diese zweite Select-Bean gibt Ihnen die Möglichkeit, die Funktionalität von DAB für Ergebnismengen zu nutzen. Die Datenbankzugriffsklasse für diese Select-Bean würde in etwa folgendermaßen aussehen:
Select-Beans und angepaßte Abfragen
DAB bietet umfassende Unterstützung für die Erstellung von Select-Beans, die angepaßte Abfragen verwenden. Wie nachstehend gezeigt, können Sie mit dem SmartGuide SQL-Assistent eine Verknüpfungsabfrage erstellen und dabei Bedingungen für eine Abfrage angeben, Spalten auswählen bzw. sortieren und Felder zuordnen.
Data Access Beans und Gespeicherte Prozeduren
Die Prozeduraufruf-Bean ermöglicht es Ihnen, mit gespeicherten Prozeduren zu arbeiten. Prozeduraufruf-Beans werden auf ähnliche Weise wie Select-Beans erstellt. Der SmartGuide für gespeicherte Prozeduren listet die verfügbaren gespeicherte Prozeduren auf, so wie nachstehend gezeigt.
Weitere Informationen zur Verwendung der Prozeduraufruf-Bean finden Sie in der Online-Hilfe für Data Access Beans.
Copyright und Hinweise
© Copyright IBM Corp. 1997, 2001. All Rights Reserved.
(C) Copyright Deutschland GmbH 1997, 2001. Alle Rechte vorbehalten.
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden. Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Dienstleistungen von IBM verwendet werden können. Anstelle der IBM Produkte, Programme oder Dienstleistungen können auch andere ihnen äquivalente Produkte, Programme oder Dienstleistungen verwendet werden, solange diese keine gewerblichen Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb von Fremdprodukten, Fremdprogrammen und Fremdservices liegt beim Kunden.
Der folgende Abschnitt gilt nicht für Großbritannien und andere Länder, in denen solche Bereitstellungen nicht den gültigen Gesetzen entsprechen:
INTERNATIONAL BUSINESS MACHINES CORPORATION STELLT DIESE VERÖFFENTLICHUNG "UNTER ABBEDINGEN DER HAFTUNG FÜR EINEN BESTIMMTEN ZWECK" ZUR VERFÜGUNG, OHNE GEWÄHRLEISTUNGEN JEGLICHER ART, WEDER AUSDRÜCKLICHEN NOCH IMPLIZIERTEN, EINSCHLIESSLICH DER, ABER NICHT BESCHRÄNKT AUF DIE IMPLIZIERTEN GEWÄHRLEISTUNGEN UND BEDINGUNGEN DER NICHT-VERLETZUNG GEWERBLICHER SCHUTZRECHTE, DER MARKTGÄNGIGEN QUALITÄT UND DER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK. In einigen Ländern sind Ablehnungserklärungen bezüglich ausdrücklicher oder implizierter Gewährleistungen nicht zulässig, daher trifft diese Erklärung möglicherweise nicht für Sie zu. Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen bzw. neuen Editionen der Veröffentlichung bekanntgegeben. IBM kann jederzeit ohne vorherige Ankündigung Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.
Verweise in dieser Veröffentlichung auf Web-Sites anderer Anbieter dienen lediglich als Benutzerinformationen und stellen keinerlei Billigung des Inhalts dieser Web-Sites dar.
Das über diese Web-Sites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Web-Sites geschieht auf eigene Verantwortung. Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht. Die Lieferung des im Dokument aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt im Rahmen der Allgemeinen Geschäftsbedingungen der IBM, der Internationalen Nutzungsbedingungen der IBM für Programme oder einer äquivalenten Vereinbarung.
IBM, AIX, AS/400, DB2, OS/390, OS/400, RS/6000, S/390, VisualAge und WebSphere sind Marken der IBM Corporation in den USA und/oder anderen Ländern.
Lotus, Lotus Notes und Domino sind Marken der Lotus Development Corporation in den USA und/oder anderen Ländern. Java und alle Java-basierten Marken und Logos sind Marken der Sun Microsystems, Inc. in den USA und/oder anderen Ländern. Microsoft, Windows und Windows NT sind Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Intel und Pentium sind Marken der Intel Corporation in den USA und/oder anderen Ländern. Andere Unternehmens-, Produkt- und Dienstleistungsnamen können Marken oder Dienstleistungsmarken anderer Unternehmen sein.