× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Patrik,

I can't take the time to respond to everything in your post. But I should
say that I agree with your questions and concerns about PASE. Splitting
your application architecture between PASE on the one hand (plus the
language environments that run in it) and native IBM i on the other hand,
leads to all sorts of problems as you try to scale your operations. As you
mentioned, the run-time inefficiencies are huge. Perhaps more importantly
the inefficiencies multiply by an order of magnitude when you try to
support multiple instances of your run-time environments.

Yesterday, we met with a customer who is running about 60 instances of our
IBM i web portal. Most of the instances align with political boundaries in
the state (counties, regional service centers, the state itself). The
political subdivisions want to manage their own operations locally (i.e.
manage their own user profiles, user authorities, etc.), although the
databases are hosted on a single IBM i server operated by the state. They
want to deploy about another 60 instances as they transition from their
home-grown system to a commercial alternative (ours).

We discussed three alternatives.

1. Add another partition for the new system.
2. Separate the run-time environments by using independent auxiliary
storage pools, which would allow us to use the same library names, but
separate storage pools for different systems.
3. Separate the run-time environments by using separate libraries (coming
up with a library naming convention).

If your application architecture relies on PASE, it is highly probable that
your only option for running multiple environments would be to divide your
hardware into multiple logical partitions, at huge operational and
administrative cost.

Our run-time environment for our web portal, database, and applications is
completely native IBM i. So we can offer a solution that consumes minimal
hardware resources, and we can deploy multiple instances of the run-time
environment, databases, etc. relatively painlessly on a single server.

I think Raul mentioned that he tried to provide response times less than 1
second. In our applications, the response times for most requests are under
6 milliseconds. A large portion of our requests complete in less than 1
millisecond on a LAN. Internet latency however may be 60-90 milliseconds.
The point is that when you have an architecture that supports outstanding
response times, you can also create more robust user interfaces, as opposed
to the dull, lagging user interfaces that one sees generally on the
Internet.





On Fri, Jan 3, 2020 at 5:56 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Nathan,

Am 03.01.2020 um 01:40 schrieb Nathan Andelin <nandelin@xxxxxxxxx>:

When you advocate for 5250, you're advocating for a terminal emulator on
the client and "interactive" sessions on the server.

Yes.

In most cases you're advocating for SEU and PDM (or their RDI
equivalents).

Maybe. There are other alternate approaches, outside SEU and outside
Windows. Personally, I'm using vim with syntax highlighting rules and it's
capabilities to "open" ftp URLs, in a terminal, on Linux.

You're generally advocating for RPG as a language.

Wrong assumption. RPG as I know it today (not the fancy free stuff) has
it's clear drawbacks, but in combination with DDS derived tables, display
files and whatnot, it's an incredibly valuable combination for getting a
program done very fast. They all are very tightly integrated. I bet that's
not much different with all-free which I didn't learn yet.

Move to UIM panels and creating small applications is way more clumsy.
From there you can also move to C with not much more inconvenience.
Personally I don't like Java, because it's a resource hog in memory and
it's inherent slowliness compared to other languages.

I'd bet that in most cases, the 5250 advocates have NOT seriously
explored alternatives. Therefore, they don't know how to create and deploy
alternatives to 5250.

Speaking for me: Wrong. But also I'm really not a typical AS/400 guy. My
first contact with serious computers was with the Macintosh. From there I
have a strong opinion towards consistent and easy to use UIs. Next I had a
short excursion into PCs, Novell Netware, and Windows 3.1. After that I was
digging into Linux (as a server platform) which stayed my profession for
now 25 years. I'm tinkering with my AS/400 for just 10 years, sometimes
more and sometimes less intense.

And honestly, it's sometimes hard to focus your brain onto new and unknown
stuff to learn when you're busy during the day keeping customer's stuff
running. This is to be meant as an explanation. Not an excuse.

Caution, heresy follows…

That said, be assured, that I *have* knowledge to create and deploy
alternatives to 5250, roughly. But as I asked before: Why on i? I don't see
a point in the clumsiness and apparent lack of completeness of PASE as
trying to be a true Unix environment, running applications designed and
written on Unix/Linux. In the end, there is a mess of stuff done in PASE
(PHP and Java comes to mind) and stuff from the CL world (wrkjobscde vs.
crontab) which doesn't help with keeping an overview.

There are a multitude of tools, frameworks and whatnot in the internet but
if IBM doesn't port them to this mixed mode environment, virtually nobody
does. I also point back *again* to the guy trying to update OpenSSL to the
most current version in PASE. No avail.

Why on i? For webby stuff, Linux made the snail race, silently and left
IIS behind many years ago. To me, Unix is *the* platform for webby stuff.
IBM even ported DB/2! So, why on i?

I know I'm really alone with this view on this list as a staging area of
Midrange fans/admins/programmers. In the outside world, this question has
been asked before many times. Why on i? With a multitude of huge licensing
costs, every year anew? Reliability? You can run Linux for POWER in an
LPAR, same hardware, with less cost. Linux *is* less stable than i but it's
also a *lot* more flexible (and has rebooted in a fraction of time compared
to i).

Why not using AIX then, if someone truly wants to stay with IBM?
Interesting that IBM itself is advocating Linux all around and bought
RedHat lately. AIX itself is there but also not actively pushed, similar to
IBM i.

IBM i was designed as a database machine and Unix was designed as general
purpose OS. IBM i is obviously a niche solution and it will stay there. The
main thing which keeps it alive is people making a living by converting
existing stuff to the browser, on i. Don't get me wrong, it's not bad to
make a living from this but to advocate this PASE-CL mess as "modern stuff"
doesn't get my acceptance.

And the user as the ultimate reason to convert to web stuff couldn't care
less as long as he can do his work.

The only thing I can imagine is that the data is already on the i,
"business logic" is already there, in the database or RPG code. To port all
that stuff to a separate system would mean a lot of more labour.

Have you learned HTML, CSS, and JavaScript? Do you understand a
browser's DOM (document object model), and do you know how to reference it
from JavaScript? Do you know how to configure the IBM i HTTP server? Have
you explored HTTP options for managing user authentication, authorization,
access to menu items, and sessions?

From advanced Database programmers to advanced Web Designers and
programmers. Now *that* is a change in direction! I wonder when the
full-stack hype will arrive in IBM i. SCNR… :-)

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.