Suche ein altes, kleines AS/400 9401-P03 System (noch CISC)

[Ron]

Guten Tag

Ich suche ein altes, kleines AS/400 9401-P03 System (noch CISC) für Testzwecke.

Möglichst in noch lauffähigem Zustand, gerne optional mit Literatur, Kabel, etc. und zahle gerne entsprechend dafür.


Beste Grüsse
Ron

[KingofKning]

Ich kenne genau 2 Leute die sowas haben. Ob Holger seine verkauft weiß ich nicht, meine behalte ich. Leider ist bei mir die Ethernetkarte defekt.
Aber da die Generation der AS/400 Leute langsam anfängt auszusterben und die Erben damit nichts anfangen können wächst die Hoffnung soetwas auf EBay zu ersteigern.

GG 2671

[Ron]

Es gibt schon noch vereinzelte, jedoch oftmals fehlt das gewünschte Featur.....

In diesem Falle könnten die erwähnten zwei Leute sogar meine frühere P03 besitzen, welches eben einen Ethernet-Adapter hatte und eine #2115-CPU. Und sie hatte auch das sehr seltene, runde Abschluss-Teil....
.....dies ist jedoch bereits etliche Jahre her.

Sicherlich eher seltener, aber oftmals auch nicht mehr so erwünscht und da wird locker etwas passendes möglich sein, mit etwas Geduld. Mir wurde bereits in diesen Tagen etwas angeboten und man kann hier zuversichtlich bleiben.

Eine IBM Power 10 Portable könnte in diesen Tagen ebenfalls interessant sein, nur scheint IBM leider hier überhaupt kein flexibles Engagement zu zeigen....

[Fuerchau]

Es gibt schlimmeres;-):

https://stadt-bremerhaven.de/bahn-ad...-3-11-gesucht/

[BenderD]

Es gibt schlimmeres;-):

https://stadt-bremerhaven.de/bahn-ad...-3-11-gesucht/

... Vorsicht, Glashaus! Die AS/400 löste 1988 das System /36 ab und noch heute laufen Anwendungen im /36 er mode und wird RPGII Knowhow nachgefragt. Und wenn man in aktuell verkaufte Software reinschaut, erblickt man oberflächlich migrierten RPGII Code. Da ist Windows 3.11 als Kind der 90er geradezu innovativ.

[Fuerchau]

/36-Umgebung habe ich nie kennengelernt und sobald es ILE und die Erweiterungen gab, habe ich die auch schnell verwendet.
Schon 1992 mit V2R1 haben wir unsere ERP-Anwendung, zwar in Cobol, aber bereits mit SQL und Journalisierung entwickelt, da das Transaktionskonzept schon gravierend ist.
Damals mussten wir noch leider einen Workaround machen, da eine Transaktion max. 32.767 gesperrte Datensätze beherrschte. Heute ist das natürlich nicht mehr erforderlich.
Wenn ich dann aber manchmal sehe, wie Views über mehrere Tabellen gebaut werden, die im Ernstfall immer zu Tablescans führen....

[camouflage]

Die AS/400 löste 1988 das System /36 ab und noch heute laufen Anwendungen im /36 er mode und wird RPGII Knowhow nachgefragt.

Da muss ich doch gleich das Klugscheisserchen hervorkramen. Die AS/400 löste vor allem die S/38 ab und nahm im gleichen Aufwasch gleich noch die S/36 mit. Waren noch schöne Zeiten, als man andächtig im grossen Auditorium von IBM sass und all die Ankündigungen über sich ergehen liess, Apero inklusive. Im Vorfeld zu Silverlake wurde den S/36ern auch empfohlen, sich mit RDB zu beschäftigen. Da wusste man, wie der Hase zu hoppeln hatte. Nebenbei wurde auch gleich einer der grössten Nachteile der 36 eliminiert, nämlich dass mit dem RPG400 endlich auch native Calls möglich waren.

[Fuerchau]

Tja, so schön kann Geschichte sein.

Es war einmal Microsoft mit der Erfindung des Net-Frameworks.
Die Versionen zogen so dahin, 1.1, 2.0, 3.5, 4.0ff.
Mit Version 4. und ff konnte man endlich Software schreiben, deren Betriebsystem regelmaßig Updates erfuhr und Sicherheitslücken geschlossen wurden.
Viele lange Jahre eine schöne Eintwicklungsumgebung mit der man Software schreiben konnte, die viele Jahre mit jedem neuen Relase von Windows seit 2008R2 bis 2022 kompatibel und lauffähig blieb.

Man fühlte sich da glatt an die IBM i mit ihrer einmaligen Kompatibilität erinnert.

Es kam jedoch der Tag, dass Microsft erkannte, dass man damit nicht so viel Geld verdienen kann wie mit ständigen Wechseln.

So wurde dann innovativ wie immer Net-Core erfunden.
Die Community hat sich wie wild daruaf gestürzt und merkte damit nicht, wie die Nachteile immer größer wurden. Vorteile werden zu Nachteilen.

Mit der eigenen Software wurde gleich die benötigte Runtime mit ausgeliefert, da sie im Windows nicht mehr vorgehalten wird.
Man vergaß nun leider dabei, dass von nun an jeder Softwarelieferant und -hersteller für den Update ins besonders bei Sicherheitslücken selber verantwortlich ist.
Also mit jeder neuen Kurzgeschichte (Updates) musste man die eigene Geschichte (Software) neu erzählen und auch verteilen.

Doch, damit war es nicht mehr getan.
Es kamen auch ganz neue Geschichten hervor: Core 3, 4, 5, 6, 7, 8.
Und Microsoft garantierte nun nicht mehr, dass die Software die ich mit 3, 4, 5 entwickelt habe nun auch mit 6, 7, 8 auch noch funktioniert. Ebenso wird keine der Geschichten länger als 3 Jahre überhaupt erzählt.

Also flugs auch hier die eigene Geschichte an Microsofts Geschichte anpassen, und wenn man Glück hatte, war es noch kompatibel. Aber das Gegenteil konnte schnell der Fall sein.

Nun ist es in der Softwareentwicklung so, dass es viele nette kleine Komponenten oder Module gibt, die man, ggf. gegen Lizenz, selber einbauen durfte.
Jedoch, auch diese Lieferanten müssen natürlich ihre Geschichten ebenso weiter erzählen.

Was passiert nun aber, wenn man ein sehr schönes Kapitel hat, dass von einem Dritten nicht mehr weiter erzählt wird? Ich würde sagen: Dicke Backen!
Entweder man verzichtet auf diese Funktionalität, oder man sucht sich etwas nahezu vergleichbares aber mit neuen Interfaces und Inkompatibilitäten zum Bisherigen, was zusätzliche Konverter erfordert. Man möchte ja den bisherigen Service für den Kunden erhalten.

Parallel zu Core gibts auch noch Net Standard.
Mit diesem Release sollte man Basistechnologien entwickeln können, die von allen Core-Versionen geladen werden können. Allerdings gibt es hier dieselben Probleme, da neue Coreversionen eben irgendwann die alten Net-Standards nicht mehr unterstützen. Warum man Net Standard nicht einfach erweitert entieht sich mir.

Ich habe 2005/2006 meine Anwendung noch zu Teilen in VB6 entwickelt. Trotz mehrerer Totmeldungen seitens Microsoft funktioniert dies auch noch auf Windwos Server 2022.
Die letzte funktionierende Entwicklungs-Umgebung läuft auf einer Window 8.0-VM, die ich auch ab und zu noch bemühen muss.

Da liebe ich die IBM i gerade zu dafür. Programme, die ich mit V2R1, V3R1 oder V4R1 entwickelt hatte laufen auch heute noch ohne Probleme weiter und weiter und weiter....

[camouflage]

Baldur, diese Geschichte geht noch viel weiter zurück. Nachdem ich ja dem Siemens/ICL Assembler den Rücken gekehrt hatte, wurde ich mit dem S/34 RPG konfrontiert. Was für ein Kulturschock. Plötzlich nur noch eingeschränkt auf die Gestaltung eines Programmes zu haben. Dafür war man viel schneller, dem Zyklus sei Dank. Grossartig, dass man diese Ergüsse auch auf die S/36 übernehmen konnte und nun kommt's: Selbst die Ur AS/400 verstand diese noch und so gesehen übernimmt auch eine IBM i diese Funktionen. IBM sagt dem übrigens: Investitionsschutz - ob es noch zeitgemäss ist, dahingestellt.

Schade hat es IBM nicht fertig gebracht, in neuerer Zeit den Entwicklern ein OA o.ä. basierte Web-Entwicklungsumgebung a la ProfoundUI zur Verfügung zu stellen. In der Schublade hätten sie es gehabt, wie man munkelt. Was die Zukunft bringt, wird sich zeigen. Jedenfalls konnte und kann das kein anderer Hersteller so bieten.

[RobertMack]

...nämlich dass mit dem RPG400 endlich auch native Calls möglich waren.

Und rückwärts, für Calls in S/36 RPG II, gab es seit etwa 1988 ein "RPG zweieinhalb" von Grünbichler…

[camouflage]

Und rückwärts, für Calls in S/36 RPG II, gab es seit etwa 1988 ein "RPG zweieinhalb" von Grünbichler…

Kannte ich schon, die Erfahrung hat jedoch gezeigt: "Nur Originales ist auch Wahres"!
Wopixx lässt grüssen.