Re: "IBM i Modernization" & PASE

Nathan is not saying they ARE somehow implemented as two partitions
with a single hypervisor. He is saying they FEEL about the same as two
partitions with a single hypervisor.

I appreciate that, John.

In the book Fortress Rochester, Frank Soltis shows a diagram which depicts
PASE and OS/400 running side by side as 2 separate technology stacks.

They're separate at the higher levels in the stack which include:

Applications.
Operating System - AIX vs. OS/400.
Machine Interface - syscall vs. Technology Independent Machine Interface
Teraspace Memory Addressing vs. Single-Level Store.

They share:

SLIC kernel - which is where I believe the hypervisor runs.

They diverge again at the CPU level:

PASE runs in 32-bit mode vs. OS/400 running 64-bit mode.

They converge again with respect to all other hardware (devices, etc.)

I'm skeptical about the assertion of the TCP/IP stack running in PASE. If
that were true it seems like you'd be able to see PASE in the call stack.
But you don't see PASE in Jobs which are performing socket I/O.

You do see PASE in the call stack of Java applications. For example:

Module or Statement
Type Program Expanded Type Identifiers
1 QCMD QSYS
HTML2PDFF RDPDF HTML2PDFF QTEMP
HTML2PDFF RDPDF HTML2PDFF QTEMP 3100
HTML2PDFR RDPDF HTML2PDFR QTEMP
HTML2PDFR RDPDF HTML2PDFR QTEMP 159
QRNXUTIL QSYS QRNXJNI QBUILDSS1 76
QXJ9VM QJVM6032 QXJ9JNI QBLDJV6032 10
QXJ9VM QJVM6032 QXJ9PASEAC QBLDJV6032 5
QP2USER QSYS QP2USER QBUILDSS1 1
QP2USER2 QSYS QP2API QBUILDSS1 9
QP2USER2 QSYS QP2API QBUILDSS1 5
P unix *PASE_32
P libi5osenv.so *PASE_32
P libj9vm24.so *PASE_32
P libj9vm24.so *PASE_32
P libj9vm24.so *PASE_32
P libj9prt24.so *PASE_32
P libj9vm24.so *PASE_32
P libj9vm24.so *PASE_32
P libj9jit24.so *PASE_32
P libj9vm24.so *PASE_32
P libj9vm24.so *PASE_32
P libj9thr24.so *PASE_32
P libj9thr24.so *PASE_32
P libj9thr24.so *PASE_32
P libpthreads.a(shr_xpg > *PASE_32
P libpthreads.a(shr_xpg > *PASE_32
P libpthreads.a(shr_xpg > *PASE_32
P libpthreads.a(shr_xpg > *PASE_32
P libpthreads.a(shr_xpg > *PASE_32
P unix *PASE_32
J HTML2PDF *JAVA_MMI
J org/xhtmlrenderer/pdf > *JAVA_MMI
J org/xhtmlrenderer/ren > *JAVA_JIT
J org/xhtmlrenderer/ren > *JAVA_JIT
J org/xhtmlrenderer/ren > *JAVA_JIT
J org/xhtmlrenderer/ren > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/lay > *JAVA_JIT
J org/xhtmlrenderer/css > *JAVA_JIT
J java/util/HashMap *JAVA_JIT
J java/util/HashMap *JAVA_JIT
J java/lang/String *JAVA_JIT

Notice how the "Type" changes from _blank, to "P", then to "J".

The "Module" goes from native objects, to *PASE_32, to *JAVA_xx.

The fact that you can see a call stack for *PASE and *JAVA supports the
assertion that "PASE applications utilize the same underlying i5/OS
support". But that's not what I was referring to in my assertion about the
application characteristics being like running in 2 separate partitions.

To be more specific, PASE applications must send messages to Jobs such as
QZDASOINIT in order to access IBM i resources (database objects, programs,
etc.). That is the same characteristic as if the language environment were
in fact running in a separate partition or a separate server altogether.

PASE language environments don't support true "calls" to native programs
and procedures. Rather, the interface is to use some form of inter-process
communication (i.e. sockets) to exchange messages. The actual "call" must
be made from the say QZDASOINIT Job; the same interface used by Linux and
Windows clients, for example.