Re: "IBM i Modernization" & PASE -- MIDRANGE-L

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 12/01/2016
05:11:59 PM:

From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 12/01/2016 05:12 PM
Subject: Re: "IBM i Modernization" & PASE
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

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.

There may be a some hypervisor code in SLIC for running i-hosted-i stuff,
but there is certainly a hypervisor below SLIC.

They diverge again at the CPU level:

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

SLIC has always run 64-bit since moving to POWER. Above the MI,
ILE/OPM/etc. applications could be considered 128-bit. Above the syscall
interface, user space PASE applications can run 32-bit or 64-bit for quite
some time now, though most of the stack remains 32-bit since it doesn't
need the extra address space. Java is one of the notable exceptions here.

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.

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

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.

This is absolutely wrong. There are a set of APIs/syscalls available in
PASE to *directly call ILE programs and service programs. They operate in
the same job and can operate on the same memory directly. The APIs are
listed here:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/apis/pase1c.htm

* they're not exactly direct, because you have to call through SLIC in
order to switch between PASE and the MI code, so calling an ILE program
from PASE would go PASE -> SLIC -> ILE PGM instead of PASE -> ILE PGM.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related

questions.