I surely stand corrected regarding Eclipse platform for my approximations (and I heavily used it in the pure java world in the past and in other tools as well); when citing it I was referring mainly to RDi (so mainly the plugin), and of course this comes not from scientifically software profiling but from anecdotal evidence having spoken and seeing and hearing what do, what say (and murmur ;) ) and how work many people and contractors "in the trenches" if they use RDi.
There is also some decent work being done on the Visual Studio RPG plugin this days, and surely worth to check it out (of course, for now, not up to RDi in completeness and sophistication, but having a middle ground, sufficient for more tasks, less complex IDE could be an advantage too).
Still, I insist on the concept that we need an "institutional" editor, connected, published from the host, IBM native, you don't have to mess with license on your laptop or install, a go-to editor, ready, always there, where you sit and connect and work (like SEU); ok not full featured like RDi, but, as baseline, the features present in SEU today should be present (plus full free syntax RPG support, plus IFS support if one wishes), nothing exoteric.
Regarding JS + REST services; they are nice and can be used for a lot of use cases and external supply chain integration, portals etc. with great results.
Still for pure and simple ERP development, it is not a conversational online interactive session based workstation and protocol (ok a mouthful ;) but take in account that an interactive session on old 5250 provides an unmatched level of visibility, introspection and easy debuggability in the system being a discrete and separate job(s) abstraction in the system).
The "web" and http was born and thought as "disconnected" session-less protocol (for documents), and we see and witness the level of complexity and software layers that are needed in some frameworks just to add the "session" abstraction to the stack.
Some, to circumvent all this, in some specific custom applications, just open a WebSocket just from the start and just run a specific/custom protocol over it.
Regarding software engineering aspects: reading some dominant opinions I just think sometimes that "i" world promoted separation of concerns FROM THE START and as a grounding and overarching philosophy, i.e. you have as a separate concept a display file (a view!!!) and you have the code. It is harder to create a monolith in RPG even III then - say - in PHP. In PHP you see sometimes "echos" all around in the code intermixed with business logic etc... difficult to do it in RPG because it forces you to have a separate view concept.
This separation allowed i.e. also today the pluggability of different view protocols and "display files" instead of the standard ones (see RPG Openaccess, used by some "modernization" suites).
RPG nowadays can with ease support any elegant software design for business applications, so, if something "smells bad", is not today the brush, but the painter.
On education IMHO: being RPG, especially the free syntax, a luckily lighter language in conceptual complexity compared to a heavy duty OO languages (say java, scala etc.), a normal software dev or CS can pick it up in one month after an introduction of i concepts.
------------------------------
ace ace
------------------------------
Original Message:
Sent: Wed February 16, 2022 02:48 PM
From: Daniel Gross
Subject: Is IBM AS400 Dead?
> > and eclipse is slow
> I have to protest against this remark
As a heavy user of RDi I can only second this - Eclipse and RDi aren't slow at all. Sometimes it seems, that RDi hangs on an operation, but you would have to wait on the terminal too, if you do the same operations there.
> > One of the major pain points: IBMi lacks a modern and visionary *native* graphic terminal
> The current consensus is to ReST services with a pluggable UI on top written in any of the
> cool frameworks that we have today.
On that point, I will have to respond - yes, today is everything JSON - some years ago everything was XML - and before that everything had to be 3-tier/client/server/pick-your-favorite - and in 10 years from now, I doubt, that JSON will be the "lastest and greatest" then.
And as long as the IBM i is degraded to an invisible back-end-system it will always be mocked as "dead". So a real "native GUI" - would have been a very good addition back then, and even today, because it gives the system a visible identity.
Today I would maybe develop it in JS to make it useable on "all platforms". But leaving it up to the developers/consultants was and still is a huge mistake IMHO, because if you already offloaded the UI from the machine (and this is often done) one might say, maybe it's not so hard, to de-platform all those nice web services too.
> Another problem with the native GUI approach is that business code gets mixed with UI
> code. Look at all the green screen applications out there that are hard to modernize
> because of this intertwining.
I would say, this is true for every platform. Look at all those (sometimes badly written) Visual Basic, Delphi, C#, PHP or other applications. Any determined programmer can embed the most sophisticated business logic in any Form/UI/Webpage if he or she wants to do so. But it seems, that nobody complains about that with PHP or Visual Studio .NET or Delphi - only if a RPG or COBOL programmer mixes logic with UI it seems to be the end of the world as we know it.
Don't get me wrong - mixing (too much) business logic into the UI is always a bad idea. With Delphi in the 1990s we extracted business code into separate units - with Java we used extra classes, sometimes in separate JARs - and today every sufficiently good RPG programmer extracts the business logic into service program procedures as far as possible.
If one doesn't do this - it is not the failure of RPG or all RPG programmers or the platform, that allows such bad programming style. So this is a non-argument to me.
------------------------------
Regards,
Daniel
Original Message:
Sent: Wed February 16, 2022 10:31 AM
From: Wim Jongman
Subject: Is IBM AS400 Dead?
> One of the major pain points: IBMi lacks a modern and visionary *native* graphic terminal
The current consensus is to ReST services with a pluggable UI on top written in any of the cool frameworks that we have today. React, Angular, you pick your favorite. Therefore, you could also argue that the vision was very good not providing yet another "native" GUI.
Another problem with the native GUI approach is that business code gets mixed with UI code. Look at all the green screen applications out there that are hard to modernize because of this intertwining.
> and eclipse is slow
I have to protest against this remark (being an Eclipse Platform committer). Eclipse is not slow. Eclipse is a very quick Rich Application Framework. It is the RDi plugin that is not fast because of the constant communication with the server. Perfectly workable though with a decent network connection.
> all the defect of eclipse
The same goes for this remark. You are insinuating that Eclipse is a buggy application, but that is not true. Even the 5-year-old version that IBM seems to be married with, 4.6, is very stable.
I enjoy reading your comments, but because you have pushed my buttons, I had to react ;)
Cheers,
------------------------------
Wim Jongman
Original Message:
Sent: Tue February 15, 2022 05:01 AM
From: ace ace
Subject: Is IBM AS400 Dead?
Really another "AS400 dead" thread? ;-P :-D I can just suggest to just search those words on google to find plenty and even good answers, we are so insecure in the AS (... pardon IBMi ) community that we investigate such aspect a lot ;)
Joking apart, the i incorporates some unique design aspects that were visionary and still are relevant and unmatched today to properly design robust business applications (from pure business perspective, x86 VMs sprawl and now microservices or light virtualization are IMHO a highly inefficient method to partition/design workloads....... much better the subsystem concept on i, pools, native job queues, high performance microservices (aka dynamic CALL to another PGM!) etc.etc.
But we must be critic also here to be constructive.
One of the major pain points: IBMi lacks a modern and visionary *native* graphic terminal (think something like PCoIP) and conversational oriented GUI usable on it and relative (streamed centrally from the machine) dev tools. I don't mean web, I mean a proper protocol built for ERPs and pure conversational sessions as a ground concept. Web is another thing (and super usable on IBMi today with all the open software available).
IBM should have improved incrementally the 5250 stream toward something different (keeping the same level of integration with the RPG toolchain).
Good design of dev tools are essential: there a reason why some people open SEU instead of RDi ... because on new machines SEU and compilers and search operations are crazy fast.... it doesn't make sense to have a disconnected (and eclipse is slow!) dev station like RDi because we need anyway a running IBMi to test and run RPG programs!
VAR "modernization" suites... (even the term itself is misplaced... what there is to modernize if the platform is indeed modern as we keep saying ? :) ) ... they are good but IMHO we need something native and integrated and supported by IBM (exactly like RPG and display file, SDA etc.etc. practically known by programmers ) otherwise there is too much fragmentation in the landscape in knowhow...
------------------------------
ace ace
Original Message:
Sent: Wed February 09, 2022 09:24 AM
From: Elise Parker
Subject: Is IBM AS400 Dead?
This is the most common topic discussed throughout the AS400 iSeries user community, and the motive behind such discussion is that current organizations, jobseekers, and developers want to know if the platform is still relevant today as it is an old platform introduced in 1988.
If you fall into one of the above categories, the answer may surprise you.
- Since the beginning, compatibility is one of the most robust features of this platform. You can efficiently run a program on IBM Power Systems that was created for IBM AS400 in the year 1988, that too with minimum or no changes.
- Due to this seamless compatibility, most of the companies that purchased AS400 years ago still refer to it as AS400 despite their Power server being of higher magnitude and features with cutting-edge technology.
Let's share your thoughts...
------------------------------
Elise Parker
Integrative Systems
Itasca IL
8664687974
------------------------------