Dieser Artikel befasst sich mit der Computerbaureihe. Zu anderen Bedeutungen siehe System I.
System i Modell 570 mit Power-6-Prozessoren (Oktober 2007)i5 Modell 570 (2006)
System i (frühere Namen AS/400/eServer iSeries oder System i5) ist eine Computer-Baureihe des Unternehmens IBM.
IBMs Systeme i haben ein proprietäres Betriebssystem namens IBM i for Business und eine eigene Datenbank namens DB2, worauf in der überwiegenden Anzahl der Installationen kaufmännische Anwendungen zur Verwaltung der typischen Geschäftsprozesse eines Unternehmens, als Server- oder Client/Serveranwendung, betrieben werden. Typisch für dieses System ist die enge Verknüpfung zwischen Betriebssystem und Datenbank (vgl. Middleware), welche erste Merkmale einer Appliance aufweist. Diese Ideen wurden bei IBMPureSystems wieder aufgegriffen.
Die aktuellen IBM-Systeme i sind skalierbar, das heißt, man kann diese als relativ kleine Maschine (z. B. fünf Benutzer) betreiben, aber auch in Großrechner-Dimensionen (mit tausenden Benutzern). Die installierten Anwendungen können mehrere tausend Benutzer parallel bedienen, sofern die Hardware richtig dimensioniert ist.
Das Anfang 2016 größte verfügbare System i Modell E880 kann bis zu 16 CPUs mit 192 Power8-Prozessorkernen enthalten und bis zu 16 TBRAM adressieren.
1986 initiierte IBM das Projekt „Silverlake“ unter Leitung von Frank G. Soltis, Chef-Entwickler bei IBM in Rochester und Professor für Computer Engineering (auch: Technical Computer Science oder Technische Informatik genannt) an der Universität von Minnesota. Soltis entwickelte die fundamentalen Design-Konzepte des Systems AS/400, die heute noch immer in einer OS/400-Partition gültig sind.
Sie gehörte ursprünglich zu den Minirechnern, wird aber hauptsächlich kommerziell verwendet und bietet eine breite Schicht an Anwendungsprogrammen. Der Begriff Minirechner wird heute (2007) nicht mehr verwendet und hat heute eine andere Bedeutung. Sie gehört in die Kategorie der Midrange-Rechner; ein Begriff, der sich Mitte der 1980er Jahre bis Ende der 1990er Jahre etablierte. Hiermit ist die Größe zwischen Servern, die auf Intel-kompatiblen Prozessoren basieren, und Großrechnern (engl. mainframes) gemeint.
Die AS/400 wurde am 21. Juni 1988 als gemeinsame Weiterentwicklung der IBM-Systeme 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. Die /36-Anwendungen konnten in einem speziellen Modus unverändert laufen (Befehl: STRS36), was zwar 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, im Oktober 2003 wurde der Name iSeries i5 geprägt, und seit 2006 gibt es die Modelle IBM System i5. Der neueste Name seit 2007 ist System i. Die neuen Modelle haben auch wesentlich erweiterte Möglichkeiten, wie z. B. den Betrieb von Linux und Unix (AIX), Lotus Domino, Java und den Einsatz als Web-Server. Fast alle IP basierten Dienste können auch unter i5/OS laufen (wie z. B. SNMP, FTP, DNS, Telnet, SMTP, POP3, LDAP, VPN).
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. In der Pinakothek der Moderne in München befindet sich ein Modell 520, welches im Jahre 2000 einen Design-Preis erhielt.
IBMPureSystems greift Ideen des System i bzw. der AS/400 wieder auf und erweitert sie in Richtung Appliance. Da Open Source ein immer wichtiger werdender Bestandteil von ERP-Lösungen ist, treibt IBM die Entwicklung insbesondere in diese Richtung voran.[1]
Eigenschaften
Generelles zum IBM System i
Die Architektur der System-i-Modelle ist durch die Besonderheit geprägt, dass das Betriebssystem von der Hardware durch eine Isolationsschicht getrennt ist. Wenn bei Systemen ohne diese Isolationsschicht das Betriebssystem die Hardware direkt anspricht, verlangt eine Modernisierung der Hardware eine intensive Anpassung des Betriebssystems. Diese ist oft so kostenintensiv, dass vorgezogen wird, eine neue Systemreihe zu entwickeln und anzukündigen.
Die Isolationsschicht der Systeme i hingegen erlaubt, Hardwaremodernisierungen ohne Eingriff in das Betriebssystem vorzunehmen (Siehe LIC weiter unten). Dies erklärt, warum die AS/400, die vor über 35 Jahren angekündigt wurde, sich bis zum System i mit der modernsten Hardware wandeln konnte, ohne dass die Anwendungsprogramme umgeschrieben werden mussten. Denn Anwendungsprogramme basieren auf dem Betriebssystem und nicht auf der Hardware. Selbstverständlich wurde das Betriebssystem ebenfalls weiterentwickelt, aber ohne die Zwänge, die üblicherweise mit der Modernisierung der unterliegenden Hardware verbunden sind.
Das System i gibt es grundsätzlich in zwei Ausführungen, und zwar als Enterprise-Modell (für klassische AS/400-Anwendungen mit Eingabe-Bildschirm per Blockgrafik) oder als Standard-Modell (für Server-Anwendungen, wie z. B. Client-Server-Lösungen auf Java-Basis oder SAP mit Client-Server-Technologie)
Es gibt kleine Systeme, die mit einer Partition ausgeliefert werden, auf denen man i/OS betreiben kann.
Es gibt mittlere und große Systeme, die in verschiedene Partitionen aufgeteilt werden können. In jeder dieser Partition wird ein separates Betriebssystem gefahren. Das Betriebssystem muss nicht das IBM-eigene i/OS sein.
Um diese Partitionen verwalten zu können, haben die System i einen eingebauten Verwaltungsrechner (flexible support processor = FSP). Dieser muss hochgefahren werden, bevor die Partitionen gestartet werden können.
Um die Informationen des FSP editieren zu können und verwaltbar zu machen, gibt es eine Hardware Management Console (HMC). Diese ist eine Software von IBM, die unter Linux auf einem eigenen Server auf Basis einer Intel-Architektur laufen muss.
Die Ressourcen Prozessoren, Hauptspeicher und Steckkarten können mit Hilfe der HMC dynamisch (d. h. im laufenden Betrieb) zwischen den Partitionen verschoben, entfernt oder hinzugefügt werden.
Hardware
Bei der Gehäuseform unterscheidet man zwischen Standalone und Rackmounted. Kleinere Modelle werden auch noch als einzeln stehende Gehäuse angeboten. Ab dem Modell 550 bis zur 570 gibt es nur 19-Zoll-Gehäuse, die in ein Rack verbaut werden, das Enterprise-Modell 595 wird in speziellen 24-Zoll-Rahmen geliefert. Je nach Prozessoranzahl und Prozessorbaureihe werden die Hauptgehäuse durch eine oder mehrere Erweiterungseinheiten ergänzt. In diesen Erweiterungseinheiten sitzen dann Festplatten, IOPs, IOAs, HSL-Adapter und sonstige Adapter. Es gibt auch Erweiterungseinheiten für Prozessoren.
Man kann diese Systeme (Server) auch per iSCSI oder SAN-Adapter festplattenlos betreiben. Die Festplattenkapazitäten werden dann von einer SAN-Lösung, also einem zentralen Storage-System bereitgestellt.
Ein optionaler virtual I/O-Server (VIO), eine eigene Partition innerhalb des System i, kann physikalisch vorhandene Ethernet-, SAS-, SCSI- und FC-Adapter als virtuelle Geräte an andere Partitionen auf dem gleichen System weitergeben. So können mehrere Partitionen Adapter gemeinsam nutzen.
Spezielle Aufgaben werden nicht vom Hauptprozessor direkt, sondern von Spezialprozessoren durchgeführt, was den Durchsatz extrem erhöht. Da sind z. B. die IOPs (Input/Output-Prozessor) zu erwähnen. Die entsprechenden Adapterkarten (IOAs) für Netzwerk, Festplatten etc. werden über diese IOPs angesteuert und entlasten somit den Hauptprozessor. Bis 2006 hatte fast jedes System einen oder mehrere IOPs. Diese IOP-Karten kosten ungefähr so viel wie zwei normale Büro-PCs. Wegen der steigenden Prozessorleistung, schnellerer Bussysteme (z. B. PCI-X) und um die Systeme günstiger anbieten zu können, ist IBM dazu übergegangen, IOP-lose IOAs zu verwenden.
Für die Ver-/Entschlüsselung gibt es eigene Kryptografie-Co-Prozessoren auf PCI- oder PCI-X-Adapterkarten, welche ebenfalls den Vorgang beschleunigen und den Hauptprozessor entlasten.
Betriebssysteme Linux, AIX, Windows
Ein IBM System i ist ein „Integrationssystem“. Das bedeutet, es unterstützt nicht nur OS/400 bzw. i5/OS, sondern auch Linux (native PowerPC- oder Intel-Architektur über eine PC-Steckkarte) und das hauseigene Unix-Derivat AIX, sowie Windows (über eine PC-Steckkarte). Die PC-Steckkarte (auch IPCS genannt) ist ein eigenständiger PC mit CPU und Hauptspeicher, der Festplattenplatz auf dem System i verwendet. Es können je nach Modell bis zu 60 dieser PC-Karten eingebaut werden. Zusätzlich können viele Linux-Partitionen installiert sein. Somit kann man bspw. 50 einzelne Server auf einem einzigen System i zusammenfassen, was die Administration und das Speichermanagement erheblich vereinfacht. Das Storage-System des System i kann mit einem SAN verglichen werden, welches dynamisch benötigten Platz einer jeweiligen Partition (LPAR genannt) zuweisen kann (ab V5R4).
OS/400 (i5/OS, IBM i for Business) Partition/System
i5 Modell 520 (inkl. HMC) (2005)
Innerhalb einer Partition (oder eines System mit nur einer Partition) mit OS/400 (bis V5R3), i5/OS (ab V5R4) oder IBM i for Business (ab V6R1) laufen die meisten Programme, die ab 1988 entwickelt wurden, auch heute noch. Und das, obwohl sich die Hardware und die Software (Betriebssystem und Compiler) gravierend verändert haben.
Das OS/400 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 abgelösten Namen iSeries bedeutet laut IBM integrated, da die Integration verschiedener Software-Elemente wie Datenbank, Sicherheitsverwaltung, Betriebssystem, Programmierumgebung etc. die Anwendung und Administration vereinfacht.
Die System i gilt als ein sehr stabiles System; in vielen Unternehmen laufen diese Systeme seit Jahren rund um die Uhr ohne Systemabstürze. Gemeinsam mit der vergleichsweise hohen Bedienerfreundlichkeit ergibt das einen niedrigen TCO-Wert. Über Viren- und Trojanerangriffe ist bisher nicht viel 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 dem System i. 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 zugreifen zu lassen. Seit 2007 ist es auch möglich, IBM Blade Center mit entsprechenden Blade Server per iSCSI an eine i5/OS-Partition anzuschließen. In diesem Falle fungiert das System i als Plattenspeicher mit hoher Sicherheit.
Objektbasiertheit
iSeries Modell 810 (2003)
Objektbasiert ist nicht in jedem Falle 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 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 „Benutzerprofil“ nicht die Eigenschaft „Farbe“ angehängt oder modifiziert werden. 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. Es ist jedoch möglich Dateien in das Internal File System zu transferieren welche z. B. JavaCode enthalten und diese zu kompilieren.
Relationale Datenbank DB2/400 (DB2 for i)
Die relationale Datenbank ist fest in das Betriebssystem OS/400 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 zusätzliche Berechtigungsverwaltungssoftware (wie z. B. RACF) nötig, sondern es kann mit den vorhandenen Objektrechten autorisiert werden. 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).
Für Abfragen und Datenmanipulation wird SQL (Structured Query Language) verwendet. Mit Programmiersprachen, die nativ im OS/400 kompiliert werden können, kann auch mit programmspezifischen Zugriffsmethoden die Datenbank abgefragt und manipuliert werden.
Im April 2007 hat IBM eine Kooperation mit MySQL AB angekündigt, um DB2 UDB for iSeries als Database-Engine für MySQL verfügbar zu machen.[2] Dadurch kann die freie Datenbank MySQL auch auf dem System i5 eingesetzt werden. IBM erhofft sich davon, neue Einsatzbereiche des Systems i5 für MySQL- und PHP-Anwendungen zu eröffnen.
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, sodass hier das Ausnutzen von Sicherheitslücken unterbunden wird.
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, sodass „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 zu kümmern braucht. Bei Plattenspeicherengpässen muss die Plattenkapazität 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 (bereits im S/38 vorhanden) fehlende Daten innerhalb des Plattenstapels ermitteln. Bei Ausfall von mehr als einer Platte ist allerdings diese Berechnung nicht mehr möglich (erst neuere Modelle ab 2006 unterstützen RAID6). Daher ist für Hochverfügbarkeitsumgebungen eine Plattenspiegelung ratsam, welche auch Controller- und Bus-übergreifend möglich ist. Defekte Magnetplatten konnten seit der Betriebssystemversion 3.2 während des laufenden Betriebs gewechselt werden. Dies wird auch als Hot-Swapping bezeichnet.
Die iSeries war von Anfang an auf einen 128-Bit-Adressraum ausgelegt. Die ersten Prozessoren (CISC-Eigenentwicklungen von IBM) waren 48-Bit-Bipolar-Systeme, Ende 1994 stieg IBM auf die 64-Bit-POWER-Prozessoren um. Derzeit werden im Betriebssystem 80 Bit für die Adressierung verwendet (unabhängig von der CPU-Architektur), ein Umstieg auf 128 Bit ist mit einfachen Mitteln machbar.
Bei einem Wechsel der Prozessorarchitektur auf 128-Bit-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 OS/400 (i5/OS) Partition (Systems), 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 stellt der Anwendungssoftware alle nötigen Programmierschnittstellen zur Verfügung. 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 etwa 3–5 % 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, sodass die Anwendungsprogramme nicht modifiziert zu werden brauchen. 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 48-Bit-CISC-Prozessoren auf 64-Bit-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.
Dieser hardwareunabhängige Objektcode kann 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, obwohl dies im AS/400-Umfeld traditionell häufig vorkommt.
Programmierung auf OS/400 (i5/OS)
Überblick
Eine AS/400 Modell 640 (ca. 1997)
Mit der klassischen AS/400-Programmierung soll allgemein folgendes ausgedrückt werden:
Als Datenbank wird die DB2 benutzt, welche im OS/400 fest verankert ist. Diese Datenbank kann man über die spezielle Datenbankbeschreibungsprache DDS oder über normierte SQL-Befehle verwalten und administrieren.
Um das OS/400 zu steuern, wird die Steuersprache CL benutzt, die wie eine Shell-Sprache funktioniert, aber wesentlich komfortabler zu benutzen ist, da es bildschirmgestütztes Prompting gibt. Die CL-Befehle können zu einer Art Script zusammengefasst werden, welche hier als CL-Programme bezeichnet werden und die kompiliert werden müssen. Eine Interpretation von CL-Programmen ist nicht vorgesehen.
Die eigentlichen „Greenscreen“-Applikationen oder zeichenorientierten Applikationen wurden in der großen Masse in RPG geschrieben. Auch COBOL spielte eine Rolle. Historisch betrachtet ist es bis heute möglich, alle RPG-Versionen (RPG-II, RPG-III, RPG/400 etc.) zu verwenden. Der in der jetzt aktuellen Version V7R3 verfügbare RPG-Compiler kann auch noch die „alte“ Syntax (Tabulator-orientiert, also Lochkarten-ähnlich) verarbeiten und lauffähige Programme/Module erstellen. Zum Teil laufen noch Anwendungen, die vor über 35 Jahren entwickelt wurden, und Anwendungen der neuesten Art parallel.
Andere Programmiersprachen wie z. B. COBOL, C, C++, oder Java sind ebenfalls verfügbar und können hier kompiliert werden. Darüber hinaus sind Interpretersprachen wie Net.Data, Rexx, als auch Perl und PHP benutzbar. Innerhalb des OS/400-Systems wird mit dem Befehl STRQSH eine Shell gestartet, in der sh-Skripte ausgeführt werden können, die AIX-kompatibel sind. Dadurch können AIX-Anwendungen parallel zu klassischen Programmen in derselben Partition ausgeführt werden.
Der Web Performance Monitor ermöglicht es, die Web Performance zu messen, indem er Daten sammelt, die das thematische Umfeld im Web betreffen. Hier beinhaltet sind:
Sollte man die passende Anwendung für i5/OS nicht finden, kann man entweder in den großen Linux-Topf greifen (einfache Netz-Anwendungen wie Firewall, Mail etc. bis zur Oracle-, MySQL- oder sonstige Datenbank) oder seine Intel-basierten Server in die Maschine integrieren (Active Directory, Microsoft SQL Server, Microsoft Exchange Server etc.)
Seit 2015 ist eine speziell angepasste Version des SUSE Linux Enterprise Servers auf Power8-Maschinen zum Betrieb eines SAP-HANA Datenbanksystems erhältlich.[4] Das ist ein eigenes Betriebssystem, nicht zu verwechseln mit SAP-on-i, bei dem die SAP-Applikationen unter iOS laufen.
Internetshops
Windows
Windows läuft nicht nativ auf Power-Systemen. Jedoch kann als „Server-im-Server“ ein eigener Intel-Rechner per Baugruppe integriert werden, der sich Hardware-Ressourcen mit der Power-Maschine teilt (z. B. Schnittstellen und Plattenspeicher).
Hardwarefakten
Prozessoren in AS/400, iSeries, i5
Die iSeries Systeme verwenden heutzutage IBM-Power-Prozessoren. Dieser RISC-Mikroprozessor hat eine Verarbeitungsbreite von 64 Bit und wird von IBM selbst entwickelt und hergestellt. Die Prozessormodelle ab sStar und Power 5/6 sind hyperthreadfähig, das heißt, sie können simultan mehrere Threads abarbeiten – bis zu 8 pro Kern bei Power 8. Die Power-Prozessoren ab Modell 4 enthalten zwei Prozessorkerne im Core. Sie sind darüber hinaus auch als Multichip-Module (MCM) erhältlich und haben hier vier Power-Prozessoren (acht Cores) bzw. acht Power-Prozessoren (16 Cores) auf einem MCM.
Folgende Teile dieses Abschnitts scheinen seit 2014 nicht mehr aktuell zu sein:
je System max.1 CPU Modul: Quad-Core-Prozessor 3,0 GHz Six-Core-Prozessor 3,7 GHz Eight-Core-Prozessor 3,55 GHz
128 GB
Modell 710 Express Server
POWER7
2012
je System max.1 CPU Modul: Quad-Core-Prozessor 3,0 GHz Six-Core-Prozessor 3,0 GHz Eight-Core-Prozessor 3,0 GHz
128 GB
Modell 720 Express Server
POWER7
2012
je System 2 CPU Module: 8-Core-Prozessor 3,0 GHz 8-Core-Prozessor 3,7 GHz 12-Core-Prozessor 3,7 GHz 16-Core-Prozessor 3,7 GHz
256 GB
Modell 730 Express Server
POWER7
2012
je System 1-2 CPU Module: 4-Core-Prozessor 3,0GHz oder 3,7GHz 8-Core-Prozessor 3,0GHz oder 3,7GHz 6-Core oder 12-Core-Prozessor 3,7 GHz 8-Core oder 16-Core-Prozessor 3,55 GHz
512 GB
Modell 740 Express Server
POWER7
2012
je System max.4 CPU Module: 4-Core oder 6-Core-Prozessor 3,7GHz 8-Core-Prozessor 3,2GHz oder 3,6GHz
512 GB
Modell 750 Express Server
POWER7
2012
je System max.48 oder 64 Cores: 8-Core-Prozessor 3,3GHz 8-Core-Prozessor 3,7GHz
4096 GB
Modell 770 Enterprise
POWER7
2012
je System max.32,64 oder 96 Cores: 8×4-Core-Prozessor 4,14GHz 16×6-Core-Prozessor 3,44GHz 8×8-Core-Prozessor 3,92GHz
Die IBM hat ihre Maschinen immer in Modellen gruppiert, die jedes Jahr leistungsstärker wurden. Die Modellbezeichnung änderte sich im Laufe der Jahre von Anfangsbuchstaben in reine Zahlen. Die Prozessorgruppe ist hier mit aufgeführt, weil sie Aufschluss über die Kosten des Betriebssystems und der Lizenzprogramme gibt. Je höher die Zahl, desto teurer auch das Betriebssystem. Der CPW-Wert ist die Maßeinheit der Leistungsfähigkeit einer AS/400. Je höher die Zahl, desto schneller und leistungsfähiger ist der Rechner. Die Systemversion („release“) ist eine Mindestanforderung auf der entsprechenden Hardware, neuere funktionieren oft bis zu einem gewissen Grad.
Die POWER-basierten Plattformen des IBM System i und System p sind seit den Ankündigungen von i5 und p5 physikalisch nahezu baugleich. Da ein IBM-System i Server bei großen Modellen immer nach Kundenwunsch konfiguriert wird, sind die verbauten Teile in dem fertigen Computer sehr selten identisch zu einer anderen Konfiguration. Den Unterschied machen die charakteristischen Eigenschaften des gewählten Betriebssystems i5/OS, AIX oder Linux aus, denn man benötigt für die verschiedenen Betriebssysteme verschiedene Features, wie zum Beispiel Plattenkontroller, Netzwerkadapter, CPU-Gehäuse.
Kosten
Hardware
Generell kann man die Hardware kaufen. Ein Leasing über die IBM sowie über andere Leasinggesellschaften ist möglich und wird in der Praxis sehr oft in Anspruch genommen.
Eine Besonderheit ist das Verfahren „Capacity on Demand“, bei dem ein Server in vollständigem Hardware-Ausbau geliefert wird, aber nur ein Teil der Leistung (CPU und RAM) zur Verfügung stehen. Wird die zusätzliche Leistung später vorübergehend oder dauerhaft gebraucht, kann das durch zusätzliche Lizenzcodes freigeschaltet werden. Die Aktivierung geschieht dabei im laufenden Betrieb, ohne dass Umbauten an der Hardware oder gar ein Abschalten des Servers notwendig werden.[5]
Wartungskosten
Nach der Garantiezeit, oder auch schon während der Garantiezeit, benötigt man bei einem produktiv eingesetzten System einen Wartungsvertrag, der mit dem Hersteller oder mit einem anderen Anbieter abgeschlossen werden kann. Darin wird in der Regel eine Reaktionszeit und eine Bereitschaftszeit (zum Beispiel 24 × 7) vereinbart.
Softwarewartung
Um eine in Produktion befindliche Maschine mit neuen Software-Fixes (Program Temporary Fixes, kurz PTFs) zu versorgen, benötigt man einen Softwarewartungsvertrag. Dieser deckt sowohl Softwareprobleme als auch neue Versionen ab.
↑Berthold Wesseler: Kompromisslos offen: Wie IBM i moderne Entwickler ansprechen soll. In: iX. Band2017, Nr.9, 23. August 2017, ISSN0935-9680, S.80–84 (heise.de [abgerufen am 10. Dezember 2021]).
↑SAP HANA on IBM Power Systems. In: ibm.com. International Business Machines Corporation, archiviert vom Original am 14. Juli 2015; abgerufen am 6. September 2023 (englisch).
↑Capacity on Demand. In: ibm.com. International Business Machines Corporation, archiviert vom Original am 28. April 2008; abgerufen am 6. September 2023 (englisch).
_and_eServer_xSeries_335_(1U).jpg)
