Fujitsu Technology Solutions BeanConnect Version 2.1A März 2009

Freigabemitteilung Alle Rechte vorbehalten, insbesondere gewerbliche Schutzrechte. Änderung von technischen Daten sowie Lieferbarkeit vorbehalten. Haftung oder Garantie für Vollständigkeit, Aktualität und Rich-tigkeit der angegebenen Daten und Abbildungen ausgeschlossen. Wiedergegebene Bezeichnungen können Marken und/oder Urheberrechte sein, deren Benutzung durch Dritte für eigene Zwecke die Rechte der Inhaber verletzen kann.

Weitere Einzelheiten unter http://ts.fujitsu.com/terms_of_use.html

Copyright © Fujitsu Technology Solutions 2009

1

Freigabemitteilung BeanConnect V2.1A 1 Allgemeines 2

1.1 Bestellung 41.1.1 Nutzungsrechte 4

1.2 Auslieferung 41.3 Dokumentation 5

2 Software-Erweiterungen 62.1 Neue Funktionen in BeanConnect V2.1A 62.2 Realisierte Change Requests 15

3 Technische Hinweise 163.1 Ressourcenbedarf 163.2 SW-Konfiguration 173.3 Produkt-Installation 19

3.3.1 Update Installation 193.3.2 Kernel Tuning 193.3.3 Java und SELinux 193.3.4 Installation unter Solaris 20

3.4 Produkt-Einsatz 203.5 Entfallene und gekündigte Funktionen 203.6 Inkompatibilitäten 213.7 Einschränkungen 253.8 Verhalten im Fehlerfall 25

4 Hardware-Unterstützung 26

2

1 Allgemeines Gegenstand dieser Freigabemitteilung ist das Produkt BeanConnect V2.1A40. BeanConnect ist eine standardisierte Adapter Implementierung nach JCA 1.5 (Java Connector Architecture), die es ermöglicht Daten zwischen J2EE Application Servern wie z.B. Oracle Application Server und EIS Systemen (Enterprise Information System) auszutau-schen. In BeanConnect V2.1A40 ist die Anbindung von openUTM-Anwendungen und CICS-Anwendungen als EIS-Systeme realisiert. BeanConnect V2.1 unterstützt verschiedene Kommunikations-richtungen. Es erlaubt Outbound-Kommunikation, d.h. die Kommuni-kation wird vom Application Server initiiert, und Inbound-Kommunikation, d.h die Kommunikation wird von einer EIS Anwendung initiiert. Die Kommunikation kann transaktional und nicht-transaktional er-folgen. Bei der Outbound-Kommunikation mit openUTM-Anwendungen gibt es wiederum zwei Kopplungsmöglichkeiten: - Kopplung mit Protokoll OSI TP - Kopplung mit Protokoll UPIC. Bei der Inbound-Kommunikation gibt es ebenfalls mehrere Kopp-lungsmöglichkeiten: - Kopplung mit Protokoll OSI TP - Kopplung mit Protokoll UPIC - Kopplung mit UTM Socket Protokoll - Kopplung mit RFC1006 Protokoll. Die Kommunikation zur CICS-Anwendung erfolgt sowohl für Outbound- als auch für Inbound-Kommunikation über das Protokoll LU6.2. BeanConnect V2.1A40 besteht aus folgenden Komponenten: - BeanConnect Resource Adapter : Diese Komponente stellt die JCA Schnittstelle (JCA 1.5) für den Anwender zur Verfügung. Sie ist im Application Server eingebettet (deployed) und läuft als Bestandteil des Application Servers. - BeanConnect Proxy : Diese Komponente ist auf Basis von openUTM - der universelle Transaktionsmonitor von Fujitsu Technology Solutions - realisiert. Sie stellt die transaktionale Verbindung zwischen dem Resource Adapter im Application Server auf der einen und der openUTM-Anwendung bzw. CICS Anwendung auf der anderen Seite her. Bei Verbindungen zu CICS-Anwendungen wird der LU62-Stack vom openUTM-LU62 Gateway zur Ver- fügung gestellt.

- BeanConnect Management Console : Diese Komponente ist das Java GUI zur Konfiguration und Administration des BeanConnect Proxy.

3

- BeanConnect Tools : Cobol2Java BeanConnect Clients mit BS2000/OSD*)-Cobol-Anwendungen

unterstützt und vereinfacht die Kommunikation von

Management Console Command Handler Management Console weitere Komponenten (z.B. openUTM-LU6.2

(MCCmdHandler) hilft der

Gateways, Communication Services, Proxies), die nicht auf dem gleichen Rechner wie die Management Console laufen, zu ver- walten BPEL GUI PartnerLinks

ist ein BPEL-WSDL-Generator zur Erzeugung von BPEL-

Hinweis: Bei der Outbound-Kommunikation mit Protokoll UPIC wird nur die Komponente Resource Adapter benötigt. Der BeanConnect Proxy und die BeanConnect Management Console werden hierfür nicht benötigt. Zusätzlicher Bestandteil des Lieferumfangs von BeanConnect V2.1A sind die Java Klassen openUTM-JConnect V2.1A zum Zugriff auf openUTM Server-Applikationen auf Basis des UPIC Protokolls. Zu openUTM-JConnect V2.1A gibt es eine separate Freigabemittei-lung. Weitere Informationen zu BeanConnect finden Sie unter: http://de.ts.fujitsu.com/products/software/openseas/beanconnect.html Die Freigabemitteilung wird als readme-Datei mit ausgeliefert. Nachträglich bekannt gewordene Änderungen werden in dieser Datei aktualisiert. Diese Freigabemitteilung sowie die Freigabemitteilung zu openUTM-JConnect sind auch über das Internet verfügbar. http://de.ts.fujitsu.com/products/software/openseas/beanconnect.html Für BeanConnect V2.1A40 existieren zweierlei Lizenzen. Die Lizenz BeanConnect V2.1 for openUTM berechtigt zur Kommunika-tion mit openUTM-Anwendungen. Die Lizenz BeanConnect V2.1 for CICS berechtigt zur Kommunikation mit CICS-Anwendungen. Für die Kommunikation zu beiden EIS-Partnern müssen beide Lizen-zen vorhanden sein. Die Wiedergabe von Namen, Warenbezeichnungen und dgl. in dieser Information berechtigt nicht zu der Annahme, dass diese Namen/ Bezeichnungen ohne weiteres von jedermann benutzt werden dürfen; oft handelt es sich um gesetzlich oder vertraglich geschützte Namen/Bezeichnungen, auch wenn sie nicht als solche gekennzeichnet sind. Werden mit dem Einsatz der vorliegenden Produktversion eine oder mehrere Vorgängerversionen übersprungen, so sind auch die Hinwei-se aus den Freigabemitteilungen (bzw. readme-Dateien) der Vorgän-gerversionen zu berücksichtigen. ________________ *) BS2000/OSD (R) ist eine Marke der Fujitsu Technology Solutions

4

1.1 Bestellung BeanConnect V2.1A kann über Ihre zuständige Vertriebsgesell-schaft bezogen werden. Für BeanConnect V2.1A gelten die allgemeinen Bedingungen zum Vertrag über die Nutzung und Betreuung von Software-Produkten. Bestandteile des Produkts sind: . Nutzungsrechte . Datenträger mit Software . Handbuch 1.1.1 Nutzungsrechte - Informationen über die Nutzungsrechte sind im Datenblatt ersichtlich. Das Datenblatt ist im Internet verfügbar. Link BeanConnect in http://de.ts.fujitsu.com/products/software/openseas/beanconnect.html - PCMX: Die Nutzung ist lizenzfrei. Das mit BeanConnect ausgelieferte PCMX darf nur zusammen mit BeanConnect V2.1A verwendet werden. - openUTM: Die Nutzung ist lizenzfrei. Das mit BeanConnect ausgelieferte openUTM darf nur zusammen mit BeanConnect V2.1A verwendet werden. - openUTM-LU62: Die Nutzung ist lizenzfrei. Das mit BeanConnect ausgelieferte openUTM-LU62 darf nur zusammen mit BeanConnect V2.1A ver- wendet werden. 1.2 Auslieferung Die Software wird über eine DVD bereitgestellt. Zusätzlich erhalten Sie auf dieser DVD folgendes Handbuch : BeanConnect V2.1

5

1.3 Dokumentation Das Handbuch zu BeanConnect V2.1 ist als Online-Manual unter http://manuals.ts.fujitsu.com verfügbar. Nach der Installation steht im JavaDoc Verzeichnis des BeanConnect Resource Adapters eine Java-Dokumentation zur Verfügung (siehe Handbuch "BeanConnect V2.1", Kapitel "BeanConnect installieren"). Die BeanConnect Management Console und das BPEL GUI enthalten ein Online-Hilfe-System. Änderungen, die sich ggf. nach Redaktionsschluss des Handbuchs zu BeanConnect ergeben haben, finden Sie im BeanConnect Installati-onsverzeichnis unter docs/Deutsch/man01-de.pdf auf Solaris/Linux docs\Deutsch\man01-de.pdf auf Windows

6

2 Software-Erweiterungen Im Folgenden werden nur die Erweiterungen bzw. Verbesserungen ge-genüber der Vorgängerversion BeanConnect V2.0A beschrieben. 2.1 Neue Funktionen in BeanConnect V2.1A - RA – gemeinsame Variante UTM & CICS In BeanConnect V2.0 gab es zwei Varianten des Resource Adapters. Mit der einen Variante konnte mit EIS Partnern vom Typ UTM kommuniziert werden, mit der anderen mit EIS Partnern vom Typ CICS. Ab BeanConnect V2.1 gibt es nur noch eine Variante des Resource Adapters mit der mit beiden Typen von EIS Partnern kommuniziert werden kann. Da es bei der Outbound Kommunikation bzgl. des Encodings und der Transaktionsbeendigung Unter- schiede zwischen den beiden Partner Typen gibt, muss deshalb zukünftig bei der Angabe der Connection URL der Partner Typ angegeben werden. Bisher wurde für die Connection URL der (neutrale) Präfix „oltp://“ verwendet. Ab BeanConnect V2.1 werden die neuen Präfixe „utm://“ und „cics://“ eingeführt, wobei der bisherige Präfix „oltp://“ synonym zu „utm://“ interpretiert wird. D.h. die Definition von CICS Partnern in der Connection URL ist inkompatibel und muss angepasst werden. Für die Inbound Kommunikation gibt es für EIS Partner CICS folgende Inkompatibilität bzgl. der ActivationSpec eines Message Endpoint. In BeanConnect for CICS V2.0 war der Default Wert für Encoding jdk:Cp1047 und encodingActive = true. Ab BeanConnect V2.1 ist der Default Wert für Encoding leer und encodingActive = false. - Installation des Resource Adapters mit IzPack In BeanConnect V2.0 wird der Resource Adapter durch Auspacken eines jar-Archivs installiert. Ab BeanConnect V2.1 erfolgt die Installation mit dem Tool IzPack. Dadurch ist zum einen möglich Parameter für die Konfiguration bereits bei der Installation anzugeben und zum anderen kann der Installationsumfang an die lokale Plattform angepasst werden. - RA – mehrere RA pro Proxy (Outbound) Die strenge Kopplung zwischen einem Resource Adapter und einem Proxy Container wird dahingehend aufgehoben, dass mehreren Resource Adaptern per Konfiguration derselbe Proxy Container zugewiesen werden kann. Analog zu einer Cluster Konfiguration wird für alle Resource Adapter, die demselben Proxy Container zugewiesen sind, eine identische Liste von Resource Adapter Adressen generiert. Zusätzlich besitzt jeder dieser Resource Adapter die gleiche Proxy URL. Damit mehrere RA mit demselben Proxy Container kommunizieren können, müssen dort auch die Userids entsprechend generiert werden. Deshalb wird empfohlen die Zuweisung mehrerer RAs zu einem Proxy Container über die Management Console vorzunehmen. - Separater TA und Reply Timer Bei Inbound Kommunikation können der Timer für Transaktionen und der Reply Timer separat eingestellt werden.

7

- RA – Event CONNECTION_ERROR_OCCURED Ab BeanConnect V2.1 erzeugt der Resource Adapter bei Fehlern in der Kommunikation zwischen dem Resource Adapter und dem Proxy Container, sowie zwischen Proxy Container und EIS, die ein Weiterarbeiten mit dieser Connection nicht sinnvoll erscheinen lassen, das Event CONNECTION_ERROR_OCCURRED. Als Folge davon zerstört der Application Server die Connection (destroy). - RA – Meldung an ApplicationServer LogWriter Ab BeanConnect V2.1 wird der Resource Adapter bei gewissen Ereignissen über den ApplicationServer LogWriter eine Meldung absetzen, damit dieses Ereignis zusammen mit anderen Ereignissen des Application Servers im AS spezifischen Protokoll enthalten ist. Es gibt drei Klassen von Ereignissen: - Fehler Ereignisse - Transaktions Ereignisse - Lifecycle Ereignisse - RA – Nutzung log4j und JDK Logging im Resource Adapter Der BeanConnect Resource Adapter verwendet für die Protokollierung standardmäßig das OpenSource Produkt log4j. - Custom Charset Sample In der offiziellen Freigabe von BeanConnect V2.0 wurde der Resource Adapter ohne ein Beispiel zur Funktion Customer Encoding ausgeliefert. Im Anschluss an die offizielle Freigabe wurde ein Beispiel implementiert und zum Download auf der BeanConnect Homepage zur Verfügung gestellt. In BeanConnect V2.1 ist dieses Beispiel offizieller Bestand- teil des Resource Adapters. - Proxy Container – gemeinsame Variante UTM & CICS In BeanConnect V2.0 gab es zwei Varianten des Proxys. Mit der einen Variante konnte mit EIS Partnern UTM kommuniziert wer- den, mit der anderen mit EIS Partner CICS. Ab BeanConnect V2.1 gibt es nur noch eine Variante des Proxys mit der mit beiden Typen von EIS Partnern kommuniziert werden kann.

- Proxy Container – mehrere RA pro Proxy (Inbound) Die strenge Kopplung zwischen einem Resource Adapter und einem Proxy Container wurde dahingehend aufgehoben, dass per Konfiguration einem Proxy Container mehr als ein Resource Adapter zugewiesen werden kann. Damit der Nachrichtenfluss vom EIS System zum Message Endpoint korrekt verläuft, muss in diesem Fall jedem Message Endpoint ein bestimmter Resource Adapter zugewiesen werden. Dies er- folgt per Konfiguration mit der Management Console. Zusätzlich wird die Funktion Check Availability in der MC um die Prüfung aller konfigurierten Resource Adapter erweitert.

- Inbound – mehrere Inbound Services pro Message Endpoint Die strenge 1:1 Zuordnung zwischen einem Message Endpoint im Resource Adapter und einem Inbound Service im Proxy Container wird aufgehoben. Mit BeanConnect V2.1 wurde die Funktionalität - analog zu BeanTransactions - so erweitert, dass es möglich ist einem Message Endpoint im Resource Adapter mehrere Inbound Services im Proxy Container zuzuordnen. Damit der Anwender den Absender im Message Driven Bean im Applications Server erkennen kann,

8

wurde das Resource Adapter (Inbound) API um Methoden für Absenderkontexte wie z.B. Anwendungsname, Servicename, User erweitert. - Inbound – Optimierung bei NoTA Falls die onMessage Methode auf Seiten des Resource Adapters mit NoTA generiert ist, unterlässt der Proxy Container die XA-Aufrufe an den RA. Dadurch Reduzierung der Kommunikations- schritte bei NoTA von drei auf eins. - Inbound – verbesserte Fehlerbehandlung Je nach Fehlersituation kann es vorkommen, dass bei Inbound Kommunikation der Client (Auftraggeber) eine (Fehler-) Nach- richt zugestellt bekommt, die er entweder nicht interpretieren kann oder die nicht die tatsächliche Fehlerursache mitteilt. In Zukunft wird eine der Fehlerursache passende Antwort an den Client gesendet, die zusätzlich mit einem Präfix versehen wurde. Dieses Präfix lautet standardmäßig BCSYSEX und kann je nach Bedarf aktiviert oder deaktiviert werden - Proxy Container – Inbound Encoding, Service spezifisch In BeanConnect V2.0 wurden die Properties Encoding und Encoding Active eines Message Endpoint im Deployment Descriptor des MessageDriven Bean konfiguriert. Ab BeanConnect V2.1 kann jedem Inbound Service im Proxy ein Encoding zugeordnet werden. Wird am Inbound Service ein Encoding konfiguriert, dann überschreibt dieser Wert den Wert der Property Encoding aus dem Deployment Descriptor und der Wert der Property EncodingActive wird auf den Wert "true" gesetzt.

- Proxy Container – Übertragung asynchroner Nachrichten mit/ohne COMMIT-FU Ab BeanConnect V2.1 werden asynchrone Nachrichten dann mit COMMIT-FU übertragen, wenn die ManagedConnectionFactory als transaktional konfiguriert ist und die Asynchronnachricht in einer Transaktion erzeugt wurde, und ohne Commit-FU, wenn dies nicht der Fall ist. In BeanConnect 2.0 wurden asynchrone Nach- richten immer ohne Verwendung der Functional Unit Commit über- tragen. Damit ist das Verhalten von BeanConnect bei Asynchronnachrich- ten identisch zu dem bei Dialognachrichten. Diese Änderung hat eine inkompatible Änderung auf Seiten des EIS Partners zur Folge, falls es sich um eine CICS Anwendung handelt. Näheres siehe im Abschnitt zur Kompatibilität. - Cluster In einer geclusterten Application Server Umgebung werden n Application Server Instanzen bzw. Resource Adapter Instanzen m Proxy Instanzen zugeordnet. Für Outbound Kommunikation ist eine RA Instanz immer genau einer Proxy Container Instanz zugeordnet. Bei Ausfall einer Proxy Container Instanz sucht sich die RA Instanz eine neue Proxy Container Instanz. D.h. einer Proxy Container Instanz können mehrere Resource Adapter Instanzen zugeordnet sein. Für Inbound Kommunikation sind einer Proxy Container Instanz alle RA Instanzen zugeordnet. Die Lastverteilung bei Outbound Kommunikation erfolgt mit Hilfe der Mechanismen des Application Servers. Für Inbound Kommunikation erfolgt die Lastverteilung im Proxy Container. Bei der Kommunikation mit EIS Partnern CICS kommen zusätzlich

9

k (1<=k<=m) UTM-LU62 Instanzen hinzu. Die Zuordnung der UTM- LU62 Instanzen zu den Proxy Container Instanzen erfolgt über Anweisungen in der Management Console. Wie mehrere AS Instanzen zu einem AS Cluster zusammengefügt werden ist abhängig vom Application Server und muss in der AS Dokumentation nachgelesen werden. Der Aufbau eines BeanConnect Clusters erfolgt konfigurations- technisch mit Hilfe der Management Console. Dabei sind die einzelnen Proxy Container Instanzen nur aus logischer BeanConnect Sicht zu einem Cluster zusammengefügt. Die einzelnen Proxy Container UTM-Anwendungen stellen aus Sicht von UTM keinen Cluster dar. Einzelheiten zum Betrieb einer BeanConnect Cluster Umgebung sind im BeanConnect Handbuch beschreiben. - Oracle BPEL Support In BeanConnect V2.1 wird der Adapter so erweitert, dass er auch in einer Oracle BPEL SOA Umgebung verwendet werden kann. Der Oracle BPEL Support wird in zwei Ausprägungen zur Verfügung gestellt:

1. BPEL Support mit NativeFormat Builder im Oracle BPEL Umfeld:

Cobol -> XML Transformation mit Hilfe des Oracle Tools Native Format Builder

2. BPEL Support mit „direkten XML-Nachrichten“ im Oracle BPEL SOA Umfeld:

Cobol -> XML Transformation erfolgt bereits in der EIS (Enterprise Information System) Anwendung.

Details siehe Handbuch BeanConnect V2.1. - BPEL WSDL Generator GUI komfortable Erzeugung der BPEL WSDL Datei, die für die Integration von BeanConnect im BPEL-Umfeld benötigt wird. - JMX MBean Application Server JMX Anschluss Implementierung von unterschiedlichen MBeans im BeanConnect Resource Adapter, die zur Laufzeit beim Application Server registriert werden und mit deren Hilfe es einem AS Administra- tor möglich ist. Aussagen über den aktuellen Zustand der Resource Adapter Anwendung zu machen. Die Verwaltung der MBeans erfolgt dabei mit Hilfe eines MBean Servers, der in jedem Application Server vorhanden ist. Jeder ApplicationServer besitzt ein graphisches Tool (JMX Client) mit dem die Daten des MBean Servers angezeigt werden können. Beim Oracle AS ist dies der Enterprise Manager. Alternativ zu den AS Tools kann als graphisches Tool auch die JConsole des JDK verwendet werden. Der Resource Adapter stellt vier MBean Typen zur Verfügung: - Resource Adapter - Managed Connection Factory - Message Endpoint - Inbound Jede der vier MBeans kann verschiedene Daten zur Verfügung stellen: - Attribute: Zahlenwerte für Statistikdaten - Operations: Methoden mit/ohne Parameter - Notifications: Ereignisanzeigen Die jeweiligen Daten der MBean Typen sind ausführlich im Hand- buch von BeanConnect V2.1A beschrieben. - 64 Bit Support

10

Im 64-Bit Mode werden die Proxy Plattformen Solaris und Linux AMD64 unterstützt. Für die Plattformen Solaris und Linux AMD64 wird jeweils ein gemeinsames Installationspaket für die 32 und die 64-Bit Variante erzeugt. Die 32- bzw. 64-Bit Ablaufumgebung wird bei der Installation des Proxy Containers ausgewählt. Beim Einsatz des Proxy Containers in einer 64-Bit Umgebung mit EIS Partner CICS ist folgendes zu beachten: Die Proxy Komponente openUTM-LU62 ist nur in einer 32-Bit Umgebung ablauffähig. - Windows Vista Unterstützung Ab BeanConnect V2.1 enthält das Produkt BeanConnect ein Zertifikat von Fujitsu Technology Solutions, das die Nutzung von BeanConnect als unbedenklich ausweist. - Installation Tool Komponenten Ab BeanConnect V2.1 können die Tools unabhängig vom Proxy Container eingesetzt werden. Für jedes Tool existiert eine eigene Installationseinheit mit der das Tool user-spezifisch installiert werden kann. Die Tool Komponenten sind unabhängig davon, mit welchem EIS Partner kommuniziert wird. - Separater MC Command Handler In BeanConnect V2.0 gab es nur die Möglichkeit pro Proxy Con- tainer einen MC Command Handler zu installieren. Dieser ermöglichte es auf Dateien des Proxy Containers und des openUTM-LU62 Gateways zuzugreifen. Ab BeanConnect V2.1 ist es möglich, dass der openUTM-LU62 Gateway auf einem anderen Rechner als der Proxy Container abläuft. Dafür ist ein eigener MC Command Handler notwendig. Zusätzlich hat der Einsatz von BeanConnect gezeigt, dass es auch nützlich ist, in der ManagementConsole Logging Dateien des Application Servers bzw. des Resource Adapters anzuzeigen. Auch dazu ist ein separater MC Command Handler auf dem Rechner des AS notwendig. Mit BeanConnect V2.1 gibt es deshalb die Möglichkeit einen MC Command Handler separat auf einem System zu installieren. - XATMI Kopplung Standardmäßig erfolgt eine Kommunikation - Outbound und Inbound - zwischen einem Proxy Container und einer UTM Anwendung über die KDCS Schnittstelle. In BeanConnect V2.1 wurde für die Outbound Kommunikation eine Schnittstelle entwickelt, die alternativ dazu das XATMI Interface und die dazu passenden Protokollelemente verwendet. Grobe Funktionsübersicht: - EIS Partner: nur UTM - Nachrichten: nur typed Buffers vom Typ X_OCTET - Paradigmen: sowohl Request/Reply als auch Conversational Details siehe Handbuch BeanConnect V2.1A. - Gliederung der Container stdout/stderr Dateien In BeanConnect V2.0 werden pro Proxy Container nach dem Starten immer die beiden Protokolldateien utmp.out und utmp.err angelegt. Diese Dateien werden beim nächsten Anwendungsstart automatisch überschrieben. Ab BeanConnect V2.1 werden die stdout und stderr Protokolldateinamen abhängig vom Erzeugungszeitpunkt angelegt

11

und täglich umgeschaltet. D.h. pro Anwendungslauf werden u. U. mehr als zwei Dateien angelegt und ein Neustart überschreibt nicht die alten Dateien. Damit immer nur die aktuellen Protokolldateien im Container Verzeichnis stehen, werden die Protokolldateien des vorangegangenen Anwendungslaufs in ein separates Verzeichnis gesichert. Dabei werden Protokolldateien von (noch) älteren Anwendungsläufen gelöscht. - Log4j Properties Dateien Zur besseren Diagnose werden bei den einzelnen BeanConnect Komponenten mehrere vordefinierte Log4j Properties Dateien ausgeliefert, damit das Erzeugen von Diagnoseunterlagen vereinfacht wird. - utmhostname Datei Ab BeanConnect V2.1 wird im Proxy Container standardmäßig eine utmhostname Datei ausgeliefert. Dadurch ist es möglich, Rechnernamen für entfernte EIS Systeme zu verwenden, die länger als 8 Zeichen sind und es wird der Umzug auf andere Rechner erleichtert. - Cobol2Java – als BeanConnect Tool Komponente In BeanConnect V2.0 wurde die Cobol2Java Komponente zusammen mit dem Resource Adapter ausgeliefert. Ab BeanConnect V2.1 wird die Auslieferung von Cobol2Java separat als BeanConnect Tool erfolgen. - Cobol2Java - NumberFormatException unterdrücken Blanks werden für numerische Felder immer akzeptiert und als 0 interpretiert. In BeanConnect for openUTM V2.0 werden numerische Felder mit Leerzeichen initialisiert, ab BeanConnect V2.1 erfolgt die Initialisierung numerischer Felder mit dem Dezimalwert 0. - Cobol2Java – Datentyp NATIONAL Ab BeanConnect V2.1 wird mit Cobol2Java auch der Cobol Daten- typ NATIONAL unterstützt. - Cobol2Java – Suffix für namensgleiche Felder in Unterstruktu-

ren Enthält eine Datenstruktur untergeordnete Strukturen mit dem Namen FILLER oder enthält ein Programm mehrere untergeordnete Strukturen mit demselben Namen, dann werden diese Strukturen bzgl. ihrer Reihenfolge in der XML-Eingabe-Datei laufend durchnummeriert. - Management Console – Administration gemeinsamer Proxy Variante

UTM und CICS In BeanConnect V2.0 gab es zwei Varianten des Proxys. Ab BeanConnect V2.1 gibt es nur noch eine Variante des Proxys. D.h. die Management Console muss folgende drei Fälle an der Oberfläche berücksichtigen. Es gibt nur EIS Partner vom Typ UTM, es gibt nur EIS Partner vom Typ CICS und es gibt so- wohl EIS Partner vom Typ UTM als auch vom Typ CICS.

- Management Console – Konfigurations-Wizzard Zur Konfiguration komplexerer Objekte muss der Administrator mehrere verschiedene Aktionen ausführen um eine konsistente Generierung zu erhalten. Dabei muss er derzeit selbst wissen um welche einzelnen Aktionen es sich hierbei handelt.

12

Ab BeanConnect V2.1 wird die Konfiguration dahingehend verein- facht, dass der Administrator vom GUI über die verschiedenen Aktionen / Bildschirme objektabhängig geführt wird. - Management Console – Verwaltung mehrer MC CommandHandler In BeanConnect V2.0 konnte über die ManagementConsole dem Proxy Container nur ein MC CommandHandler zugewiesen werden. Ab BeanConnect V2.1 ist es möglich einem Proxy Container bis zu drei MC CommandHandler zuzuweisen. Notwendig ist dies für die Administration des BeanConnect Proxys falls das openUTM-LU62 Gateway nicht auf dem Proxy Container Rechner abläuft. Auch Logging Dateien des ApplicationServers und des Resource Adapters können zusätzlich in der MC angezeigt werden, falls sich diese auf einem separaten Rechner befinden. - Management Console – JMX Client In der Management Console wurde ein JMX Client integriert. Mit diesem Client ist es möglich die Informationen der MBeans eines Application Servers von der Management Console anzeigen zu lassen. Die Anzeige beschränkt sich nicht nur auf Informationen der BeanConnect MBeans, sondern umfasst alle aktiven MBeans im Application Server.

- Management Console – Check Availability Proxy -> EIS In BeanConnect V2.1 wird die Check Availability Funktionalität bzgl. der Verbindung Proxy -> EIS erweitert. Ab BeanConnect V2.1 kann ein Service im EIS konfiguriert werden, der bei jedem Check Availability Zyklus automatisch aufgerufen wird. Zusätzlich kann bei der Konfiguration der EIS Partneradresse eine Überprüfung a ’la ping Mechanismus aktiviert werden. - Management Console – Redeployment Proxy Bean In BeanConnect V2.0 wird das Proxy Bean automatisch redeployt, falls dies aufgrund von Änderungen mit der Management Console notwendig ist. Dieses automatische Redeployment gibt es auch mit BeanConnect V2.1. Ab BeanConnect V2.1 gibt es an der Oberfläche zusätzlich die Möglichkeit das Redeployment des Proxy Beans zu aktivieren auch ohne dass zuvor an der Management Console Änderungen vorgenommen wurden. - Management Console – Umschalten stdout/stderr Dateien Ab BeanConnect V2.1 ist es möglich über die Management Console die Protokolldateien für stdout und stderr bei Bedarf umzuschalten. Dadurch kann die Größe der Dateien beeinflusst werden, da es bei sehr großen Dateien Probleme bei der Anzeige über die Management Console geben kann. - Management Console – Administration lokaler Proxy über MCCmdHandler In BeanConnect V2.0 erfolgte die Administration eines lokalen Proxys, der nicht aktiv war, direkt von der Management Console aus. Ab BeanConnect V2.1 erfolgt die Administration eines lokalen Proxys nur dann direkt, falls die Zugriffsrechte dies zulassen. Andernfalls erfolgt die Administration über den MCCmdHandler. Dadurch wird verhindert, dass bei unter- schiedlichen Zugriffsrechten Probleme entstehen.

13

- Management Console – Präfix für Inbound Fehlerbehandlung In der Management Console ist es möglich pro Proxy Container den Inbound Fehler Präfix individuell festzulegen. Dabei kann auf Solaris und Linux entweder der Default Wert (BCSYSEX) ver- wendet werden, als auch ein individueller Wert angegeben wer- den. Auf Windows kann nur der default Wert verwendet werden. Auf allen Plattformen ist es außerdem möglich die Funktionali- tät „Inbound Fehler Präfix“ zu deaktivieren. - Management Console – Zeitunterschiede BeanConnect Komponenten In der Management Console wird für jeden Proxy der Zeitunter- schied der verschiedenen BeanConnect Komponenten relativ zum Proxy Container angezeigt. Durch diese Anzeige soll die Diagnose der unterschiedlichen Komponenten Logs vereinfacht werden. Die Zeitunterschiede, können nur dann errechnet wer- den, falls alle Komponenten auf demselben Rechner ablaufen oder pro Komponente auf einem anderen Rechner ein Command Handler aktiv ist. - Management Console – Anpassung der Anzahl der Proxy Contention

Winner nach Änderung der Anzahl Verbindungen (Connections)

Falls in der ManagementConsole im Dialog zur Konfiguration der Kommunikation zum EIS Partners über OSI-TP die Anzahl der Verbindungen geändert wurde, musste bisher die Anzahl contention winner im gleichen Dialog extra angepasst werden. Ab BeanConnect V2.1 wird der Administrator nach einer Änderung der Anzahl der Verbindungen automatisch aufgefordert die Anzahl contention winner Verbindungen anzupassen. Dabei berechnet die MC implizit zwei neue Werte im bisherigen Verhältnis und bietet diese zur Übernahme an. - Management Console – Generierung OLTP Partner / new ACCESSPOINT Bei der Konfiguration von OLTP Partner für EIS Partner UTM kann ab BeanConnect V2.1 der Inhalt des Feldes new ACCESSPOINT frei ausgewählt werden. - Management Console – Namensbildung des remote ACCESSPOINT In BeanConnect for openUTM V2.0 erfolgte die Namensgebung generisch und war etwas irreführend. Ab BeanConnect V2.1 kann der Anwender die Namen selbst wählen, außerdem werden passen- dere Namen an der Oberfläche vorgeschlagen. - Management Console – Nutzung grace shutdown im Proxy Container In openUTM V5.3 wurde die Funktionalität „grace shutdown“ neu implementiert, die es ermöglicht UTM OSI-TP Anwendungen schneller normal zu beenden. Diese Funktionalität wird auch in BeanConnect V2.1 verwendet um kürzere „shutdown“ Zeiten zu erreichen. - Management Console – TSEL-Format für EIS Partner UTM Bei der Konfiguration eines UTM EIS Partners für Outbound Kommunikation über OSI-TP wird von der Management Console eine KDCDEF Generierungsdatei erzeugt. In BeanConnect for openUTM V2.0 hatte das TSEL-FORMAT der entfernten UTM Partner Anwendung (OSI-CON Anweisung) immer den Typ TRANSDATA. Residiert die UTM Partner Anwendung aber auf einer offenen Plattform, so kann das TSEL-FORMAT auch vom Typ ASCII sein. Ab BeanConnect V2.1 gibt es daher die Möglichkeit im EIS Partner Eigenschaftsdialog das TSEL-FORMAT zwischen TRANSDATA, EBCDIC und ASCII auszuwählen.

14

- Management Console – Rechnergrenze Proxy Container <-> openUTM-LU62 Gateway In BeanConnect for CICS V2.0 ist die Konfiguration so eingeschränkt, dass die Proxy Komponenten Container und openUTM-LU62 Gateway auf demselben Rechner ablaufen müssen. Diese Einschränkung wird mit BeanConnect V2.1 aufgehoben. - Management Console – Konfiguration LU62 Instanz Bisher war in openUTM-LU62 die Eigenschaft ob eine Instanz im Dialog oder asynchron abläuft global einstellbar. Dies führte zu Problemen bei der Kopplung mit IMS und CICS. Ab sofort ist diese Eigenschaft nicht mehr global, sondern einer Instanz zu- geordnet. Deshalb muss in Zukunft je nach Dialog- oder Asynchron-Kommunikation die richtige Instanz ausgewählt werden. Für die BeanConnect ManagementConsole heißt dies, dass beim Erzeugen der Instanz zukünftig der Partner Type abgefragt wird. Im Resource Adapter muss deshalb künftig für Dialog- und Asynchron-Kommunikation jeweils eine eigene Connection Factory eingerichtet werden. Das Bean muss dann je nach Anwendungsfall die passende MCF adressieren. - Management Console – Automatische Anpassung Startskript für IBM-CS(Linux) bzw. SNAP-IX(Solaris) In BeanConnect V2.1 werden die Startskripts für IBM-CS(Linux) bzw. SNAP-IX(Solaris) von der Management Console automatisch an die aktuelle Konfiguration angepasst. - Management Console – Link Station Die Link Station ist Bestandteil der Definitionen für den IBM Communications Server for Windows bzw. Linux und SNAP-IX. Als Name wurde in BeanConnect for CICS V2.0 unter Windows der in VTAM auf dem z/OS definierte Control Point Name gewählt. Auf den anderen Plattformen wurde der Name zusammengesetzt, und zwar aus dem String IP_ für einen über Enterprise Extender verbundenen Partner bzw. ET_ für einen über LAN verbundenen Partner als erster Teil des Namens. Der zweite Teil des Namens bestand in BeanConnect for CICS V2.0 aus den ersten fünf Zeichen des Control Point Name. Dies führte immer dann zu einem Problem, wenn es EIS-Partner auf verschiedenen Rechnern gab und die Control Point Namen sich nicht in den ersten fünf Zeichen unterschieden. In BeanConnect V2.1 wird als Name der Link Station grundsätzlich der gesamte Control Point Name verwendet, entspricht also der Lösung für den IBM Communications Server for Windows in BeanConnect for CICS V2.0. Dieser Name ist für verschiedene z/OS-Rechner unterschiedlich. - Management Console – Vergabe XID für einen Proxy und für einen EIS Partner auf Solaris bzw. Windows Die XID dient zur Identifikation eines Knotens im SNA Netz- werk. Diese Information wird bei der Kommunikation mit einem anderen Knoten ausgetauscht, sollte also eindeutig sein. Der Wert besteht aus den Teilen IDBLK (Block ID, Zahl hexadezimal, 3 Ziffern) und IDNUM (Physical Unit ID, Zahl hexadezimal, 5 Ziffern), Die XID wird in BeanConnect for CICS V2.0 generiert, ohne dass der Anwender eine Angabe machen muss. Es handelt sich dabei um den generierten Wert für NODE_ID in den Generierungsdateien für den IBM Communications Server for Windows bzw. Linux, die Generierungsdatei für SNAP-IX und die generierten Werte für die Parameter IDBLK und IDNUM in den

15

generierten VTAM Definitionen. Differenzierendes Merkmal war in BeanConnect for CICS V2.0 der letzte Teil der IP-Adresse, womit allerdings keine Eindeutigkeit gewährleistet werden kann. Ab BeanConnect V2.1 können im Proxy Dialog und im EIS Partner Dialog für einen EIS Partner auf Windows bzw. Solaris die Werte IDBLK und IDNUM individuell eingegeben werden. Als Default wird für NODE_ID der Wert aus BeanConnect for CICS V2.0 verwendet. - Management Console – Generierung VTAM Bei der VTAM Generierung in der MC kann ab BeanConnect V2.1 der Gruppenname frei ausgewählt werden. - Management Console – CICS Definitionen für Connection und Session Die Management Console erzeugt CICS Definitionen für eine Connection und Session. In BeanConnect for CICS V2.0 wird der Name der Connection aus dem Buchstaben C und dem Präfix zusammengesetzt. Im CICS Umfeld ist aber der Namensraum von Objekten, die mit C beginnen, für System-Ressourcen reserviert. Ab BeanConnect V2.1 wird statt dem Buchstaben C der Buchstabe A (A stellvertretend für association) verwendet. 2.2 Realisierte Change Requests

Folgende Change Requests wurden mit BeanConnect V2.1 umgesetzt: CR A0528027 CR A0529275 CR A0529839 CR A0532599 CR A0544896 CR A0544900 CR A0545156 CR A0546023

16

3 Technische Hinweise 3.1 Ressourcenbedarf CPU / BeanConnect Proxy : mind. 450 MHz, empfohlen 1 GHz oder höher Hauptspeicher / BeanConnect Proxy : mind. 512 MB, empfohlen 1 GB oder höher Plattenspeicherbedarf : BeanConnect Resource Adapter: Archiv ca. 4 MB extrahiert ca. 8 MB Zentrale Komponenten: BeanConnect Systemteil: Solaris : ca. 37 MB Linux : ca. 21 MB Windows : ca. 11 MB openUTM : Solaris : ca. 630 MB Linux : ca. 180 MB Windows : ca. 54 MB openUTM-LU62 : Solaris : ca. 11 MB Linux : ca. 6 MB Windows : ca. 6 MB BeanConnect Proxy: Container : Solaris : ca. 59 MB Linux : ca. 59 MB Windows : ca. 56 MB BeanConnect Management Console: Console : Solaris : ca. 13 KB Linux : ca. 44 KB Windows : ca. 400 KB

Tools: Cobol2Java : Archiv: ca. 7 MB extrahiert ca. 10 MB MCCmdHandler : Archiv: ca. 3 MB extrahiert ca. 3 MB BPEL WSDL Generator : Archiv: ca. 3 MB extrahiert ca. 3 MB JConnect : Archiv: ca. 2 MB extrahiert ca. 7MB

17

3.2 SW-Konfiguration Die Komponenten BeanConnect Resource Adapter und BeanConnect Tools sind für folgende Betriebssysteme verfügbar: - Solaris(SPARC) ab V9 (32 und 64 Bit) - Linux x86 und x86-64: RedHat Enterprise Linux ab 4 (32 und 64 Bit) SUSE LINUX Enterprise Server ab 9 (32 und 64 Bit) - Windows Server 2003 (32 und 64 Bit) / Windows XP (32 und 64 Bit) / Windows Vista (32 und 64 Bit)

- HP-UX ab 11i (32 und 64 Bit) Die Komponenten BeanConnect Proxy und BeanConnect Management Console sind für folgende Betriebssysteme verfügbar: - Solaris(SPARC) ab V9 (32 und 64 Bit) - Linux x86 und x86-64: RedHat Enterprise Linux ab 4 (32 und 64 Bit) SUSE LINUX Enterprise Server ab 9 (32 und 64 Bit)

- Windows Server 2003 (32 Bit) / Windows XP (32 Bit)

/ Windows Vista (32 Bit) Die BeanConnect Komponenten können auf dem gleichen Rechner oder auf unterschiedlichen Rechnern ablaufen. Für die Funktionalität von BeanConnect ist es ohne Bedeutung welche Kopplung von Betriebssystemen bzw. Betriebssystemversionen dabei zum Einsatz kommen. BeanConnect V2.1A erfordert J2SE JDK 1.5.0_15 oder höher.

BeanConnect V2.1 unterstützt folgende Application Server:

- Oracle AS / OC4J ab 10.1.3.3 unter der Voraussetzung eines Interoperability Checks

- IBM WebSphere AS ab 6.1.0.13 - RedHat JBoss ab 4.2.2 - SUN Glassfish V2 - Bea WebLogic V10

Der BeanConnect Proxy benötigt zusätzlich:

PCMX : Die erforderlichen PCMX Versionen - Solaris : PCMX V6.0A60 - Linux : PCMX V6.0A70 - Windows : PCMX32 V5.0A30 sind auf der DVD enthalten und müssen installiert werden. Hinweis: Unter Solaris kann statt PCMX auch CMX ab V6.0 verwendet werden.

18

openUTM : Eine erforderliche openUTM-Version zur Benutzung durch den BeanConnect Proxy ist auf der DVD enthalten und muss installiert werden. Sie darf nur mit BeanConnect V2.1A verwendet werden. openUTM-LU62 Gateway : Eine entsprechende openUTM-LU62-Version zur Benutzung durch den BeanConnect Proxy ist auf der DVD enthalten und muss installiert werden. Sie darf nur mit BeanConnect V2.1A verwendet werden.

Cobol2XML: Für das BS2000-Tool Cobol2XML – im Lieferumfang enthalten - gelten die Software-Voraussetzungen von Cobol2000 V1.4A. Einzelheiten entnehmen Sie bitte der Freigabemitteilung von Cobol2000 V1.4A

Cobol2Java benötigt zusätzlich:

Enterprise Information System (EIS) openUTM : - openUTM ab V5.2 auf allen Plattformen (32 und 64 Bit) Unter BS2000/OSD*) wird für transaktionale Kommunikation zusätzlich das Produkt openUTM-D benötigt. - openUTM-Client (UPIC) ab V5.2 auf allen Plattformen (32 und 64 Bit) Enterprise Information System (EIS) CICS : - CICS auf z/OS: z/OS ab V1.4 CICS ab V2.2 Erforderliche Kopplungssoftware von Fremdfirmen : - Solaris : SNAP-IX V7.0.2.4 oder höher, von Data Connection Ltd. - Linux : IBM Communications Server for Linux, V6.2 oder höher - Windows : IBM Communications Server for Windows, V6.1.2 oder höher Hinweis: SNAP-IX und der Communications Server gehören nicht zum Lieferumfang von BeanConnect V2.1A. Als Kopplungsmöglichkeit wird sowohl Enterprise Extender als auch Ethernet (LLC2) unterstützt. Kostenfrei mitgeliefert werden eine Reihe von Produkten anderer Hersteller, die für den Betrieb von BeanConnect V2.1A notwendig sind. Eine ausführliche Liste dieser Produkte finden Sie in der Datei „Copyright.htm“ im Unterverzeichnis Docs des Installationsver-zeichnisses von BeanConnect. Bitte beachten Sie die Copyright-Vermerke unter der jeweils angegebenen URL.

19

3.3 Produkt-Installation Ausführliche Hinweise zur Installation von BeanConnect V2.1A40 finden Sie im Handbuch ("BeanConnect V2.1", Kapitel "BeanConnect installieren"). 3.3.1 Update Installation Voraussetzung für eine Update Installation ist, dass der Proxy und die ManagementConsole mit der "alten" Installation ablauffä-hig sind. 3.3.2 Kernel Tuning Für den Betrieb des BeanConnect Proxy kann es notwendig sein, einige UNIX-Kernelparameter zu vergrößern. - Änderung der Kernelparameter unter Solaris: Die Werte können durch Einträge in der Datei /etc/system verändert werden. Nach dem Ändern ist ein Reboot nötig. Empfohlene Werte für die entsprechenden Parameter: set shmsys:shminfo_shmmax=0x10000000 set shmsys:shminfo_shmseg=32 set semsys:seminfo_semmap=64 set semsys:seminfo_semmni=64 set semsys:seminfo_semmns=1600 set semsys:seminfo_semmnu=64 set semsys:seminfo_semume=900 - Änderung der Kernelparameter unter Linux: Die Werte können durch Einträge in der Datei /etc/sysctl.conf verändert werden. Nach dem Ändern sind die Kommandos: sysctl -p und zusätzlich auf SuSE Linux chkconfig boot.sysctl on nötig. Empfohlene Werte für die entsprechenden Parameter: kernel.shmmax = 0x10000000 Weitere Hinweise zur Änderung von Kernelparametern und wie Sie einen neuen Kernel erzeugen, entnehmen Sie bitte den Unterlagen Ihres Linux-Distributors. Außerdem sind zusätzlich die Hinweise in der Liefer-Info zu berücksichtigen. 3.3.3 Java und SELinux

Beim Betrieb von BeanConnect auf Linux kann es beim Starten zu folgender Fehlermeldung kommen: error while loading shared libraries: ./libjvm.so: cannot restore segment prot after reloc: Permission denied

20

Ursache dieses Problems ist eine aktivierte SELinux (Security-Enhanced-Linux) Umgebung auf Ihrem System. Da es sich um ein allgemeines Problem zwischen Java und SELinux handelt, können Sie das Problem nur umgehen, in dem Sie die SELinux Umgehung deaktivieren. Dazu müssen Sie folgendermaßen vorgehen: Öffnen Sie die Datei /etc/sysconfig/selinux und Ersetzen Sie die Zeile SELINUX=enforcing durch SELINUX=disabled. Danach müssen Sie den Rechner rebooten, damit die Deaktivierung erfolgt. 3.3.4 Installation unter Solaris Aus technischen Gründen lässt sich eine IzPack-Installation des ResourceAdapters und der Tools MCCmdHandler, Cobol2Java und BPELWsdlGen über die grafische Oberfläche unter SUN Solaris V10 nicht immer durchführen (Fehlermeldung: not enough free space on device to install). Auf diesem System muss die Installation dann im Command-Line-Modus erfolgen. Weitere Hinweise können Sie dem Handbuch entnehmen. 3.4 Produkt-Einsatz Informationen sind dem Handbuch "BeanConnect V2.1" zu entnehmen. 3.5 Entfallene und gekündigte Funktionen Resource Adapter: Die Präfixangabe ‚oltp’ in der ConnectionURL wird zur nächsten BeanConnect Version aufgekündigt. Alternativ ist der Präfix ‚utm’ zu verwenden.

21

3.6 Inkompatibilitäten BeanConnect V2.1A ist bis auf folgende Einschränkungen voll kompatibel zu BeanConnect V2.0: - Java SDK Ab BeanConnect V2.1 wird für den Betrieb von BeanConnect Java 5 vorausgesetzt.

- Resource Adapter Name Ab BeanConnect V2.1 wird der Name des jar-Archivs so abgeändert, dass die Version erkennbar ist. Alter Name: RAInstall.jar Neuer Name: BC21A40_RA.jar

- Resource Adapter rar-Archiv Name Ab BeanConnect V2.1 wird der Name des rar-Archivs so abgeändert, dass die Version erkennbar ist. Alter Name: BeanConnect.rar Neuer Name: BC21A40.rar

- Installation auf Linux x86 Architektur Ab BeanConnect V2.1 muss bei der Installation des BeanConnect rpm Paketes auf Linux x86 Architektur zusätzlich die Option „--ignorearch" angegeben werden.

- OltpMessageListener Interface Die Methode onMessage des Interface OltpMessageListener wirft keine OltpMessageException mehr (die Throws-Klausel wurde gestrichen). Die Streichung der Throws-Klausel ist inkompatibel für die Anwenderprogramme. Diese Änderung betrifft alle EJBs, die das Interface OltpMessageListener implementieren. Die Inkompatibilität macht sich nicht zur Laufzeit, sondern nur beim Übersetzen der Bean Klasse bemerkbar. - OltpMessage Interface Verhalten in BeanConnect V2.0: In BeanConnect V2.0 werden von einigen Methoden des OltpMessage-Pakets Runtime Exceptions geworfen (IllegalArgumentException, IndexOutOfBoundException), obwohl die Ursachen Fehler der Anwendung (EJB) sind. Wird eine solche Exception bis zum Application Server geworfen, dann führt dies bis hin zum EJB oder EIS Client zu unerwarteten Situationen. Verhalten in BeanConnect V2.1: Da es sich eindeutig um Anwenderfehler handelt, werden in BeanConnect V2.1 in diesen Situationen OltpMessageExceptions geworfen. Dazu müssen einige Methoden der OltpMessage Interfaces um entsprechende Throws-Klauseln für die OltpMessageException erweitert werden. Die Erweiterung der betroffenen Methoden um eine solche Throws-Klausel ist inkompatibel für die Anwenderprogramme, da diese dann die Exception fangen müssen. Diese Änderung betrifft alle EJBs, die die OltpMessage Interfaces verwenden. Die Inkompatibilität macht sich nicht zur Laufzeit, sondern nur beim Übersetzen der Bean Klasse bemerkbar.

22

Folgende Methoden sind von dieser Änderung betroffen: Interface net.fsc.jca.communication.OltpMessageBase: int readBytes(byte[] b) int readBytes(byte[] b, int length) int readBytes(byte[] b, int offset, int length) void writeBytes(byte[] b) void writeBytes(byte[] b, int length) void writeBytes(byte[] b, int offset, int length) Interface net.fsc.jca.communication.OltpMessageContext: OltpMessage createMessage() Interface net.fsc.jca.communication.OltpMessage: OltpMessageRecord createMessageRecord(String mapName) void addMessagePart(OltpMessagePart messagePart) void addMessagePart(byte[] message) void addMessageRecord(OltpMessageRecord messageRecord) void addMessageRecord(String mapName, byte[] message) Iterator getMessageParts() Iterator getMessageRecords() int countMessageParts()

- Änderungen am BcComConnectionMetaData Interface Für BeanConnect V2.1 wurden die Methoden getEISProductName() und getEISProductVersion() inkompatibel geändert. Verhalten in BeanConnect V2.0: In dieser Version lieferten diese beiden Methoden für UPIC- Connections "openUTM Version unknown" und für OLTP- Connections "oltp partner". Diese Ergebnisse waren fest in BeanConnect einprogrammiert, aber sie müssten eigentlich vom EIS-Partner geliefert werden.

Verhalten in BeanConnect V2.1: Mit BeanConnect V2.1 werfen beide Methoden eine Resource- Exception, da die von diesen Methoden zu liefernde Information nicht von den EIS-Partnern abgefragt werden kann.

- Änderungen bei Einsatz mit EIS Partner CICS

Auswahl MCF (ManagedConnectionFactory) für asynchron/dialog

Verhalten in BeanConnect V2.0: Kommunikation:

In openUTM-LU62 Gateway, konnte über die Shell-Variable U62_ASYNC (bzw. dem entsprechenden Registry Eintrag) unter Windows eingestellt werden, dass für alle generierten Instanzen des openUTM-LU62 Gateway ein vom Proxy Container ohne Handshake angeforderter Dialog in Richtung CICS in eine Conversation mit SYNCLEVEL 1 (CONFIRM) umgesetzt werden soll. Dieses Verhalten hatte die folgenden Auswirkungen: Wurde nicht umgesetzt, so wurden zwar asynchrone Nachrichten übertragen, aber beim Beenden der Conversation trat ein Fehler auf. Wurde umgesetzt, so wurden Dialognachrichten nicht über- tragen. Verhalten in BeanConnect V2.1: Für jede Instanz von openUTM-LU62 kann mit dem Parameter UTM-ASYNC eingestellt werden, ob eine Umsetzung des Synclevels durchgeführt werden soll. Dieses Verhalten wird von BeanConnect V2.1 genutzt. Hierzu wird beim Einrichten eines EIS-Partners der Partner- Typ abgefragt. Es sind die Werte Dialog (UTM-ASYNC=NO) und Asynchronous (UTM-ASYNC=YES) möglich. Sollen Dialognachrichten und asynchrone Nachrichten an CICS geschickt werden, so muss

23

ein Partner mit der Eigenschaft Dialog und ein anderer mit der Eigenschaft Asynchronous definiert werden. Bei der Definition eines Communication Endpoint müssen EIS-Partner und der Partner Service dieselbe Eigenschaft haben (Dialog oder Asynchronous). Für jeden Communication Endpoint wird mindestens eine Connection Factory für den Resource Adapter definiert. Dies wirkt sich auf die Programmierung so aus, dass CICS Transaktionen, abhängig von ihrem Typ, über eine Connection aufgerufen werden müssen, die von einer Connection Factory erzeugt wurde, die über den Communication Endpoint dem EIS-Partner vom selben Partner Type zugeordnet ist. Eine Überprüfung bei der Methode setServiceName(), ob die Typen verträglich sind, findet nicht statt. Verhalten in BeanConnect V2.0:

Outbound-Kommunikation

In BeanConnect V2.0 wurde die ConnectionURL in der Form oltp://<name> angegeben. Verhalten in BeanConnect V2.1: In BeanConnect V2.1 muss die ConnectionURL einer Connection- Factory für einen CICS-Partner als cics://<name> angegeben werden, wobei <name> den Name eines Outbound Communication Endpoints bezeichnet, wie er in der Management Console definiert wurde. Verhalten in BeanConnect V2.0: In BeanConnect 2.0 war für CICS-Partner der Standardwert jdk:Cp1047. Verhalten in BeanConnect V2.1: In BeanConnect V2.1 muss bei einer ConnectionFactory für einen CICS-Partner explizit ein Encoding definiert werden, z.B. jdk:Cp1047. Der Standardwert für Encoding ist für openUTM Partner voreingestellt. Verhalten in BeanConnect V2.0:

Default Encoding für Inbound Kommunikation

In BeanConnect V2.0 wird für jeden aktivierten Message Endpoint die activation-config-property encoding auf den Wert jdk:cp1047 und die activation-config-property encodingActive auf den Wert true gesetzt. Verhalten in BeanConnect V2.1: In BeanConnect V2.1 gibt es keinen Default Wert für die activation-config-property encoding und der Default-Wert für die activation-config-property encodingActive ist false. - Tool Komponente Cobol2Java Bei BeanConnect V2.0 wurde die Komponente Cobol2Java zusammen

Installation

mit der UTM Variante des Resource Adapters ausgeliefert. Ab BeanConnect V2.1 wird Cobol2Java separat als eigenständige BeanConnect Tool Komponente ausgeliefert. Deshalb wurden auch die Namen der folgenden Cobol2Java Bibliotheken an die BeanConnect Namenskonventionen angepasst. alter Name: neuer Name: cob2java.jar BeanConnectCob2Java.jar cob2java_ext.jar BeanConnectCob2Java_ext.jar NumberFormatException in Pic9

24

Mit der Einführung eines ausgezeichneten nicht-numerischen Byte-Wertes mit der Bedeutung "undefined" (Ant-Parameter undef.pic9) hat sich die Behandlung von nicht initialisierten Pic9-Feldern geändert. Im Konstruktor Pic9(int offset, int length, byte[] globalArray, ConversionInterface ci) wurde bisher immer dann eine NumberFormatException geworfen, wenn die zum Pic9 Objekt gehörenden Bytes (abdruckbar) einen nicht-numerischen Wert enthielten. Mit BeanConnect V2.1 ändert sich das Verhalten wie folgt: • Haben alle zum Pic9 Objekt gehörenden Bytes denselben nicht-

numerischen Wert, wird keine Exception geworfen. • Ist dieser Bytewert gleich dem Defaultwert für "undefined", wird bei den Methoden intValue(), longValue(), bigIntValue() und toString() der Wert 0 zurückgegeben. • Ist dieser Bytewert ungleich dem Defaultwert für "undefined", wird bei den Methoden intValue(), longValue(), bigIntValue() und toString() eine NumberFormatException geworfen. - BeanConnect Proxy Container Verhalten in BeanConnect V2.0:

Übertragung asynchroner Nachrichten

In BeanConnect V2.0 werden asynchrone Nachrichten immer ohne Verwendung der Functional Unit Commit übertragen. Da nur die Verwendung der Functional Unit Commit die maximale Sicherheit bei der Übertragung garantiert, wurde entschieden dieses Verhalten in BeanConnect V2.1 zu ändern. Verhalten in BeanConnect V2.1: In BeanConnect V2.1 werden asynchrone Nachrichten immer dann unter Verwendung der Functional Unit Commit übertragen, wenn die ManagedConnectionFactory als transaktional konfiguriert ist und die Asynchronnachricht in einer Transaktion erzeugt wurde; in allen anderen Fällen erfolgt die Übertragung von asynchronen Nachrichten ohne Verwendung der Functional Unit Commit. Damit ist das Verhalten von BeanConnect bei Asynchronnachrichten identisch zu dem bei Dialognachrichten. Ist der Partner eine UTM-Anwendung, dann ist diese Änderung für das Anwendungsprogramm transparent. In der UTM-Anwendung muss für das OSI-LPAP dieser Verbindung lediglich ein Application- context ausgewählt sein, der die abstrakte Syntax CCR enthält, also z.B. UDTSEC oder UDTCCR. Ist der Partner eine CICS-Anwendung, dann muss das Anwendungs- programm geeignet angepasst werden, wenn eine Nachricht unter Verwendung der Functional Unit Commit übertragen wird.

25

3.7 Einschränkungen CICS Programme: - Outbound Kommunikation: Ein CICS-Programm muss dem Paradigma Distributed Transaction Programming (DTP) entsprechen. Zusätzlich beachten Sie bitte die Hinweise zur Programmierung von CICS-Programmen (siehe Handbuch "BeanConnect V2.1",Kapitel "Programmierinformationen für Outbound Kommunikation") CICS DPL Programme werden nicht direkt unterstützt. Es gibt aber trotzdem die Möglichkeit DPL Programme einzusetzen, indem ein DTP Programm vorangestellt wird, das den program link einschalt. Eine ausführliche Anleitung dazu finden Sie im Handbuch "BeanConnect V2.1" im Kapitel "Programmierinformationen für Outbound Kommunikation"). - Inbound Kommunikation: Ein CICS-Programm muss dem Paradigma Distributed Transaction Programming (DTP) entsprechen. Zusätzlich beachten Sie bitte die Hinweise zur Programmierung von CICS-Programmen (siehe Handbuch "BeanConnect V2.1", Kapitel "Programmierinformationen für Outbound Kommunikation") CICS EIS Plattformen: BeanConnect V2.1 unterstützt nur die Kommunikation zu CICS Anwendungen, die auf z/OS-Systemen laufen. 3.8 Verhalten im Fehlerfall Zur Fehlerdiagnose sind folgende Angaben nötig: - genaue Beschreibung der Fehlersituation - Angabe der Versions-/Korrekturstände der beteiligten Software - Genaue Angabe des Rechnertyps Die Fehlerunterlagen sollten möglichst vollständig vorhanden sein. Als Fehlerunterlagen werden benötigt: - alle erzeugten Loggingfiles - UTM-Dumps aller Work-Prozesse sowie zugehörige gcores Diese Dateien sollten als Binaerdateien, d.h. in nicht aufbereiteter Form, vorliegen - SYSLOG-Datei(en) - stdout/stderr-Protokolle der UTM-Prozesse - KDCDEF-Generierung, Startprozedur und Startparameter - core-Dateien mit zugehörigen Phasen (utmwork) und shared objects. Die shared objects können mit "ldd utmwork" ermittelt werden.

26

Bei Fehlern, die in Zusammenhang mit der openUTM-Netzanbindung stehen, können zusätzlich folgende Unterlagen erstellt werden: - CMX-Traces - OSS-Traces - UTM-BCAM-Trace - Umwandlungsdatei mit Mapped Hostname Einträgen - Bei heterogener Kopplung Generierungsinformation und Trace von openUTM LU6.2 und seiner SNA Komponenten und vom IBM-SNA System. Bei Fehlern, die in Zusammenhang mit Datenbanken stehen, können zusätzlich folgende Unterlagen erstellt werden: - XA Debug Trace - weitere Unterlagen siehe entsprechende Freigabemitteilung des Datenbanksystems. Weitere Informationen zu den für die Diagnose erforderlichen Fehlerunterlagen finden Sie im Handbuch "BeanConnect V2.1", Kapitel "Diagnose und Fehlerbehebung".

4 Hardware-Unterstützung Es wird die Hardware unterstützt, auf der die unter "3.2 SW-Konfiguration" genannten Betriebssystemversionen ablauffähig sind.