gibt es eigentlich AS400 VIREN oder WÜRMER ?

[BenderD]

Hallo,

wenn das nicht ginge, dann könnte man das MI nicht implementieren, abgesehen davon würde wohl pase schon reichen (derselbe Ansatz mit Prozessor abhängigem Code!!!).

Das mit der Behandlung beliebiger Objekte als Streamfile ist in den APIs Objekt abhängig abgefangen, aber hier gibt es in der Tat einen weiteren Ansatz; SaveFiles haben zwar eine Art Zeilensignatur, aber die dürfte angreifbar sein (wieder mal amerikanische Exportrestriktionen und IBM).

Dieter

Ich glaube nicht, dass du in ein PGM-Objekt (kann man ja per /qsys.lib ggf. bearbeiten) nativen Prozessor-Code einfügen und dann auch ausführen kannst.
Basis der AS für ALLE ausführbaren Objekte ist und bleibt die MI-Ebene.

Dass man PGM-Objekte auch als Datei behandeln kann zeigt ja bereits der SAV-Befehl. Wie sonst kann man denn alle Objekte sichern als als Stream.

[Fuerchau]

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.

[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 ... ?!)