gibt es eigentlich AS400 VIREN oder WÜRMER ?

[BenderD]

@Baldur,

Pase Programme sind nicht binär kompatibel cross Prozessor. Was da so auf MI aufsetzt und was nicht, da glaube ich dem Marketing nix mehr; seitdem ich mal auf die Frage (bei V4R2) ob die Java Implementierung eine AIX Portierung sei zur Antwort bekam, das ginge garnicht und kurz später kam Pase als Lic Produkt raus. Die ganzen JVM Bildchen mit MI und TINI und hastenichtgesehn waren möglicherweise alles Schmonz.
Auch AS400 Programme müssen nicht binär kompatibel sein, solange man den (teilweise) recompile nicht merkt, weiss man nicht was da wirklich passiert.
Pase und Linux lenken angeblich einige direkte Hardware Interrupts auf MI level um, um die Kontrolle über die Hardware zu behalten, aber wieweit das stimmt und wenn es denn stimme auch wieder umgeknipst werden kann, steht auf einem anderen Blatt.

Dieter

Sind also mittels PASE erstellte Pgme nicht MI-orientiert ?
Dies würde ja bedeuten, dass ich mit jedem neuen Prozessor die Objekte neu erstellen muss (also die Quelle da sein muss).
Ich dachte (wohl falsch), dass auch die Pase/Linux-Implementierung auf MI aufsetzt und somit Prozessorunabhängig ist.

[Sven Schneider]

Zum Thema Pase :
Pase Programme werden im IFS (QOPENSYS) abgelegt und sind damit manipulierbare Streamfiles.
Ich kann sie mit einem AIX-Compiler unter pase auf der AS/400 oder auch unter AIX erstellen.
Es werden in beiden Fällen nativ Risc-Power Code erzeugt.
Diese wäre nicht portabel, falls sich die Hardwareplattform ändert (RISC --> ???)
Es läuft nur das unter pase-Kontrolle, was auch unix-API's benutzt, weil diese Aufrufe werden auf diePase-runtime umgeleitet.

Zum Thema MI oder beliebiges PGM-Objekt:
Egal welches PGM-Objekt unter OS/400, es wird intern immer ein Programm template und der binäre Power-RISC-Code gemeinsam im PGM-Objekt abgelegt. Deshalb sind diese PGM-Objekte auch von Hause aus etwas größer als auf anderen Plattformen.
Der HLL-Compiler/Linker erzeugt den plattformunabhängigen internen Zwischencode (programm template) auf MI-Ebene.
Der IBM-Translator erzeugt zusätzlich den ausführbaren Power-RISC-Code, mit exakt definierten RISC-Instructionen.
Hier kann ich halt nicht eingreifen.

Gibt es nun irgend wann einen Plattformwechsel, wird auf der Zielplattform nur der Translator (STROBJCVN) angeschmissen und aus dem template der neue ausführbar Binärcode erzeugt.

Ab Version V5R1 kann ich zusätzlich die observabilty Daten (nichts anderes als das programm template) entfernen und trotzdem lässt sich des Objekt vom Translator neu erstellen.
Es wird ein komprimierte Format des programm templates weiterhin gespeichert.
Es ist aber damit schwieriger den Source-Code aus dem Programmobjekt zu rekompilieren. (laut IBM besser Schutz für ISV's)

Java ist wieder ein eigenes Thema :
die JVM ist im SLIC implementiert, also unterhalb der MI.
Java-PGM-Objekte bestehen aus einem (internen nicht sichtbarem)PGM-Objektteil und dem Java-Byte Code im IFS.
Der PGM-Objektteil existiert nur, wenn ich CRTJVAPGM auf eine Java-Klasse ausführe. Es wird hier ein optimierter plattformspezifischer RISC-Code erzeugt.
Beim Save/Restore wird ein vorhandenes Java-PGM-Objekt mit berücksichtigt.

Dazu gibt es ein gutes Buch von Frank Soltis. (Inside ...AS/400 ... ?!)