Tech Corner

Tips von verschiedenen Autoren

QCMD-Problem im Batch-Modus

Frage

Ich habe ein CL-Programm, das unter anderem die Aufgabe hat, Anforderungsnachrichten zu verarbeiten. Nach der Verarbeitung soll das Programm mit anderen Aufgaben fortfahren. Im interaktiven Betrieb funktioniert das reibungslos, aber sobald das Programm im Batch läuft, bricht es nach der Verarbeitung der Anforderungsnachrichten einfach ab. Ich erhalte keinerlei Fehlermeldung. Ich habe die Protokollierungsstufe für den Job heraufgesetzt, um detailliertere Informationen zu bekommen, aber ich kann keine Fehlermeldung finden. Was mache ich falsch?

Antwort

QCMD ist der Befehls-Analyzer und –Prozessor von OS/400. Er reagiert auf Anforderungsnachrichten in der externen Nachrichtenwarteschlange eines Jobs. Interaktiv aufgerufen, sucht QCMD alle Anforderungsnachrichten in der externen Nachrichtenwarteschlange eines Jobs, führt diese aus und zeigt anschließend den Befehlseingabebildschirm an. Sobald der Benutzer die Befehlseingabe verläßt, wird das Programm fortgesetzt, von dem aus QCMD aufgerufen wurde. Im Batch-Modus sucht QCMD alle Anforderungsnachrichten in der externen Nachrichtenwarteschlange eines Jobs, führt diese aus und beendet den Job. Dieses Verhalten ist normal. Da QCMD ein Befehlsprozessor für Anforderungsnachrichten ist,  geht man davon aus, daß keine weiteren Befehlsanforderungen folgen, sobald das Ende der externen Jobnachrichtenwarteschlange erreicht ist, und der Job wird beendet. Sehen Sie sich das Beispiel in Abbildung 1 an: Im interaktiven Modus würde QCMD erst das Benutzerprofil QSYSOPR anzeigen, dann das Benutzerprofil QSECOFR und zuletzt den Befehlseingabebildschirm. Nach dem Verlassen der Befehlseingabe zeigt das Programm das Benutzerprofil YourPrf an und endet dann. Im Batch-Modus druckt das Programm das Benutzerprofil QSYSOPR, dann das Benutzerprofil QSECOFR und endet anschließend, da keine weiteren Anforderungsnachrichten vorliegen.

Berechnen der Leitungsgeschwindigkeit für ferne Drucker

Frage

Einige Zweigniederlassungen unserer Firma sind über Standleitungen mit der AS/400 in der Zentrale verbunden. Wir wollen, daß die Benutzer in den Zweigstellen ihre Berichte (teils 132-spaltig, teils auf Formularvordrucken) von der zentralen AS/400 auf ihre fernen Drucker ausgeben können . Wie ermitteln wir die Leitungsgeschwindigkeit, die wir für das Drucken benötigen?

Antwort
Nehmen wir an, die Anwendungsdaten enthalten etwa 6 KB pro Seite. Das wäre in etwa angemessen für einen 132-spaltigen Bericht und vielleicht etwas großzügig für einen Formularvordruck. Als Nächstes müssen Sie die Druckgeschwindigkeit des Zieldruckers berücksichtigen. Nehmen wir an, Sie wollen 20 Seiten pro Minute drucken. Daraus ergibt sich ein Volumen von 120.000 Bytes pro Minute oder 2.000 Bytes pro Sekunde. Eine Leitung mit 19.200 baud (etwa 2.200 Bytes pro Sekunde) würde also ausreichen, um die Anwendung mit einem 20-Seiten-Drucker zu betreiben. Für einen schnelleren Drucker müßten Sie sich nach einer schnelleren Kommunikationsverbindung umsehen.

Bestimmte Jobs beenden

Frage

Ich suche nach einer Möglichkeit, eine AS/400-Sitzung abzubrechen, wenn in einem bestimmten Menü oder Programm keine Aktivität festgestellt wird. Ich kann den Sys-temwert QINACTITV nicht verwenden, weil ich nur Sitzungen beenden will, die dieses Menü oder bestimmte Programme benutzen. Wie kann ich am Besten feststellen, wann die letzte Aktivität vorkam?

Antwort

OS/400 bietet zwar keine Möglichkeit, den Systemwert QINACTITV auf bestimmte Jobs anzuwenden, aber Sie können trotzdem die Systemwerte QINACTITV und QINACTMSGQ verwenden, um Jobs nach eine bestimmten Inaktivitätsdauer zu beenden. Dazu müssen Sie sich aber einige Programme schreiben. Erstellen Sie eine Nachrichtenwarteschlange zum Empfangen von Inaktivitätsmeldungen, und setzen Sie QINACTMSGQ, so daß diese Nachrichtenwarteschlange verwendet wird. Ist ein Job für die in QINACTITV angegebene Zeitspanne inaktiv, wird die Nachricht CPI1126 an diese Nachrichtenwarteschlange gesendet. Sie können ein Endlosprogramm schreiben, das die Nachrichtenwarteschlange überwacht und mit dem Befehl RCVMSG WAIT(*MAX) alle ankommenden Nachrichten auswertet. Ist die Nachrichten-ID nicht CPI1126, gehen Sie einfach wieder zum Schleifenanfang mit der RCVMSG-Anweisung. Sobald eine Nachricht mit der ID CPI1126 ankommt, können Sie damit den inaktiven Job identifizieren. Mit einem weiteren Programm, das mit Work-Management-APIs arbeitet, können Sie Job-Informationen abrufen und z.B. feststellen, welches Programm gerade ausgeführt wird. Sobald Sie diese Informationen haben, kann Ihr Programm entsprechend reagieren, also entweder die Nachricht ignorieren oder den Job beenden.

DB2/400-Wartung

Frage

Ich bin für die Wartung einer DB2/400-Datenbank auf einer AS/400e unter OS/400 V3 verantwortlich. Gibt es routinemäßige Wartungsprozeduren, die in bestimmten Abständen augeführt werden sollten, wie z.B. Neuerstellung der Indizes und Reorganisieren der Tabellen? Gibt es Techniken, die sicherstellen, daß die Datenbank-Performance nicht mit der Zeit nachläßt?

Antwort

Die Datenbank-Performance läßt prinzipiell nicht nach, solange Sie über Schlüssel zugreifen. Bei sequentiellen, ungeschlüsselten Zugriffen können Sie jedoch Performance-Einbußen feststellen, wenn die Datei viele gelöschte Sätze enthält. Sie können den Befehl RGZPFM verwenden, um eine Datei zu reorganisieren und gelöschte Datensätze zu entfernen (mehr zu RGZPFM weiter unten). Ein weiteres Wartungs-Thema ist die Plattenbelegung. Wenn Sie beim Erstellen von physischen Dateien die Standardwerte verwenden, wird das System gelöschte Datensätze nicht wiederverwenden, was im Lauf der Zeit zur Verschwendung von Plattenspeicher führt. Wie bereits erwähnt, können Sie den verschwendeten Platz mit dem Befehl RGZPFM zurückgewinnen. Je nachdem, wie groß eine Datei ist und wieviele Zugriffspfade (für logische Dateien) neu aufzubauen sind, kann RGZPFM relativ viel Zeit beanspruchen. Eine andere Möglichkeit wäre, den Parameter REUSEDLT(*YES) zu verwenden, wenn mit CRTPF eine neue physische Datei erstellt wird, und die vorhandenen mit dem Befehl CHGPF und demselben Parameter anzupassen. Auf diese Weise wird der Speicherplatz gelöschter Datensätze wiederverwendet und die Verschwendung von Speicherplatz wird minimiert. Das Reorganisieren mit RGZPFM ist dann nicht mehr so oft erforderlich, wenn es nur darum geht, Speicherplatz freizugeben. Wenn allerdings Situationen vorkommen, in denen eine große Anzahl von Datensätzen gelöscht wird und nur wenige neu hinzugefügt werden, kann RGZPFM trotzdem sinnvoll sein, um eine Datei zu komprimieren. Das Reorganisieren einer Datei bietet noch weitere Performance-Vorteile: Eine Anwendung, die Daten sequentiell in Schlüsselfolge liest, kann wesentlich schneller laufen, wenn geblockt gelesen wird. Das Blocken bringt nützt aber wenig, wenn die Ankunftsfolge der Datei nicht mit der Schlüsselfolge übereinstimmt. Der Parameter KEYFILE im Befehl RGZPFM löst dieses Problem: Wenn Sie KEYFILE(*FILE) angeben, wird die Datei so reorganisiert, daß die Ankunftsfolge der Schlüsselfolge der physischen Datei entspricht. Sie können auch den Namen einer logischen Datei für den Parameter KEYFILE angeben, um die Datei in der Schlüsselfolge der logischen Datei zu reorganisieren.

Datenübertragung im Batch mit CA für Windows 95/NT

Frage

Wie kann ich mit Client Access für Windows 95/NT im Batch Dateien von der AS/400 auf einen PC übertragen?
Antwort

Client Access für Windows 95/NT benutzt dieselben Befehle zum Übertragen von Dateien aus einem DOS-Fenster wie frühere Versionen von Client Access und PC Support: RFROMPCB und RTOPCB. Der Befehl RFROMPCB überträgt Dateien zu einer AS/400 anhand einer Übertragungsanforderung, die Sie zuvor mit Hilfe der Datenübertragungsfunktion von Client Access erstellt haben. Die Anforderung wird in einer Datei mit der Endung .tfr gespeichert und enthält alle erforderlichen Angaben für die Abwicklung der Übertragung. RTOPCB holt Dateien von einer AS/400 auf den PC mit Hilfe einer ebenfalls zuvor mit der Datenübertragungsfunktion erstellten Anforderung, die in einer Datei mit der Endung .tto gespeichert ist.  Sowohl RFROMPCB als auch RTOPCB können in DOS-Batchdateien benutzt werden. Um eine Datei auf Ihren PC zu übertragen, verwenden Sie einen Befehl wie diesen: RTOPCB myreq.tto Denken Sie daran, daß es auch andere Möglichkeiten gibt, wie z.B. die Definition mehrfacher Übertragungen. Die Beschreibung dazu finden Sie im Client Access-Benutzerhandbuch in der Programmgruppe Client Access. Wenn sich die Dateinamen ändern, müssen Sie den Inhalt der TTO-Datei überarbeiten. Da es sich um eine einfache Textdatei handelt, können Sie sie mit Notepad bearbeiten und mit jedem PC-Programm ändern, das Textdateien verarbeiten kann.