AS/400
aus AS400wiki, der freien Wissensdatenbank
Das System AS/400 ist ein Computersystem von IBM. Es ist ein klassisches Mehrbenutzersystem und als Server konzipiert. Eine AS/400 ist kein "Programm" oder ein "Warenwirtschaftssystem" (gelegentliche telefonische Fragen danach enden meist in einer langen Erklärung). Das System ist ein eigenständiges (manche nennen es proprietär) Computersystem mit einem eigenen Betriebssystem namens OS/400.
Inhaltsverzeichnis |
Einführung
Die IBM Power Systems-Rechner sind als frühere Modelle auch unter den Namen "AS/400", "iSeries" oder System i bekannt. Die korrekte Bezeichnung lautet (momentan) IBM Power Systems. Allerdings ist der Name AS/400 stark verbreitet und hält sich trotz gelegentlicher Marketing-Aktionen. IBM möchte mit der neuen Namensgebung auf die erweiterten Funktionen der aktuellen Modelle hindeuten. Trotzdem sprechen viele Anwender von der oder dem AS/400, so dass auch in diesem Wiki überall dort, wo AS/400 geschrieben ist, auch die neuen iSeries gemeint sind.
Die AS/400 ist ein Midrange-System. Dieser Begriff stammt aus den 70ern und bedeutet "Mittleres Computersystem". Damals gab es die Grossrechner, die Midrange-Systeme und Kleincomputer für Steuerungsaufgaben oder kleine Firmen. Der Begriff des PC war damals noch nicht geläufig.
Die Rechner der AS/400-Reihe sind seit 1988 auf dem Markt und werden von IBM stets weiter entwickelt. Es gibt für viele Einsatzgebiete und Größe des anwendenden Unternehmens ein passendes Modell. Die Bandbreite reicht von kleinen portablen Maschinen für den Messe-Einsatz (9401-P03), das leider nicht mehr gebaut wird, bis zu grossen Maschinen mit 64 Prozessoren (9406-595), die auch einen Großrechner neidisch machen. Dementsprechend ist aber auch der Preis.
Entwicklungsgeschichte
1986 initiierte IBM das Projekt "Silverlake" unter Leitung von Frank G. Soltis, Chef-Entwickler bei IBM in Rochester. Soltis entwickelte die fünf fundamentalen Design-Konzepte der AS/400 (siehe unter "Besonderheiten"), wie auch schon viele der Vorgängermodelle.
Die AS/400 (AS = Application System) wurde am 20. Juni 1988 als gemeinsame Weiterentwicklung von System/36 und System/38 auf den Markt gebracht. Genauer gesagt handelte es sich um den Nachfolger der S/38 und war zu dieser sogar objektcodekompatibel, d.h. bisherige S/38-Anwendungen konnten ohne oder mit nur geringen Modifikationen wiederverwendet werden und laufen auch noch bis heute ohne neukompilierung. Die /36-Anwendungen konnten in einem speziellen Modus unverändert laufen (Befehl: STRS36), was aber zu Geschwindigkeitseinbußen führen konnte, jedoch viele Anwender dazu bewog, auf die AS/400 zu wechseln. Im Jahre 2000 wurde die AS/400 in iSeries umbenannt, und seit 2004 gibt es neue (POWER5-basierte) Modelle, die iSeries i5 heißen. Die neuen Modelle haben auch wesentlich erweiterte Möglichkeiten, wie z.B. den Betrieb von Linux und Unix (AIX), Lotus Domino, Java, den Einsatz als Web-Server, usw.
Die ersten Modelle waren die sogenannten B-Modelle (B10, B20, B30, B35, B40, B50), danach folgten die D-, E- und F-Modelle. IBM ging danach zu numerischen Modellbezeichnungen über.
Besonderheiten
Die AS/400 hat einige Besonderheiten gegenüber anderen Rechnersystemen, die hier ein wenig erläutert werden sollen.
Zweigeteiltes Betriebssystem
Was in anderen Systemen als das Betriebssystem bezeichnet wird, ist bei der AS/400 zweigeteilt. Diese in der IT-Industrie einzigartige Implementierung besteht aus dem SLIC (system licensed internal code) und dem OS/400 oder i5/OS (Betriebssystem). Der SLIC implementiert das (woanders als "Kernel" bezeichnete) Grundsystem mit den Funktionsbereichen:
- TIMI - Technologie-unabhängiges Maschinen-Interface
- Prozessüberwachung
- Ressourcen-Management
- eingebaute SQL-Datenbank
- Sicherheitskonzeption und -Überwachung
- Kommunikation und Netzwerk
- Dateisysteme
- Speicherverwaltung
- Java virtual machine
SLIC ist eine sehr penibel konzipierte und ausführlich getestete Software, die man salopp auch als "ausgefeilteste API-Sammlung" in der IT-Branche bezeichnen könnte. Diese APIs haben sehr viele Funktionen, die in anderen Systemen fehlen, sind recht hardwarenah implementiert und enthalten neben optimierten Code für alle unterstützten Prozessoren auch Informationen über die möglichen Hardware-Konfigurationen.
OS/400 bietet Funktionen auf einer höheren Ebene, die Anwenderprogrammen, Programmierern und Anwendern zur Verfügung gestellt werden. Hierunter fallen auch Funktionalitäten für die Programmierung, Menuführung und externe Programme wie Client Access. OS/400 selbst enthält kaum hardwarenahe Programme, sondern einen Objektcode, der vom SLIC bei Bedarf in maschinennahe Befehle kompiliert wird.
Objektbasiert
Objektbasiert ist nicht gleichzusetzen mit dem Begriff objektorientiert, wie er bei Programmiersprachen häufig gebraucht wird. Grundsätzlich wird jedes Element im System - ob Bibliothek, Benutzerprofil, Gerätekonfiguration, Datei etc. - als Objekt mit bestimmten Funktionen und Attributen angesehen. Ein Objekt gliedert sich in einen Header und in die eigentlichen Informationen, wobei der Header das Objekt allgemein beschreibt (z.B. durch Eigentumsrechte, Name, Objektart, Schnittstellen). So wird durch den Header z.B. definiert, auf welche Art und Weise das Objekt bearbeitet werden kann. So verfügen Objekte über Eigenschaften (oder Parameter), die verändert werden können. Nicht definierte Eigenschaften können nicht angelegt oder geändert werden. Beispielsweise kann einem Objekt "Gerätekonfiguration" nicht die Eigenschaft "Kennwort" angehängt oder modifiziert werden. Auf den Header kann mit normalen Betriebsystem-Mitteln nicht zugegriffen werden, so dass hier ein gewisser Manipulationsschutz vorliegt. Nur mit einem speziellen System-Service-Programm kann hier eine Veränderung vorgenommen werden - der Zugriff hierauf ist limitiert.
Dateien sind ebenso stets ein Objekt. Reine Textdateien gibt es nur zur Emulation von Kompatibilitäten mit anderen Betriebssystemen; in der Regel ist eine AS/400-Datei aber ein Datenbankobjekt.
Durch diese Objektbasiertheit ist es nahezu unmöglich, dass ein Programm ein anderes Programmobjekt modifiziert. Dazu müsste es im so genannten Systemmodus laufen und gleichzeitig die Rechte des SST-Tools aus dem SLIC haben. Dies ist jedoch nicht möglich. Es gibt im OS/400 keine Methode "Ändern" eines Programmobjekts, nur eine Methode "Neu erstellen", die nur IBM-Compiler haben. Somit sind Viren auf OS/400 kein Thema.
Relationale Datenbank
Die relationale Datenbank ist fest in das Betriebssystem integriert. Es gilt: "ohne Betriebssystem keine Datenbank und umgekehrt". Die DB2/400 bietet eine hohe Funktionalität und Leistung, weshalb sie zu den führenden Datenbanksystemen gehört. Durch die feste Integration ist keine weitere Berechtigungsverwaltung oder Ressourcenverwaltung nötig. Durch die permanente Weiterentwicklung durch IBM ist diese Datenbank heute auch für eine Vielzahl von externen Schnittstellen, wie JDBC (Java), ODBC, FTP o.ä. offen.
Die Datenbank hatte am Anfang (1988) gar keinen Namen, wurde später DB2/400 genannt und heißt seit iSeries DB2/UDB (Universal Database).
Einstufiger Speicher
Der Arbeitsspeicher und der Festplattenspeicher werden zu einem großen virtuellen Speicher zusammengefasst, das heißt, der Adressraum ist durchgängig beschreibbar. Man nennt dies auch single level storage.
Somit gibt es keine Segmentierung des Adressraums, die Programme nutzen während der Ausführung absolute Adressen. Wenn ein Objekt bearbeitet wird, existiert keine vollständige Kopie im Arbeitsspeicher, sondern es werden nur Teile (sog. "Pages") geladen. Wird ein Objekt gelöscht, markiert das System den darauf zeigenden Pointer als ungültig und nicht wiederverwendbar, so dass hier das Ausnutzen von Sicherheitslücken unterbunden wird.
Es gibt keine Unterscheidung, ob ein Objekt im Hauptspeicher oder auf Platte vorliegt. Der SLIC unterscheidet hier nur aus Gründen der Performance und einer dauerhaften Speicherung.
Durch diese einstufige Adressierung, verbunden mit einem 128Bit-Adressierungskonzept muss sich ein Programmierer keine Gedanken um Adressierungsmethoden oder den Speicherverbrauch machen, auch die Performance-Anpassung kann vom Betriebssystem vorgenommen werden. Dadurch ist es auch möglich, im laufenden Betrieb Hauptspeicher-Ressourcen zwischen verschiedenen Partitionen auszutauschen.
Kenner der Windows- oder Unix-Systeme müssen sich das Konzept so vorstellen: Der Hauptspeicher wird als Read-Cache für die Festplatten verwendet, alle Festplatten stellen eine Art "Auslagerungsdatei" dar, in der alle Objekte (temporär oder permanent) abgelegt werden. Diese Daten werden beim Systemstart nicht gelöscht, so dass "permanente" Objekte wieder zur Verfügung stehen.
Durch die einstufige Speicherverwaltung ist für den Anwender (und auch für das Betriebssystem) nicht nachvollziehbar, welche Objekte auf welcher Platte abgelegt werden. Vorteilhaft ist, dass sich der Anwender nicht um eine Aufteilung des Plattenplatzes kümmern muss. Bei geringem Plattenspeicher muss dieser nur erweitert werden, um die Verteilung der Daten kümmert sich das System. Die AS/400 hatte von Anfang an das sogenannte RAID-Prinzip integriert. Bei Ausfall einer Platte kann das System durch die checksum-Methode fehlende Daten innerhalb des Plattenstapels ermitteln. Bei Ausfall von mehr als einer Platte ist allerdings diese Berechnung nicht mehr möglich. Daher ist für Hochverfügbarkeitsumgebungen eine Plattenspiegelung ratsam, welches auch Controller- und Bus-übergreifend möglich ist. Man kann auf diese Weise auch ein RAID-Set mit 10 Platten komplett spiegeln, notfalls auch in einem eigenen Gehäuse, welches dann ausfallen dürfte, ohne den Betrieb zu stören.
Die iSeries war von Anfang an auf einen 128Bit-Adressraum ausgelegt. Die ersten Prozessoren (CISC-Eigenentwicklungen von IBM) waren 48Bit-Bipolar-Systeme, Ende 1994 stieg IBM auf die 64Bit-POWER-Prozessoren um. Derzeit werden im Betriebssystem 80Bit für die Adressierung verwendet (unabhängig von der CPU-Architektur), ein Umstieg auf 128Bit ist mit einfachen Mitteln machbar.
Der 128-Bit-Adressraum erlaubt eine direkte Adressierung von 18 Quintillionen Bytes. Bei einem Wechsel der Prozessorarchitektur auf 128Bit-CPUs ist durch das objektbasierte Konzept und dem Vorhandensein von Objektcode in den Programmen ein problemloser Umstieg möglich, siehe nachfolgendes Kapitel. Systemintern sind alle Pointer 16 Byte breit.
Lizenzierter Interner Code
Der lizenzierte interne Code (auch LIC genannt) ist das Herzstück jeder AS/400, da diese Software-Komponente zwischen der Hardware und der Anwendungssoftware vermittelt (das Betriebssystem OS/400 wird hier als Anwendungssoftware angesehen). Nur dieser LIC kann eine Hardware direkt ansprechen, und er bietet der Anwendungssoftware alle nötigen Programmierschnittstellen zur Verwendung. Es kann keine Funktion unter Umgehung dieser APIs verwendet werden, und diese prüfen neben Plausibilität auch Berechtigungen. Dies ist auch ein Grund, warum OS/400 auf der gleichen Hardware minimal langsamer als beispielsweise AIX ist, da diese Prüfungen Rechenzeit benötigen.
Bei einem Hardware-Wechsel ändert IBM diesen internen Code, behält die Schnittstellen aber bei, so dass die Anwendungsprogramme nicht modifiziert werden müssen. Bei gravierenden Änderungen in der Hardware (Wechsel der CPU-Architektur) wird weiterhin auf die in den Programmen üblicherweise vorhandene Zwischencode-Schicht zurückgegriffen. In einem Programmobjekt ist nicht nur ein (fast) direkt ausführbarer Code enthalten, sondern auch ein Objektcode. Ruft man ein Programm auf, welches für eine andere CPU erstellt wurde, erkennt dies das Betriebssystem und wandelt das Programm automatisch um. Auf diese Weise wurde auf der iSeries der Wechsel von proprietären 48Bit-CISC-Prozessoren auf 64Bit-RISC-Prozessoren vollzogen. Die Anwender haben auf dem alten System alle Programme auf ein Band gesichert und auf dem neuen System zurückgeladen. Den Rest erledigte das Betriebssystem.
Übrigens kann dieser Hardware-unabhängige Objektcode aus dem Programmobjekt entfernt werden, um Speicherplatz zu sparen. Dann muss aber das Programm unter Verwendung des Quellcodes neu umgewandelt werden, wenn es eine neue Hardware-Architektur gibt.
Diese Möglichkeit der hardwareunabhängigen Software ist in der IT-Branche recht einzigartig, da hier nicht ein menschenlesbarer Quelltext mit der (oft ja kommerziell vertriebenen) Software mitgegeben werden muss.
Hardware-Integration
Spezielle Aufgaben werden nicht vom Prozessor, sondern von Spezial-Prozessoren ausgeführt, was den Durchsatz extrem erhöht. So sind die Festplattencontroller recht intelligent, was das Erledigen von Plattenanforderungen betrifft. Im Bus-System werden stets einige Steckkarten von einem eigenen IO-Prozessor gesteuert, der die Hauptprozessoren entlastet, und bei grösseren Systemen mit mehreren Gehäusen wird unter Verwendung von Grossrechner-Technik jeweils einer oder mehrere Datenbus-Anbindungen über Glasfaser oder spezielle Kupferkabel realisiert.
Betriebssystem OS/400 - i5/OS
Das OS/400 (ab Version 5 Release 3 (V5R3) i5/OS genannt), ist ein herstellerspezifisches (andere Bezeichnung: proprietäres) Betriebssystem, das grundsätzlich nur auf dieser Hardware von IBM lauffähig ist. Es kann aber auch in einer Partition auf einem eServer pSeries (p5) betrieben werden. Neben dem integrierten Datenbankverwaltungssystem bietet das OS/400 u.a. integrierte Sicherheitsfeatures und Netzwerkunterstützung. Viele Systemelemente sind hier in einer Umgebung zusammengefasst. Das i im Namen der iSeries bedeutet laut IBM integrated, da die Integration verschiedener Software-Elemente wie Datenbank, Sicherheitsverwaltung, Betriebssystem, Programmierumgebung etc. die Anwendung und Administration vereinfacht.
Die iSeries gilt als ein sehr stabiles System; in vielen Firmen laufen diese Systeme rund um die Uhr ohne Systemabstürze. Gemeinsam mit der vergleichsweise hohen Bedienerfreundlichkeit ergibt das einen niedrigen TCO-Wert. Über Viren- und Trojanerangiffe ist bisher nichts bekannt. In großen Unternehmen betreut oft ein einziger Administrator eine iSeries, die mehreren Tausend Anwendern Daten und Programme bereitstellt.
Neben dem Betriebssystem OS/400 laufen auch GNU/Linux und AIX nativ auf der iSeries. Zusätzlich ist es möglich, über sogenannte IXS-Karten (Integrated xSeries Server for iSeries) sowie IXA-Adapter (Integrated xSeries Adapter) und deren x86-Architektur Windows auf die Hardware-Ressourcen der Maschine zuzugreifen zu lassen.
Weblinks
| Dieser Artikel wurde der Wikipedia (http://de.wikipedia.org) entnommen. Er sollte aber den Anforderungen des AS400-Wikis angepasst werden, so dass auch eigene Ideen hier einfliessen! |
