Re: SFTP Question

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 03/11/2016
03:39:15 PM:

From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 03/11/2016 03:40 PM
Subject: Re: SFTP Question
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

LOL, Vern. I believe there are relevant distinctions between IBM i and

PASE

that more people, particularly developers should be aware of. The same
would be true if say Microsoft were to port Windows to run on Power 8
processors.

Actually, Windows NT 3.51 - NT 4.0 did run on POWER, but I can't see how
that's relevant at all.

PASE and IBM i are joined at the hypervisor level in the SLIC, and below
that at the Power chip level. Otherwise they are quite separate. PASE

runs

on top of the "syscall" interface, while IBM i runs on top of the
"technology independent machine interface". PASE does not receive the
benefits of single-level store, nor the assurance that your applications
will run on new hardware.

Below the SLIC, the hypervisor switches between two distinct processor
modes, one for running PASE workloads, and another for running IBM i
workloads. The "switching" is comparable to that which results from

having

multiple partitions running simultaneously.

Sort of:
PASE applications and the MI applications both sit on top of SLIC
SLIC sits above PowerVM
PowerVM runs on POWER CPUs

PASE code run with the CPU in "tags inactive" mode and OPM and ILE code
run in "tags active" mode. This CPU mode is switched in SLIC, not in the
hypervisor. This switching is also nothing compared to running multiple
LPARs simultaneously.

And, while PASE doesn't get the benefits of single-level store, it also
doesn't have the problems that come along with it either ;) (namely that
most code is not written with SLS in mind, since no other platform has
it). Also, while it may be true that there could be some hypothetical
future POWER processor that drops an instruction and your PASE code will
no longer work, it's about as likely as the existence of a teapot orbiting
the sun. Even in that hypothetical case, the illegal instruction could be
trapped and emulated by SLIC (albeit much slower).

Up in the application layer, it takes a lot of work and overhead for

PASE

applications to communicate with IBM i applications, and visa versa. The
overhead is similar to communicating between Unix / Linux workloads and

IBM

i workloads, which are running on completely separate hardware.

Yes it can be a pain to call in to PASE from ILE or ILE from PASE, but
that overhead is nothing compared to "communicating between Unix / Linux
workloads and IBM i workloads, which are running on completely separate
hardware."

The cost to call in to PASE from ILE is:
- possible ASCII/EBCDIC conversion
- making sure arguments are accessible by PASE (Teraspace)
- API call Qp2CallPase -> MI call in to SLIC
- SLIC parses API arguments and sets up POWER calling conventions in to
API
- SLIC sets tags inactive
- upcall from SLIC to PASE
<PASE code runs>
- return from PASE to SLIC
- SLIC handles return value for Qp2CallPase
- SLIC sets tags active
- return from SLIC back to ILE

Any time you cross the MI or syscall boundary results in a CPU context
switch, so you require 4 context switches to call from PASE to ILE or ILE
to PASE. While a context switch is expensive (in CPU terms), it is much
less expensive than any form of socket call between separate LPARs on the
same hardware let alone on "completely separate hardware." By the way, to
do any sort of IO is going to require a context switch anyway, so you
still have at least 2 context switches in the socket case, plus the socket
overhead.

I acknowledge the benefit of joining these environments on shared

hardware.

On the other hand, I find it silly for an organization to refuse say a
third party SFTP client which runs "natively" on IBM i, and favoring one
that runs in PASE.

Favor the one that works better for your needs. It's going to be easier to
integrate ILE/OPM code with other ILE/OPM code and PASE code with PASE
code, so if you have a choice to suit your environment that meets your
needs there's no reason to make your life harder. Likewise, if a PASE tool
exists that doesn't have an ILE/OPM equivalent (or vice versa), why make
your life harder by rewriting it in ILE/OPM (or vice versa)?

On Fri, Mar 11, 2016 at 12:46 PM, Vernon Hamberg

<vhamberg@xxxxxxxxxxxxxxx>

wrote:

LOL - this is maybe a distinction without a difference, since IBM are
making a strong point of using something in PASE instead of taking

time and

personnel to write it in "native" IBM i.

We already have Java running there, and the C/C++ compiler, IIRC.

Add to that the 5733-OPS "product" offering - is that the licensed

product

designation for the open source stuff?

I know you said "like", Nathan - still, it's not a Linux anything -

and it

is an AIX environment, not a full-blown installation, as you know,I'm

sure.

There are no commands to run things in an AIX or Linux LPAR directly -
there are to run things in PASE.

Admittedly, all this does get kind of confusing. And I prefer that the

IBM

i developers concentrate on what is more important, the native stuff,
rather than take time to port and rewrite everything else.

Of course, this is only my own opinion as to whether it is "IBM i" -

IBM

seem to be thinking of PASE as part of IBM i.

Regards
Vern


On 3/11/2016 12:19 PM, Nathan Andelin wrote:

That definition would include the sftp option they're using!

Good point. PASE is more like running a second AIX/Linux partition on

a

Power server. It's not really "IBM i". There are fundamental and

relevant

distinctions

--
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.

--
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.

--
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.