Haben Sie sich auch schon die folgenden Fragen gestellt: Wodurch verlangsamt sich der AS/400-Webserver? Wie kann ich Performance-Probleme mit Open Database Connectivity untersuchen? Welche IP-Druckmöglichkeiten habe ich mit der AS/400? Wozu sind FTP-Befehle gut? Ist mit Client Access für Windows 95/NT virtuelles Drucken möglich?

IS-Manager, Netzwerkadministratoren und Client/Server-Anwendungsentwickler müssen oft tief in die Trickkiste greifen, um den täglichen Herausforderungen gewachsen zu sein. Die folgenden 25 Tips und Techniken bieten eine Vielzahl nützlicher Tricks, die Ihnen dabei helfen, knifflige Probleme aus dem Weg zu räumen.

Zusätzliche PC5250-Sitzungen starten
Virtueller Druck mit Client Access für Win95/NT
802.2-Performance von NS/Router optimieren
Rumba/400 als TN5250-Client verwenden
Status der TCP/IP-Hostserver überprüfen
SQL-Server-Importdatei mit CA-Dateitransfer erstellen

FTP-Server-Anmeldeaufforderungen werden nicht angezeigt
AS/400 und Java im Web
Handbücher zur AS/400 im Internet
Langsame Anwortzeiten des Webservers
Langsame Anwortzeiten des Webservers � Teil 2
Korrekte Zeitstempel für Internet-Mail

Visual Basic 4.0- und 5.0 Byte-Felder für ODBC-gebundene Parameter verwenden
Clients eindeutig identifizieren
ODBC-Leistungsprobleme mit PRTSQLINF untersuchen
AS/400-Datenbankdateien mit FTP übertragen

CL-Programm zum Start der TCP/IP-Hostserver
Konvertierungsprogramm durch Eingabe von FTP-Befehlen starten
Automatisches FTP von der AS/400 aus
IP-Druck auf der AS/400
FTP-Übertragungen von und zu Sicherungsdateien

Die Suche nach AS/400 Client/Server-Aufträgen
Verwaiste Aufträge löschen
Remote-Diagnose mit STRCYSCN
IFS-Objekte über SNADS übertragen

 

Zusätzliche PC5250-Sitzungen starten
Sie können mehrere PC5250-Sitzungen starten, um Optionen zu vergleichen, Aufträge zu überwachen oder einfach nur verschiedene Aufgaben gleichzeitig auszuführen. Dazu können Sie eine konfigurierte PC5250-Sitzung aufrufen, indem Sie die entsprechende Verknüpfung auswählen und darauf doppelklicken. Wenn bereits eine PC5250-Sitzung läuft und die Verknüpfung für die neue Sitzung verdeckt ist, können Sie die zweite Sitzung auch starten, indem Sie den Befehl zum Ausführen derselben Option im Dateimenü von PC5250 auswählen. Um die Sitzung auf einem anderen System zu starten, müssen Sie den Menübefehl zum Ausführen einer anderen Option wählen. Der Befehl ermöglicht, ein PC5250-Profil auszuwählen. In beiden Fällen wird die PC5250-Sitzung gestartet, ohne daß Sie die aktuelle Sitzung minimieren und wiederherstellen müssen.

 

Virtueller Druck mit Client Access für Win95/NT
PCs mit Client Access für Windows 95 und NT können ähnlich auf die AS/400-Drucker zugreifen wie dies bei PCs mit Client Access für Windows 3.1 und Client Access für DOS beim virtuellen Druck der Fall war. Für den virtuellen Druck unter Windows 95 oder NT muß der PC über Client Access für Win95/NT an die AS/400 angeschlossen werden. Wählen Sie dann auf dem Windows 95- oder NT-Desktop „Arbeitsplatz“ und „Drucker“. Doppelklicken Sie auf „Neuer Drucker“ , um den Assistenten für die Druckerinstallation aufzurufen. Wählen Sie unter „Druckertyp“ die Einstellung „Netzwerkdrucker“. Klicken Sie auf „Weiter“, und geben Sie als Druckernamen //AS400/PRINTER ein. AS400 ist der Netzwerkname und PRINTER ist der Name der Warteschlange für den gewünschten Drucker. Klicken Sie auf „Durchsuchen“, um die Liste der Netzwerk- und AS/400-Drucker einzublenden.
Der Installationsassistent fordert Sie auf, den Hersteller- und Druckernamen auszuwählen. Klicken Sie auf „Weiter“, nachdem Sie die entsprechenden Einträge in der Liste gewählt haben. Geben Sie den Druckernamen ein. Mit diesem Namen verweist der Win95/NT-Client-PC auf den Drucker. Der Name muß nicht mit dem Namen in der AS/400-Ausgabewarteschlange identisch sein. Klicken Sie auf „Weiter“, drucken Sie eine Testseite und klicken Sie dann auf „Fertigstellen“. Der Windows 95- oder NT-Client-PC kann die Druckdaten nun an den Drucker senden, der an die AS/400 angeschlossen ist.

802.2-Performance von NS/Router optimieren
Wenn Sie den NetSoft/Client Access für Windows 95/NT NS/Router für eine 802.2-Verknüpfung konfigurieren und dabei die Standardwerte verwenden, erzielen Sie bei PC-AS/400-Anbindungen unter Umständen keine optimalen Leistungen. In der Standardeinstellung verwendet die 802.2-Verknüpfung einen MAXDATA-Parameter von 521 � eine Größe, die gut für SDLC-Verbindungen geeignet ist. Falls der PC über ein Ethernet- oder Token-Ring-LAN an die AS/400 angeschlossen wird, sollten Sie jedoch einen höheren Parameterwert wählen, um die Leistung bei PC-AS/400-Dateitransfers und Open Database Connectivity (OBDC)-Anbindungen zu steigern. Überprüfen Sie die AS/400-Zeilenbeschreibung mit dem Befehl DSPLIND (Zeilenbeschreibung anzeigen) und dem Zeilennamen, um die optimale Größe für MAXDATA festzulegen. Der Wert sollte nicht größer als die in der AS/400-Zeilenbeschreibung festgelegte Datenblockgröße sein. Wenn die AS/400-Zeilenbeschreibung eine maximale Datenblockgröße von 1496 hat, sollten Sie als MAXDATA-Größe für NS/Router den Wert 1033 wählen. (1033 ist der höchste zulässige Wert unter NS/Router, der die maximale Datenblockgröße der AS/400 nicht überschreitet.)
Ändern Sie den MAXDATA-Parameter für NS/Router, indem Sie den NS/Administrator starten und mit der rechten Maustaste das NS/Router-Symbol anklicken. Klicken Sie im Einblendmenü auf die Option „Eigenschaften“. Wählen Sie in der Liste der Verknüpfungen 802.2, und klicken Sie auf die Schaltfläche „Eigenschaften“. Klicken Sie dann auf das Register „Erweitert“, um die möglichen MAXDATA-Werte für 802.2 einzublenden: 256, 521, 1033, 1929 oder 2042.

Rumba/400 als TN5250-Client verwenden
Die mit Client Access für Windows 3.1 ausgelieferte 16-Bit-Version von Rumba/400 kann auch als TN5250-Client auf PCs mit Windows 95 oder NT eingesetzt werden. Um ein Installationsverzeichnis für alle an einen Netzwerkserver angeschlossenen Clients zu erstellen, müssen Sie die Verbindung zur AS/400 von einem PC mit Client Access aus herstellen, der ebenfalls an ein Netzwerklaufwerk auf Ihrem Server angeschlossen ist (NetWare oder NT). Vergewissern Sie sich, daß Laufwerk I der AS/400 zugeordnet ist. Kopieren Sie alle in Abbildung 1 aufgeführten Dateien und Verzeichnisse aus dem AS/400-Unterverzeichnis QDLS\QPWXCRB oder QDLS\QRUMBA auf den Server. Von dort können die Dateien auf jeden PC kopiert werden, der sich an den Server anschließen läßt. Für jeden Rechner, auf dem diese Version von Rumba/400 ausgeführt wird, ist eine eigene Client Access-Lizenz notwendig. Kopieren Sie alle Dateien, die zum Start von RUMBAWSF.EXE auf dem PC mit Windows 95 oder NT notwendig sind. Wählen Sie „Optionen“ und „Schnittstelle“ und anschließend „TN5250“. Klicken Sie auf „Konfigurieren“, und wählen Sie „Windows Sockets für Windows 95“. Klicken Sie dann auf „Sitzung“ und „Sitzung konfigurieren“, und geben Sie den IP-Namen oder die IP-Adresse der Ziel-AS/400 ein. Speichern Sie die Sitzung und fügen Sie sie einer Verknüpfung hinzu. Rumba meldet sich dann auf der AS/400 oder einem anderen TN5250-Server an.

Status der TCP/IP-Hostserver überprüfen
Die meisten Probleme bei der TCP/IP-Verbindung mit Client Access für Windows 95/NT entstehen, da die TCP/IP-Serverprogramme der AS/400 nicht gestartet wurden. Im Gegensatz zum automatisch gestarteten SNA-Server müssen TCP/IP-Server mit STRHOSTSVR (Hostserver starten) aufgerufen werden. Stellen Sie mit dem Programm cwbping, das als Teil von Client Access für Windows 95/NT ausgeliefert wird, fest, ob die Hostserver gestartet wurden. Geben Sie dazu folgenden Befehl ein:

 

cwbping [Systemname] [Protokoll]

Der Befehl stützt sich auf zwei optionale Parameter. Der erste Parameter ist der Systemname der AS/400, die aufgerufen werden soll. Ohne den Parameter verwendet das Programm den Standardnamen. Der zweite Parameter legt das Hostserver-Protokoll fest. Das Standardprotokoll ist IP, Sie können jedoch auch IPX wählen. Cwbping wird von der Befehlszeile in Windows 95 oder NT ausgegeben. Nach dem Start der TCP/IP-Hostserver wird die folgende Anzeige ausgegeben (leichte Abweichungen möglich):

[192.Ø.Ø.7]
pinging server Port Mapper successful
pinging server as-central successful
pinging server as-database successful
pinging server as-dtag successful
pinging server as-file successful
pinging server as-netprt successful
pinging server as-rmtcmd successful
pinging server as-signon successful
Beispiel: Wenn Sie sich mit Client Access für Windows 95/NT über TCP/IP nicht auf der AS/400 anmelden können und cwbping ausgibt, daß der TCP/IP-Anmeldeserver (as-signon) nicht aufgerufen werden konnte, wurde der TCP/IP-Anmeldeserver nicht gestartet. Starten Sie den Server mit folgendem Befehl:

STRHOSTSVR SERVER (*SIGNON)

SQL-Server-Importdatei mit CA-Dateitransfer erstellen
Sie können bei der Stapeldaten-Replikation von der AS/400 zur SQL-Server-Datenbank in Windows NT mit einer Kombination aus Client Access-Dateitransfer und der SQL-Server-Programmkomponente BCP (Bulk Copy Program) arbeiten. Sowohl das Client Access-Programm RTOPC als auch BCP werden direkt von den Stapeldateien aus ausgeführt. Dadurch läßt sich die Replikation leichter automatisieren. BCP ist ein Befehlszeilen-Programm, das den Import und Export großer Datenmengen von und zur SQL-Serverdatenbank ermöglicht. BCP unterstützt sowohl flache Dateien als auch verschiedene Arten begrenzter Dateien. Die gesamte numerische Eingabe muß dabei im Anzeigeformat erfolgen. Dies gilt auch für Dezimalpunkte und alle negativen Zeichen in den Daten. Die ASCII-Textdatei-Ausgabeoption der Client Access-Dateitransfer-Funktion ermöglicht, eine flache Textdatei in einem Anzeigeformat zu erstellen, das für das BCP-Programm des SQL-Servers erforderlich ist. Hinweis: Beim Erstellen der SQL-Server-Importdatei sollten Sie sich vergewissern, daß die numerischen Felder groß genug für Dezimalpunkte und/oder andere negative Zeichen sind. Die numerischen Definitionen in der BCP-Datei sollten zwei Positionen größer sein als das Datenbankfeld.

FTP-Server-Anmeldeaufforderungen werden nicht angezeigt
Wenn Remote-Benutzer die Verbindung mit Ihrem FTP-Server ohne Anmeldeaufforderung herstellen können, liegt voraussichtlich ein Fehler bei der Konfiguration von DNS vor. Überprüfen Sie zunächst, ob der FTP-Servername korrekt auf der AS/400 eingegeben wurde. Gehen wir davon aus, daß der FTP-Server der AS/400 den Namen MAIN.ACMEWIDEGETS.COM hat. Bei der Konfiguration des Servernamens auf der AS/400 über Option 12 im Befehlsmenü CFGTCP (TCP/IP konfigurieren) müssen Sie diesen Namen in seiner voll-qualifizierten Form eingeben � d.h. nicht nur den Hostnamen MAIN. Internet-DNS-Server müssen in der Lage sein, diesen Namen in die aktuelle IP-Adresse des Servers umzuwandeln. Häufig wird ein DNS-Alias für MAIN.ACMEWIDEGETS.COM mit dem Namen FTP.ACMEWIDGETS.COM auf dem DNS-Server erstellt. Danach wird aber oft vergessen, den tatsächlichen DNS-Adreßeintrag für MAIN.ACMEWIDEGETS.COM zu erstellen. Ohne diesen Adreßeintrag blendet der DNS-Server die Anmeldeaufforderung nicht ein. Kurzfristig können Sie das Problem umgehen, indem Sie einen Hosttabellen-Eintrag (CFGTCP-Menü, Option 10) für MAIN.ACMEWIDEGETS.COM mit der korrekten IP-Adresse erstellen. Ändern Sie dann im CFGTCP-Menü in Option 13 den Parameter für Searched First auf *LOCAL. Dadurch wird die AS/400 gezwungen, vor der DNS-Abfrage die lokale Tabelle zu durchsuchen. Sie können feststellen, ob DNS ordnungsgemäß arbeitet, indem Sie PING von der AS/400 aus starten und dabei den voll-qualifizierten Namen verwenden. Z.B.:

PING MAIN.ACMEWIDGETS.COM

Dadurch wird OS/400 gezwungen, den Namen einer Zahl zuzuordnen. Ist dies nicht möglich, kann PING nicht ausgeführt werden, und es wird ein Fehler bei der Namenszuordnung ausgegeben.

AS/400 und Java im Web
Wenn Sie mehr über Java und die AS/400 wissen wollen, sollten Sie sich die folgende Webseite ansehen: http://www.software.ibm.com/ad/as400/vajava. Hier können Sie IBMs AS/400 Toolbox für Java herunterladen. Außerdem erfahren Sie auf dieser Seite mehr über die Toolbox und wie sie sich in VisualAge für Java integrieren läßt. Die Seite läßt keinen Zweifel daran, daß IBM sich für VisualAge für Java als Entwicklungstool für die AS/400 entschieden hat.

Handbücher zur AS/400 im Internet
Wenn Sie professionell mit der AS/400 arbeiten, sollten Sie sich folgende Website nicht entgehen lassen: http://as400bks.rochester.ibm.com. Hier finden Sie alles Wichtige zur AS/400. Sie können online nach elektronischen Handbüchern zu V3R2, V3R6, V3R7 und V4R1 suchen und viele Redbooks der International Technical Support Organization (ITSO) zur AS/400 einsehen. Fügen Sie einfach Lesezeichen für die gewünschte Buchreihe oder den Titel ein, um sich beim nächsten Surfen die zeitraubende Suche zu sparen.

Langsame Anwortzeiten des Webservers
Wenn Sie IBMs Internet Connection Server (früher HTTP-Server) als Webserver auf Ihrer AS/400 einsetzen und Remote-Anwender sich über langsame Antwortzeiten beklagen � von Zehntelsekunden bis hin zu mehreren Minuten pro Seite � ist wahrscheinlich der DNS-Server falsch konfiguriert. Wenn ein Remote-Anwender die Verbindung mit Ihrem Webserver herstellt, führt der Server automatisch eine DNS-Suche (genannt Reverse Name Look-up) auf der IP-Adresse des Remote-Systems durch. Falls Sie über keinen lokalen Internet-fähigen DNS-Server verfügen oder der DNS-Server falsch konfiguriert ist, erfolgt nach 30 Sekunden eine Zeitüberschreitung. Der Webserver erhält die Meldung „nicht gefunden“. Der Server kann dann nur solange fortfahren, bis er das nächste Objekt an denselben Anwender ausgegeben hat. Danach führt er erneut einen Suchvorgang durch. Der DNS-Server muß neu konfiguriert werden, damit die Suche fehlerfrei erfolgt. Kurzfristig können Sie das Problem umgehen, indem Sie der AS/400-Konfigurationsdatei folgende Anweisung hinzufügen:

Dnslookup Off

Wenn bereits die Anweisung Dnslookup On vorhanden ist, müssen Sie lediglich On in Off ändern. Andernfalls kann die Anweisung an beliebiger Stelle in der Datei eingefügt werden, außer innerhalb einer Definition für eine mehrzeilige Anweisung. Dnslookup Off veranlaßt, daß die Domänennamen der anfragenden Remote-Anwender in der ICS-Anmeldedatei nicht abgemeldet werden können. (Lesen Sie auch „Make an Internet Name for Yourself with DNS“ , May 1997 und „Setting up your Own DNS Server“, August 1997.)

Langsame Anwortzeiten des Webservers � Teil 2
Ein weiterer Grund für den langsamen Web-Zugriff ist ein Internet-weites Problem bei der Zuordnung der Namen von Ihrer IP-Adresse. Wenn ein Client die Verbindung mit einem fernen Webserver herstellt, führt der Server in der Regel eine DNS-Suche (Reverse Name Look-up) auf der IP-Adresse des Client durch, um das System zu ermitteln, das auf den Server zugreift. Wenn Ihre Internet-leitbaren IP-Adressen nicht in der Domäne „Inverse Address“ (IN-ADDR.ARPA) des DNS-Servers für Ihren Internet-Dienst aufgeführt sind, erfolgt nach 30 Sekunden eine Zeitüberschreitung. Die Meldung „nicht gefunden“ wird an den Webserver ausgegeben. Der Webserver kann nur solange fortfahren, bis er das nächste Web-Objekt an denselben Anwender ausgegeben hat. Danach versucht der Server erneut, einen Suchvorgang durchzuführen. Führen Sie NSLOOKUP für eine Ihrer IP-Adressen aus, um festzustellen, ob die langen Antwortzeiten auf diese Weise verursacht werden. NSLOOKUP ist Teil von Windows NT und ein optionales Dienstprogramm in Windows 95 (OS/400 unterstützt das Programm nicht). Geben Sie folgendes ein, wenn eine Ihrer IP-Adressen 199.245.140.200 ist:

NSLOOKUP 199.245.14Ø.2ØØ

Sie sollten die Antwort einige Sekunden später zusammen mit dem Domänennamen erhalten, der dieser Adresse entspricht. Falls nach einer längeren Pause die Meldung „nicht gefunden“ ausgegeben wird, ist bei der Suche nach Ihrer IP-Adresse ein Fehler aufgetreten. Überprüfen Sie die IP-Adressen, die der Internet-Dienst Ihnen zugewiesen hat, einzeln. Unter Umständen werden einige Adressen gefunden.

Korrekte Zeitstempel für Internet-Mail
Wenn Sie glauben, daß die Zeitangaben bei AS/400-Nachrichten an das Internet falsch sind, sollten Sie den Systemwert QUTCOFFSET überprüfen. Der Wert legt den Zeitstempel für Ihre Zeitzone relativ zur Greenwich-Zeit (GMT) fest. Der Standardwert für QUTCOFFSET ist +00:00. Der GMT-Offset ist ein notwendiger Bestandteil des Mail-Headers unter SMTP (Simple Mail Transfer Protocol). Der Mail-Client des Empfängers verwendet die Zahl, um die Meldungen in der Uhrzeit seiner Zeitzone anzuzeigen. Durch die richtige Einstellung unter QUTCOFFSET wird sichergestellt, daß der Zeitstempel der Internet Mail immer korrekt ist. Wählen Sie für die mitteleuropäische Zeit den Wert +01:00. Die internen AS/400-Zeitstempel werden durch den QUTCOFFSET-Wert nicht beeinflußt.

Visual Basic 4.0- und 5.0 Byte-Felder für ODBC-gebundene Parameter verwenden
Eine der Hauptschwierigkeiten bei der Verwendung des Open Database Connectivity (ODBC) API von Visual Basic ist die Handhabung der Bindungsparameter. Dies gilt insbesondere für Zeichenfelder in Zeichenfolgenvariablen. Diese Variablen verursachen Probleme, da die beiden API-Funktionen SQLBindParameter und SQLBindCoL verlangen, daß die Adresse einer Variablen konstant bleibt. Visual Basic kann jedoch den Speicherort der Zeichenfolge verschieben, wenn bestimmte Zeichenfolgenoperationen durchgeführt werden. Eine Lösung ist die Verwendung des in VB 4.0 eingeführten neuen Byte-Datentpys. Sie können für SQLBindParameter oder SQLBindCoL statt der Zeichenfolgenvariable ein Byte-Feld verwenden. Der folgende Code zeigt ein Byte-Datenfeld mit SQLBindCol:

Dim bMyCoLumn(256) As Byte
Dim lMyCoLumn(256) As Long
result% = SQLBindCoL <hstmt, 1, SQL_C_CHAR,
bMyCoLumn(Ø), 256 (MyCoLumnLen)


Im Gegensatz zu den Zeichenfolgenvariablen werden die Byte-Datenfelder durch VB nicht im Speicher verschoben, so daß die Adresse des Byte-Datenfeldes konstant bleibt. Verwenden Sie die Funktion StrConv, um Daten zwischen VB-Zeichenfolgenvariablen und Byte-Datenfeldern auszutauschen. Weitere Informationen über das OBDC API und gebundene Parameter finden Sie unter „Using the ODBC API und Visual Basic“, Juni 1997.)

 

 

Clients eindeutig identifizieren
In Client/Server-Anwendungen, in denen ein Server mehrere Clients verwaltet, müssen die Clients eindeutig identifiziert werden. Bei APPC-Anwendungen sollten Sie hierzu die Namen der logischen Einheit (LU) verwenden. Dieser Name muß für jeden angeschlossenen PC eindeutig sein. Sie können den Namen mit der APPC-Funktion EHN APPC_Get Attributes des API dynamisch ermitteln. Allerdings bietet keine der anderen Client Access APIs den direkten Zugriff auf den Namen der logischen Einheit.
In vielen Datenwarteschlangen-Anwendungen müssen die einzelnen Client-Systeme eindeutig identifiziert werden. Bei Datenschlangen-Anwendungen in Umgebungen mit mehreren Clients ermittelt ein Serverprogramm auf der AS/400 alle Einträge, die über eine Warteschlange eines gemeinsamen Servers eingehen, und schreibt die Einträge dann in die private Antwort-Datenschlange der einzelnen Clients. Im Idealfall wird so für jedes Client-Programm dynamisch eine eindeutige private Datenschlange erstellt, während das Programm mit dem Server verbunden ist. Leider können Sie dabei nicht auf Informationen zur Sender-ID zurückgreifen, die zusammen mit der Datenschlange abgerufen werden. Diese Informationen sind nur für die Anwendung verfügbar, die den Datenschlangeneintrag erhält. (Sie können festlegen, ob Sender-ID-Informationen, z.B. das Benutzerprofil des Senders und der qualifizierte Auftragsname, automatisch mit dem Parameter SENDERID im Befehl CRTDTAQ (Datenschlange erstellen) an jeden Datenschlangeneintrag angefügt werden sollen.)
Verwenden Sie die Windows-Zugriffsnummer der Client-Anwendung, um eindeutige Datenschlangen zu erhalten. Die Client-Anwendung hat Zugriff auf diese Nummer und kann sie über die Eingabe-Datenschlange an den Server senden. Obwohl keine Garantie dafür besteht, daß alle Windows-Zugriffsnummern eindeutig sind, ist es unwahrscheinlich, daß die Nummer zwischen mehreren Systemen doppelt ausgegeben wird.
Neben der dynamischen LU und der Windows-Zugriffsnummer können Sie das Client-System durch statische Konfigurationsdaten kennzeichnen. Bei Client Access für Windows 3.1-Router befinden sich diese Informationen in der Datei NSD.INI im [Konfigurationsabschnitt] im Eintrag LOCALLUNAME =. Bei Client Access für Windows 95/NT-Router finden Sie die Informationen im Registry-Wert „PCLocationName“ unter

[HKEY_CURRENT_USER\Software\Netsoft\NS/Elite\CurrentVersion\
Workspaces\system-name\Engines\NS/Router\workspace-name].

Das Extrahieren des PC-Standortnamens aus dem Registry oder der NSD.INI ist aufwendiger als die Verwendung der Windows-Zugriffsnummer, garantiert aber eine eindeutige Kennzeichnung.

ODBC-Leistungsprobleme mit PRTSQLINF untersuchen
Wenn die Leistung bei ODBC-Anwendungen auffällig langsam ist � insbesondere bei größeren Dateien � greift ODBC unter Umständen sequentiell und nicht per Schlüssel auf die Dateien zu. Durch die sequentielle Bearbeitung wird die Performance deutlich herabgesetzt. Mit dem Client Access ODBC-Treiber können Sie den Befehl PRTSQLINF (SQL-Informationen drucken) ausführen und ermitteln, mit welcher Dateizugriffsmethode ODBC arbeitet. Geben Sie folgendes in die AS/400-Befehlszeile ein, um den Befehl auszuführen:

PRTSQLINF sqlpackagename *SQLPKG

Standardmäßig werden die Client Access SQL-Pakete in der QGPL-Bibliothek erstellt � im Normalfall ein *SQLPKG-Objekt für jede Client-Anwendung. Obwohl die SQL-Pakete verschlüsselt sind, ist der Name der Anwendung erkennbar. Wenn Sie den Client Access ODBC-Treiber mit Microsoft Query verwenden, wird ein SQL-Paket namens MSQRY32FBA erstellt. Wenn Sie ODBC in einer Visual Basic-Umgebung einsetzen, wird ein SQL-Paket namens VB32FBA erstellt. Abbildung 2 zeigt die Beispielsausgabe für den Befehl PRTSQLINF. Die PRTSQLINF-Spooldateiliste enthält die ausgeführte SQL-Anweisung, das Erstelldatum des Zugriffsplans, das Öffnungsverfahren (in den Zeilen, die mit „Arrival Sequence“ starten, Zeilen 7 bis 15) und die gültigen Verbindungsbedingungen. Die Ankunftssequenzzeilen in dem Beispiel zeigen, daß ODBC sequentiell auf die Datei zugreift. Daß eine Datei anders als erwartet geöffnet wird, kann auf unterschiedlichen Faktoren beruhen. Einer der häufigsten Gründe ist, daß zum Zeitpunkt, als das *SQLPKG-Objekt erstellt wurde, noch kein Zugriffsplan existierte. Löschen Sie das *SQLPKG-Objekt. Das *SQLPKG und sein Zugriffsplan werden automatisch neu erstellt, sobald die Anwendung erneut ausgeführt wird. Sie können dann die SQL und die Dateizugriffsmethoden neu überprüfen, indem Sie den Befehl PRTSQLINF noch einmal ausführen. Die Anwendung sollte einmal mit den Produktionsdaten laufen, bevor Sie PRTSQLINF ausführen, da der Zugriffsplan erst fertiggestellt wird, nachdem der Befehl einmal ausgeführt wurde. Wenn Sie den Befehl nur mit Testdaten laufen lassen, erhalten Sie eventuell falsche Ergebnisse, da der Zugriffsplan bei jeder Änderung der Zugriffsdateien neu erstellt wird.

AS/400-Datenbankdateien mit FTP übertragen
Um eine oder mehrere V3R7- oder V3R2-AS/400-Datenbankdateien � einschließlich aller Datei- und Feldattribute � mit FTP an eine andere AS/400 zu übertragen, sollten Sie die Datei(en) zunächst mit dem Befehl SAVOBJ (Objekt speichern) und dem Parameter DEV(*SAVF) abspeichern. Erstellen Sie dann mit CRTSAVF (Sicherungsdatei erstellen) eine leere gleichnamige Sicherungsdatei auf der Ziel-AS/400. Danach können Sie die Originaldatei an die Ziel-AS/400 senden. Vergessen Sie nicht, dabei den FTP-Befehl BINARY einzugeben, bevor Sie PUT ausgeben. Andernfalls wird die Datei während der Übertragung beschädigt. Um die Sicherungsdatei XSAVET auf die AS/400-Sicherungsdatei XSAVE in der Bibliothek QGPL zu übertragen, müssen Sie folgendes eingeben:

BINARY
PUT XSAVET QGPL/XSAVE

Beenden Sie das FTP-Programm und stellen Sie die Datei(en) auf der Ziel-AS/400 von den Sicherungsdateien aus wieder her, indem Sie den Befehl RSTOBJ (Objekt wiederherstellen) mit DEV(*SAVF) eingeben. Mit diesem Verfahren lassen sich alle OS/400-Objektarten in beliebiger Kombination übertragen. Die Übertragung von Sicherungsdateien mit FTP wird erst nach V3R1 unterstützt.

CL-Programm zum Start der TCP/IP-Hostserver
Wie bereits unter „Statusüberprüfung des TCP/IP-Hostservers“ gezeigt, müssen die TCP/IP-Hostserver manuell gestartet werden, bevor PC-Clients die Verbindung mit der AS/400 herstellen können. TCP/IP selbst muß ebenfalls manuell auf der AS/400 gestartet werden. Um dies zu vereinfachen, habe ich ein einfaches CL-Programm mit Namen STRALLTCP geschrieben, das am Ende des Startprogramms QSTRTUP aufgerufen wird. STRALLTCP führt zunächst den Befehl STRTCP (TCP/IP starten) aus, um die TCP/IP-Unterstützung auf der AS/400 zu aktivieren. Anschließend wird der Befehl STRHOSTSVR (Hostserver starten) aufgerufen, mit dem alle Client Access TCP/IP-Server gestartet werden.

/* ===================================*/
/* STRALLTCP */
/* THIS PROGRAM STARTS TCP/IP AS WELL */
/* AS ALL TCP/IP HOST SERVERS */
/* ==================================*/
PGM
STRTCP
STRHOSTSVR SERVER(*ALL)
ENDPGM


Konvertierungsprogramm durch Eingabe von FTP-Befehlen starten
Der in OS/400 V3R1 und höher unterstützte FTP-Befehl bietet einen High-Speed- Mechanismus zur Übertragung kompletter Datenbankdateien zwischen der AS/400 und anderen angeschlossenen TCP/IP-Systemen. Wenn Sie die Daten von der AS/400 an ein Unix-System oder einen PC senden, müssen Sie die gepackten und binären Felder in Anzeigetypdaten umwandeln. Häufig verlangt das Empfangssystem Kommas, Dezimalpunkte und sogar Führungszeichen für numerische Daten. Eine Möglichkeit, diese Zeichen zu generieren, ist die Verwendung eines allgemeinen RPG- oder Cobol-Programms. Damit werden die Originaldateien bearbeitet und in einer Datei ausgegeben, die übertragen werden kann. Die Frage ist, wie das Konvertierungsprogramm vor der Übertragung automatisch gestartet werden kann. Eine Möglichkeit sind die FTP-Unterbefehle QUOTE und RCMD. Das folgende FTP-Beispielskript verwendet RCMD, um ein angepaßtes Konvertierungsprogramm auszuführen. Danach wird die konvertierte Datei mit FTP übertragen:

open S1Ø1AAØA
mikeo
xxxxx
quote rcmd call odbcdemo/empcopy
get odbcdemo/empftp
quit


Die erste Zeile öffnet die FTP-Verbindung zum Zielsystem. Die zweite und dritte Zeile enthalten die Benutzer-ID und das entsprechende Kennwort. Die vierte Zeile verwendet die FTP-Unterbefehle QUOTE und RCMD, mit denen das angepaßte Programm EMPCOPY auf der Ziel-AS/400 ausgeführt wird. EMPCOPY gibt die Datei EMPFTP aus, die der FTP-Befehl GET in der fünften Zeile abruft. Durch QUIT wird die FTP-Verbindung beendet. Sie können das hier beschriebene Skript zusammen mit dem Befehl CPYTORMTF verwenden, der in „Convert AS/400 Data for FTP, November 1997) beschrieben ist. CPYTORMTF bereitet die AS/400-Daten vor, die mit FTP übertragen werden sollen. Das Programm konvertiert die Daten, so daß sie von PCs, Mainframes und Unix-Systemen gelesen werden können. Geben Sie die von CPYTORMTF erwarteten Parameter ein, wenn das Skript zusammen mit CPYTORMTF ausgeführt werden soll. Sie müssen dann nicht für jede Datei, die mit QUOTE RCMD übertragen werden soll, ein anderes Programm aufrufen. Das folgende FTP-Skript zeigt, wie Sie mit CPYTORMTF die EMPFTP-Datei als Tabelle ausgeben können, die von System S101AA0A abgerufen werden soll:

open S1Ø1AAØA
mikeo
xxxxx
quote rcmd CPYTORMTF FROMFILE(EMPMST) +
TOFILE (ODBCDEMO/EMPFTP) +
RMTFMT( *TBL ) FIELDS( *ALL )
get odbcdemo/empftp
quit


Automatisches FTP von der AS/400 aus
Für eine automatische FTP-Dateiübertragung von einer AS/400 mit einem Skript müssen Sie zunächst die folgenden Skript-Befehle im Quelldateimitglied FTPCMDS eingeben:

USER PASSWORD
PUT FROMTEST/TEST TOTEST/TEST
QUIT


Die erste Zeile enthält Ihr Anwenderprofil und das Kennwort des Hostsystems. Die folgenden Zeilen können jeden beliebigen gültigen FTP-Befehl enthalten. In diesem Beispiel wird die Datei TEST in der Bibliothek FROMTEST an die Bibliothek TOTEST auf dem Hostsystem gesendet. Die letzte Zeile ist QUIT, ein FTP-Befehl, der die FTP-Sitzung beendet. Im nächsten Schritt wird ein CL-Programm erstellt:

PGM
OVRDBF FILE(INPUT) TOFILE(TSSRC)
MBR(FTPCMDS)
OVRDBF FILE(OUTPUT) TOFILE(TSSRC) MBR(OUT)
FTP HOST
ENDPGM


Der erste OVRDBF-Befehl (Mit Datenbankdatei überschreiben) veranlaßt FTP, die Befehle von Mitglied FTPCMDS in der Quelldatei TSSRC abzurufen. Mit dem zweiten OVRDBF-Befehl werden alle vom Host empfangenen Nachrichten an Mitglied OUT in der Quelldatei TSSRC ausgegeben. Das Programm sendet dann die Hostsite mit Namen HOST, und die Datei(en) werden übertragen.
Sie können auch ein RPG- Programm oder ein anderes HLL-Programm schreiben, das die FTP-Befehle dynamisch in einer Datei erstellt und von dort mit dem Befehl CPYF (Datei kopieren) mit dem Parameter FMTOPT(*CVTSRC) an die Quelldatei ausgibt.

IP-Druck auf der AS/400
Wenn Sie mit IP von einer AS/400 aus Daten an einen ASCII-Drucker senden möchten, müssen Sie zunächst mit folgendem Befehl eine Ausgabe-Warteschlange erstellen:

CRTOUTQ OUTQ(IPLASER1) +
RMTSYS(*INTNETADR) +
RMTPRTQ('IPLASER1') +
CNNTYPE(*IP) +
DESTTYPE(*OTHER) +
TRANSFORM(*YES) +
MFRTYPMDL(*HP4) +
INTNETADR('123.456.789.Ø12') +
TEXT('IP REMOTE PRINTER') +


Achten Sie darauf, daß die IP-Adresse Ihrer AS/400 als INTNETADR-Parameter verwendet wird. Erstellen Sie dann einen Datenbereich, um die zusätzlich ausgedruckte Footer-Seite zu steuern, die von der AS/400 generiert wird. Geben Sie dazu folgenden Befehl ein:

CRTDTAARA DTAARA(QTCP/QTMPLPR +
TYPE(*CHAR) +
AUT(*USE) +
LEN(1) +


Geben Sie folgenden Befehl ein, um die Footer-Seite zu drucken:

CHGDTAARA DTAARA(QTCP/QTMPLPR +
(1 1)) VALUE(' ') +


Geben Sie folgendes ein, wenn die Footer-Seite nicht gedruckt werden soll:

CHGDTAARA DTAARA(QTCP/QTMPLPR +
(1 1)) VALUE('N') +


Verwenden Sie den Befehl STRRMTWTR (Remote-Drucker starten), um auf einem IP-Remote-Drucker zu drucken.
Verschiedene verfügbare PTFs erleichtern den Druck komplexer Grafiken auf IP-Druckern. Hierzu zählen unter anderem SF40782 für das Lizenzprogramm 5716-TC1 (V3R7) und SF41803 sowie SF4040 für 5716-TC1 (V3R6).

FTP-Übertragungen von und zu Sicherungsdateien
FTP macht den Datenaustausch von und zur AS/400 über das Internet besonders leicht. Sie können die Daten von Sicherungsdateien an Datenstromdateien übertragen und umgekehrt. Das folgende Beispiel zeigt, wie Sie bestimmte Software an Remote-Kunden verteilen:

 

1. Speichern Sie die Bibliothek in einer Sicherungsdatei.
2. Übertragen Sie die Sicherungsdatei mit FTP an eine Datenstromdatei.
3. Die Kunden können die Datenstromdatei per Internet, per Mailbox oder über eine direkte Verbindung herunterladen.
4. Die Kunden verwenden FTP, um die Datenstromdatei wieder an eine AS/400-Sicherungsdatei zu übertragen.
5. Die Kunden stellen die Bibliothek von der Sicherungsdatei aus wieder her.

IBM verteilt mit diesem Verfahren Produkte wie die Betaversion von Java Virtual Machine für die AS/400 oder die Produktionsversion von Network Station Manager.

Die Suche nach AS/400 Client/Server-Aufträgen
Beim Testen und Debuggen der Client/Server-Aufträge ist es oft hilfreich, die AS/400-Auftragsprotokolle einzusehen. Die Suche nach Auftragsprotokollen für bestimmte Dienste wie Open Database Connectivity kann recht mühsam sein, da AS/400-Serveraufträge für Standardanwender (z.B. QUSER) gestartet werden, wobei der Auftragsname QZDAINIT ist. Bei Systemen mit vielen Benutzern ist die Suche nach bestimmten Aufträgen oft kompliziert, da die Aufträge alle gleich aussehen. Sie können entweder das Protokoll für jeden Auftrag überprüfen oder sich die Arbeit mit dem folgenden Befehl erleichtern:

WRKCFGSTS *CTL PCName

PCName ist der konfigurierte Name des PCs, von dem aus die Client/Server-Anwendung initiiert wurde. Der Befehl gibt alle Aufträge aus, die auf diesem PC initiiert wurden. Dies gilt auch für Workstation-Sitzungen und Client/Server-Aufträge für alle Dienste. Die Laufzeit der einzelnen Aufträge wird mit Option 5 – WRKCFGSTS angezeigt.

Verwaiste Aufträge löschen
Beim Testen und Debuggen von Client/Server-Programmen bleiben oft viele verwaiste Aufträge auf der AS/400 zurück. Die verwaisten Aufträge entstehen durch Programmabstürze von Client-Anwendungen bei der Programmentwicklung. Um verwaiste Aufträge eines angeschlossenen PCs definitiv zu erkennen, sollten Sie sich das Auftragsprotokoll für jeden Auftrag anzeigen lassen (siehe vorherigen Abschnitt). Nachdem Sie die Programmierungsfehler ermittelt haben, können Sie die verwaisten Aufträge über den Befehl ENDJOB mit den Parametern OPTION(*IMMED) und LOGLMT(0) terminieren. Der folgende Befehl beendet sofort alle Aufträge:

ENDJOB OPTION(*IMMED) LOGLMT(Ø)

LOGLMT(0) teilt OS/400 mit, keine Auftragsprotokolle zu erstellen. Dies erspart Ihnen das Löschen der gespoolten Dateien.

Remote-Diagnose mit STRCYSCN
Mit dem Befehl STRCYSCN (Anzeigekopie starten) können Sie lokale oder entfernte Anwender während der Ausführung einer 5250-Anwendung überwachen. Der Befehl kopiert die 5250-Anzeige von einem Ziel-5250-Anzeigegerät und gibt sie an ein 5250-Anzeigegerät oder an eine Datei aus. Die Ausgabedatei wird, falls notwendig erstellt. Führen Sie STRCYSCN wie folgt aus, um die Anzeige an ein 5250-Terminal auszugeben:

STRCYSCN targetdevice

Bevor STRCYSCN mit der Ausgabe der Anzeige beginnt, wird eine Pausenmeldung an das Zielgerät ausgegeben.
Der Nachteil von STRCYSCN ist, daß der Befehl immer eine Anzeige hinter der des Zielanwenders zurückbleibt. Der Vorteil ist, daß der Befehl als Teil von OS/400 auf jedem 5250-Terminal ausgeführt werden kann. Für Microsoft NetMeeting ist ein PC notwendig.

IFS-Objekte über SNADS übertragen
Wenn Sie IFS-Verzeichnisse oder Datenstromdateien von einer zur anderen AS/400 kopieren müssen, sollten Sie den Befehl SAV (Speichern) verwenden. Die Objekte werden in einer Sicherungsdatei gespeichert, und diese Datei wird über SNADS an die Remote-AS/400 gesendet. Mit folgendem Code können Sie das im IFS-Stammverzeichnis residente Verzeichnis MYDIR in der Sicherungsdatei MYSAVF in der Bibliothek MYLIB speichern:

SAV DEV('/QSYS.LIB/MYLIB.LIB/ +
MYSAVF.FILE') OBJ(('/MYDIR'))


Senden Sie die Sicherungsdatei mit dem Befehl SNDNETF (Netzwerkdatei senden) an das Remote-System. Führen Sie auf dem Remote-System RCVNETF (Netzwerkdatei empfangen) aus, um die Netzwerkdatei in eine bereits vorhandene Sicherungsdatei auf dem Zielsystem zu kopieren. Stellen Sie anschließend das IFS-Verzeichnis und seinen gesamten Inhalt mit folgendem Befehl wieder her:

RST DEV('/QSYS.LIB/MYLIB.LIB/ +
MYSAVF.FILE') OBJ(('/MYDIR'))