Midrange MAGAZIN – Juli 2007

Weitere Magazine

Empfehlungen

Info

0 TECHNIK & INTEGRATION 3 WRKREGINF sondern insgesamt 81. Der erste Start startet den Server und die Anzahl an Jobs, die bei CHGFTPA eingestellt sind. Die weiteren Starts ergänzten jeweils einen Job, womit ich auf 100 Jobs kam. Die Tests verliefen jetzt zufriedenstellend. Allerdings fiel mir danach eine Sache auf, die mich unglücklich machte: Im Massentestprogramm hatte sich ein Fehler eingeschlichen. Statt 100 Clients wurden versehentlich 1.000 simuliert. Das ‚Arbeitstier’ iSeries versuchte, diese 1.000 Jobs auch tatsächlich zu starten. Damit war das Entwicklungssystem allerdings hemmungslos überfordert, sinnvolles Arbeiten war geraume Zeit nicht möglich. Wenn Sie nichts anderes angeben, laufen die FTP-Jobs nämlich im Subsystem QSYSWRK – und das zu beenden, ist keine gute Idee. Was passiert, wenn alle 2.000 Clients auf einmal versuchen, sich mit der Maschine zu verbinden? Die Antwort gab mir die Praxis etwa anderthalb Jahre später: Es passierte genau das Gleiche, was auf dem Entwicklungssystem passiert ist: Die Produktion war geraume Zeit mit sich selbst beschäftigt. Hier galt es also, eine Möglichkeit – einen „Deckel“ – für die Anzahl der Jobs zu finden. Dazu muss der FTP-Server zunächst in einem eigenen Subsystem laufen, MIDRANGE MAgAZIN · 07/2007 was wiederum ganz leicht ist: Man trägt einfach den gewünschten Namen im Befehl CHGFTPA in den Parameter SBSD ein. Gerade mal die Bibliothek sollte es geben – das Subsystem und eine gleichnamige Jobwarteschlange erstellt das Betriebssystem selber! Damit kann man im Falle eines Falles schon relativ schnell das Subsystem abdrehen und das System so vor einer Client-Schwemme schützen. Allerdings ist das gar nicht nötig, denn es gibt ja den Parameter MAXJOBS beim Befehl CHGSBSD – „Subsystembeschreibung ändern“. Mehr als die genannte Anzahl der Jobs können gar nicht laufen – Problem gelöst! (Bild 2). Die meisten Clients sind keine iSeries, sondern PCs mit Windows-, einem Unix- oder einem Linux-Betriebssystem. Das bedeutet, dass es nicht sinnvoll ist, mit dem iSeries-Namensformat und den Bibliotheken zu arbeiten, vielmehr mit IFS und der damit verbundenen Pfad- Schreibweise. (Das heißt, um mit den FTP-Befehlen zu sprechen: „Namensformat 1“ statt „Namensformat 0“.) Dies stellen Sie ebenfalls mit dem Befehl CHGFTPA um – und zwar mit dem Wert *PATH im Parameter NAMEFMT. Sinnvollerweise stellt man hier auch gleich den Wert *HOMEDIR für den Parameter CURDIR ein. Damit befindet sich ein OS/400-Benutzer nach dem Anmelden auch gleich im Verzeichnis, das im Parameter HOMEDIR seines Benutzerprofils eingestellt ist. Was ich bis jetzt verschwiegen habe, ist, wie die Anmeldung der Clients mit einer Nicht-OS/400-User-ID sowie Kennwort nun tatsächlich gelöst werden konnte. Es gibt sogenannte „Exit-Points“. Das sind bestimmte Stellen in den Server-Funktionalitäten des Betriebssystems der iSeries, an denen Benutzerprogramme aufgerufen werden können – ähnlich wie ein umgekehrtes API: Das Betriebssystem ruft ein Anwendungsprogrammierer-Programm auf, wenn es nicht mehr weiter weiß. Schön – oder? Unklar ist noch, wo und wie man diese Exit-Point-Programme einträgt. Mit Hilfe des Befehls WRKREGINF – „Mit Registrierungsinformationen arbeiten“. Hierbei war ein erster Gedanke: „Schön, die iSeries hat eine Registry.“ Wenn Sie den Befehl einmal ohne Parameter aufrufen, sehen Sie eine ganze Reihe von Exit-Points. Je jünger die Version und das Release des installierten Betriebssystems ist, desto mehr sehen Sie. Uns interessieren hier aber nur die Exit-Points, die mit „QIBM_QTMF“ beginnen; wir setzen also den Befehl WRKREGINF EXITPNT(QIBM_QTMF*) ab (siehe Bild 3). Nun wird der Grund ersichtlich, warum so viele Exit-Points vorhanden sind. Pro Exit-Point gibt es meist mehrere mögliche „Formate“, das sind im Prinzip die Parameterlisten. Ich habe mich für das Format TCPL0200 des Exit-Points QIBM_QTMF_SVR_LOGON entschieden. Anton Gombkötö ó CLICK TO www.midrange.de Den vollständigen Artikel finden Sie in unserer aktuellen Online-Ausgabe.
Release V5R4M0 Neues in Datenbank und SQL In den letzten Releases hat IBM die Datenbank, die im Betriebssystem der iSeries (System i) integriert ist, von Grund auf verändert und wichtige Erweiterungen implementiert. Der Schwerpunkt der Entwicklung liegt dabei auf SQL (Structured Query Language). Allerdings kamen beim nativen Dateizugriff und der Definition von Datenbankobjekten über DDS (Data Description Specification) nur geringfügige Änderungen hinzu. Mit Release V5R4 hat sich dieser Trend ungebrochen fortgesetzt. Mit dem Erfolg, dass die DB2 UDB for iSeries die erste Datenbank ist, die den von ISO (International Organization for Standardization) festgelegten Standard für SQL (aktuell SQL- 2003 http://www.sigmod.org/sigmod/ record/issues/0403/E.JimAndrewstandard.pdf) zu hundert Prozent abdeckt. Auf die wichtigsten Neuerungen – wie OLAP- (OnLine Analytical Processing-) Ranking-Funktionen, RCTE (Recursive Common Table Expression), Instead Of Triggers, neue beziehungsweise erweiterte Analyse-Tools unter der iSeries Navigator-Datenbank – werden wir in einer Reihe von Artikeln näher eingehen. In diesem Artikel wollen wir uns zunächst mit den erweiterten Datenbanken-Limits beschäftigen – sowie mit den SQL-Statements, die ab Release V5R4 von der SQL Query Enginge (SQE) verarbeitet werden können. Erweiterte Datenbanken-Limits Um ein Maximum an Portabilität und Flexibilität zu erreichen, wurden einige der bisherigen Datenbank-Beschränkungen beträchtlich erweitert: ó Spaltennamen waren bis einschließlich Release V5R3 auf 30 Zeichen beschränkt, während für die Namen der Datenbankobjekte (zum Beispiel Tabellen, Indices, Stored Procedures) bis zu 128 Zeichen verwendet werden konnten. Ab Release V5R4 wurde das Limit für Spaltennamen ebenfalls auf 128 Zeichen erweitert. Die Systemnamen bleiben weiterhin auf 10 Zeichen begrenzt. ó Ab Release V5R4 können in einem einzigen SQL-Statement bis zu 1.000 Tabellen verknüpft werden. Die bisherige Grenze lag bei 256 Tabellen. Diese Grenze gilt auch weiterhin für die Anzahl von Verknüpfungen innerhalb von Datenbankobjekten – wie Views oder MQTs (Materialized Query Tables). ó Die maximale Länge eines SQL- Statements wurde von 65.535 Byte auf 2 Gigabyte erhöht. Damit ist es möglich, noch wesentlich komplexere Stored Procedures, Trigger oder User Defined Functions (UDF) zu codieren. Obwohl diese Statements sich aus einzelnen auszuführenden Befehlen zusammensetzen können, werden die SQL-Anweisungen – CRE- ATE PROCEDURE, CREATE TRIGGER oder CREATE FUNCTION – mit allem was dazugehört, jeweils als ein einzelnes Statement betrachtet. ó Während unter Release V5R3 nur maximal 1.000 Spalten mit einer Gesamt-Länge von bis zu 1.000 Bytes in einer Order By-Anweisung angegeben werden konnten, können unter Release V5R4 maximal 32.766 Spalten mit einer Gesamtlänge von bis zu 32.766 Byte verwendet werden. ó Ab Release V5R4 ist es möglich, für SQL beschriebene Stored Procedures bis zu 1.024 Parameter zu definieren. Die Anzahl der maximal zulässigen Parameter für externe Stored Procedures dagegen ist zum Einen abhängig von den Restriktionen in den einzelnen Programmiersprachen, in denen die Prozeduren geschrieben wurden, und zum Anderen vom verwendeten Parameter-Style: ó Parameter-Style GENERAL: 1.024 Parameter ó Parameter-Style GENERAL WITH NULLS: 1.023 Parameter ó Parameter-Style SQL oder DB2SQL: 508 Parameter ó Parameter-Style JAVA oder DB2GENERAL: 90 Parameter Die Anzahl der übergebenen Parameter für SQL-beschriebene und externe User Defined Functions (UDF) bleibt weiterhin auf 90 beschränkt. Von der Classic Query Engine (CQE) zur SQL Query Engine (SQE) In den letzten Releases wurde Schritt für Schritt eine neue Query Engine zur Verarbeitung von SQL-basierten Datenbankabfragen eingeführt: SQL Query Engine (SQE). Die neue Query Engine wurde im OO- (= objektorientiert) Design erstellt und kann dadurch wesentlich flexibler agieren als die klassische (classic) Query Engine (CQE). Sämtliche Neuentwicklungen im Bereich von SQL- Abfragen und deren Optimierung erfolgen in und für die neue SQE. Abfragen, die mit CQE bearbeitet werden müssen, können von diesen Neuerungen nicht profitieren. Die Entscheidung, durch welche der beiden Query Engines die 07/2007 · MIDRANGE MAgAZIN 1
Seite 1 und 2: 3 0 5 81 9 I 9 8 E · I S S N 0 9 4
Seite 3 und 4: Thomas Seibold Redaktion MIDRANGE M
Seite 5 und 6: MARKTÜBERSICHT Basisarbeit 46 Elf
Seite 7 und 8: Rückblick: iNN-Partner-Camp in Bad
Seite 9 und 10: WORKSHOPS KALENDER System i SQL Sum
Seite 11 und 12: Foto: Christine Balderas, iStockpho
Seite 13 und 14: eich der Kundenzufriedenheit. unser
Seite 15 und 16: Anwendungsmodernisierung auf iSerie
Seite 17 und 18: ausgeführt. Die Activation Group e
Seite 19 und 20: Umfangreiche Virtualisierungsfunkti
Seite 21 und 22: wodurch sich die Anzahl der externe
Seite 23 und 24: ��
Seite 25 und 26: prozeduren sollte jedoch die Mögli
Seite 27 und 28: Bundesversicherungsamt schützt sic
Seite 29 und 30: Hochverfügbarkeit nach Modellen de
Seite 31 und 32: Einen großen Vorteil sieht der EDV
Seite 33 und 34: SPEzIAL System i: Lösungen für de
Seite 39: Ich stellte den Parameter NBRSVR de
Seite 43 und 44: Eine Entwicklungsplattform für iSe
Seite 45 und 46: Damit Sie die Möglichkeiten von SQ
Seite 47 und 48: Positive Erfahrungen Florian Litsch
Seite 49 und 50: SERVICE AUTOREN DIESER AUSGABE Hein
Seite 51 und 52: TOOLMAKER SOFTWARE Mehr E� zienz

Midrange MAGAZIN – Juli 2007

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?