I understand what you're saying and if you want to think of things working
that way "figuratively" that's fine. You're PC
"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 12/03/2016
06:15:29 PM:
From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 12/03/2016 06:16 PM
Subject: Re: "IBM i Modernization" & PASE
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
I've been catching up on some of the points made about the java native
interface, etc. I admit that IBM has provided interfaces which help
integrate PASE and IBM i, and PASE hosted language environments with the
IBM i integrated language environment.
I'm pleased that IBM i and PASE are integrated. I'm pleased that IBM is
supporting popular language environments in PASE. I've written ILE
programs
which call Java methods. I appreciate that Java is a supported platform.
I
don't want anyone misinterpreting my views as being anti-PASE or
anti-PASE
language environments.
On the other hand, I view IBM i as a platform, Java as a platform, PASE
as
a platform, and all the interpreted language environments which are
hosted
on PASE to be platforms. They are all virtual machine environments in
their
own right.
I'm mostly saying that platforms are containers which have fairly well
defined boundaries. And I think it makes sense to recognize and
acknowledge
the boundaries when you see them.
At the CPU level, IBM has indicated that Power chips supports 32-bit and
64-bit "PC mode", and 64-bit "Amazon" mode. The majority of Unix
applications in the world are 32-bit applications in contrast to IBM i,
which runs in the 64-bit Amazon mode. I just note the boundary.
Single-level store is a boundary. The technology independent machine
interface is a boundary. Frank Soltis makes a point that future hardware
changes may force a rewrite of Unix applications, for example.
This is correct. If we ever switch to a different architecture that
doesn't support running POWER-architecture binaries, PASE and all PASE
applications would need to be recompiled at the very least and some would
probably have to be modified.
In regards to the CPU switching between 64-bit Amazon and 32-bit PC
modes,
that sounds a lot like the role of a hypervisor. Frank Soltis indicated
If you're running a 64-bit OS on your PC (Windows, Linux, OS X are all
64-bit now) you do this every time you run a 32-bit application, no
hypervisor needed. x86-64 chips support 3 modes: 16-bit Real Mode, 32-bit
Protected Mode, and 64-bit Long Mode. Your OS will switch between these on
startup and then when running 32-bit applications will switch between
32-bit compatibility mode to run 32-bit applications and 64-bit mode to
run 64-bit applications. You're OS will do this many times per second as
it task-switches between different processes.
While hypervisors and operating systems are very similar (in fact so
similar that the Linux kernel integrated a hypervisor in to it: KVM), they
are distinct in this regard: an OS manages resources to run applications
(processes/tasks), while a hypervisor manages resources to run operating
systems (kernels).
that the hypervisor was a requirement for running IBM i and AIX together
on
Power; PASE is a subset of AIX.
Yes, if you want to run an AIX LPAR and an IBM i LPAR on the same system,
you need a hypervisor. While PASE is a subset of AIX, it runs as part of
IBM i and so it runs in the same LPAR - you do not need a hypervisor at
all to run PASE. PASE does not use the AIX kernel whatsoever, instead the
IBM i SLIC kernel implements the AIX system call interface and maps those
system calls in to SLIC code. That is why it's a subset of AIX as SLIC
does not do all the same things that AIX does, just as AIX does not do all
the same things that SLIC does. There are other projects in the world that
are similar: FreeBSD has a Linux syscall layer, the "Linuxulator" to run
x86 Linux binaries on top of the FreeBSD kernel. The most prominent
example now would be the BASH on Windows support in Windows 10.
I understand what you're trying to say, though: there are certain stacks
that are easier to use when you stay within those stacks. If you're
writing ILE RPG, it's easier to call other ILE RPG than calling PASE code.
You could say the same about calling ILE C code as well, since it expects
NULL-terminated strings and other differences. They're both more difficult
to call from RPG than other RPG code (though the difficulty is an order or
two apart between calling PASE vs calling ILE C).
I would not expect most developers to try to integrate these pieces. I
would think instead it would be better for someone to write a wrapper
interface that would be easy to use from RPG or ILE C or COBOL or whatever
and would abstract away the intricacies of calling in to the PASE code.
The reason you might want to do this is that there is code already written
in PASE that has some function you might want to leverage without having
to rewrite that in ILE code. It is up to each developer to determine
whether the amount of work to rewrite that function (provided someone
hasn't already written an ILE interface which does the same) is worth the
effort vs the time it would take to integrate the PASE code in to their
application.
midrange.com
