Installations- und Migrationshandbuch

IBM VisualAge für Java
Version 4.0
IBM
Installations- und Migrationshandbuch
Hinweis
Vor Verwendung dieser Informationen und des darin beschriebenen Produkts sollten die allgemeinen
Informationen unter ’Bemerkungen’ gelesen werden.
v Die IBM Homepage finden Sie im Internet unter: ibm.com
v IBM und das IBM Logo sind eingetragene Marken der International Business Machines Corporation.
v Das e-business Symbol ist eine Marke der International Business Machines Corporation
v Infoprint ist eine eingetragene Marke der IBM.
v ActionMedia, LANDesk, MMX, Pentium und ProShare sind Marken der Intel Corporation
in den USA und/oder anderen Ländern.
v C-bus ist eine Marke der Corollary, Inc. in den USA und/oder anderen Ländern.
v Java und alle Java-basierenden Marken und Logos sind Marken der Sun Microsystems, Inc.
in den USA und/oder anderen Ländern.
v Microsoft Windows, Windows NT und das Windows-Logo sind Marken der Microsoft Corporation
in den USA und/oder anderen Ländern.
v PC Direct ist eine Marke der Ziff Communications Company in den USA und/oder anderen Ländern.
v SET und das SET-Logo sind Marken der SET Secure Electronic Transaction LLC.
v UNIX ist eine eingetragene Marke der Open Group in den USA und/oder anderen Ländern.
v Marken anderer Unternehmen/Hersteller werden anerkannt.
Änderungen in der IBM Terminologie
Die ständige Weiterentwicklung der deutschen Sprache nimmt auch Einfluß auf die IBM Terminologie. Durch
die daraus resultierende Umstellung der IBM Terminologie, kann es u. U. vorkommen, dass in diesem
Handbuch sowohl alte als auch neue Termini gleichbedeutend verwendet werden. Dies ist der Fall, wenn auf
ältere existierende Handbuchausschnitte und/oder Programmteile zurückgegriffen wird.
Erste Ausgabe (Juni 2001)
Diese Ausgabe bezieht sich auf Version 4.0 von IBM(R) VisualAge für Java.
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
Installation and Migration Guide,
herausgegeben von International Business Machines Corporation, USA.
© Copyright International Business Machines Corporation 2001
© Copyright IBM Deutschland Informationssysteme GmbH 2001
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz
nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
Herausgegeben von:
SW TSC Germany
Kst. 2877
Juni 2001
Inhaltsverzeichnis
Installations- und Migrationshandbuch . 1
Inhaltsverzeichnis. . . . . . . . . . . . . 2
Teil A: VisualAge für Java, Professional Edition . . . 4
A.1.0 Voraussetzungen . . . . . . . . . . 4
A.2.0 Installation . . . . . . . . . . . . 5
A.3.0 Migration von einer früheren Version von
VisualAge für Java . . . . . . . . . . . 12
A.4.0 Bekannte Probleme und Einschränkungen
15
Teil B: VisualAge für Java, Enterprise Edition . . . 25
B.1.0 Voraussetzungen . . . . . . . . . . 25
B.2.0 Installation . . . . . . . . . . . . 27
B.3.0 Migration von einer früheren Version von
VisualAge für Java . . . . . . . . . . . 37
B.4.0 Bekannte Probleme und Einschränkungen
41
Teil C: EMSRV . . . . . . . . . . . . . 51
C.1.0 Voraussetzungen. . . . . . . . . . 51
C.2.0 Installation. . . . . . . . . . . . 54
C.3.0 Migration . . . . . . . . . . . . 68
C.4.0 Vorbereitungen für die Entwicklung im
Team . . . . . . . . . . . . . . . 68
C.5.0 Einschränkungen und bekannte Probleme
(EMSRV) . . . . . . . . . . . . . . 70
Teil D. Komponentenspezifische Migrationsinformationen . . . . . . . . . . . . . 72
D.1.0 CICS Transaction Server (CICS TS). . . . 72
D.2.0 Data Access Beans für den Zugriff auf
Daten . . . . . . . . . . . . . . . 72
D.3.0 Data Access Builder . . . . . . . . 73
D.4.0 EJB(TM)-Entwicklungsumgebung . . . . 73
D.5.0 Enterprise Access Builder(EAB) und e-Konnektoren . . . . . . . . . . . . . . 77
D.6.0 Enterprise Toolkit für AS/400 (ET/400) . . 84
D.7.0 Enterprise Toolkit für OS/390 (ET/390) . . 85
D.8.0 Enterprise Toolkit für Workstations
(ET/WS) . . . . . . . . . . . . . . 86
D.9.0 Externe Versionskontrolle
. . . . . . 86
D.10.0 IDL-Entwicklungsumgebung . . . . . 87
D.11.0 Integrierte Entwicklungsumgebung (Integrated Development Environment - IDE) . . . 87
D.12.0 EJB-Entwicklungsumgebung (EJB Development Environment). . . . . . . . . . 87
D.13.0 Migrationsunterstützung für ActiveX . . 88
D.14.0 Persistence Builder . . . . . . . . 88
D.15.0 RMI Access Builder . . . . . . . . 89
D.16.0 Visual Composition Editor . . . . . . 91
D.17.0 Servlet Builder und Servlet Launcher . . 92
D.18.0 Swing-Klassen . . . . . . . . . . 95
D.19.0 XMI Toolkit
. . . . . . . . . . 95
Teil E: Allgemeine Informationen . . . . . . . 96
E.1.0 Arbeiten mit Projektressourcen und
Ressourcenverwaltung. . . . . . . . . . 96
E.2.0 Migration von OS/2 und AIX . . . . . 96
E.3.0 Neue Sicherheitseinschränkungen in J2SDK
v1.2.2 . . . . . . . . . . . . . . . 97
E.4.0 Neues Tool zur externen Versionssteuerung
(ersetzt externes SCM-Tool) . . . . . . . . 98
E. 5.0 Arbeiten mit ORBs (Object Request Broker)
anderer Hersteller in VisualAge für Java. . . . 98
E.6.0 Inhalt der CD für zusätzliche Funktionen
(Additional Features) . . . . . . . . . . 99
Anhang A: Ein Vergleich der Komponenten für den
Datenzugriff. . . . . . . . . . . . . . 104
Teil 1: Features für die Zuordnung Objekt-zuRelational . . . . . . . . . . . . . 105
Teil 2: Laufzeit-Features . . . . . . . . . 115
Teil 3: Data Access Beans (DAB)-Funktionen . . 119
Bemerkungen . . . . . . . . . . . 125
iii
iv
Installations- und Migrationshandbuch
Installations- und Migrationshandbuch
Dieses Installations- und Migrationshandbuch enthält die folgenden Informationen:
v Hardware- und Softwarevoraussetzungen für VisualAge(R) für Java(TM), Professional Edition und Enterprise Edition
v Vorgehensweise bei der Installation von VisualAge für Java, Professional Edition
und Enterprise Edition
v Voraussetzungen und unterstützte Plattformen für den Team-Repository-Server
(EMSRV)
v Vorgehensweise bei der Installation des Team-Repository-Servers (EMSRV)
v Vorbereitungen für die Team-Entwicklungsumgebung
v Einschränkungen und bekannte Probleme bei der Installation
v Vorgehensweise bei der Migration von einer früheren Version von VisualAge für
Java (sowohl allgemeine als auch komponentenspezifische Informationen)
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 OnlineHilfe. 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
1
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
Inhaltsverzeichnis
Teil A: VisualAge für Java, Professional Edition
1.0 „A.1.0 Voraussetzungen” auf Seite 4
2.0 „A.2.0 Installation” auf Seite 5
2.1 Installation von VisualAge für Java, Version (page 5) 4.0 (page 5)
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„B.1.0 Voraussetzungen” auf Seite 25
1.1 Allgemeine Voraussetzungen
1.2 Komponentenspezifische Voraussetzungen
2.0 Installation„B.2.0 Installation” auf Seite 27
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
2
Installations- und Migrationshandbuch
Teil C: Team-Repository-Server (EMSRV)
1.0 Voraussetzungen„C.1.0 Voraussetzungen” auf Seite 51
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
(page 53)
1.5 Unterstützte Dateisysteme
2.0 Installation„C.2.0 Installation” auf Seite 54
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„C.3.0 Migration ” auf Seite 68
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 EMSRVUtilities
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
Installations- und Migrationshandbuch
3
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
Java6.0 Inhalt der CD für zusätzliche Funktionen (Additional Features)
Anhänge
Anhang A: Ein Vergleich der Komponenten für den Datenzugriff
Teil A: VisualAge für Java, Professional Edition
A.1.0 Voraussetzungen
Bei dieser Edition von VisualAge für Java, Version 4.0 sind die folgenden Hardware- und Softwarevoraussetzungen zu beachten:
v Windows(R) 98, Windows 2000 oder Windows NT (R) 4.0 mit Service Pack 4
(oder höher)
v Maus oder Zeigereinheit *
v TCP/IP installiert und konfiguriert
v Pentium (R) II-Prozessor oder höher wird empfohlen. Wenn Sie in der
WebSphere-Testumgebung arbeiten wollen, empfehlen wir eine Prozessormindestgeschwindigkeit von 400 MHz.
v SVGA-Bildschirm (800x600) oder höher (1024 x 768 wird empfohlen)
v Mindestens 48 MB RAM (96 MB empfohlen)
v Um mit dem Distributed Debugger zu arbeiten, benötigen Sie mindestens 128
MB RAM (196 MB empfohlen)
v 128 MB RAM sind erforderlich, wenn Sie mit der VisualAge für Java WebSphereTestumgebung arbeiten möchten. Wir empfehlen dringend 256 MB, um eine
Festplattenüberlastung zu vermeiden.
v Rahmenfähiger Web-Browser wie Netscape Navigator 4.7 oder höher oder Microsoft (R) Internet Explorer 5.0 oder höher. Sie sollten zum Anzeigen der OnlineDokumentation keine Browserversionen vor Navigator 4.7 oder Internet Explorer
5.0 verwenden.
v Erforderlicher Plattenspeicherplatz (NTFS-Laufwerk): mindestens 350 MB (400
MB oder mehr empfohlen). Der auf FAT-Laufwerken erforderliche Plattenspeicherplatz ist von der Festplattengröße und der Partitionierung abhängig:
Wenn Sie die Installation auf einem sehr großen FAT-Laufwerk durchführen, verdoppelt sich der für VisualAge für Java erforderliche Speicherplatz nahezu (aufgrund des Overheads bei 32KB-Clustern).
4
Installations- und Migrationshandbuch
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.
A.2.0 Installation
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:
v Auf Ihrem Windows-Systemlaufwerk müssen mindestens 20 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 6
MB Speicherplatz frei sind.
v Wenn Sie das Standardzielverzeichnis verwenden, muss PATH weniger als 377
Zeichen unter Windows 98 und weniger als 820 Zeichen unter Windows NT und
Windows 2000 lang sein.
v Der CLASSPATH muss weniger als 455 Zeichen umfassen. VisualAge für Java
fügt während der Installation etwa 54 Zeichen zum CLASSPATH hinzu. Diese
Zahlen basieren auf der Annahme, dass das Zielverzeichnis 36 Zeichen lang ist
(z. B. Programme\IBM\VisualAge für Java).
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:
1. Verlassen Sie das Installationsfenster.
2. Öffnen Sie den Windows-Explorer. Gehen Sie in das Windows-Verzeichnis (beispielsweise C:\Windows).
3. Klicken Sie mit der rechten Maustaste Command.com, an, und wählen Sie
anschließend Eigenschaften im Kontextmenü aus. Klicken Sie die Registerkarte
Speicher an.
4. Geben Sie im Feld Anfänglicher Umgebungsspeicher als Größe 4096 Byte an.
Klicken Sie OK an.
5. Schließen Sie den Windows-Explorer.
6. Starten Sie Ihren Computer neu.
7. Starten Sie anschließend die Installation von VisualAge für Java erneut.
Installations- und Migrationshandbuch
5
A.2.1.1 Installation von VisualAge für Java, Version 4.0, von der Produkt-CD
1. Legen Sie die CD-ROM in Ihr CD-ROM-Laufwerk ein. Wenn Sie von einer früheren Version von VisualAge für Java migrieren, lesen Sie den Abschnitt “Migration von einer früheren Version von VisualAge für Java” (Abschnitt 3.0 dieses
Dokuments), BEVOR Sie mit der Installation fortfahren.
2. Ist autorun auf Ihrem System inaktiviert, führen Sie setup.exe im Stammverzeichnis des CD-Laufwerks aus.
3. Wählen Sie Produkte installieren aus. Wählen Sie VisualAge für Java installieren aus, um mit der Installation von VisualAge für Java zu beginnen. 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, lesen Sie den Abschnitt A.2.1.1.1; dort finden Sie Informationen zur Installation des Distributed Debugger.
4. Befolgen Sie die Anweisungen auf dem Bildschirm.
5. Starten Sie die VisualAge für Java IDE.
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
1. Führen Sie setup.exe aus, und wählen Sie Produkte installieren aus. Wählen
Sie anschließend Distributed Debugger installieren aus, um den Debugger zu
installieren.
6
Installations- und Migrationshandbuch
Distributed Debugger für AIX
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die idebug.tar.Z vom Installationsdatenträger in Ihr Scratch-Verzeichnis.
3. Wechseln Sie in Ihr Scratch-Verzeichnis.
4. Dekomprimieren Sie die Datei idebug.tar.Z file, indem Sie den folgenden Befehl
eingeben: uncompress idebug.tar.Z
5. Extrahieren Sie die Installationsimages aus der Datei idebug.tar, indem Sie den
folgenden Befehl eingeben: tar -xvf idebug.tar
6. Geben Sie als Root-Benutzer den folgenden Befehl ein: installp -ac -X -V2 -g
-N -d idebug
7. Sie können für diesen Befehl auch SMIT verwenden: smitty install_latest
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.
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die Datei install.class in Ihr Scratch-Verzeichnis.
3. Öffnen Sie von einer Eingabeaufforderung aus Ihr Scratch-Verzeichnis. Hat Ihr
Scratch-Verzeichnis beispielsweise den Namen /tmp/idebug, müssen Sie den
Befehl cd /tmp/idebug eingeben, um es zu öffnen.
4. Geben Sie als Root-Benutzer den folgenden Befehl ein: java install.class
Distributed Debugger für Solaris
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die Dateien dbgsetup und idebug.pkg in Ihr Scratch-Verzeichnis.
3. Öffnen Sie von einer Eingabeaufforderung aus Ihr Scratch-Verzeichnis. Hat Ihr
Scratch-Verzeichnis beispielsweise den Namen /tmp/idebug, müssen Sie den
Befehl cd /tmp/idebug eingeben, um es zu öffnen.
4. Machen Sie ″dbgsetup″ zur ausführbaren Datei, indem Sie den folgenden befehl
ausführen: chmod +x dbgsetup
5. Geben Sie als Root-Benutzer den folgenden Befehl ein, um den Debugger zu
installieren: ./dbgsetup idebug.pkg
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.rpm
Distributed 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
Installations- und Migrationshandbuch
7
Distributed Debugger für OS/390
1. Installieren Sie den Distributed Debugger für Windows.
2. Befolgen Sie die Anweisungen in der Datei README_install.txt, die sich im
Basisinstallationsverzeichnis von Windows befindet.
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.
v IDE (Integrated Development Environment) - umfasst neun Archivpakete, von
denen nur zwei benötigt werden. So können Sie gezielt nur die Komponenten
herunterladen, die Sie möchten.
v Distributed Debugger - steht für jedes Betriebssystem als separates Paket zur
Verfügung, so dass Sie nur die entsprechenden Pakete für die Plattformen herunterladen müssen, auf denen Sie Programme debuggen wollen.
v 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.
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:
v VisualAge for Java - IDE 1 of 9 (English only) - REQUIRED. Das erste der beiden unbedingt benötigten Archive. Enthält die Basis für die IDE, Data Access
Beans für den Datenzugriff und den Visual Composition Editor.
v VisualAge for Java - IDE 2 of 9 (English only) - REQUIRED. Das zweite der beiden unbedingt benötigten Archive. Enthält die Basis für die IDE, die Tools-API,
den SmartGuide für Servlets und XML für Java-Parser.
8
Installations- und Migrationshandbuch
v VisualAge for Java - IDE 3 of 9 (English only) - OPTIONAL. Erweiterte
Datenbankunterstützung (Stored Procedure Builder und SQLJ), JSPEntwicklungsumgebung, Externe Versionssteuerung.
v VisualAge for Java - IDE 4 of 9 - OPTIONAL. Implementierungsumgebungen
und Online-Dokumentation im PDF-Format.
v VisualAge for Java - IDE 5 of 9 - OPTIONAL. Portugiesisches (BR) und spanisches Sprachenpaket. Es enthält den portugiesischen (BR) und spanischen Text
für die IDE und ihre sämtlichen Komponenten.
v VisualAge for Java - IDE 6 of 9 - OPTIONAL. Französisches und italienisches
Sprachenpaket. Es enthält den französischen und italienischen Text für die IDE
und ihre sämtlichen Komponenten.
v VisualAge for Java - IDE 7 of 9 - OPTIONAL. Japanisches Sprachenpaket. Es enthält den japanischen Text für die IDE und ihre sämtlichen Komponenten.
v VisualAge for Java - IDE 8 of 9 - OPTIONAL. Deutsches und koreanisches
Sprachenpaket. Es enthält den deutschen und koreanischen Text für die IDE und
ihre sämtlichen Komponenten.
v VisualAge for Java - IDE 9 of 9 - OPTIONAL. Sprachenpaket für vereinfachtes
und traditionelles Chinesisch. Es enthält den Text für die IDE und ihre sämtlichen Komponenten in vereinfachtem und traditionellem Chinesisch.
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:
1. Wenn Sie VisualAge für Java herunterladen und extrahiert haben, führen Sie
setup.exe aus, und wählen Sie Produkte installieren aus. Wählen Sie anschließend Distributed Debugger installieren aus.
2. Wenn Sie den Distributed Debugger ohne VisualAge für Java installieren wollen, öffnen Sie das folgende Verzeichnis von einer Eingabeaufforderung aus:
DebugDirectory\windows (hierbei ist DebugDirectory das Verzeichnis, in das Sie
den Distributed Debugger extrahiert haben), und führen Sie den folgenden
Befehl aus: setup.bat
VisualAge for Java - Distributed Debugger for AIX enthält die Debug-Maschine
für AIX. Führen Sie folgende Anweisungen aus, um sie zu installieren:
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die idebug.tar.Z vom Installationsdatenträger in Ihr Scratch-Verzeichnis.
3. Wechseln Sie in Ihr Scratch-Verzeichnis.
4. Dekomprimieren Sie die Datei idebug.tar.Z file, indem Sie den folgenden Befehl
eingeben: uncompress idebug.tar.Z
Installations- und Migrationshandbuch
9
5. Extrahieren Sie die Installationsimages aus der Datei idebug.tar, indem Sie den
folgenden Befehl eingeben: tar -xvf idebug.tar
6. Geben Sie als Root-Benutzer den folgenden Befehl ein: installp -ac -X -V2 -g
-N -d idebug
7. Sie können für diesen befehl auch SMIT verwenden: smitty install_latest
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.
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die Datei install.class in Ihr Scratch-Verzeichnis.
3. Öffnen Sie von einer Eingabeaufforderung aus Ihr Scratch-Verzeichnis. Hat Ihr
Scratch-Verzeichnis beispielsweise den Namen /tmp/idebug, müssen Sie den
Befehl cd /tmp/idebug eingeben, um es zu öffnen.
4. Geben Sie als Root-Benutzer den folgenden Befehl ein: java install.class
VisualAge for Java - Distributed Debugger for Solaris enthält die Debug-Engine
für die Solaris-Betriebsumgebung. Um dieses Paket zu installieren, entpacken Sie
die Datei und befolgen Sie die folgenden Anweisungen.
1. Machen Sie ″dbgsetup″ zur ausführbaren Datei, indem Sie den folgenden befehl
ausführen: chmod +x dbgsetup
2. Geben Sie als Root-Benutzer den folgenden Befehl ein, um den Debugger zu
installieren: ./dbgsetup idebug.pkg
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.rpm
VisualAge 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
1. Installieren Sie den Distributed Debugger für Windows.
2. Befolgen Sie die Anweisungen in der Datei README_install.txt, die sich im
Basisinstallationsverzeichnis von Windows befindet.
10
Installations- und Migrationshandbuch
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.
Installations- und Migrationshandbuch
11
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 READMEDatei im Verzeichnis ’IBM Developer Kit’.
A.3.0 Migration von einer früheren Version von VisualAge für
Java
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.xUnterstü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.
12
Installations- und Migrationshandbuch
Automatische Migration
1. Führen Sie die folgenden Schritte aus, um Ihre Benutzerdaten zu sichern. Es
empfiehlt sich dringend, Sicherungskopien Ihres Repositorys und der
Ressourcendateien zu erstellen für den Fall, dass während der Migration Probleme auftreten.
a. Versionieren Sie Ihre Projekte und Pakete. In das Repository von VisualAge
für Java, Version 4.0 können nur versionierte Projekte und Pakete importiert
werden. In der Online-Hilfe von VisualAge für Java sind Anweisungen zur
Versionierung enthalten.
b. Sichern Sie Ihr Repository an einer neuen Position außerhalb der
Verzeichnisstruktur von VisualAge für Java. Der Dateiname und -pfad des
Repositorys ist x:\IBMVJava\ide\repository\ivj.dat, wobei x:\IBMVJava das
Installationsverzeichnis von VisualAge für Java ist.
Hinweis: Wenn Sie von Version 3.5 oder Version 3.5.3 migrieren, enthält das
Repository auch versionierte Kopien Ihrer Projektressourcendateien, die sich
in folgendem Verzeichnis befinden: x:\IBMVJava\ide\repository\ivj.dat.pr.
Sie müssen eine Kopie des Verzeichnisses ’ivj.dat.pr’ außerhalb der
Verzeichnisstruktur von VisualAge für Java sichern.
2. Um VisualAge für Java, Version 4.0 zu installieren, gehen Sie anhand der
Anweisungen in Abschnitt 2.1 (page 5) vor.
3. Geben Sie an, dass Sie ein Upgrade Ihrer bisherigen Installation wünschen. Sie
müssen Version 3.5 oder Version 3.5.3 vorher nicht deinstallieren, da für diese
Versionen automatisch ein Upgrade auf Version 4.0 durchgeführt werden werden kann. Version 4.0 wird automatisch im bisherigen Verzeichnis der Version
3.5 oder Version 3.5.3 installiert.
4. Nach Beendigung einer erfolgreichen Upgrade-Installation werden alle Ihre
Projektressourcen und die Repository-Daten automatisch auf Version 4.0 migriert, wenn Sie die IDE von Version 4.0 zum ersten Mal starten.
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
1. Stellen Sie sicher, dass Ihre Repository-Daten (also Ihr Repository und, wenn
Sie von Version 3.5 oder Version 3.5.3 migrieren, Ihr ivj.dat.pr-Verzeichnis) und
die Ressourcendateien außerhalb der VisualAge für Java-Dateiverzeichnisstruktur gesichert sind.
2. Deinstallieren Sie das Produkt vollständig. Alle Unterverzeichnisse und Dateien
der Version 3.5 oder Version 3.5.3 müssen gelöscht werden.
3. Starten Sie Ihr System neu und installieren Sie Version 4.0.
4. Starten Sie die IDE.
5. Nun können Sie Pakete und Projekte von Ihrem alten Repository in das neue
Repository importieren. Wählen Sie in der Workbench Datei, dann Importieren
und anschließend den Radioknopf Repository aus. Klicken Sie danach Weiter
an. Geben Sie im Feld Repository-Name den Pfad Ihrer Sicherungskopie von
ivj.dat ein. Wählen Sie anschließend die Projekte und Pakete aus, die Sie importieren möchten. Sie können keine Projekte oder Pakete importieren, die nicht
versioniert wurden. Hinweis: Sie dürfen keine Systemprojekte aus einer vorhergehenden Version von VisualAge für Java importieren.
Installations- und Migrationshandbuch
13
6. Um die ausgewählten Projekte automatisch zum Arbeitsbereich hinzuzufügen,
wählen Sie das Markierungsfeld Aktuellste Projektedition dem Arbeitsbereich
hinzufügen aus. Dieses Markierungsfeld ist nur verfügbar, wenn der Radioknopf Projekte ausgewählt ist.
7. Klicken Sie Fertig stellen an.
8. Sie müssen die Sicherungskopie Ihrer Ressourcendateien nicht in das Unterverzeichnis x:\IBMVJava\ide\project_resources\projekt kopieren; hierbei ist
x:\IBMVJava das Installationsverzeichnis von VisualAge für Java, Version 3.5.3,
und projekt ost der Name des Projekts ist, dem die Ressourcen zugeordnet sind.
Wenn Sie Ihre mit Version 3.5 oder Version 3.5.3 erstellten Projekte in das Repository importieren, werden alle versionierten Kopien Ihrer im Verzeichnis ’ivj.dat.pr’ enthaltenen Projektressourcen automatisch dem Repository hinzugefügt.
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.
1. Versionieren Sie Ihre Projekte und Pakete. In VisualAge für Java, Version 3.5
können nur versionierte Projekte und Pakete importiert werden. In der OnlineHilfe von VisualAge für Java sind Anweisungen zur Versionierung enthalten.
2. Sichern Sie Ihr Repository an einer neuen Position außerhalb der Verzeichnisstruktur von VisualAge für Java. Der Dateiname und -pfad des Repositorys ist
x:\IBMVJava\ide\repository\ivj.dat, wobei x:\IBMVJava das Installationsverzeichnis von VisualAge für Java ist.
3. Kopieren Sie alle Ressourcendateien (z. B. Bilder oder Audiodateien), die von
den Java-Anwendungen verwendet werden, in einem Verzeichnis außerhalb der
Verzeichnisstruktur von VisualAge für Java. Standardmäßig befinden sich die
Ressourcendateien für jedes VisualAge für Java-Projekt in Unterverzeichnissen
mit dem Namen x:\IBMVJava\ide\project_resources\projekt, wobei
x:\IBMVJava das Installationsverzeichnis von VisualAge für Java und projekt der
Name des Projekts ist, dem die Ressourcen zugeordnet sind.
4. Sie können nun Version 2.0, 3.0x oder 3.0x, Early Adopters, deinstallieren und
Version 4.0 installieren. 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.
5. Installieren Sie VisualAge für Java, Version 4.0 (siehe Abschnitt 2.1 (page 5))
und starten Sie die IDE der Version 4.0.
14
Installations- und Migrationshandbuch
6. In der Online-Hilfe finden Sie Informationen dazu, wie Sie Pakete und Projekte
aus Ihrem alten Repository in das neue Repository importieren können. Sie
können keine Projekte oder Pakete importieren, die nicht versioniert wurden.
Hinweis: Sie dürfen keine Systemprojekte aus einer vorhergehenden Version
von VisualAge für Java importieren.
7. Kopieren Sie die Sicherungskopie Ihrer Ressourcendateien in das Unterverzeichnis x:\IBMVJava\ide\project_resources\projekt, wobei x:\IBMVJava das
Installationsverzeichnis von VisualAge für Java, Version 4.0, ist und projekt der
Name des Projektes, dem die Ressourcen zugeordnet sind. Sie können auch
eine Kopie Ihrer Ressourcendateien über die aktuelle Installation der Version
2.0/3.0x oder 3.0x, Early Adopters erstellen (sofern sie nicht deinstalliert
wurde) und diese Kopie in das vorstehende Unterverzeichnis kopieren.
8. Wenn Sie sichergestellt haben, dass die manuelle Migration erfolgreich war,
können Sie die in den Schritten 2 und 3 erstellten Sicherungskopien wieder
löschen.
A.4.0 Bekannte Probleme und Einschränkungen
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
v Führen Sie die Installation nicht auf einem HPFS-Netzlaufwerk oder auf einem
lokalen HPFS-Laufwerk aus, da Windows 98, Windows 2000 und Windows NT
4.0 auf HPFS Schwierigkeiten bei langen Dateinamen haben.
v Führen Sie die Installation nicht auf einem Novell NetWare-Laufwerk aus. Die
Installation auf einem Novell NetWare-Laufwerk schlägt fehl.
A.4.1.2 Benutzerberechtigung
v Sie müssen Schreibzugriff auf das Stammverzeichnis “\” des Laufwerks haben,
auf dem VisualAge für Java installiert ist, damit Sie den NetQuestion-Such-Server installieren können.
v Wenn Sie das Produkt unter Windows 2000 installieren, erhalten Sie möglicherweise eine Warnung, wenn Sie kein Administrator sind. Die Warnung besagt,
dass einige Programme nicht korrekt arbeiten, wenn sie nicht von einem Administrator installiert wurden. Sie sollten sich als Administrator anmelden, bevor
Sie mit der Installation von VisualAge für Java beginnen.
v Wenn ein normaler Benutzer versucht, VisualAge für Java, Version 4.0 unter
Windows 2000 zu installieren, kann fälschlicherweise ein “Fehler bei der SetupInitialisierung” mit folgendem Inhalt angezeigt werden: “Setup hat festgestellt,
dass unInstallShield bereits aktiv ist. Bitte schließen Sie unInstallShield und starten Sie Setup erneut. Fehler 432.” Bevor Sie versuchen, das Produkt erneut zu
installieren, stellen Sie sicher, dass Sie die Benutzerzugriffsrechte eines Administrators oder Hauptbenutzers haben.
v Wenn Sie bei der Installation unter Windows NT keine Administrator-Berechtigung haben, funktioniert die Suchfunktion der Online-Hilfe nicht.
Installations- und Migrationshandbuch
15
A.4.1.3 TCP/IP-Voraussetzungen
v Wenn Sie die Warnung “Automatisch konfiguriert” vom Installationsprogramm
erhalten, bedeutet dies, dass die Proxy-Ausnahmebedingungen Ihres Browsers
automatisch konfiguriert wurden. Wenden Sie sich an den Systemadministrator,
um sicherzustellen, dass 127.0.0.1 als lokale Adresse interpretiert wird.
v Sie müssen TCP/IP installieren und konfigurieren, damit die Installation von
IBM VisualAge für Java ordnungsgemäß ausgeführt werden kann. Unter Windows 98 und Windows 2000 müssen Sie TCP/IP wie folgt aktivieren:
1. Bei einer LAN-Adapter-Konfiguration:
– DNS muss mit einem gültigen Host- und Domänennamen aktiviert sein.
– Ihr LAN DNS muss “localhost” als 127.0.0.1 auflösen.
– Sie können bei einer LAN-Adapter-Konfiguration das Programm nicht
ausführen, wenn die Verbindung nicht hergestellt ist.
2. Bei einer Wahl-Adapter-Konfiguration:
– DNS muss inaktiviert sein.
– Ihre TCP/IP-Adresse muss automatisch abgerufen werden.
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:
1. Stellen Sie sicher, dass Sie über eine Notfalldiskette verfügen. Anweisungen zur
Erstellung einer solchen Diskette erhalten Sie in der Hilfedokumentation zum
Betriebssystem Windows.
2. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
3. Blenden Sie im Registrierungs-Editor alle Verzweigungen des folgenden Schlüssels ein:
\\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon
16
Installations- und Migrationshandbuch
4. Wählen Sie den Namen shell im Name/Daten-Paar für den obigen Schlüssel
aus. Wichtig: Notieren Sie sich unbedingt die Daten für diesen Namen, da
diese nach dem Installieren von IBM VisualAge für Java benötigt werden.
5. Wählen Sie Bearbeiten -> Modifizieren in der Menüleiste für das
Name/Daten-Paar shell aus.
6. Setzen Sie den Wert für den SHELL-Namen auf Explorer.exe. Klicken Sie OK
an.
7. Wählen Sie Registrierung -> Beenden in der Menüleiste aus.
8. Starten Sie die Installation von IBM VisualAge für Java erneut und führen Sie
sie vollständig aus.
9. Wenn die Installation vollständig abgeschlossen ist, stellen Sie den vorherigen
Registrierungseintrag wie folgt wieder her:
a. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
b. Blenden Sie im Registrierungs-Editor alle Verzweigungen des Schlüssels
\\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon ein.
c. Wählen Sie den Namen shell im Name/Daten-Paar für den obigen Schlüssel
aus.
d. Wählen Sie Bearbeiten -> Modifizieren in der Menüleiste für das
Name/Daten-Paar shell aus.
e. Stellen Sie als Wert für den SHELL-Namen den Wert wieder her, den Sie sich
in Schritt 4 notiert haben. Klicken Sie anschließend OK an.
f. Wählen Sie in der Menüleiste Registrierung -> Beenden 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:
1. Stellen Sie sicher, dass Sie über eine Notfalldiskette verfügen. Anweisungen zur
Erstellung einer solchen Diskette erhalten Sie in der Hilfedokumentation zum
Betriebssystem Windows.
2. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
3. Blenden Sie im Registrierungs-Editor alle Verzweigungen des folgenden Schlüssels ein, und wählen Sie ihn aus:
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows\4.0
Installations- und Migrationshandbuch
17
4. Wählen Sie Bearbeiten -> Löschen in der Menüleiste für diesen Schlüssel aus.
5. Wählen Sie Ja aus, wenn Sie gefragt werden, ob dieser Schlüssel wirklich
gelöscht werden soll.
6. Wählen Sie in der Menüleiste Registrierung > Beenden aus.
Wenn vor dem Fehlschlagen der Installation bereits NetQuestion-Dateien installiert
wurden, müssen Sie diese ebenfalls löschen.
1. Öffnen Sie eine neue Eingabeaufforderung. Überprüfen Sie, ob irgendwelche
NetQuestion-Dateien installiert wurden, indem Sie an der soeben geöffneten
Eingabeaufforderung den folgenden Befehl eingeben: set imninstsrv. Mit diesem Befehl erhalten Sie die Position, an der NetQuestion auf Ihrer Maschine
installiert ist. Beispiel:
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.
2. Wechseln Sie in das NetQuestion-Verzeichnis (das nach IMNINSTSRV= angegeben ist).
3. Geben Sie vahcfg remove /p vj32 ein.
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.
18
Installations- und Migrationshandbuch
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:
1. Wählen Sie Start > Suchen > Dateien/Ordner aus, und suchen Sie in Ihrem
System nach der Datei sfc.dll.
2. Benennen Sie die Datei ’sfc.dll’ (die Version im Pfad (PATH) von Windows NT
4.0) vorübergehend in ’sfc.old’ um.
3. Installieren Sie VisualAge für Java.
4. Wenn Sie VisualAge für Java erfolgreich installiert haben, benennen Sie die
Datei ’sfc.old’ in ’sfc.dll’ um.
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:
1. Verlassen Sie gegebenenfalls die Installation.
2. Löschen Sie das folgende Verzeichnis: x:\Programme\Common
Files\InstallShield, wobei x das Laufwerk ist, auf dem Sie VisualAge für Java
eigentlich installieren wollten.
3. Installieren Sie das Produkt erneut.
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:
v Fehler 1631: The Windows Installer service failed to start. Contact your support
personnel (Der Windows Installer-Service wurde nicht gestartet. Wenden Sie sich
an die Benutzerunterstützung.)
v Interner Fehler 2755: Please contact product support for assistance. (Bitte wenden Sie sich an die Produktunterstützung.)
Installations- und Migrationshandbuch
19
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:
v Sie installieren VisualAge für Java unter Windows NT 4.0
v Das Laufwerk mit dem Ordner ’winnt’ oder das Laufwerk, auf dem Sie VisualAge für Java installieren wollen, ist mit dem NTFS-Dateisystem formatiert
v Für diese Laufwerke sind keine gültigen Berechtigungen definiert
v Sie verfügen über Leseberechtigungen für das Verzeichnis, in dem Sie VisualAge
für Java installieren wollen
erhalten Sie möglicherweise eine oder mehrere der folgenden Fehlernachrichten:
v Interner Fehler 2381: Please contact product support for assistance. (Bitte wenden Sie sich an die Produktunterstützung.)
v Interner Fehler 1303: The Installer has insufficient privileges to access this directory: DirectoryName (Der Installer verfügt nicht über die entsprechenden Berechtigungen für den Zugriff auf dieses Verzeichnis: Verzeichnisname.)
v Interner Fehler 1310: Error attempting to create the destination file: FileName System error code: ErrorCode (this code varies depending on your problem) (Fehler
beim Erstellen der Zieldatei: Dateiname Systemfehlercode: Fehlercode (dieser Code
hängt vom entsprechenden Problem ab).)
v Interner Fehler 1315: The specified folder ’FolderName ’ is not writable. (Auf den
spezifische Ordner ’Ordnername’ besteht kein Schreibzugriff.)
Dieses Problem tritt Berichten zufolge dann auf, wenn für die folgenden Ordner
lediglich Leseberechtigungen vorliegen:
\Programme\IBM\VisualAge for Java
\WinNT\Installer
20
Installations- und Migrationshandbuch
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:
1. Wählen Sie in Windows Explorer das entsprechende Laufwerk bzw. Verzeichnis
aus.
2. Klicken Sie den Ordner mit der rechten Maustaste an, und wählen Sie anschließend die Option Eigenschaften im aufgerufenen Kontextmenü aus.
3. Wählen Sie die Indexzunge Sicherheit aus. Klicken Sie auf Berechtigungen.
4. Wählen Sie Jeder aus. Wählen Sie im Dropdown-Menü Zugriffsart die Option
Vollzugriff aus.
5. Wählen Sie das Markierungsfeld Berechtigungen für Unterverzeichnisse ersetzen aus.
6. Klicken Sie OK an.
7. Klicken Sie auf Ja, wenn Sie aufgefordert werden zu bestätigen, ob Sie die
Berechtigungen für alle Unterverzeichnisse ersetzen wollen.
8. Klicken Sie OK an.
9. Installieren Sie VisualAge für Java.
Interner Fehler 2735 Engine-Start
Wenn Sie den Fehler 2735 erhalten, führen Sie folgende Schritte aus, um das Problem zu umgehen:
1. Suchen Sie in Ihrem Windows 32-Systemverzeichnis nach den folgenden
Dateien:
v shd401lc.dll
v shdoclc.dll
v shdoc401.dll
v shdocvw.dll
2. Benennen Sie shd401lc.dll in shd401lc.old um.
3. Benennen Sie shdoclc.dll in shdoclc.old um.
4. Wählen Sie Start > Ausführen aus, um den Dialog ’Ausführen’ zu öffnen. Führen Sie die folgenden Befehle aus, um die Registrierung dieser .dll-Dateien aufzuheben:
v regsvr32 /u shd401lc.dll
v regsvr32 /u shdoclc.dll
5. Registrieren Sie diese dlls, indem Sie die folgenden Befehle über den Dialog
’Ausführen’ ausführen:
v regsvr32 shdoc401.dll
v regsvr32 shdocvw.dll
6. Installieren Sie VisualAge für Java.
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
Installations- und Migrationshandbuch
21
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:
1. Rufen Sie regedit.exe von einer Eingabeaufforderung aus auf.
2. Blenden Sie den folgenden Schlüssel ein und wählen Sie ihn aus:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current
Version\Explorer\User Shell Folder
3. Wählen Sie Common Administrative Tools aus.
4. Wählen Sie Bearbeiten > Ändern aus.
5. Geben Sie in das Feld ’Wert’ Folgendes ein:
%SystemRoot%\Profiles\AllUsers\StartMenu\Programs\Administrative Tools.
6. Klicken Sie OK an.
7. Wählen Sie in der Menüleiste Registrierung > Beenden aus.
8. Installieren Sie VisualAge für Java.
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.
22
Installations- und Migrationshandbuch
Führen Sie die folgenden Schritte aus:
1. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
2. Blenden Sie im Registrierungs-Editor alle Verzweigungen des folgendes Schlüssels ein, und wählen Sie ihn aus:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed
Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
3. Wählen Sie in der Menüleiste für diesen Schlüssel Bearbeiten > Löschen aus.
4. Wählen Sie Ja aus, wenn Sie gefragt werden, ob dieser Schlüssel wirklich
gelöscht werden soll.
5. Wählen Sie in der Menüleiste Registrierung > Beenden 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:
1. Erstellen Sie eine Sicherungskopie der Datei autoexec.bat.
2. Stellen Sie fest, ob auf Ihrem System ein anderes Programm installiert ist, das
die HTML-Such-Engine benötigt (z. B. DB2). Gehen Sie dabei wie folgt vor:
a) Deinstallieren Sie VisualAge für Java, und starten Sie das System erneut.
b) Geben Sie regedit.exe in einer Eingabeaufforderung ein, und blenden Sie im
Registrierungs-Editor die Baumstruktur von
HKEY_LOCAL_MACHINE\SOFTWARE\ ein. Wenn sich in dieser Baumstruktur ein IBM Verzeichnis befindet, erweitern Sie es, um festzustellen, ob
sich dort ein NetQuestion-Verzeichnis befindet. Wenn ja, verwenden Sie die
Such-Engine wahrscheinlich mit einem anderen IBM Produkt.
3. Wenn Sie die HTML-Such-Engine nicht für ein anderes Produkt verwenden,
müssen Sie alle IMN- oder IMQ-Einträge in der Datei autoexec.bat entfernen,
bevor Sie VisualAge für Java erneut installieren.
4. Wenn Sie die HTML-Such-Engine für ein anderes Produkt verwenden, müssen
Sie alle Doppeleinträge hierfür in der Datei autoexec.bat löschen.
IMNINST
IMNINSTSRV
IMNNQ
IMNNQ_95
IMQCONFIGCL
IMQCONFIGSRV
Löschen Sie ebenfalls die doppelten Einträge der Zeile IF EXIST
X:\IMNNQ_95\IMNENV.BAT CALL IMNEV.BAT
Installations- und Migrationshandbuch
23
5. Achten Sie dabei darauf, dass Sie nicht die Originaleinträge löschen. Wenn Sie
sich nicht sicher sind, welche Einträge die Originaleinträge sind, müssen Sie
feststellen, wo NetQuestion im System installiert ist. Führen Sie hierzu folgende
Schritte aus:
a. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
b. Blenden Sie im Registrierungs-Editor alle Verzweigungen des folgenden
Schlüssels ein:
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\NetQuestion\Installation
Directory
c. Der Verzeichniswert in diesem Schlüssel zeigt den Pfad an, wo NetQuestion
installiert ist. Bestimmte Umgebungsvariablen müssen dieses Verzeichnis als
Teil ihres Werts enthalten, damit NetQuestion einwandfrei funktioniert.
Wenn Sie eine der oben genannten Umgebungsvariablen finden, die als Teil
ihres Werts ein anderes Verzeichnis als das Verzeichnis in der Registrierung
enthält, müssen Sie diese Umgebungsvariable löschen.
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 NetQuestionDateien zu entfernen. NetQuestion-Dateien von anderen Produkten (beispielsweise
DB2) sind davon nicht betroffen.
1. Um das NetQuestion-Verzeichnis zu ermitteln, geben Sie unter einer Eingabeaufforderung den Befehl set imninstsrv ein. Mit diesem Befehl erhalten Sie die
Position, an der NetQuestion auf Ihrer Maschine installiert ist. Beispiel:
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.
2. Wechseln Sie in das NetQuestion-Verzeichnis (das nach IMNINSTSRV= angegeben ist).
3. Geben Sie vahcfg remove /p vj32 ein.
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.
24
Installations- und Migrationshandbuch
Teil B: VisualAge für Java, Enterprise Edition
B.1.0 Voraussetzungen
B. 1.1 Allgemeine Voraussetzungen
Bei dieser Edition von VisualAge für Java, Version 4.0 sind die folgenden Hardware- und Softwarevoraussetzungen zu beachten:
v Windows 98, Windows 2000 oder Windows NT (R) 4.0 mit Service Pack 4 (oder
höher).
v Maus oder Zeigereinheit *
v TCP/IP installiert und konfiguriert
v Pentium II (R)-Prozessor oder höher empfohlen. Wenn Sie in der WebSphereTestumgebung arbeiten wollen, empfehlen wir eine Prozessormindestgeschwindigkeit von 400 MHz.
v SVGA-Bildschirm (800x600) oder höher (1024x768 empfohlen)
v Mindestens 96 MB RAM (160 MB empfohlen)
v 128 MB RAM sind erforderlich, wenn Sie mit der VisualAge für Java WebSphereTestumgebung arbeiten möchten. Wir empfehlen dringend 256 MB, um eine
Festplattenüberlastung zu vermeiden.
v Um mit dem Distributed Debugger zu arbeiten, benötigen Sie mindestens 128
MB RAM (196 MB empfohlen)
v Erforderlicher Plattenspeicherplatz (NTFS-Laufwerk): mindestens 400 MB (750
MB oder mehr empfohlen). Der auf FAT-Laufwerken erforderliche Plattenspeicherplatz ist von der Festplattengröße und der Partitionierung abhängig.
Wenn Sie die Installation auf einem sehr großen FAT-Laufwerk durchführen, verdoppelt sich der für VisualAge für Java erforderliche Speicherplatz nahezu (aufgrund des Overheads bei 32KB-Clustern). Wenn Sie die e-Konnektoren installieren (werden mit dem Transactions Access Builder automatisch installiert),
benötigen Sie weitere 150-200 MB freien Plattenplatz.
v Rahmenfähiger Web-Browser wie Netscape Navigator 4.7 oder höher oder Microsoft (R) Internet Explorer 5.0 oder höher.
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:
v Domino(TM) AgentRunner
– Zur Entwicklung der Anwendungen sind Notes 5.0.5 (oder höher) Client und
der Domino 5.0.5 (oder höher) Designer erforderlich. Zur Ausführung von
Anwendungen ist Notes 5.0 (oder höher) Client oder Domino 5.0 (oder
höher) Server erforderlich.
Installations- und Migrationshandbuch
25
v Domino Access Builder
– Benötigt Notes 5.0.5 (oder höher) Client oder Domino 5.0.5 (oder höher) Server
v Enterprise Toolkit für AS/400 (R) (ET/400)
– Benötigt OS/400 Release V, V4R3M0 oder höher
v Enterprise Toolkit für OS/390(R) (ET/390)
– Unter OS/390:
- NFS-Dämon aktiv auf OS/390
- REXEC-Server aktiv auf OS/390
- OMVS FTP-Server aktiv auf OS/390
- VisualAge für Java, Enterprise Edition for OS/390, Run Time Feature
- Schreibzugriff auf das Verzeichnis /tmp unter OS/390
- Für VisualAge für Java, Enterprise Edition für OS/390, Version 2, muss der
TCP-Parameter SBDATACONN auf dem Host konfiguriert werden, um die
Konvertierung zwischen EBCDIC- und ASCII-Codepages zu definieren,
wenn über die IDE (Integrated Development Environment) von VisualAge
für Java Aktionen von ET/390 Run Executable, Debug Executable, Run
Main und Debug Main ausgeführt werden. Weitere Informationen zum
Definieren dieses Parameters finden Sie im Handbuch OS/390 TCP/IP OpenEdition: Configuration Guide.
- Eine ordnungsgemäß konfigurierte ET/390 Java Install Data-Datei (javaInstall.data) im Verzeichnis /usr/lpp/hpj/. Wenn Sie die Compiler Feature
von VisualAge für Java, Enterprise Edition für OS/390, nicht erworben
haben, können Sie diese Datei manuell erstellen. Informationen über die
entsprechenden Schlüsselwörter und Parameter finden Sie in der ET/390Onlinehilfefunktion.
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.
v Enterprise Access Builder für SAP R/3
– Benötigt Zugriff auf einen SAP R/3-Server.
v Enterprise Access Builder für IMS(TM)
–
Für die Ausführung einer Java-Anwendung oder eines Java-Servlets, die bzw.
das den IMS-Konnektor verwendet, müssen die folgenden, in separaten Paketen gelieferten und installierten Produkte auf der Ziel-Host-Maschine installiert und aktiv sein:
– IMS Connect V1.1 und IMS Version 7 (empfohlen) oder
– IMS Connect V1.1 und IMS Version 5.1 oder 6.1
– Für die Verwendung von Local Option mit IMS Connector für Java, Version
4.0 gelten folgende Voraussetzungen:
- IMS Connect V1.1 plus Local Option mit Aktivierung von APAR PQ45057
- IMS V7.1; Hinweis: Local Option wird nur für IMS V7.1 und höher unterstützt.
– Wenn Sie eine EAB-Anwendung von einer früheren Version von VisualAge
für Java implementieren wollen, die IMS Connector für Java verwendet hat,
müssen Sie die folgenden Laufzeitdateien der Version 4.0 verwenden, die sich
im Verzeichnis IBM Connectors\classes und eab\runtime30 befinden:
- imsconn.jar
- ccf.jar
- recjava.jar
- eablib.jar
26
Installations- und Migrationshandbuch
B.2.0 Installation
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):
v ENCINA VAJ.RUL DELCon* copies failed
v ENCINA VAJ.RUL Deligh* copies failed
v ENCINA VAJ.RUL Drpc*
v ENCINA VAJ.RUL Transaction*
v HOD VAJ.RULcopy of file *.* failed
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:
v Der CLASSPATH muss weniger als 418 Zeichen umfassen. VisualAge für Java
fügt während der Installation etwa 92 Zeichen zum CLASSPATH hinzu. Diese
Zahlen basieren auf der Annahme, dass das Zielverzeichnis 36 Zeichen lang ist
(z. B. Programme\IBM\VisualAge für Java).
v Wenn Sie das Standardzielverzeichnis verwenden, muss PATH weniger als 377
Zeichen unter Windows 98 und weniger als 820 Zeichen unter Windows NT und
Windows 2000 lang sein.
v Auf Ihrem Windows-Systemlaufwerk müssen mindestens 20 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 6
MB Speicherplatz frei sind.
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:
Installations- und Migrationshandbuch
27
1. Verlassen Sie das Installationsfenster.
2. Öffnen Sie den Windows-Explorer. Gehen Sie in das Windows-Verzeichnis (beispielsweise C:\Windows).
3. Klicken Sie mit der rechten Maustaste Command.com, an, und wählen Sie
anschließend Eigenschaften im Kontextmenü aus. Klicken Sie die Registerkarte
Speicher an.
4. Geben Sie im Feld Anfänglicher Umgebungsspeicher als Größe 4096 Byte an.
Klicken Sie OK an.
5. Schließen Sie den Windows-Explorer.
6. Starten Sie Ihren Computer neu.
7. Starten Sie anschließend die Installation von VisualAge für Java erneut.
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
1. Wenn Sie von einer früheren Version von VisualAge für Java migrieren, lesen
Sie den Abschnitt 3.0 “Migration von einer früheren Version von VisualAge für
Java”, BEVOR Sie mit dem Installationsverfahren fortfahren.
2. Legen Sie die CD-ROM in Ihr CD-ROM-Laufwerk ein.
3. Ist autorun auf Ihrem System inaktiviert, führen Sie setup.exe im Stammverzeichnis des CD-Laufwerks aus.
4. Wählen Sie Produkte installieren aus. Wählen Sie VisualAge für Java installieren aus, um mit der Installation von VisualAge für Java zu beginnen. 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, lesen Sie den Abschnitt B.2.1.1.1; dort finden Sie Informationen zur Installation des Distributed Debugger.
5. Befolgen Sie die Anweisungen auf dem Bildschirm.
6. Starten Sie die VisualAge für Java IDE.
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.
28
Installations- und Migrationshandbuch
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
1. Sie können den Distributed Debugger von der CD für die zusätzlichen Funktionen (Additional Features) aus installieren. Wählen Sie in der Installationsanzeige der Additional Features-CD Produkte installieren, und dann Distributed
Debugger installieren aus.
Distributed Debugger für AIX
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die idebug.tar.Z vom Installationsdatenträger in Ihr Scratch-Verzeichnis.
3. Wechseln Sie in Ihr Scratch-Verzeichnis.
4. Dekomprimieren Sie die Datei idebug.tar.Z file, indem Sie den folgenden Befehl
eingeben: uncompress idebug.tar.Z
5. Extrahieren Sie die Installationsimages aus der Datei idebug.tar, indem Sie den
folgenden Befehl eingeben: tar -xvf idebug.tar
6. Geben Sie als Root-Benutzer den folgenden Befehl ein: installp -ac -X -V2 -g
-N -d idebug
7. Sie können für diesen befehl auch SMIT verwenden: smitty install_latest
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.
Installations- und Migrationshandbuch
29
Distributed Debugger für HP-UX
Voraussetzung:
Java Version 1.3 ist für die Installation und für Java-Debugging erforderlich.
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die Datei install.class in Ihr Scratch-Verzeichnis.
3. Öffnen Sie von einer Eingabeaufforderung aus Ihr Scratch-Verzeichnis. Hat Ihr
Scratch-Verzeichnis beispielsweise den Namen /tmp/idebug, müssen Sie den
Befehl cd /tmp/idebug eingeben, um es zu öffnen.
4. Geben Sie als Root-Benutzer den folgenden Befehl ein: java install.class
Distributed Debugger für Solaris
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die Dateien dbgsetup und idebug.pkg in Ihr Scratch-Verzeichnis.
3. Öffnen Sie von einer Eingabeaufforderung aus Ihr Scratch-Verzeichnis. Hat Ihr
Scratch-Verzeichnis beispielsweise den Namen /tmp/idebug, müssen Sie den
Befehl cd /tmp/idebug eingeben, um es zu öffnen.
4. Machen Sie ″dbgsetup″ zur ausführbaren Datei, indem Sie den folgenden befehl
ausführen: chmod +x dbgsetup
5. Geben Sie als Root-Benutzer den folgenden Befehl ein, um den Debugger zu
installieren: ./dbgsetup idebug.pkg
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.rpm
Distributed 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
1. Installieren Sie den Distributed Debugger für Windows.
2. Befolgen Sie die Anweisungen in der Datei README_install.txt, die sich im
Unterverzeichnis Debugger\OS390 auf der Produkt-CD befindet.
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:
v J2EE-Konnektor für CICS
v J2EE-Konnektor für SAP R/3
v J2EE-Konnektor für PeopleSoft
v J2EE-Konnektor für J.D. Edwards OneWorld.
v J2EE-Konnektor für Oracle Applications/Financials
v Tools zum Importieren von Datenstrukturen, die sich auf Anwendungs-Servern
von JD Edwards, PeopleSoft und Oracle befinden
v Tools zum Generieren J2EE-konformer Datensätze
v Tools zum Erstellen und Bearbeiten J2EE-konformer Befehle
v Tools zum Erstellen und Bearbeiten J2EE-konformer EAB-Sitzungs-Beans
30
Installations- und Migrationshandbuch
v
Tools zum Migrieren vorhandener EAB-Anwendungen in die J2EE-basierte
Architektur. Diese Tools migrieren Datensätze, Befehle und Navigatoren.
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.
v IDE (Integrated Development Environment) - umfasst vierzehn Archivpakete,
von denen nur zwei benötigt werden. So können Sie gezielt nur die Komponenten herunterladen, die Sie möchten.
v Distributed Debugger - steht für jedes Betriebssystem als separates Paket zur
Verfügung, so dass Sie nur die entsprechenden Pakete für die Plattformen herunterladen müssen, auf denen Sie Programme debuggen wollen.
v EMSRV - eine Archivdatei enthält den Team-Server-Code für alle unterstützten
Server-Plattformen, die in Teil C, Abschnitt 1.1 dieses Dokuments aufgeführt
sind.
v 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.
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.
Installations- und Migrationshandbuch
31
Die einzelnen Archive haben jeweils den folgenden Inhalt:
v VisualAge for Java - IDE 1 of 14 (English only) - REQUIRED. Das erste der beiden unbedingt benötigten Archive. Enthält die Basis für die IDE, Data Access
Beans für den Datenzugriff und den Visual Composition Editor.
v VisualAge for Java - IDE 2 of 14 (English only) - REQUIRED. Das zweite der
beiden unbedingt benötigten Archive. Enthält die Basis für die IDE, die ToolsAPI, den SmartGuide für Servlets und XML für Java-Parser.
v VisualAge for Java - IDE 3 of 14 (English only) - OPTIONAL. Erweiterte
Datenbankunterstützung (Stored Procedure Builder und SQLJ), EJB/JSPEntwicklungsumgebung, Persistence Builder, Externe Versionssteuerung, ET/400,
ET/390, Tivoli-Verbindung. HINWEIS: Dies ist erforderlich, wenn Sie den Transaction Access Builder installieren wollen
v VisualAge for Java - IDE 4 of 14 (English only) - OPTIONAL. Application Access
Builders (Domino, SAP R/3, C++), Transactions Access Builder (hierfür ist auch
Archivpaket 3, 5 und 6 erforderlich), XMI Toolkit, XML Generator, Domino
Agent Runner, IDL-Entwicklungsumgebung.
v VisualAge for Java - IDE 5 of 14 - OPTIONAL. e-Konnektoren. Wenn Sie dieses
Paket installieren, müssen Sie ebenfalls Paket 6 installieren. HINWEIS: Dies ist
erforderlich, wenn Sie den Transaction Access Builder installieren wollen
v VisualAge for Java - IDE 6 of 14 - OPTIONAL. e-Konnektoren. Wenn Sie dieses
Paket installieren, müssen Sie ebenfalls Paket 5 installieren. HINWEIS: Dies ist
erforderlich, wenn Sie den Transaction Access Builder installieren wollen
v VisualAge for Java - IDE 7 of 14 - OPTIONAL. Deployment Environments, Technology Previews, Merant(TM) DataDirect SequeLink Java Edition Version 5.1 für
Oracle und Microsoft SQLServer
v VisualAge for Java - IDE 8 of 14 - OPTIONAL. Portugiesisches (BR) und spanisches Sprachenpaket. Es enthält den portugiesischen (BR) und spanischen Text
für die IDE und ihre sämtlichen Komponenten.
v VisualAge for Java - IDE 9 of 14 - OPTIONAL. Französisches und italienisches
Sprachenpaket. Es enthält den französischen und italienischen Text für die IDE
und ihre sämtlichen Komponenten.
v VisualAge for Java - IDE 10 of 14 - OPTIONAL. Japanisches Sprachenpaket. Es
enthält den japanischen Text für die IDE und ihre sämtlichen Komponenten.
v VisualAge for Java - IDE 11 of 14 - OPTIONAL. Deutsches und koreanisches
Sprachenpaket. Es enthält den deutschen und koreanischen Text für die IDE und
ihre sämtlichen Komponenten.
v VisualAge for Java - IDE 12 of 14 - OPTIONAL. Sprachenpaket für vereinfachtes
und traditionelles Chinesisch. Es enthält den Text für die IDE und ihre sämtlichen Komponenten in vereinfachtem und traditionellem Chinesisch.
v VisualAge for Java - IDE 13 of 14 - OPTIONAL. J2EE-Komponenten (Java 2 Platform, Enterprise Edition) für den Transaction Access Builder. Enthält IBM Connectors und Tools für J2EE(TM) - Beta (erfordert Teil 4).
v VisualAge for Java - IDE 14 of 14 - OPTIONAL. Online-Dokumentation im PDFFormat.
32
Installations- und Migrationshandbuch
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:
1. Wenn Sie VisualAge für Java herunterladen und extrahiert haben, führen Sie
setup.exe aus, und wählen Sie Produkte installieren aus. Wählen Sie anschließend Distributed Debugger installieren aus.
2. Wenn Sie den Distributed Debugger ohne VisualAge für Java installieren wollen, öffnen Sie das folgende Verzeichnis von einer Eingabeaufforderung aus:
DebugDirectory\windows (hierbei ist DebugDirectory das Verzeichnis, in das Sie
den Distributed Debugger extrahiert haben), und führen Sie den folgenden
Befehl aus: setup.bat
VisualAge for Java - Distributed Debugger for AIX enthält die Debug-Maschine
für AIX. Führen Sie folgende Anweisungen aus, um sie zu installieren:
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die idebug.tar.Z vom Installationsdatenträger in Ihr Scratch-Verzeichnis.
3. Wechseln Sie in Ihr Scratch-Verzeichnis.
4. Dekomprimieren Sie die Datei idebug.tar.Z file, indem Sie den folgenden Befehl
eingeben: uncompress idebug.tar.Z
5. Extrahieren Sie die Installationsimages aus der Datei idebug.tar, indem Sie den
folgenden Befehl eingeben: tar -xvf idebug.tar
6. Geben Sie als Root-Benutzer den folgenden Befehl ein: installp -ac -X -V2 -g
-N -d idebug
7. Sie können für diesen befehl auch SMIT verwenden: smitty install_latest
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.
1. Erstellen Sie ein Scratch-Verzeichnis, beispielsweise /tmp/idebug
2. Kopieren Sie die Datei install.class in Ihr Scratch-Verzeichnis.
3. Öffnen Sie von einer Eingabeaufforderung aus Ihr Scratch-Verzeichnis. Hat Ihr
Scratch-Verzeichnis beispielsweise den Namen /tmp/idebug, müssen Sie den
Befehl cd /tmp/idebug eingeben, um es zu öffnen.
4. Geben Sie als Root-Benutzer den folgenden Befehl ein: java install.class
Installations- und Migrationshandbuch
33
VisualAge for Java - Distributed Debugger for Solaris enthält die Debug-Engine
für die Solaris-Betriebsumgebung. Um dieses Paket zu installieren, entpacken Sie
die Datei und befolgen Sie die folgenden Anweisungen.
1. Machen Sie ″dbgsetup″ zur ausführbaren Datei, indem Sie den folgenden befehl
ausführen: chmod +x dbgsetup
2. Geben Sie als Root-Benutzer den folgenden Befehl ein, um den Debugger zu
installieren: ./dbgsetup idebug.pkg
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.rpm
VisualAge 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
1. Installieren Sie den Distributed Debugger für Windows.
2. Befolgen Sie die Anweisungen in der Datei README_install.txt, die sich im
Basisinstallationsverzeichnis von Windows befindet.
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.
34
Installations- und Migrationshandbuch
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.
1. Bevor Sie mit der Installation von VisualAge für Java, Version 4.0 beginnen,
holen Sie bei Ihrem Administrator die folgenden Informationen ein:
v Den Host-Namen oder die IP-Adresse des Servers.
v Den Dateinamen des gemeinsam benutzten Repositorys. Der Dateiname lautet standardmäßig ivj.dat. Sie müssen Pfadinformationen angeben, wenn der
Administrator beim Starten des Servers die Position des Repositorys als
EMSRV-Arbeitsverzeichnis angibt.
v Ihren Repository-Benutzername. Sie müssen diesen Namen auswählen, wenn
Sie den VisualAge für Java-Client starten.
v Wenn der Kennwortschutz aktiviert ist, das Kennwort für diesen Eigner des
Arbeitsbereichs. (Standardmäßig ist der Kennwortschutz nicht aktiviert.)
2. Starten Sie die Installation von VisualAge für Java, Version 4.0. Einzelheiten zur
Installation sind im Abschnitt 2.0„B.2.0 Installation” auf Seite 27 enthalten.
Wenn Sie von einer früheren Version von VisualAge für Java migrieren, entnehmen Sie bitte dem Abschnitt 3.0 weitere Informationen über den Migrationsprozess.
3. Geben Sie an, dass Sie ein Repository verwenden möchten, das sich auf einem
Server befindet, wenn Sie vom Installationsprogramm dazu aufgefordert werden. Wenn Sie nicht nur als Client arbeiten wollen, der mit einem gemeinsam
benutzten Repository verbunden ist, sondern auf Ihrer Workstation auch ein
lokales Repository für das Arbeiten im Stand-Alone-Modus Workstation haben
möchten, lesen Sie die in Abschnitt 2.4 beschriebenen Alternativanweisungen.
Geben Sie den vom Administrator erhaltenen TCP/IP-Host-Namen (oder die
IP-Adresse) des Servers und den Repository-Namen an. Wenn der Administrator beim Starten des Programms EMSRV kein Arbeitsverzeichnis angab, müssen
Sie den vollständig qualifizierten Repository-Namen mit den Pfadinformationen
des Servers für diese Datei angeben. Das Installationsprogramm fügt in die
Datei ide.ini des Clients automatisch die Server-Adresse und Repository-Informationen ein.
Installations- und Migrationshandbuch
35
4. Sie werden aufgefordert, aus der vom Administrator erstellten Liste der Repository-Benutzer den Namen des Eigners eines Arbeitsbereichs auszuwählen.
Wählen Sie Ihren Benutzer-Namen aus. Wenn der Kennwortschutz aktiviert
wurde, müssen Sie auch das Kennwort des Benutzers angeben.
Eine Statusleiste zeigt an, dass der Arbeitsbereich mit dem Repository verbunden wird. Wenn anstatt einer Benutzerliste eine Fehlernachricht angezeigt wird,
die Sie darauf hinweist, dass ein nicht behebbarer Fehler aufgetreten ist, ist
möglicherweise eine der folgenden Situationen aufgetreten:
1. Der Server ist nicht aktiv.
2. Sie haben einen falschen Server-Namen bei der Installation von VisualAge
für Java auf Ihrer Workstation angegeben.
3. Sie haben einen falschen Repository-Namen während der Installation angegeben.
Sie können die Server- oder Repository-Informationen korrigieren, indem Sie
die Datei ide.ini auf dem Team-Client editieren.
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 TeamServer 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.
36
Installations- und Migrationshandbuch
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 KitArchiv automatisch gestartet wird.
Ausführliche Informationen zum IBM Developer Kit finden Sie in der READMEDatei im Verzeichnis ’IBM Developer Kit’.
B.3.0 Migration von einer früheren Version von VisualAge für
Java
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.
Installations- und Migrationshandbuch
37
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:
v Werden Sie Ihre vorhandenen Repositories weiter verwenden? Falls ja, haben Sie
zwei Möglichkeiten, die Migration durchzuführen.
– Sie können den Inhalt des Repositorys der Version 4.0 in Ihr vorhandenes
Repository migrieren. Hierdurch können Benutzer gemischter Entwicklungsumgebungen gleichzeitig auf dasselbe Repository zugreifen, auch wenn die
unterschiedlichen JDK-Stufen es möglicherweise verhindern, dass der gesamte
Code in gleicher Weise behandelt werden kann. Weitere Informationen hierzu
finden Sie in Teil C im Abschnitt 3.1.
– Sie können alternativ auch Ihr bisheriges Repository unverändert lassen und
das Repository der Version 4.0 zusätzlich zur separaten Verwendung installieren. In diesem Fall müssen Sie sich mit Punkten wie dualer Verwaltung und
der Planung der allmählichen, stufenweisen Migration Ihrer Benutzer auf das
Repository der Version 4.0 befassen.
v Von welcher Version von VisualAge für Java wollen Sie migrieren? Wenn Sie Ihr
auf JDK 1.1.x basierendes Repository aktualisieren wollen und Sie Ihre Anwendungen migrieren, so dass sie einwandfrei mit der Java 2-Plattform, v1.2.2 funktionieren, dann werden Ihre Anwendungen vermutlich nicht mehr auf v1.1.x der
Java-Plattform funktionieren. Beispielsweise befinden sich die Swing-Klassen in
J2SDK v1.2.2 in einem anderen Paket als in JDK v 1.1.x, d. h. Sie müssen die
Verweise auf Swing-Klassen in Ihren Anwendungen aktualisieren, wenn Sie
Anwendungen von 1.1.x auf 1.2.2 migrieren. Wenn Sie viele JDK-abhängige
Anwendungen haben, wollen Sie sie vielleicht lieber in separaten Repositories
belassen.
38
Installations- und Migrationshandbuch
v Wie viele Repositories sind bei der Migration betroffen? Sie müssen dabei alle
gemeinsam benutzten Repositories und die lokalen Repositories der Early Adopters-Umgebung der Version 3.5 oder der Version 3.5.3 berücksichtigen. Wenn N
Benutzer der Early Adopters-Umgebung der Version 3.5 oder der Version 3.5.3
lokale Repositories verwenden und daneben R Repositories gemeinsam benutzt
werden, müssen N + R Repositories migriert werden.
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.
1. Aktualisieren Sie EMSRV auf Version 7.1. Der Team-Administrator muss
EMSRV, Version 7.1 installieren. Informationen und Anweisungen hierzu finden
Sie in Teil C im Abschnitt 2„C.2.0 Installation” auf Seite 54.
2. Erstellen Sie Sicherungskopien Ihrer Benutzerdaten.
a. Versionieren Sie Ihre Projekte und Pakete. In das Repository von VisualAge
für Java, Version 4.0 können nur versionierte Projekte und Pakete importiert
werden. In der Online-Hilfe von VisualAge für Java sind Anweisungen zur
Versionierung enthalten.
b. Sichern Sie Ihr Repository an einer neuen Position außerhalb der
Verzeichnisstruktur von VisualAge für Java. Der Dateiname und -pfad des
Repositorys ist x:\IBMVJava\ide\repository\ivj.dat, wobei x:\IBMVJava das
Installationsverzeichnis von VisualAge für Java ist.
Hinweis: Wenn Sie von Version 3.5 oder Version 3.5.3 migrieren, enthält das
Repository auch versionierte Kopien Ihrer Projektressourcendateien, die sich
in folgendem Verzeichnis befinden: x:\IBMVJava\ide\repository\ivj.dat.pr.
Sie müssen eine Kopie des Verzeichnisses ’ivj.dat.pr’ außerhalb der
Verzeichnisstruktur von VisualAge für Java sichern.
3. Der Team-Administrator führt 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. Weitere Informationen und Anweisungen hierzu finden Sie in Teil B, Abschnitt 3.1.
4. Alle Benutzer der Version 3.5 oder 3.5.3 installieren nun ebenfalls Version 4.0
lokal, wodurch automatisch die N lokalen Repositories migriert werden.
Der Migrationsprozess ist nun abgeschlossen, und die Benutzer können nach
Wunsch zwischen einem lokalen und einem gemeinsam benutzten Repository hinund 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.
Installations- und Migrationshandbuch
39
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:
1. Installieren Sie VisualAge für Java, Version 4.0 vollständig mit einem lokalen
Repository. Informationen und Anweisungen hierzu finden Sie in Teil B im
Abschnitt 2.0„B.2.0 Installation” auf Seite 27.
2. Starten Sie die IDE Version 4.0. Sie werden mit dem lokalen Repository verbunden.
3. Wählen Sie in der Workbench Datei -> Exportieren, anschließend den Radioknopf Repository aus und klicken Sie danach Weiter an. Wählen Sie Gemeinsam benutztes Repository mit EMSRV-Server aus. Geben Sie die IP-Adresse
oder den Host-Namen des Servers in das Feld Gemeinsam benutztes Repository mit EMSRV - Server-Adresse ein.
4. Klicken Sie Durchsuchen an, um Ihr gemeinsam benutztes Repository zu lokalisieren oder geben Sie den Pfad und den Dateinamen manuell in das Feld
Name des Repositorys ein.
5. Wählen Sie Projekte aus. Klicken Sie Details an, um eine Liste der versionierten Projekte aufzurufen, die aus dem Quellen-Repository exportiert werden
können.
6. Wählen Sie alle Projekteditionen aus und exportieren Sie sie.
7. Klicken Sie Fertig stellen an.
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.
40
Installations- und Migrationshandbuch
B.4.0 Bekannte Probleme und Einschränkungen
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
v Führen Sie die Installation nicht auf einem HPFS-Netzlaufwerk oder auf einem
lokalen HPFS-Laufwerk aus, da Windows 98, Windows 2000 und Windows NT
4.0 auf HPFS Schwierigkeiten bei langen Dateinamen haben.
v Führen Sie die Installation nicht auf einem Novell NetWare-Laufwerk aus. Die
Installation auf einem Novell NetWare-Laufwerk schlägt fehl.
B.4.1.2 Benutzerberechtigung
v Sie müssen Schreibzugriff auf das Stammverzeichnis “\” des Laufwerks haben,
auf dem VisualAge für Java installiert ist, damit Sie den NetQuestion-Such-Server installieren können.
v Wenn Sie das Produkt unter Windows 2000 installieren, erhalten Sie möglicherweise eine Warnung, wenn Sie kein Administrator sind. Die Warnung besagt,
dass einige Programme nicht korrekt arbeiten, wenn sie nicht von einem Administrator installiert wurden. Sie sollten sich als Administrator anmelden, bevor
Sie mit der Installation von VisualAge für Java beginnen.
v Wenn ein normaler Benutzer versucht, VisualAge für Java, Version 4.0 unter
Windows 2000 zu installieren, kann fälschlicherweise ein “Fehler bei der SetupInitialisierung” mit folgendem Inhalt angezeigt werden: “Setup hat festgestellt,
dass unInstallShield bereits aktiv ist. Bitte schließen Sie unInstallShield und starten Sie Setup erneut. Fehler 432.” Bevor Sie versuchen, das Produkt erneut zu
installieren, stellen Sie sicher, dass Sie die Benutzerzugriffsrechte eines Administrators oder Hauptbenutzers haben.
v Wenn Sie bei der Installation unter Windows NT keine Administrator-Berechtigung haben, funktioniert die Suchfunktion der Online-Hilfe nicht.
B.4.1.3 TCP/IP-Voraussetzungen
v Wenn Sie die Warnung “Automatisch konfiguriert” vom Installationsprogramm
erhalten, bedeutet dies, dass die Proxy-Ausnahmebedingungen Ihres Browsers
automatisch konfiguriert wurden. Wenden Sie sich an den Systemadministrator,
um sicherzustellen, dass 127.0.0.1 als lokale Adresse interpretiert wird.
v Sie müssen TCP/IP installieren und konfigurieren, damit die Installation von
IBM VisualAge für Java ordnungsgemäß ausgeführt werden kann. Unter Windows 98 und Windows 2000 müssen Sie TCP/IP wie folgt aktivieren:
1. Bei einer LAN-Adapter-Konfiguration:
– DNS muss mit einem gültigen Host- und Domänennamen aktiviert sein.
– Ihr LAN DNS muss “localhost” als 127.0.0.1 auflösen.
– Sie können bei einer LAN-Adapter-Konfiguration das Programm nicht
ausführen, wenn die Verbindung nicht hergestellt ist.
Installations- und Migrationshandbuch
41
2. Bei einer Wahl-Adapter-Konfiguration:
– DNS muss inaktiviert sein.
– Ihre TCP/IP-Adresse muss automatisch abgerufen werden.
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:
1. Stellen Sie sicher, dass Sie über eine Notfalldiskette verfügen. Anweisungen zur
Erstellung einer solchen Diskette erhalten Sie in der Hilfedokumentation zum
Betriebssystem Windows.
2. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
3. Blenden Sie im Registrierungs-Editor alle Verzweigungen des folgenden Schlüssels ein:
\\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon
4. Wählen Sie den Namen shell im Name/Daten-Paar für den obigen Schlüssel
aus. Wichtig: Notieren Sie sich unbedingt die Daten für diesen Namen, da
diese nach dem Installieren von IBM VisualAge für Java benötigt werden.
5. Wählen Sie Bearbeiten -> Modifizieren in der Menüleiste für das
Name/Daten-Paar shell aus.
6. Setzen Sie den Wert für den SHELL-Namen auf Explorer.exe. Klicken Sie OK
an.
7. Wählen Sie Registrierung -> Beenden in der Menüleiste aus.
8. Starten Sie die Installation von IBM VisualAge für Java erneut und führen Sie
sie vollständig aus.
9. Wenn die Installation vollständig abgeschlossen ist, stellen Sie den vorherigen
Registrierungseintrag wie folgt wieder her:
a. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
b. Blenden Sie im Registrierungs-Editor alle Verzweigungen des Schlüssels
42
Installations- und Migrationshandbuch
\\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon ein.
c. Wählen Sie den Namen shell im Name/Daten-Paar für den obigen Schlüssel
aus.
d. Wählen Sie Bearbeiten -> Modifizieren in der Menüleiste für das
Name/Daten-Paar shell aus.
e. Stellen Sie als Wert für den SHELL-Namen den Wert wieder her, den Sie sich
in Schritt 4 notiert haben. Klicken Sie anschließend OK an.
f. Wählen Sie in der Menüleiste Registrierung -> Beenden 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:
1. Stellen Sie sicher, dass Sie über eine Notfalldiskette verfügen. Anweisungen zur
Erstellung einer solchen Diskette erhalten Sie in der Hilfedokumentation zum
Betriebssystem Windows.
2. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
3. Blenden Sie im Registrierungs-Editor alle Verzweigungen des folgenden Schlüssels ein, und wählen Sie ihn aus:
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows\4.0
4. Wählen Sie Bearbeiten -> Löschen in der Menüleiste für diesen Schlüssel aus.
5. Wählen Sie Ja aus, wenn Sie gefragt werden, ob dieser Schlüssel wirklich
gelöscht werden soll.
6. Wählen Sie in der Menüleiste Registrierung > Beenden aus.
Wenn vor dem Fehlschlagen der Installation bereits NetQuestion-Dateien installiert
wurden, müssen Sie diese ebenfalls löschen.
1. Öffnen Sie eine neue Eingabeaufforderung. Überprüfen Sie, ob irgendwelche
NetQuestion-Dateien installiert wurden, indem Sie an der soeben geöffneten
Eingabeaufforderung den folgenden Befehl eingeben: set imninstsrv. Mit diesem Befehl erhalten Sie die Position, an der NetQuestion auf Ihrer Maschine
installiert ist. Beispiel:
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.
Installations- und Migrationshandbuch
43
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.
2. Wechseln Sie in das NetQuestion-Verzeichnis (das nach IMNINSTSRV= angegeben ist).
3. Geben Sie vahcfg remove /p vj32 ein.
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.
44
Installations- und Migrationshandbuch
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:
1. Wählen Sie Start > Suchen > Dateien/Ordner aus, und suchen Sie in Ihrem
System nach der Datei sfc.dll.
2. Benennen Sie die Datei ’sfc.dll’ (die Version im Pfad (PATH) von Windows NT
4.0) vorübergehend in ’sfc.old’ um.
3. Installieren Sie VisualAge für Java.
4. Wenn Sie VisualAge für Java erfolgreich installiert haben, benennen Sie die
Datei ’sfc.old’ in ’sfc.dll’ um.
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:
1. Verlassen Sie gegebenenfalls die Installation.
2. Löschen Sie das folgende Verzeichnis: x:\Programme\Common
Files\InstallShield, wobei x das Laufwerk ist, auf dem Sie VisualAge für Java
eigentlich installieren wollten.
3. Installieren Sie das Produkt erneut.
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:
v Fehler 1631: The Windows Installer service failed to start. Contact your support
personnel (Der Windows Installer-Service wurde nicht gestartet. Wenden Sie sich
an die Benutzerunterstützung.)
v Interner Fehler 2755: Please contact product support for assistance. (Bitte wenden Sie sich an die Produktunterstützung.)
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.
Installations- und Migrationshandbuch
45
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:
v Sie installieren VisualAge für Java unter Windows NT 4.0
v Das Laufwerk mit dem Ordner ’winnt’ oder das Laufwerk, auf dem Sie VisualAge für Java installieren wollen, ist mit dem NTFS-Dateisystem formatiert
v Für diese Laufwerke sind keine gültigen Berechtigungen definiert
v Sie verfügen über Leseberechtigungen für das Verzeichnis, in dem Sie VisualAge
für Java installieren wollen
erhalten Sie möglicherweise eine oder mehrere der folgenden Fehlernachrichten:
v Interner Fehler 2381: Please contact product support for assistance. (Bitte wenden Sie sich an die Produktunterstützung.)
v Interner Fehler 1303: The Installer has insufficient privileges to access this directory: DirectoryName (Der Installer verfügt nicht über die entsprechenden Berechtigungen für den Zugriff auf dieses Verzeichnis: Verzeichnisname.)
v Interner Fehler 1310: Error attempting to create the destination file: FileName System error code: ErrorCode (this code varies depending on your problem) (Fehler
beim Erstellen der Zieldatei: Dateiname Systemfehlercode: Fehlercode (dieser Code
hängt vom entsprechenden Problem ab).)
v Interner Fehler 1315: The specified folder ’FolderName ’ is not writable. (Auf den
spezifische Ordner ’Ordnername’ besteht kein Schreibzugriff.)
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:
1. Wählen Sie in Windows Explorer das entsprechende Laufwerk bzw. Verzeichnis
aus.
2. Klicken Sie den Ordner mit der rechten Maustaste an, und wählen Sie anschließend die Option Eigenschaften im aufgerufenen Kontextmenü aus.
3. Wählen Sie die Indexzunge Sicherheit aus. Klicken Sie auf Berechtigungen.
4. Wählen Sie Jeder aus. Wählen Sie im Dropdown-Menü Zugriffsart die Option
Vollzugriff aus.
5. Wählen Sie das Markierungsfeld Berechtigungen für Unterverzeichnisse ersetzen aus.
6. Klicken Sie OK an.
7. Klicken Sie auf Ja, wenn Sie aufgefordert werden zu bestätigen, ob Sie die
Berechtigungen für alle Unterverzeichnisse ersetzen wollen.
8. Klicken Sie OK an.
9. Installieren Sie VisualAge für Java.
46
Installations- und Migrationshandbuch
Interner Fehler 2735 Engine-Start
Wenn Sie den Fehler 2735 erhalten, führen Sie folgende Schritte aus, um das Problem zu umgehen:
1. Suchen Sie in Ihrem Windows 32-Systemverzeichnis nach den folgenden
Dateien:
v shd401lc.dll
v shdoclc.dll
v shdoc401.dll
v shdocvw.dll
2. Benennen Sie shd401lc.dll in shd401lc.old um.
3. Benennen Sie shdoclc.dll in shdoclc.old um.
4. Wählen Sie Start > Ausführen aus, um den Dialog ’Ausführen’ zu öffnen. Führen Sie die folgenden Befehle aus, um die Registrierung dieser .dll-Dateien aufzuheben:
v regsvr32 /u shd401lc.dll
v regsvr32 /u shdoclc.dll
5. Registrieren Sie diese dlls, indem Sie die folgenden Befehle über den Dialog
’Ausführen’ ausführen:
v regsvr32 shdoc401.dll
v regsvr32 shdocvw.dll
6. Installieren Sie VisualAge für Java.
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:
1. Rufen Sie regedit.exe von einer Eingabeaufforderung aus auf.
2. Blenden Sie den folgenden Schlüssel ein und wählen Sie ihn aus:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Explorer\User Shell Folder
3. Wählen Sie Common Administrative Tools aus.
4. Wählen Sie Bearbeiten > Ändern aus.
5. Geben Sie in das Feld ’Wert’ Folgendes ein:
%SystemRoot%\Profiles\AllUsers\StartMenu\Programs\Administrative Tools.
6. Klicken Sie OK an.
7. Wählen Sie in der Menüleiste Registrierung > Beenden aus.
8. Installieren Sie VisualAge für Java.
Installations- und Migrationshandbuch
47
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:
1. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
2. Blenden Sie im Registrierungs-Editor alle Verzweigungen des folgenden Schlüssels ein, und wählen Sie ihn aus:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed
Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
3. Wählen Sie in der Menüleiste für diesen Schlüssel Bearbeiten > Löschen aus.
4. Wählen Sie Ja aus, wenn Sie gefragt werden, ob dieser Schlüssel wirklich
gelöscht werden soll.
5. Wählen Sie in der Menüleiste Registrierung > Beenden 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
48
Installations- und Migrationshandbuch
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:
1. Erstellen Sie eine Sicherungskopie der Datei autoexec.bat.
2. Stellen Sie fest, ob auf Ihrem System ein anderes Programm installiert ist, das
die HTML-Such-Engine benötigt (z. B. DB2). Gehen Sie dabei wie folgt vor:
a) Deinstallieren Sie VisualAge für Java, und starten Sie das System erneut.
b) Geben Sie regedit.exe in einer Eingabeaufforderung ein, und blenden Sie im
Registrierungs-Editor die Baumstruktur von
HKEY_LOCAL_MACHINE\SOFTWARE\ ein. Wenn sich in dieser Baumstruktur ein IBM Verzeichnis befindet, erweitern Sie es, um festzustellen, ob
sich dort ein NetQuestion-Verzeichnis befindet. Wenn ja, verwenden Sie die
Such-Engine wahrscheinlich mit einem anderen IBM Produkt.
3. Wenn Sie die HTML-Such-Engine nicht für ein anderes Produkt verwenden,
müssen Sie alle IMN- oder IMQ-Einträge in der Datei autoexec.bat entfernen,
bevor Sie VisualAge für Java erneut installieren.
4. Wenn Sie die HTML-Such-Engine für ein anderes Produkt verwenden, müssen
Sie alle Doppeleinträge hierfür in der Datei autoexec.bat löschen.
IMNINST
IMNINSTSRV
IMNNQ
IMNNQ_95
IMQCONFIGCL
IMQCONFIGSRV
Löschen Sie ebenfalls die doppelten Einträge der Zeile IF EXIST
X:\IMNNQ_95\IMNENV.BAT CALL IMNEV.BAT
5. Achten Sie dabei darauf, dass Sie nicht die Originaleinträge löschen. Wenn Sie
sich nicht sicher sind, welche Einträge die Originaleinträge sind, müssen Sie
feststellen, wo NetQuestion im System installiert ist. Führen Sie hierzu folgende
Schritte aus:
a. Geben Sie regedit.exe von einer Eingabeaufforderung aus.
b. Blenden Sie im Registrierungs-Editor alle Verzweigungen des Schlüssels
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\NetQuestion\Installation
Directory ein.
c. Der Verzeichniswert in diesem Schlüssel zeigt den Pfad an, wo NetQuestion
installiert ist. Bestimmte Umgebungsvariablen müssen dieses Verzeichnis als
Teil ihres Werts enthalten, damit NetQuestion einwandfrei funktioniert.
Wenn Sie eine der oben genannten Umgebungsvariablen finden, die als Teil
ihres Werts ein anderes Verzeichnis als das Verzeichnis in der Registrierung
enthält, müssen Sie diese Umgebungsvariable löschen.
Installations- und Migrationshandbuch
49
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 NetQuestionDateien zu entfernen. NetQuestion-Dateien von anderen Produkten (beispielsweise
DB2) sind davon nicht betroffen.
1. Um das NetQuestion-Verzeichnis zu ermitteln, geben Sie unter einer Eingabeaufforderung den Befehl set imninstsrv ein. Mit diesem Befehl erhalten Sie die
Position, an der NetQuestion auf Ihrer Maschine installiert ist. Beispiel:
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.
2. Wechseln Sie in das NetQuestion-Verzeichnis (das nach IMNINSTSRV= angegeben ist).
3. Geben Sie vahcfg remove /p vj32 ein.
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.
50
Installations- und Migrationshandbuch
Teil C: EMSRV
Informationen zur Installation des VisualAge für Java-Clients finden Sie in Teil B
dieses Handbuchs. Informationen zur Einrichtung und Verwaltung des Servers
sind im Abschnitt “Server-Einrichtung und -Verwaltung” in der Datei emsrv70.htm
(emsrv70.htm für alle Sprachen außer Englisch), enthalten, die Sie im Verzeichnis
TeamServer\docs auf der CD für zusätzliche Funktionen (Additional Features) finden. 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 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).
C.1.0 Voraussetzungen
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:
v Novell NetWare4.2
v Novell NetWare 5.1
v OS/2 (R) Warp Version 4.0
v OS/2 Warp Server für e-business
v
v
v
v
v
v
Windows NT (R) Workstation Version 4.0 (mit Service Pack 5) **
Windows NT Server Version 4.0 (mit Service Pack 5) **
Windows (R) 2000 Professional **
Windows 2000 Professional Server **
Windows 2000 Advanced Server **
Sun Solaris (TM) Version 2.6 (mit Patch 106757-05) +
v Sun Solaris Version 7.0
v HP-UX Version 10.20 *
v
v
v
v
v
HP-UX Version 11.0 *
AIX (R) Version 4.3.2
AIX Version 4.3.3
Red Hat Linux 6.1
Red Hat Linux 6.2
Installations- und Migrationshandbuch
51
* 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 (page 53).
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/cgibin/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 SMPHardware 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.
52
Installations- und Migrationshandbuch
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/pubcgi/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
v NWFS (NetWare File System) mit DOS Namespace
v NWFS mit OS/2 oder LONG Namespace
v NSS (Novell Storage Services) mit DOS Namespace
v NSS mit OS/2 oder LONG Namespace
OS/2
v HPFS (High-Performance File System)
v FAT
Windows NT und Windows 2000
v NTFS (New Technology File System)
v FAT32
v FAT
Solaris
v UFS (Unix File System)
Installations- und Migrationshandbuch
53
HP-UX
v VxFS (Veritas File System)
AIX
v JFS (Journaled File System)
Linux
v EXT2FS (Second Extended File System)
EMSRV unterstützt nur lokal angehängte Dateisysteme.
C.2.0 Installation
Dieser Kapitel enthält Anweisungen zur Installation des EMSRV-Repository-ServerProgramms 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:
v Der Pfad zu einem Repositorys, auf das über EMSRV für Windows NT zugegriffen wird, muss in der Befehlszeile als ein FAT-, NTFS- oder UNC-Pfad in Relation zum EMSRV-Arbeitsverzeichnis angegeben werden (dies bedeutet: wenn Sie
den Pfad für das Repository angeben, muss er mit dem EMSRV-Arbeitsverzeichnis beginnen). Der Zugriff auf Repositories, die sich auf einem fernen
Datenträger )also eine ferne Datenspeichereinheit) befinden, ist nicht möglich.
Beispiele hierfür sind Laufwerke, die mit Microsoft (R) Networking gemeinsam
benutzt werden und die sich auf anderen Maschinen befinden, sowie NetWareDatenträger, auf die über die Gateway- (und Client-) Services für NetWare zugegriffen werden kann.
v Wenn Sie mit EMSRV für Windows NT oder Windows 2000 arbeiten, können
lange Dateinamen auf FAT-, FAT32- und NTFS-Datenträgern erstellt und angezeigt werden. Im Gegensatz zu früheren FAT-Implementierungen bieten die Windows NT bzw. Windows 2000 FAT-Implementierungen nun Unterstützung für
lange Dateinamen. Die Unterstützung langer Dateinamen ist für das Feature der
gespeicherten Ressourcenverwaltung erforderlich, das von VisualAge für Java,
Version 4.0, verwendet wird.
54
Installations- und Migrationshandbuch
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:
1. Führen Sie im Verzeichnis ’TeamServer/Windows’ auf der CD für zusätzliche
Funktionen (Additional Features) die Datei ’setup.exe’ aus.
2. Befolgen Sie die Anweisungen auf dem Bildschirm. Wenn Sie dazu aufgefordert
werden, ein Installationsverzeichnis auszuwählen, wählen Sie ein Unterverzeichnis aus, das Bestandteil Ihres Pfades (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,
das Sie auswählen.
3. Extrahieren Sie aus der Datei ide.zip folgendes in das gewünschte Verzeichnis:
v ivj.dat (Repository-Datei)
v ivj.dat.pr, komplettes Verzeichnis (Projektressourcenverzeichnis)
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.
1. Wenn Sie die Kennwortüberprüfung durch Verwendung einer passwd.dat-Datei
aktivieren wollen, kopieren Sie die passwd.dat-Datei aus dem TeamServer-Verzeichnis in dasselbe Verzeichnis, in das Sie ivj.dat kopierten. Ausführliche Informationen zu den verfügbaren Arten der Kennwortüberprüfung sind im
Abschnitt “Server-Einrichtung und -Verwaltung” in der Datei emsrv70.htm
(emsrv70.htm für alle Sprachen außer Englisch), enthalten, die Sie im Verzeichnis TeamServer\docs finden.
Installations- und Migrationshandbuch
55
2. Überprüfen Sie, ob TCP/IP installiert und korrekt an einen LAN-Adapter
gebunden ist. Sie können die Bindung unter Verwendung des Dienstprogrammbefehls ping (beispielsweise ping IP adresse/host_name) prüfen, mit dem Sie von
einer Workstation im LAN mit dem Server kommunizieren können.
3. Fahren Sie mit der Installation von EMSRV in der Windows NT Registry (optional) fort, erteilen Sie dem EMSRV-Benutzer die erforderliche Berechtigung und
starten Sie EMSRV. Diese Themen werden im Abschnitt “Server-Einrichtung
und -Verwaltung” in der Datei emsrv70.htm (emsrv70.htm für alle Sprachen
außer Englisch) beschrieben.
C.2.1.1 Installation von EMSRV als einen Dienst in der Windows-Registrierung
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:
v Sie können das automatische Starten angeben. Auf diese Weise wird EMSRV
stets gestartet, wenn der Repository-Server gebootet wird.
v Sie können die Standardeinstellungen angeben, die EMSRV verwenden soll. Auf
diese Weise können Sie z. B. sicherstellen, dass die Kennwortgültigkeitsprüfung
stets aktiviert ist.
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.
56
Installations- und Migrationshandbuch
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:
1. Wechseln Sie von einer Eingabeaufforderung aus in das Verzeichnis, in dem das
ausführbare Programm EMSRV installiert ist.
2. Geben Sie den Befehl emsrv -install [parameter2] [parameter3] ... ein. Der
erste Parameter muss -install sein. Die übrigen Parameter sind die EMSRVStartparameter, die Sie für Ihre Umgebung auswählten.
Nachfolgend ein Beispiel für diesen Befehl:
emsrv -install -u joe -p donttell -W j:\sharedrep -rn
In diesem Beispiel wird EMSRV mit joe als EMSRV-Benutzername und
donttell als Kennwort von ’joe’ als Dienst in der Windows Registry installiert.
Standardmäßig ist j:\sharedrep das EMSRV-Arbeitsverzeichnis, und die native
Kennwortgültigkeitsprüfung wird erzwungen.
Eine Nachricht bestätigt, dass EMSRV installiert wurde.
3. Für den nächsten Schritt muss unter Windows NT bzw. Windows 2000 jeweils
unterschiedlich vorgegangen werden.
a) Klicken Sie unter Windows NT in der Systemsteuerung das Symbol Dienste
doppelt an. Das Dialogfenster Dienste wird angezeigt. Wählen Sie EMSRV aus
der Liste der Dienste aus.
b) Klicken Sie unter Windows 2000 in der Systemsteuerung das Symbol Verwaltung doppelt an. Klicken Sie das Symbol Dienste doppelt an. Klicken Sie
EMSRV doppelt an.
Sie können es von hier manuell starten. EMSRV ist jetzt als Dienst in der Registry installiert und die erforderlichen DLLs wurden in das Benutzerverzeichnis
kopiert.
Installations- und Migrationshandbuch
57
4. Geben Sie in das Textfenster für Startparameter die gewünschten EMSRV-Startparameter ein. Wenn sie das Arbeitsverzeichnis für EMSRV angeben, müssen
Sie für jeden umgekehrten Schrägstrich (“Backslash”) einen zusätzlichen Backslash angeben. Beispiel:
-u emsrvacc -p secret -W d:\\javateam
5. Klicken Sie Starten an. Eine Nachricht gibt nun an, dass EMSRV gestartet wird.
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 NetWare
EMSRV für Netware einrichten
Vor der Installation von EMSRV unter Netware sind folgende Einschränkungen zu
beachten:
v Wenn Sie mit EMSRV für NetWare arbeiten, können lange Dateinamen nur auf
solchen NetWare-Datenträgern erstellt und angezeigt werden, denen LONG
oder OS/2 Namespace hinzugefügt wurde. Die Unterstützung langer Dateinamen ist für das Feature der gespeicherten Ressourcenverwaltung erforderlich,
das von VisualAge für Java, Version 4.0, verwendet wird.
v EMSRV für NetWare erfordert, dass der NetWare TCP/IP-Stack (TCPIP.NLM)
geladen und auf dem Server konfiguriert ist. Wird EMSRV für NetWare gestartet, wird TCPIP.NLM automatisch geladen (wenn noch nicht bereits installiert).
Die NWSNUT.NLM-Dateien, die für die Benutzerschnittstelle von EMSRV für
NetWare erforderlich sind, werden ebenfalls automatisch geladen.
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:
1. Kopieren Sie die folgenden Dateien aus dem TeamServer\Netware-Verzeichnis
in das Verzeichnis SYS:\SYSTEM auf dem Server:
v emsrv.nlm
2. Extrahieren Sie aus der Datei ide.zip Folgendes in das Verzeichnis auf dem Server:
v ivj.dat (Repository-Datei)
v ivj.dat.pr, komplettes Verzeichnis (Projektressourcenverzeichnis)
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-
58
Installations- und Migrationshandbuch
.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.
1. Kopieren Sie die Beispiel-Kennwortdatei, passwd.dat, aus dem TeamServer-Verzeichnis in dasselbe Verzeichnis, in das Sie ivj.dat kopierten.
2. Überprüfen Sie, ob das NetWare-Datei TCPIP.NLM geladen und korrekt an
einen LAN-Adapter gebunden ist. Sie können die Bindung unter Verwendung
des Dienstprogrammbefehls ping (beispielsweise ping IP adresse/host_name) prüfen, mit dem Sie von einer Workstation im LAN mit dem Produkt kommunizieren können.
3. Um sicherzustellen, dass die Host-Namen bei der Abfrage von EMSRV in der
EMADMIN-Ausgabe angezeigt werden, überprüfen Sie, ob der Resolver ordnungsgemäß konfiguriert ist, um umgekehrte DNS-Suchfunktionen aktivieren
zu können. Stellen Sie ebenfalls sicher, dass die Datei RESOLV.CFG (unter
sys:\etc) ordnungsgemäß eingerichtet ist. Das folgende Beispiel zeigt, wie eine
Datei aufgebaut ist:
domain javadev.com
nameserver 192.168.73.150
4. Anweisungen zum Starten des Produkts 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.
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:
v Wenn Sie mit EMSRV für OS/2 arbeiten, können lange Dateinamen auf HPFSDatenträgern erstellt und angezeigt werden. Die Unterstützung langer Dateinamen ist für das Feature der gespeicherten Ressourcenverwaltung erforderlich,
das von VisualAge für Java, Version 4.0, verwendet wird.
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:
1. Kopieren Sie die folgenden drei Dateien aus dem TeamServer-Verzeichnis in
das gewünschte Verzeichnis auf dem OS/2-Computer:
v emsrv.exe
v emadmin.exe
v emclient.mod
Installations- und Migrationshandbuch
59
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.
2. Extrahieren Sie aus der Datei ide.zip folgendes in das Unterverzeichnis, in das
Sie die in Schritt 1 kopierten Dateien gestellt haben:
v ivj.dat (Repository-Datei)
v ivj.dat.pr, komplettes Verzeichnis (Projektressourcenverzeichnis)
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.
3. Wenn Sie die Kennwortüberprüfung durch Verwendung einer passwd.dat-Datei
aktivieren wollen, kopieren Sie die passwd.dat-Datei aus dem TeamServer-Verzeichnis in dasselbe Verzeichnis, in das Sie ivj.dat kopierten. Ausführliche Informationen zu den verfügbaren Arten der Kennwortüberprüfung sind im
Abschnitt “Server-Einrichtung und -Verwaltung” in der Datei emsrv70.htm
(emsrv70.htm für alle Sprachen außer Englisch), enthalten, die Sie im Verzeichnis TeamServer\docs finden.
4. Überprüfen Sie, ob TCP/IP installiert und korrekt an einen LAN-Adapter
gebunden ist. Sie können die Bindung unter Verwendung des Dienstprogrammbefehls ping (beispielsweise ping IP adresse/host_name) prüfen, mit dem Sie von
einer Workstation im LAN mit dem Server kommunizieren können.
5. Zum Starten des Servers befolgen Sie die Anweisungen zum Starten von
EMSRV unter OS/2 im Abschnitt “Server-Einrichtung und -Verwaltung” in der
Datei emsrv70.htm (emsrv70.htm für alle Sprachen außer Englisch).
60
Installations- und Migrationshandbuch
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:
v Unter AIX muss die Unterstützung großer Dateien aktiviert sein, und zwar für
den Datenträger, auf dem sich ein Repository befindet und für den Benutzer, der
den EMSRV-Prozess startet.
v Stellen Sie beim Erstellen eines Dateisystems sicher, dass das Argument ’-o
bf=true’ mit mkfs verwendet wird.
v Um die Begrenzungen für den Benutzer, der den EMSRV-Prozess startet, einzustellen, sind für die Optionen -Hf und -Sf für den Befehl ’ulimit’ Argumente
erforderlich, die die Anzahl an 512-Byte-Blöcken angeben. Mit den folgenden
Befehlen sollte es möglich sein, Repositories mit einer Größe von bis zu 16 GB
zu aktivieren:
ulimit -Hf 33554432
ulimit -Sf unlimited
v Die Authentifizierung von EMSRV für AIX wird mit der Funktion ’system
authenticate()’ implementiert. Dies ermöglicht es einer EMSRV-Executable
(emsrv), zusätzlich zur DCE-Authentifizierung sowohl gespiegelte als auch nichtgespiegelte Kennwörter zu unterstützen. Die Authentifizierungsmethode für die
jeweiligen Benutzer wird in der Datei ’/etc/security/user’ festgelegt.
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:
v emsrv
v emadmin
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:
1. Der EMSRV-Benutzer oder der Systemadministrator (root) muss Plattenspeicherplatz zum Speichern der Repositories reservieren.
2. Um ein Anfangs-Repository einzurichten, extrahieren Sie folgendes aus der
Datei ide.zip file in den in Schritt 1 reservierten Plattenspeicherplatz:
v ivj.dat (Repository-Datei)
v ivj.dat.pr, komplettes Verzeichnis (Projektressourcenverzeichnis)
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.
Installations- und Migrationshandbuch
61
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.
3. Ändern Sie den Dateieigner in den EMSRV-Benutzer oder den Systemadministrator. Wenn Sie planen, mit mehr als einem Repository zu arbeiten,
erstellen Sie Kopien von ivj.dat mit verschiedenen Namen; achten Sie jedoch
darauf, dass die Repository-Dateien das Suffix (.dat) beibehalten. Wenn Sie
Kopien des Repositorys erstellen, müssen Sie auch das Verzeichnis ivj.dat.pr
kopieren und den Verzeichnisnamen an den Namen der zugehörigen Repository-Kopie anpassen. Wenn Sie beispielsweise eine Kopie mit dem Namen “team.dat” erstellen, kopieren Sie das Projektressourcenverzeichnis und nennen Sie es
“team.dat.pr”.
Der EMSRV-Benutzer oder der Systemadministrator muss in das Verzeichnis
wechseln, in dem die Repositories gespeichert sind und das Programm EMSRV
mit den entsprechenden Befehlsoptionen starten. Ausführliche Informationen zu
den verfügbaren EMSRV-Befehlsoptionen sind im Abschnitt “Server-Einrichtung
und -Verwaltung” in der Datei emsrv70.htm (emsrv70.htm für alle Sprachen
außer Englisch), enthalten, die Sie im Verzeichnis TeamServer\docs finden.
4. Der EMSRV-Benutzer bzw. der Systemadministrator muss den Team-Mitgliedern die Position und den Namen des Team-Repositories mitteilen. Diese Informationen werden später benötigt, wenn Team-Mitglieder Ihren Client-Code
installieren.
5. Zum Starten des Servers befolgen Sie die Anweisungen im Abschnitt “ServerEinrichtung und -Verwaltung” in der Datei emsrv70.htm (emsrv70.htm für alle
Sprachen außer Englisch).
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.
62
Installations- und Migrationshandbuch
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
v Unter Solaris verfügen Dateisysteme automatisch über eine Unterstützung für
große Dateien. Begrenzungen für den Benutzer, der den EMSRV-Prozess startet,
müssen mit Hilfe des Befehls ’ulimit’ festgelegt werden. Die Optionen -Hf und
-Sf für den Befehl ’ulimit’ benötigen Argumente, die die Anzahl an 512-Byte-Blöcken angeben. Mit den folgenden Befehlen sollte es möglich sein, Repositories
mit einer Größe von bis zu 16 GB zu aktivieren:
ulimit -Hf 33554432
ulimit -Sf unlimited
v EMSRV für Solaris implementiert die Authentifizierung mit PAM. PAM muss auf
einer Maschine, die EMSRV ausführt, korrekt konfiguriert sein; andernfalls ist es
nicht in der Lage, EMSRV mit EMADMIN herunterzufahren. Die Datei
/etc/pam.conf file muss EMSRV als Service angeben, der PAM verwendet (er
muss als “emsrv” angegeben werden, nicht als “EMSRV”). Mit diesem Release
wird auch ein Beispiel einer pam.conf-Datei geliefert.
v
EMSRV erfordert einen gemeinsam benutzten Speicher von 4 Byte. Die Minimal- und Maximalgrößen von Blöcken an gemeinsam benutztem Speicher, den
ein Prozess anfordern kann, werden mit Hilfe von Betriebssystemeinstellungen
definiert. Beträgt die Maximaleinstellung weniger als 4 Byte bzw. beträgt die
Minimaleinstellung mehr als 4 Byte, kann EMSRV nicht ausgeführt und keine
Protokolldatei erstellt werden.
Für HP-UX
v Unter HP-UX muss die Unterstützung großer Dateien aktiviert sein, und zwar
für den Datenträger, auf dem sich ein Repository befindet und für den Benutzer,
der den EMSRV-Prozess startet.
v Stellen Sie beim Erstellen eines Dateisystems sicher, dass das Argument ’-o largefiles’ mit newfs verwendet wird.
v Um die Begrenzungen für den Benutzer, der den EMSRV-Prozess startet, einzustellen, sind für die Optionen -Hf und -Sf für den Befehl ’ulimit’ Argumente
erforderlich, die die Anzahl an 512-Byte-Blöcken angeben. Mit den folgenden
Befehlen sollte es möglich sein, Repositories mit einer Größe von bis zu 16 GB
zu aktivieren:
ulimit -Hf 33554432
ulimit -Sf unlimited
Installations- und Migrationshandbuch
63
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:
v emsrv
v emsrv.shadow
v emadmin
Für Solaris:
v emsrv
v emadmin
v pam.conf
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-UXMaschine einzurichten:
1. Der EMSRV-Benutzer oder der Systemadministrator (root) muss Plattenspeicherplatz zum Speichern der Repositories reservieren.
2. Um ein Anfangs-Repository einzurichten, extrahieren Sie folgendes aus der
Datei ide.zip file in den in Schritt 1 reservierten Plattenspeicherplatz:
v ivj.dat (Repository-Datei)
v ivj.dat.pr, komplettes Verzeichnis (Projektressourcenverzeichnis)
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.
64
Installations- und Migrationshandbuch
3. Ändern Sie den Dateieigner in den EMSRV-Benutzer oder den Systemadministrator. Wenn Sie planen, mit mehr als einem Repository zu arbeiten,
erstellen Sie Kopien von ivj.dat mit verschiedenen Namen; achten Sie jedoch
darauf, dass die Repository-Dateien das Suffix (.dat) beibehalten. Wenn Sie
Kopien des Repositorys erstellen, müssen Sie auch das Verzeichnis ivj.dat.pr
kopieren und den Verzeichnisnamen an den Namen der zugehörigen Repository-Kopie anpassen. Wenn Sie beispielsweise eine Kopie mit dem Namen “team.dat” erstellen, kopieren Sie das Projektressourcenverzeichnis und nennen Sie es
“team.dat.pr”.
Der EMSRV-Benutzer oder der Systemadministrator muss in das Verzeichnis
wechseln, in dem die Repositories gespeichert sind und das Programm EMSRV
mit den entsprechenden Befehlsoptionen starten. Ausführliche Informationen zu
den verfügbaren EMSRV-Befehlsoptionen sind im Abschnitt “Server-Einrichtung
und -Verwaltung” in der Datei emsrv70.htm (emsrv70.htm für alle Sprachen
außer Englisch), enthalten, die Sie im Verzeichnis TeamServer\docs finden.
4. Der EMSRV-Benutzer bzw. der Systemadministrator muss den Team-Mitgliedern die Position und den Namen des Team-Repositories mitteilen. Diese Informationen werden später benötigt, wenn Team-Mitglieder Ihren Client-Code
installieren.
5. Zum Starten des Servers befolgen Sie die Anweisungen im Abschnitt “ServerEinrichtung und -Verwaltung” in der Datei emsrv70.htm (emsrv70.htm für alle
Sprachen außer Englisch).
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.
Installations- und Migrationshandbuch
65
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:
v EMSRV für Linux implementiert die Authentifizierung mit PAM. Dadurch können sowohl gespiegelte als auch nicht-gespiegelte Kennwörter mit einer EMSRVExecutable unterstützt werden. Darüber hinaus unterstützt Red Hat Linux 6.2
MD5-Kennwörter, die auch von EMSRV über PAM unterstützt werden.
v PAM muss auf einer Maschine, die EMSRV ausführt, korrekt konfiguriert sein;
andernfalls ist es nicht in der Lage, EMSRV mit EMADMIN herunterzufahren.
Die PAM-Konfigurationsdatei muss in /etc/pam.d/emsrv kopiert werden. Mit
diesem Release wird auch ein Beispiel einer PAM-Konfigurationsdatei geliefert.
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:
v emsrv
v emadmin
v pam/emsrv
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:
1. Der EMSRV-Benutzer oder der Systemadministrator (root) muss Plattenspeicherplatz zum Speichern der Repositories reservieren.
2. Um ein Anfangs-Repository einzurichten, extrahieren Sie folgendes aus der
Datei ide.zip file in den in Schritt 1 reservierten Plattenspeicherplatz:
v ivj.dat (Repository-Datei)
v ivj.dat.pr, komplettes Verzeichnis (Projektressourcenverzeichnis)
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.
66
Installations- und Migrationshandbuch
3. Ändern Sie den Dateieigner in den EMSRV-Benutzer oder den Systemadministrator. Wenn Sie planen, mit mehr als einem Repository zu arbeiten,
erstellen Sie Kopien von ivj.dat mit verschiedenen Namen; achten Sie jedoch
darauf, dass die Repository-Dateien das Suffix (.dat) beibehalten. Wenn Sie
Kopien des Repositorys erstellen, müssen Sie auch das Verzeichnis ivj.dat.pr
kopieren und den Verzeichnisnamen an den Namen der zugehörigen Repository-Kopie anpassen. Wenn Sie beispielsweise eine Kopie mit dem Namen “team.dat” erstellen, kopieren Sie das Projektressourcenverzeichnis und nennen Sie es
“team.dat.pr”.
Der EMSRV-Benutzer oder der Systemadministrator muss in das Verzeichnis
wechseln, in dem die Repositories gespeichert sind und das Programm EMSRV
mit den entsprechenden Befehlsoptionen starten. Ausführliche Informationen zu
den verfügbaren EMSRV-Befehlsoptionen sind im Abschnitt “Server-Einrichtung
und -Verwaltung” in der Datei emsrv70.htm (emsrv70.htm für alle Sprachen
außer Englisch), enthalten, die Sie im Verzeichnis TeamServer\docs finden.
4. Der EMSRV-Benutzer bzw. der Systemadministrator muss den Team-Mitgliedern die Position und den Namen des Team-Repositories mitteilen. Diese Informationen werden später benötigt, wenn Team-Mitglieder Ihren Client-Code
installieren.
5. Zum Starten des Servers befolgen Sie die Anweisungen im Abschnitt “ServerEinrichtung und -Verwaltung” in der Datei emsrv70.htm (emsrv70.htm für alle
Sprachen außer Englisch).
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.
Installations- und Migrationshandbuch
67
C.3.0 Migration
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:
1. Erstellen Sie eine Sicherungskopie Ihres Repositorys.
2. Fahren Sie EMSRV 6.x/7.0 herunter.
3. Installieren Sie EMSRV 7.1.
4. Starten Sie EMSRV 7.1.
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.
C.4.0 Vorbereitungen für die Entwicklung im Team
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.
68
Installations- und Migrationshandbuch
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 JavaTeam-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„B.2.0 Installation” auf Seite 27 dieses Handbuchs.
Installations- und Migrationshandbuch
69
C.5.0 Einschränkungen und bekannte Probleme (EMSRV)
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 HochgeschwindigkeitsDSL-, 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/IPStapelspeichern 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.
70
Installations- und Migrationshandbuch
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’ angezeigt
EMSRV 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 nicht
Wenn 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.
Installations- und Migrationshandbuch
71
Teil D. Komponentenspezifische Migrationsinformationen
Bitte entnehmen Sie die zur Migration von Swing-Klassen wichtigen Informationen
dem Abschnitt 18.0.
D.1.0 CICS Transaction Server (CICS TS)
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.0 Data Access Beans für den Zugriff auf Daten
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.
72
Installations- und Migrationshandbuch
D.3.0 Data Access Builder
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.0 EJB(TM)-Entwicklungsumgebung
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:
1. Sichern Sie im Schema-Browser alle noch nicht gesicherten Schemas.
2. Sichern Sie im Zuordnungs-Browser alle noch nicht gesicherten Zuordnungen.
3. Wenn Sie seit der letzten Generierung von implementiertem Code noch
Änderungen an den Schemas oder Zuordnungen vorgenommen haben, löschen
Sie den implementierten Code, erstellen Sie ihn anschließend erneut und testen
Sie ihn dann.
4. Versionieren Sie die Pakete (einschließlich den Schema- und Zuordnungspaketen) und das Projekt, und exportieren Sie anschließend das Projekt im .datFormat.
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.
Installations- und Migrationshandbuch
73
Szenario 1 - Import aus einem Repository
Wenn Sie Ihre Beans aus einem Repository importieren, führen Sie die folgenden
Schritte aus:
1. Fügen Sie die Projekte mit den Enterprise-Beans, Schemas und Zuordnungen
aus dem Repository dem Arbeitsbereich hinzu. Neben einigen der geladenen
Klassen werden Fehlersymbole angezeigt.
2. Erstellen Sie von allen Projekten offene Editionen. Erstellen Sie ebenfalls von
allen Paketen, die alte generierte Klassen enthalten, offene Editionen.
3. Verwenden Sie den Schema- und den Zuordnungs-Browser, um alle verfügbaren Schemas und Zuordnungen zu laden. Generieren Sie anschließend die implementierten Klassen erneut.
4. Wenn Sie kein Schema und keine Zuordnung erstellt und gespeichert hatten,
erstellen Sie nun ein Standardschema und eine Standardzuordnung und generieren Sie Ihren implementierten Code erneut.
5. Wenn Sie planen, einzig und allein mit Version 4.0 zu arbeiten, löschen Sie die
vorhandenen EJB-Test-Client-Klassen auf der Seite Projekte, die Sie mit Hilfe
der EJB-Entwicklungsumgebung des Version 2.0, Enterprise Updates erstellt
haben. Diese Klassen enthalten Fehler und funktionieren in Version 4.0 nicht,
da der EJB-Test-Client generierte Klassen nicht länger verwendet. (Beachten Sie,
dass die Test-Client-Klassen nicht im Teilfenster EJB-Typen vor ihrer Löschung
angezeigt werden. Sie müssen also auf der Seite Projekte nachschauen, um festzustellen, ob Test-Client-Klassen zum Löschen vorhanden sind.)
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:
1. Wählen Sie auf der Seite EJB die Option EJB -> Enterprise Beans importieren
aus, um die JAR-Datei in Ihren Arbeitsbereich von VisualAge für Java, Version
4.0 zu importieren.
2. Da die JAR-Datei nicht die erforderlichen Zuordnungen enthält, werden neben
vielen der importierten Klassen Fehlersymbole angezeigt.
3. Generieren Sie die Schemas, Zuordnungen, implementierten Klassen und alle
verfügbaren Test-Clients neu.
4. Wenn Sie planen, einzig und allein mit Version 4.0 zu arbeiten, löschen Sie die
vorhandenen EJB-Test-Client-Klassen auf der Seite Projekte, die Sie mit Hilfe
der EJB-Entwicklungsumgebung des Version 2.0, Enterprise Updates erstellt
haben. Diese Klassen enthalten Fehler und funktionieren in Version 4.0 nicht,
da der EJB-Test-Client generierte Klassen nicht länger verwendet. (Beachten Sie,
dass die Test-Client-Klassen nicht im Teilfenster EJB-Typen vor ihrer Löschung
angezeigt werden. Sie müssen also auf der Seite Projekte nachschauen, um festzustellen, ob Test-Client-Klassen zum Löschen vorhanden sind.)
Weitere Informationen zum Ausführen dieser Schritte finden Sie in der VisualAge
für Java Online-Hilfe für die EJB-Entwicklungsumgebung.
74
Installations- und Migrationshandbuch
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:
1. Sichern Sie im Schema-Browser alle noch nicht gesicherten Schemas.
2. Sichern Sie im Zuordnungs-Browser alle noch nicht gesicherten Zuordnungen.
3. Wenn Sie seit der letzten Generierung von implementiertem Code noch
Änderungen an den Schemas oder Zuordnungen vorgenommen haben, löschen
Sie den implementierten Code, erstellen Sie ihn anschließend erneut und testen
Sie ihn dann.
4. Versionieren Sie die Pakete (einschließlich den Schema- und Zuordnungspaketen) und das Projekt, und exportieren Sie anschließend das Projekt im .datFormat.
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:
1. Importieren Sie die Projekt-Respository-Datei in den Arbeitsbereich.
2. Erstellen Sie eine offene Edition des Projekts. Erstellen Sie ebenfalls offene Editionen von allen Paketen, die implementierten Code enthalten, den Sie löschen
wollen.
3. Klicken Sie in der Workbench auf die Indexzunge EJB.
4. Wählen Sie im Teilfenster EJB die Enterprise-Bean oder Gruppe aus, deren
implementierten Code Sie löschen wollen.
5. Wählen Sie EJB > Löschen aus.
6. Klicken Sie auf Implementierter Code, um den implementierten Code zu
löschen.
7. Migrieren Sie Ihre Zuordnungen (falls vorhanden), indem Sie die Anweisungen in Abschnitt D.4.3 (beim Migrieren von Version 3.0) oder in Abschnitt
D.4.4 (beim Migrieren von Version 3.02) befolgen.
8. Stellen Sie sicher, dass Ihre Bean-Klasse und die übergeordneten Bean-Klassen
keine Fehler enthalten.
9. Generieren Sie Ihre EJB-Zugriffs-Beans (falls vorhanden) erneut, indem Sie die
folgenden Schritte ausführen:
a. Wählen Sie auf der EJB-Seite der Workbench die Enterprise-Bean aus, die
der zu migrierenden Access-Bean zugeordnet ist.
b. Wählen Sie im EJB-Menü die Option Hinzufügen> Access-Bean aus, um
den SmartGuide ’Eine Access-Bean erstellen’ zu öffnen. Klicken Sie
anschließend den Knopf Beenden an. Alle notwendigen Migrationsänderungen an der Access-Bean werden automatisch durchgeführt.
Installations- und Migrationshandbuch
75
10. Generieren Sie den implementierten Code erneut.
11. Wenn Sie planen, einzig und allein mit Version 4.0 zu arbeiten, löschen Sie die
vorhandenen EJB-Test-Client-Klassen auf der Seite Projekte, die Sie mit Hilfe
der EJB-Entwicklungsumgebung von Version 3.0 oder 3.02 erstellt haben. Diese
Klassen enthalten Fehler und funktionieren in Version 4.0 nicht, da der EJBTest-Client generierte Klassen nicht länger verwendet. Klasse(Beachten Sie,
dass die Test-Client-Klassen nicht im Teilfenster EJB-Typen vor ihrer Löschung
angezeigt werden. Sie müssen also auf der Seite Projekte nachschauen, um
festzustellen, ob Test-Client-Klassen zum Löschen vorhanden sind.)
12. Wenn Sie früher bereits Client-JAR-Dateien in VisualAge für Java, Version 3.0,
3.02 oder 3.5 erstellt haben, sollten Sie Ihre Client-JAR-Dateien in VisualAge
für Java, Version 4.0 neu erstellen.
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:
v Fügen Sie zu this._initLinks() in den Methoden ejbCreate (alle Varianten), ejbActivate und ejbLoad der Bean-Klasse einen Aufruf hinzu. Diesen Aufruf müssen
Sie auch allen zukünftigen Varianten von ejbCreate hinzufügen, die der BeanKlasse hinzugefügt werden.
v Fügen Sie zu this._removeLinks() in der Methode ejbRemove der Bean-Klasse
einen Aufruf hinzu.
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 EJBGruppe 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 AccessBeans 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.
76
Installations- und Migrationshandbuch
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.0 Enterprise Access Builder(EAB) und e-Konnektoren
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:
v Befehls-SmartGuide
v Befehlseditor
v Sitzungs-Bean-SmartGuide
v Sitzungs-Bean-Editor
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.
Installations- und Migrationshandbuch
77
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 JARDateien, 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 JARDateien, 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):
v ENCINA VAJ.RUL DELCon* copies failed
v ENCINA VAJ.RUL Deligh* copies failed
v ENCINA VAJ.RUL Drpc*
v ENCINA VAJ.RUL Transaction*
v HOD VAJ.RULcopy of file *.* failed
78
Installations- und Migrationshandbuch
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.
Installations- und Migrationshandbuch
79
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
1. Versionieren Sie alle Projekte der Version 3.x oder Version 3.5.x, die Konnektoren oder EAB-Code enthalten.
2. Exportieren Sie diese Projekte und alle zugehörigen Ressourcen in ein Verzeichnis außerhalb der Verzeichnisstruktur von VisualAge für Java.
3. Entfernen Sie alle diese Projekte aus dem Arbeitsbereich der Version 3.0x oder
3.5.x.
4. Entfernen Sie alle Features von CICS, Host-On-Demand, IBM Enterprise
Access Builder, Encina(R), IMS(TM) und MQSeries(R) aus dem Arbeitsbereich.
5. Verlassen Sie die IDE der Version 3.0x oder 3.5.x.
6. Deinstallieren Sie die Konnektoren für VisualAge für Java Version 3.0x oder
3.5.x. Gehen Sie dazu folgendermaßen vor:
a. Wählen Sie im Windows Startmenü Start -> Einstellungen -> Systemsteuerung aus.
b. Klicken Sie das Symbol Software doppelt an. Klicken Sie die Indexzunge
Installieren/Deinstallieren an, falls sie nicht schon zuoberst liegt.
c. Wählen Sie IBM Konnektoren aus und klicken Sie dann auf
Hinzufügen/Entfernen.
d. Bestätigen Sie, dass Sie die Konnektoren und die zugehörigen Komponenten deinstallieren wollen.
e. Klicken Sie im Fenster zum Entfernen von Programmen auf OK.
7. 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:
80
Installations- und Migrationshandbuch
Windows NT und Windows 2000
a. Wählen Sie Start -> Einstellungen -> Systemsteuerung aus.
b. Klicken Sie das Symbol System doppelt an. Wählen Sie die Indexzunge
Umgebung aus.
c. Löschen Sie in CLASSPATH, PATH und NLS PATH alle Verweise auf IBM
Konnektoren oder IBM\Connectors.
Windows 98
a. Erstellen Sie eine Sicherungskopie der Datei c:\autoexec.bat
b. Geben Sie an einer Eingabeaufforderung folgendes ein: edit c:\
autoexec.bat
c. Löschen Sie in den Anweisungen SET CLASSPATH, SET PATH und SET
NLS PATH alle Verweise auf IBM Konnektoren oder IBM\Connectors.
8. Installieren Sie VisualAge für Java, Version 4.0.
9. Fügen Sie dem Arbeitsbereich der Version 4.0 die gewünschten Features von
CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina, IMS und
MQSeries hinzu.
10. Importieren Sie Ihre Projekte in den Arbeitsbereich der Version 4.0, um die
Migration Ihres in 1.1.x erstellten Codes abzuschließen. Wenn Sie den SAP
R/3 Access Builder und Konnektor verwenden, lesen Sie hierzu bitte die Hinweise weiter unten.
11. Sie können VisualAge für Java, Version 3.0x oder 3.5.x, deinstallieren, nachdem Sie allen Code, den Sie beibehalten wollen, auf VisualAge für Java 4.0
migriert haben.
Wenn Sie die SAP-Konnektoren verwenden, müssen Sie die Klassen, die mit VisualAge für Java, Version 3.0x oder 3.5.x, erstellt wurden, erneut generieren.
Der Access Builder und der Konnektor für SAP R/3 stellen ebenfalls einige UtilityKlassen (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
1. Installieren Sie VisualAge für Java, Version 4.0, jedoch ohne den Enterprise
Access Builder for Transactions:
a. Installieren Sie VisualAge für Java, Version 4.0. Befolgen Sie die Anweisungen auf dem Bildschirm.
b. Wählen Sie auf der Seite ’Setup-Typ’ die Option Angepaßt aus. Klicken Sie
Weiter an.
c. Wählen Sie alle Komponenten aus, die Sie installieren wollen. Wählen Sie
jedoch nicht den Transactions Access Builder aus. Klicken Sie auf Weiter,
wenn Sie alle gewünschten Komponenten zur Installation ausgewählt
haben. Wenn Sie nach versuchter Installation des Transactions Access Builders zum Installationsfenster zurückgeführt werden und Sie nicht die Konnektoren installieren wollen, wählen Sie das Markierungsfeld Transactions
Access Builder ab und klicken Sie auf Weiter.
Installations- und Migrationshandbuch
81
d. Befolgen Sie die weiteren Anweisungen auf dem Bildschirm, um die Installation abzuschließen.
Sie können die Konnektoren für VisualAge für Java Version 3.0x oder Version 3.5.x nun weiter verwenden.
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:
1. Installieren Sie VisualAge für Java, Version 4.0. Befolgen Sie die Anweisungen
auf dem Bildschirm.
2. Wählen Sie in der Seite für Programmpflege Ändern aus. Klicken Sie Weiter
an.
3. Wählen Sie Transaction Access Builder aus. Klicken Sie auf Weiter und befolgen Sie die Anweisungen auf dem Bildschirm, um die Komponente zu installieren.
4. Fügen Sie der VisualAge für Java IDE die Konnektoren hinzu. Weitere Informationen und Anweisungen hierzu finden Sie in der Online-Hilfe.
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.
1. Versionieren Sie alle Projekte der Version 3.5 oder 3.5.3, die Konnektoren oder
EAB-Code enthalten.
2. Exportieren Sie diese Projekte und alle zugehörigen Ressourcen in ein Verzeichnis außerhalb der Verzeichnisstruktur von VisualAge für Java.
3. Löschen Sie diese Projekte aus dem Arbeitsbereich der Version 3.5 oder 3.5.3.
4. Entfernen Sie alle Features von CICS, Host-On-Demand, IBM Enterprise Access
Builder, Encina, IMS und MQSeries aus dem Arbeitsbereich.
5. Verlassen Sie die IDE der Version 3.5 oder 3.5.3.
6. Deinstallieren Sie die Konnektoren für VisualAge für Java Version 3.5 oder
3.5.3. Gehen Sie dazu folgendermaßen vor:
a. Wählen Sie im Windows Startmenü Start -> Einstellungen -> Systemsteuerung aus.
b. Klicken Sie das Symbol Software doppelt an. Klicken Sie die Indexzunge
Installieren/Deinstallieren an, falls sie nicht schon zuoberst liegt.
c. Wählen Sie IBM Konnektoren aus. Klicken Sie dann auf
Hinzufügen/Entfernen.
82
Installations- und Migrationshandbuch
d. Bestätigen Sie, dass Sie die Konnektoren und die zugehörigen Komponenten
deinstallieren wollen.
e. Klicken Sie im Fenster zum Entfernen von Programmen auf OK.
7. 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
a. Wählen Sie Start -> Einstellungen -> Systemsteuerung aus.
b. Klicken Sie das Symbol System doppelt an. Wählen Sie die Indexzunge
Umgebung aus.
c. Löschen Sie in CLASSPATH, PATH und NLS PATH alle Verweise auf IBM
Konnektoren oder IBM\Connectors.
Windows 98
a. Erstellen Sie eine Sicherungskopie der Datei c:\autoexec.bat
b. Geben Sie an einer Eingabeaufforderung folgendes ein: edit c:\
autoexec.bat
c. Löschen Sie in den Anweisungen SET CLASSPATH, SET PATH und SET
NLS PATH alle Verweise auf IBM Konnektoren oder IBM\Connectors.
8. Installieren Sie VisualAge für Java, Version 4.0.
9. Fügen Sie dem Arbeitsbereich der Version 4.0 die gewünschten Features von
CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina, IMS und
MQSeries hinzu.
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
1. Wählen Sie Start -> Einstellungen -> Systemsteuerung aus.
Klicken Sie das Symbol System doppelt an. Wählen Sie die Indexzunge Umgebung aus.
3. Löschen Sie in CLASSPATH, PATH und NLS PATH alle Verweise auf IBM
Konnektoren oder IBM\Connectors.
2.
Windows 98
1. Erstellen Sie eine Sicherungskopie der Datei c:\autoexec.bat
2. Geben Sie an einer Eingabeaufforderung folgendes ein: edit c:\ autoexec.bat
3. Löschen Sie in den Anweisungen SET CLASSPATH, SET PATH und SET NLS
PATH alle Verweise auf IBM Konnektoren oder IBM\Connectors.
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.
Installations- und Migrationshandbuch
83
D.6.0 Enterprise Toolkit für AS/400 (ET/400)
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 OnlineHilfe.
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 JFormattedTableBeans 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.
84
Installations- und Migrationshandbuch
D.7.0 Enterprise Toolkit für OS/390 (ET/390)
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:
v Interpretierte Anwendungen, die unter WebSphere Application Server, Version
3.0, mit SDK 1.1.8 ausgeführt werden. In dieser Umgebung können Sie Ihre
Anwendungen erstellen, exportieren, ausführen und debuggen.
v Eigenständige interpretierte Anwendungen, die unter OS/390 mit SDK 1.3.0 ausgeführt werden. In dieser Umgebung können Sie Ihre Anwendungen erstellen,
exportieren und ausführen.
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-
Installations- und Migrationshandbuch
85
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:
v Interpretierte und kompilierte Transaktionen unter CICS Transaction Server, Version 1.3, mit SDK 1.1.8
v Kompilierte gespeicherte Prozeduren unter DB2 Universal Database, Versionen 5
und 6, mit SDK 1.1.8
v Eigenständige interpretierte Anwendungen unter OS/390 mit SDK 1.1.8
D.8.0 Enterprise Toolkit für Workstations (ET/WS)
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 JavaMaschine (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.
D.9.0 Externe Versionskontrolle
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.
86
Installations- und Migrationshandbuch
D.10.0 IDL-Entwicklungsumgebung
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.
D.11.0 Integrierte Entwicklungsumgebung (Integrated Development Environment - IDE)
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.
D.12.0 EJB-Entwicklungsumgebung (EJB Development Environment)
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:
v ide\project_resources\IBM WebSphere Test
Environment\hosts\default_host\default_app\servlets\default_app.webapp
v ide\project_resources\IBM WebSphere Test
Environment\properties\default.servlet_engine
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.
Installations- und Migrationshandbuch
87
D.13.0 Migrationsunterstützung für ActiveX
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.
D.14.0 Persistence Builder
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:
1. Versionieren Sie alle Projekte, die für Ihre Persistence Builder-Anwendungen
erforderlich sind.
2. Nachdem Sie Ihren Code auf VisualAge für Java, Version 4.0, migriert haben,
fügen Sie Ihre Projekte dem Arbeitsbereich der Version 4.0 hinzu. Sie werden
dabei Probleme bei den Service-Klassen feststellen, da einige Umsetzer nicht
mehr in VisualAge für Java enthalten sind. Um diese Probleme zu beheben,
generieren Sie die “Daten-Service-Klassen und -Schnittstellen” für Ihr Objektmodell. Die Probleme werden dann von den Codegenerierungsservices gelöst.
3. Die Superklasse für Umsetzer wurde in das Projekt “VisualAge Persistence
Common Runtime” verschoben. Sie müssen die Superklasse Ihrer Composer in
com.ibm.vap.converters.VapAbstractConverter ändern.
4. Die Composer-Superklasse wurde ebenfalls in ein neues Projekt verschoben. Sie
müssen die Superklasse Ihrer Composer in com.ibm.vap.composers.VapAttributeComposer ändern.
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.
88
Installations- und Migrationshandbuch
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:
1. Wählen Sie die gewünschte Klasse aus.
2. Wählen Sie aus dem Menü Ausgewählt oder dem Kontextmenü für die Klasse
die Option Ausführen und anschließend Klassenpfad prüfen aus.
3. Klicken Sie den Knopf Jetzt ermitteln neben dem Markierungsfeld für den
Projektpfad aus.
4. Um die neu bestimmten Pfadeinstellungen zu sichern, wählen Sie das
Markierungsfeld Im Repository sichern (als Standard) aus. Wenn Sie die Einstellung sichern, wird eine neue Edition der Klasse erstellt.
5. Klicken Sie OK an.
D.15.0 RMI Access Builder
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.
1. Wählen Sie Datei -> Importieren aus.
2. Wählen Sie den Radioknopf Jar-Datei aus.
3. Geben Sie den Pfad und den Namen der Laufzeit ein:
x:\IBMJava\eab\runtime\ivjrmi.zip, wobei x:\IBMJava\ das Installationsverzeichnis von Version 3.0x ist.
4. Wählen Sie das Markierungsfeld .class aus. Wenn das Markierungsfeld für Ressourcen ausgewählt ist, nehmen Sie die Auswahl zurück.
Installations- und Migrationshandbuch
89
5. Geben Sie in das Feld Projekt IBM Enterprise RMI Access Builder Library ein.
6. Klicken Sie Fertigstellen an.
7. Falls das Projekt IBM Enterprise RMI Access Builder Libary noch nicht existiert, werden Sie aufgefordert, es zu erstellen.
8. Stellen Sie sicher, dass das Projekt Ihrem Arbeitsbereich hinzugefügt wird. Wird
es in Ihrem Arbeitsbereich nicht angezeigt, wechseln Sie zum Repository Explorer, und wählen Sie das Projekt aus, um es hinzuzufügen.
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.
1. Versionieren Sie Ihre RMI Access Builder-Klassen und Laufzeitbibliothekprojekte in Ihrer alten Version von VisualAge für Java. Sie können die Klassen
einfach als .java-Klassen beibehalten.
2. Importieren Sie sie in die IDE der Version 4.0, indem Sie die folgenden Schritte
ausführen:
v Wählen Sie in der Workbench Datei > Importieren aus.
v Wählen Sie den Radioknopf für Verzeichnis oder Repository aus.
v Geben Sie den Namen des Verzeichnisses oder Repositorys ein, in dem Sie
Ihre Anwendungen gespeichert haben.
v Wählen Sie den Typ der zu importierenden Dateien aus und importieren Sie
sie.
v Vergessen Sie nicht, alle für Ihr RMI-Projekt benötigten Projektressourcen in
das Projektressourcenverzeichnis der Version 4.0 kopieren, falls Sie dies noch
nicht getan haben. Erstellen Sie nun eine offene Edition des Projekts und versionieren Sie die Edition. In Version 4.0 von VisualAge für Java werden die
zugehörigen Projektressourcen automatisch versioniert, sobald Sie ein Projekt
versionieren.
Wenn Sie eines Ihrer Server-Objekte ausführen wollen, müssen Sie zuerst einen Server-Hauptanschluss erstellen. Wenn Sie beispielsweise einen server-seitigen ServerProxy 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.”);
}
}
90
Installations- und Migrationshandbuch
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.
D.16.0 Visual Composition Editor
Um Metadaten für visuell zusammengesetzte Beans zu reparieren, müssen Sie das
IDE-Migrations-Tool verwenden. In der Online-Hilfedatei “Richtlinien für Klassenoder 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:
Installations- und Migrationshandbuch
91
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.
D.17.0 Servlet Builder und Servlet Launcher
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 WebBrowser 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:
v Sie importieren Ihre Anwendung nicht in VisualAge für Java, Version 4.0, sondern führen mit einem Migrationshilfsprogramm ein Upgrade auf J2SDK v1.2.2
durch und implementieren sie uf dem Websphere-Anwendungs-Server. Diese
Option wird in Szenario 1 erläutert.
v Sie importieren Ihre Anwendung in VisualAge für Java, Version 4.0, migrieren
sie mit dem SmartGuide Fix installieren/Migrieren auf J2SDK v1.2.2, modifizieren sie manuell, kompilieren Sie in der WebSphere Unit-Testumgebung, exportieren die Anwendung und implementieren sie auf dem WebSphere-Anwendungsserver. Diese Option wird in Szenario 2 erläutert.
92
Installations- und Migrationshandbuch
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.
1. Exportieren Sie Ihren Anwendungscode aus Ihrer früheren Version von VisualAge für Java in ein Verzeichnis oder ein Repository außerhalb der VAJVerzeichnisstruktur.
2. Verwenden Sie ein Dienstprogramm wie das WoodenChair’s “Utility+ JDK
Standard Edition”, um Ihren Java-Code auf J2SDK v1.2.2 zu migrieren (d. h.
um Pakete umzubenennen, Änderungen in den Abhängigkeiten zu behandeln
usw.). Weitere Informationen zu diesem Produkt und seinem Leistungsspektrum finden Sie auf der Web-Site von WoodenChair unter
http://www.woodenchair.com/
3. Kompilieren Sie alle .java-Klassendateien und JAR-Dateien mit J2SDK v1.2.2.
Die Laufzeit-JAR-Datei des Servlet Builders 4.0 muss im Kompilierungsklassenpfad angegeben sein.
4. Implementieren Sie Ihren Code auf dem Websphere-Anwendungs-Server. Die
Laufzeit-JAR-Datei des Servlet Builders 4.0 muss sich im Stammverzeichnis des
WebSphere-Anwendungs-Servers befinden oder im Klassenpfad des Servers
angegeben sein.
5. Wenn Sie weitere Änderungen vornehmen wollen, beginnen Sie erneut bei
Schritt 1 und wiederholen Sie die übrigen Schritte, soweit erforderlich.
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:
1. Importieren Sie die Laufzeit-JAR-Datei des Servlet Builders 4.0 in VisualAge für
Java, Version 4.0.
2. Importieren Sie das Projekt, mit dem Sie arbeiten wollen, in den Arbeitsbereich
von VisualAge für Java 4.0.
3. Reparieren Sie mit dem SmartGuide Fix installieren/Migrieren im Code alle
unterbrochenen Referenzen.
4. Modifizieren Sie den Code manuell entsprechend Ihren Erfordernissen und testen Sie ihn in der WebSphere Unit-Testumgebung.
5. Exportieren Sie das Projekt in eine Jar-Datei.
6. Implementieren Sie Ihren Code auf dem Websphere-Anwendungs-Server. Die
Laufzeit-JAR-Datei des Servlet Builders 4.0 muss sich im Stammverzeichnis des
WebSphere-Anwendungs-Servers befinden oder im Klassenpfad des Servers
angegeben sein.
Weitere Informationen zum Ausführen dieser Schritte finden Sie in der OnlineHilfe von VisualAge für Java.
Installations- und Migrationshandbuch
93
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 WebAnwendungen 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:
1. Erstellen Sie eine Java-Bean für die Geschäftslogik der Anwendung.
2. Führen Sie den SmartGuide aus, um das Servlet, JSP und das HTML-Formular
zu erstellen.
3. Testen Sie das Servlet in VisualAge für Java.
4. Setzen Sie die Entwicklung des Servlets in VisualAge für Java fort.
5. Passen Sie die JSP- und HTML-Dateien in WebSphere Studio oder ähnlichen
Tools an.
94
Installations- und Migrationshandbuch
D.18.0 Swing-Klassen
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 SwingReferenzen 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 SwingAnwendungsklassen 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:
1. Öffnen Sie die Klassen erneut im VCE Ihrer früheren Version von VisualAge für Java.
2. 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.
3. Speichern Sie die Klasse und importieren Sie sie erneut in Version 4.0 IDE.
D.19.0 XMI Toolkit
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 VorBeta-Release 1.2 sind mit keinem der 3.5- oder 3.5.x-Releases des XMI Toolkit kompatibel.
Installations- und Migrationshandbuch
95
Teil E: Allgemeine Informationen
E.1.0 Arbeiten mit Projektressourcen und Ressourcenverwaltung
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.
1. Stellen Sie sicher, dass Sie alle alten Projektressourcendateien in das Projektressourcenverzeichnis von Version 4.0 kopiert haben.
2. Importieren Sie die Projekte aus dem Repository in den Arbeitsbereich.
3. Erstellen Sie von jedem Projekt eine neue offene Edition. Sie können nur offenen Editionen von Projekten neue Ressourcen hinzufügen.
4. Versionieren Sie das Projekt, wodurch alle Ressourcen freigegeben werden.
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.
E.2.0 Migration von OS/2 und AIX
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.
96
Installations- und Migrationshandbuch
Szenario 1
Wenn Ihr OS/2-Repository ivj.dat sich auf derselben Maschine, wie der WindowsClient befindet:
1. Erstellen Sie eine Sicherungskopie des alten Repositorys ivj.dat. Das Repository
wird nach der Installation von Windows 98 Windows NT bzw. Windows 2000
und VisualAge für Java, Version 4.0 zu einem späteren Zeitpunkt zurückgeschrieben. Falls sich das Repository auf einer von OS/2 verwalteten FAT-Partition befindet und Sie Windows 98/NT/2000 auf derselben Maschine installieren und die FAT-Partition beibehalten wollen, brauchen Sie keine
Sicherungskopie des Repositorys zu erstellen. Es wird jedoch empfohlen, dennoch eine Sicherungskopie des Repositorys zu erstellen, falls bei der Installation
von Windows Probleme auftreten.
2. Installieren Sie Windows 98, Windows NT oder Windows 2000. Wird auf Ihrer
Maschine OS/2 ausgeführt, kann Windows mit Hilfe der Dual-Boot-Option auf
derselben Maschine installiert werden, um die vorhandene OS/2-Installation
beizubehalten.
3. Installieren Sie VisualAge für Java, Version 4.0.
4. Schreiben Sie das Repository in eine Partition auf einer lokalen Festplatte
zurück, auf die die neue Windows-Installation Zugriff hat. Falls sich das Repository zuvor auf einer von OS/2 verwalteten FAT-Partition befand und diese
Partition weiterhin existiert, brauchen Sie das Repository nicht zurückzuschreiben.
5. Stellen Sie eine Verbindung zu dem alten Repository her (Enterprise) oder
importieren Sie aus dem alten Repository (Professional). Sie sollten alle alten
Projektressourcen in das Projektressourcenverzeichnis von Version 4.0 kopieren.
Szenario 2
Ihr OS/2- oder AIX-Repository ivj.dat befindet sich auf einer anderen Maschine,
als der Windows-Client:
1. Ihre OS/2- oder AIX-Maschine muss über das mit VisualAge für Java, Version
4.0 bereitgestellte EMSRV-Repository-Programm (Version 7.1) verfügen. Sie können grundsätzlich Verbindungen zu Repositories herstellen, die mit VisualAge
für Java Version 3.02 oder früher verwendet wurden. Um von Version 4.0 eine
Verbindung zu einem alten Repository herzustellen, benötigen Sie jedoch unbedingt EMSRV Version 7.1.
2. Der Windows-Client, auf dem Sie VisualAge für Java, Version 4.0, ausführen,
stellt die Verbindung zu dem OS/2 oder AIX-Server wie erforderlich her. Sie
sollten alle alten Projektressourcen in das Projektressourcenverzeichnis von Version 4.0 kopieren.
E.3.0 Neue Sicherheitseinschränkungen in J2SDK v1.2.2
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.
Installations- und Migrationshandbuch
97
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.
E.4.0 Neues Tool zur externen Versionssteuerung (ersetzt
externes SCM-Tool)
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.
E. 5.0 Arbeiten mit ORBs (Object Request Broker) anderer
Hersteller in VisualAge für Java
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.
98
Installations- und Migrationshandbuch
E.6.0 Inhalt der CD für zusätzliche Funktionen (Additional Features)
Die CD für zusätzliche Funktionen (Additional Features) von VisualAge für Java
enthält Folgendes:
v IBM Connectors und Tools für J2EE(TM) - Beta
v Team-Server
v Distributable Run-Times
v IBM Developer Kit 1.2.2
v Merant DataDirect SequeLink Java Edition Version 5.1 für Oracle und Microsoft
SQLServer
v Distributed Debugger
v Technologische Vorabinformationen (Technology Previews)
– IBM Stored Procedure Integration Tool for Enterprise JavaBeans
– XMI Bridge
v Druckbare Dokumentation
v Handbuch zur Fehlerbehebung im Hilfesystem
v Ressourcen und Sicherungskopie des Repositorys
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:
v Distributable Run-Times
v IBM Developer Kit 1.2.2
v
v
v
v
Distributed Debugger
Druckbare Dokumentation
Handbuch zur Fehlerbehebung im Hilfesystem
Ressourcen und Sicherungskopie des Repositorys
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:
v J2EE-Konnektor für CICS
v J2EE-Konnektor für SAP R/3
v J2EE-Konnektor für PeopleSoft
v J2EE-Konnektor für J.D. Edwards OneWorld.
v J2EE-Konnektor für Oracle Applications/Financials
v J2EE-Konnektor für IMS (verfügbar auf http://www.ibm.com/vadd)
v J2EE-Konnektor für HOD (verfügbar auf http://www.ibm.com/vadd)
Installations- und Migrationshandbuch
99
v Tools zum Importieren von Datenstrukturen, die sich auf Anwendungs-Servern
von JD Edwards, PeopleSoft und Oracle befinden
v Tools zum Generieren J2EE-konformer Datensätze
v Tools zum Erstellen und Bearbeiten J2EE-konformer Befehle
v Tools zum Erstellen und Bearbeiten J2EE-konformer EAB-Sitzungs-Beans
v Tools zum Migrieren vorhandener EAB-Anwendungen in die J2EE-basierte
Architektur. Diese Tools migrieren Datensätze, Befehle und Navigatoren.
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 J2EEKomponenten 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 “ServerEinrichtung 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.
100
Installations- und Migrationshandbuch
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:
Java-Compiler
Konvertiert Java-Quellcode in Java-Bytecodes, die später mit dem Java
Interpreter ausgeführt werden können.
Java-Klassenbibliotheken (Class Libraries)
Stellen alle Java-Standardklassen zur Verfügung, sodass Ihre Java-Anwendungen bestehende Java-Objekte erstellen und erweitern können.
Java Applet Viewer
Stellt eine Methode zum Ausführen eines Applets über die Eingabeaufforderung zur Verfügung.
Java Documentation Generator
Generiert die Dokumentation der Toolkit-API (Anwendungsprogrammierschnittstelle, Application Programming Interface) aus Java-Programmen mit
ordnungsgemäßen Kommentaren.
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 OracleDatenbankzugriff.
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.1Server kommunizieren, während Sie den Client zusammen mit der WebSphereTestumgebung oder dem WebSphere-Anwendungsserver verwenden. Der Merant
DataDirect SequeLink Java Edition Version 5.1-Server ist kein vollständig lizenzierter Server.
Installations- und Migrationshandbuch
101
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).
v Enterprise JavaBeans (EJB)
v Persistence Builder
v Data Access Beans
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 DebuggerDateien 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.
102
Installations- und Migrationshandbuch
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-ibmivj-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.
Installations- und Migrationshandbuch
103
Anhang A: Ein Vergleich der Komponenten für den Datenzugriff
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 EnterpriseBeans 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 Topdown (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
v Abschnitt 1.0 - Verwendung von Tabellen und Sichten
v Abschnitt 2.0 - Verwendung angepaßter Abfragen
v Abschnitt 3.0 - Verwendung gespeicherter Prozeduren
104
Installations- und Migrationshandbuch
Code-Generierung
v Abschnitt 4.0 - CRUD Operationen gegen Objekte und Unterstützung für gespeicherte Prozeduren
v Abschnitt 5.0 - Unterstützung für angepaßte Abfragen
Teil 2: Laufzeit-Features
v Abschnitt
nen
v Abschnitt
v Abschnitt
v Abschnitt
1.0 - Unterstützung für Datensammlungen (DataStore) und Transaktio2.0 - API LOB Unterstützung
3.0 - Schnellformulare
4.0 - Unterstützung für aktuelle(s) Datum/Zeit/Zeitmarke
v Abschnitt 5.0 - Unterstützung für Cursor
v Abschnitt 6.0 - Asynchrone Ausführung und Hinweise zu gemeinsamem Zugriff
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.
Teil 1: Features für die Zuordnung Objekt-zu-Relational
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:
Installations- und Migrationshandbuch
105
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.
106
Installations- und Migrationshandbuch
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.
Installations- und Migrationshandbuch
107
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.
1. Importieren Sie das Schema mit dem Schema-Browser.
2. Öffnen Sie den Modell-Browser und erstellen Sie das Objekt-Modell, dem die
Tabellen zugeordnet werden.
3. Wenn das Modell vollständig ist, öffnen Sie den Zuordnungs-Browser und
erstellen Sie eine neue DataStore-Zuordnung. Wählen Sie das Schema und das
bereits erstellte Modell aus.
4. Wählen Sie eine Modellklasse aus und fügen Sie eine neue Tabellenzuordnung
hinzu, indem Sie Neue Tabellenzuordnung > Tabellenzuordnung ohne Vererbung hinzufügen... auswählen.
5. Um weitere Verknüpfungstabellen hinzuzufügen, wählen Sie Neue Tabellenzuordnung > Sekundäre Tabellenzuordnung hinzufügen... aus. Nachdem die
Tabellen hinzugefügt wurden, ordnen Sie die individuellen Attribute zu, indem
Sie den Editor für Eigenschaftszuordnung für jede Tabellenzuordnung öffnen.
108
Installations- und Migrationshandbuch
6. Ordnen Sie die Attribute den Tabellenspalten zu, ordnen Sie die übrigen
Tabellenspalten nicht zu. Im Zuordnungs-Browser werden die Eigenschaftszuordnungen entsprechend der einzelnen Tabellen im vierten Teilfenster angezeigt.
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.
Installations- und Migrationshandbuch
109
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;
}
110
Installations- und Migrationshandbuch
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.
1. Wählen Sie im Fenster des Data Access Builders im Kontextmenü einer Bean
die Option Methoden aus. Fügen Sie eine neue Methode mit dem Namen
addCustomer1 hinzu.
2. 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.
Installations- und Migrationshandbuch
111
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 ServiceEngine 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;
112
Installations- und Migrationshandbuch
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 LiteCollection 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()) {
Installations- und Migrationshandbuch
113
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.
114
Installations- und Migrationshandbuch
Teil 2: Laufzeit-Features
Unterstützung für Datensammlungen (DataStore) und Transaktionen
Im Data Access Builder
Datensammlungen können im Data Access Builder auf verschiedenen
Anwendungsebenen konfiguriert werden:
v Die Anwendungsdatensammlung (Application Datastore) wird als Standarddatensammlung verwendet, die von allen Business-Klassen genutzt werden
kann, für die keine eigene Datensammlung definiert wurde
v Die Standardklassendatensammlung (Default Class Datastore) gibt auf Klassenebene an, welche Datensammlung die einzelnen Exemplare verwenden.
v Die Datensammlung des Objekts (Object’s Datastore) gibt die Datensammlung
auf Exemplarebene an.
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 WebSphereVerbindungs-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.
Installations- und Migrationshandbuch
115
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 VerwaltungsObjekte 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();
116
Installations- und Migrationshandbuch
Code-Beispiel: Einen Mitarbeiter suchen und dessen Telefonnummer ändern
Employee anEmp =
new Employee();
anEmp.setEmpno
(“000130”);
anEmp.retrieve();
anEmp.setPhoneno
(“555-9988”);
anEmp.update();
anEmp.getDefault
Datastore().
commit();
EmployeeHome aHome =
EmployeeHome.singleton();
Employee anEmp =
aHome.find(“000130”);
anEmp.setPhoneno(“5559988”);
Transaction.
getCurrent().commit();
Retrieve all employees:
aSelectBean.execute();
positionToEmployee
(“000130”);
// User written method
// to position to
//correct row
aSelectBean.
setColumnValue
(“PhoneNo”, “555-9988”);
aSelectBean.updateRow();
aSelectBean.commit();
// If connection is not
//autoCommit=true
Retrieve result set with
only one employee row.
aSelectBean.setParameter
(“EmployeeID”, “000130”);
aSelectBean.execute();
aSelectBean.setColumnValue
(“PhoneNo”, “555-9988”);
aSelectBean.updateRow();
aSelectBean.commit();
// If connection is not
//autoCommit=true
(*)Aktualisierungsoperationen werden durch Änderung der Werte eines BusinessObjekts 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 LOBDatentypen. 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.
Installations- und Migrationshandbuch
117
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:
v Cache-Unterstützung für Ergebnismengen
v Direktzugriff auf bestimmte Zeilen im Cache
v Blättern (vorwärts und rückwärts)
v Unterstützung für große Ergebnismengen mit benutzerdefinierten Optionen
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 SelectBean 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.
v Unterstützung für update/insert/delete-Aktionen in der Ergebnismenge
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.
118
Installations- und Migrationshandbuch
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.
v Non-locking Repeatable Read (nicht sperrendes wiederholbares Lesen)
v Non-locking Unrepeatable Read (nicht sperrendes nicht wiederholbares Lesen)
v Locking Repeatable Read (sperrendes wiederholbares Lesen)
v Locking Unrepeatable Read (sperrendes nicht wiederholbares Lesen).
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.
Teil 3: Data Access Beans (DAB)-Funktionen
Die Zuordnung für Data Access Beans (DAB) wird zwischen Tabellen und SelectBeans vorgenommen. Diese Zuordnung zwischen einer Tabelle und einer SelectBean 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.
Installations- und Migrationshandbuch
119
Sie können mit Datenbanken interagieren, indem Sie die Eigenschaft query (die aus
Verbindungsinformationen und SQL-Abfrageinformationen besteht) einer SelectBean 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:
1. Öffnen Sie im VCE eine Klasse, wählen Sie eine Select-Bean aus und öffnen Sie
den Editor für die Eigenschaft query.
2. Geben Sie die erforderlichen Verbindungsinformationen ein und generieren Sie
eine Datenbankzugriffsklasse.
3. Spezifizieren Sie die Datenbankzugriffsklasse. Öffnen Sie den SmartGuide
SQL-Assistent.
4. Das Auswählen der Kundentabelle und das Angeben der Bedingung der
Kundennummer (cusno) entspricht genau der Funktion des Parameters CUSTNUM. Mit ihm wird eine Select-Bean für den Kunden generiert. Die
Datenbankzugriffsklasse für diese Select-Bean würde in etwa folgendermaßen
aussehen:
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).
120
Installations- und Migrationshandbuch
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.
Installations- und Migrationshandbuch
121
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.
122
Installations- und Migrationshandbuch
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.
Installations- und Migrationshandbuch
123
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.
124
Installations- und Migrationshandbuch
Bemerkungen
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 Produkte, Programme und Dienstleistungen in dieser
Veröffentlichung bedeuten nicht, dass IBM diese in allen Ländern, in denen IBM
vertreten ist, anbietet. 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.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM
Patente oder Patentanmeldungen geben. Mit der Auslieferung dieses Handbuchs
ist keine Lizenzierung dieser Patente verbunden. Lizenzanfragen sind schriftlich an
folgende Adresse zu richten:
IBM Europe
Director of Licensing
92066 Paris La Defense
Cedex,
France
Anfragen an obige Adresse sind auf englisch zu formulieren.
125