To Kill SEU Or Not Kill SEU – That Is The Question
July 12, 2023 Alex Woodie
It was a simple question posed by Liam Allan on Ryver: Should IBM stop shipping SEU? The dozens of answers it generated exposed a stark divide when it comes to the use of legacy technology in the IBM i ecosystem and to what extent it’s okay for IBM to force its customers to adopt new technology.
There is no denying that IBM’s Source Entry Utility (SEU) is still in widespread use in the IBM i world. Statistics are tough to come by, but evidence suggests a majority of IBM i developers still use the greenscreen development tool for at least some of their application development or program maintenance work. Some peg the number at 75 percent or higher using SEU and its legacy partner in crime, Program Development Manager (PDM).
IBM hasn’t updated SEU with new features in many years, but it still continues to ship the utility with the operating system, and people of course still use it. Big Blue would love it if SEU and PDM users moved to Rational Developer for IBM i (RDi), it’s Java-based integrated development environment (IDE) to write and edit RPG, COBOL, CL, and other ILE languages. However, less than one-quarter of the IBM i user base uses RDi, according to the most recent IBM i Marketplace Study from Fortra (formerly HelpSystems), which develops RDi on behalf of IBM.
SEU is a familiar tool for most IBM i programmers.
RDi has its own set of issues and also prompts a love/hate relationships among its users and detractors. To IBM’s credit, it recognized the reluctance to move to RDi by creating a browser-based development tool, its Merlin offering. And then there is Allan’s own Code for IBM i, the open source development tool based on Microsoft VS Code. Allan, who joined IBM in 2022, is now looking to hand the care and feeding of Code for IBM i to somebody else.
So the message from IBM is clear: Use anything you like to develop on IBM i, just as long as it’s not SEU!
All the animosity directed at the code editor begs the question: Why doesn’t IBM just kill it altogether and force the community to use something else? In June, Allan posed that very question to the community of open source IBM i users on the Ryver website. The answers were quite illuminating.
There were a handful of folks who expressed strong feelings about leaving SEU out of the next major release of IBM i.
“It is a definite YES from me,” write Koen Decorete, the owner of CD Invest and a member of the Common Europe Advisory Council. “I’m against leaving old stuff in that is no longer being enhanced. This way we create technical debt. I’m almost the only left in my team that still uses it for certain things. If we keep it in and we keep using it, then we are feeding the impression we are an old and dead platform. We should use the new tools and move forward.”
“I think many of the old stuff should be removed,” writes Juan Manual Alcudia, a solution architect with CD Invest and the president of Common Europe. “Cleaning the O.S. of technical debt is a must. Maybe an alternate lite editor for CLs can be in place in case you need to use an editor in restricted state but should be more for sysadmins than developers.”
It’s a strong yes from Ryan Beckham, at McCreary Modern, a furniture maker in Hickory, North Carolina. “What if refusing to adopt newer techniques and tools is what’s stalling the platform now?” Beckham writes. “Catering to developers that expect to code the same way for 40 years…is ridiculous and aggravating. We still have tons of applications written in fixed format rpg that are about 12000 lines long written 25 years ago. They were good at the time but awful in today’s standards. They are terrible. The only way to move customers like us is to kill seu and we will be better off for it.”
However, some IBM i users noted that SEU continues to fill a vital role in their organizations, a role that would become a gap if IBM were to kill it.
“IBM should continue to ship SEU along with PDM,” writes Jim Oberholtzer, a longtime IBM i community member and consultant. “I use both VSCode and RDi and neither of them are universally accepted among my customer set. Many times, the firewall will stop connections with VPN and even internally at some locations. Convincing the customer to open up the ports needed for ACS is equivalent to brain surgery at times, complicated and only for the practiced…At many locations I’d be reduced to EDTF (shuddering at the thought) without SEU and PDM.”
According to Jesse Gorzinksi’s Twitter poll, a majority do not want IBM to kill SEU.
“From me, the answer is ‘no at this time,” writes Yoshiki Ushida, a system engineer from Chubu System Co. Ltd in Japan. “We, Japanese, treat DBCS as strings. On a 5250 emulator, we can represent shift codes realistically. However, in ordinary text editors, problems caused by shift codes often plague us. When all shift code problems are cleared up, then it will be a ‘yes.’”
“Imho definitely not!” writes Karl Fritz, the owner of Logic IT-Services in Switzerland. “I usually use RDi, VSCode or ChatGPT (joke) for wide programming as 1st choice. But for Q&D [quick and dirty] things, SEU is unbeatable . . . From a developer’s point of view you might consider it, but as an alternative it should not disappear . . . A really bad idea!”
“For me SEU is still an important tool,” writes Marks A. Litters, an IBM i developer in German. “Not for developing of course. [For that] we use RDi, MIWorkplace and VS Code (as well as Visual Studio for many other things) but when we need to make a quick fix SEU is still very fast and when you know where to look for it is much faster than the others . . . As someone else said it is also always available when you have 5250 access even in restricted mode. No need [to] install anything.”
Some folks saw plusses and minuses with keeping SEU around and with moving on from it.
“I like SEU. I can absolutely fly in it with my keyboard mapped to that of an old dumb terminal. I’d honestly hate to see it go,” writes Jefferson “Jay” Vaughn of Core-I Solutions. “But because it’s been unsupported for years now, I’m surprised it hasn’t been dragged out behind the barn yet.”
“Yes, if it holds back the language itself in any way. I’d support it going away or going read-only in a heartbeat if there was some reason we couldn’t keep it and have continual improvements to the language,” writes IBM i developer Joseph Wright. “Until then I see no harm in keeping it. It’s like notepad for windows. You wouldn’t get rid of it just because it’s a less powerful tool to write programs in than modern IDEs. Same with SEU. It’s up to then individual developer and the company they work for to set standards and they need to choose to use something better like vscode, merlin, or rdi.”
“You can lead a horse to water but you can’t make him drink,” writes Steve Pavlichek, a system engineer with Key Information Systems, which is now part of Converge Technology Solutions. “Just removing SEU will not force old RPG programmers into other languages. The tools are available for those who want to move forward but they need to want to or be allowed to. Merlin is not the answer either.”
Allan, who has probably done more to boost VSCode-style development on the platform than any IBM i community member, chimed in with his opinion too.
“It’s a yes from me,” Allan writes. “Sadly, I think it’s holding back IBM i and is a big part of what people see and what they are shown. Just because it’s working that way for X years doesn’t mean it’s right. I might feel a little differently if it supported newer versions of RPGLE, etc., and maybe was extensible (like Neovim or Emacs), but it’s not.”
IBM i educator Jon Paris took exception with Allan’s claim that SEU isn’t extensible. “Actually SEU is extensible. Perhaps not to the degree of some of the editors [you] listed but extensible nonetheless,” he writes. “As to the original question . . . much as I hate to admit it, it would be a disaster to remove it.”
Maybe there’s a third path that involves unshackling the chains holding the proprietary editor down? That’s the idea floated by Richard Schoen of MobiGogo.
“There’s an opportunity for you to get IBM to open source SEU for those who want to extend it,” Schoen wrote. “I’ve wanted extensions for literally decades. Just saying that if it’s frozen, fork it and allow an open source extensible version of SEU. OSEU for Open SEU.”
“I’d rather see it die,” responded Jesse Gorzinski, the IBM business architect for open source, to Schoen’s proposition.
Gorzinski took the debate to Twitter, where he ran a poll, asking “should SEU be dropped from #IBMi?” With 155 people voting, the “Definitely not!” contingent easily won with about 48 percent of the votes, compared to “Definitely!” with 18 percent of the votes.
The debate over SEU aptly showcases the conundrum that IBM has long faced when it comes to its legendary backwards compatibility. Yes, you can still program like you did in the 1980s, but is that what’s best for your business?
While Windows is again improving Notepad, people that think removing SEU will solve the technical debt problem clearly don’t understand the issue. Technical debt is a PEBKAC problem !
Clearly, one’s next job and continued career on the AS/400 (or whatever IBM’s calling it this week) is very likely going to depend on their knowledge of RDi. Even though MANY companies refuse to foot the expen$e to acquire and deploy RDi, many jobs now are becoming totally dependent on a programmer being able to use it. In short, unfortunately, if you don’t know/use RDi, there’s a lower chance of you being hired, regardless of if you have 30 years experience on the product line or not. Unfortunately, companies are tending to trend towards not wanting to hire someone that doesn’t have RDi in their talent list…nor are they willing to help a person with major experience on the product line to develop those talents.
In short, unfortunately, your continued cash flow will most likely depend on you knowing/using RDi. SO, if you don’t have it, you need to use the SPNDCSH command and get it…which will clearly make IBM happy…
As for keeping SEU available….YES, it needs to be kept available. Cutting off support for it will do nothing to enhance good feelings between users and IBM…
Always good to hear from you, Don.
SEU has exit points. If you don’t like the way it works, you can modify it. If they get rid of SEU I’ll move to vi. I killed the syntax checker a long time ago; it just gets in my way. I can’t stand Rational Developer – I can’t get it to quit throwing java null pointer exceptions. Multiple versions, multiple machines.
75% of iSeries Developers use SEU and people are advocating that IBM drop it? That’s nuts. Issues with the modernization of the iSeries has nothing to do with what source editor we use.
The graphic with the survey results says 75 percent say it should probably or definitely NOT be killed. The text says an estimated 75% still use it
I’ve used RDi exclusively for quite some time now… However, occasionally use SEU when quirky things happen (i.e. telling me the member is locked and I can’t save it).
As an IBM customer, I would be OK with removing SEU… But ONLY if IBM ships RDi or one of the other source editors WITH the operating system!
When they dropped twinax connections, they included ACS (client access) with the OS. If you are purchasing the compilers, how is this any different?
The main “problem” with PDM and SEU is that they are just so darn good! I’ve developed on multiple platforms when text editors were new-ish and SEU is by far the best platform- and language-specific editor I have ever used. PDM delivered dramatic productivity gains and is, essentially, emulated in RDi and other editors.
The main “problem” with RDi is the cost and the steep learning curve. The later we just need to get over it. The former is a change of mindset for those creating the IT budget and, IMHO, IBM got the price just way too high to begin with. The cost was (if I recall correctly) higher for 1 seat of RDi than that of PDM/SEU for unlimited users.
Do we need to move forward? Yes, without a doubt. Has IBM made that transition any easier? No – they stymied the transition by making the price of RDi far too high for the average IBM i company.
I don’t believe SEU/PDM is/are holding back the platform. If you are showing SEU to someone as “this is IBM i” you are misrepresenting the best platform on the planet – ever! But text editors are a “given” on any platform as we must edit all kinds of text files. So eliminating the BEST would be a foolish mistake.
IMHO!
Why the hate on PDM? “Partner in crime”, really? SEU, I get, but unless RDi has added new features since the last time I used it four years ago, RDi is no match for PDM’s capabilities.
As far as killing SEU, doesn’t the platform already have enough problems with a shrinking programmer pool? How many programmers will retire if SEU is dropped from OS 7.6? You say “good riddance”, but you’re really just cutting off your nose to spite your face.
Win still has notepad and cmd.exe. AIX still supports VI and other ancient tools. One toolset for all customers is not reasonable. Developers should learn new tools, but many shops only need basic tools for light or no maintenance. Way back when the “you don’t need an army to run the system” was promoted – this basic idea – ..the system should allow you to focus on your business, not on the machine (or tools) that help you run it.
Many of my user defined PDM functions are CL with DDS screens. They don’t work with RDI user defined functions. So if you run a function with validation, RDI can’t display the DDS validation screen. I use RDI 99% of the time but need RDI to stick around.
RDi is surely (despite some quirks) the more complete tool feature wise for IBMi.
The possibility to debug a live machine creating a SEP with filters per userid remotely with a couple of click, integrated with the IDE, monitoring memory and variable in different windows while tracing, is indeed powerful and optimize time and accuracy (some people IMHO forget that good debugging support is a major part of a dev tool… ain’t only editing! and RDi is the more complete on the market on that regard without a real competitor).
Suggestion: buy RDi license with the machine and OS (not after).
Still, stated that, this does have nothing to do if SEU exists or will exists or should exists or not!!
As many polls, the questions distorts and guides the result, because it lacks the fatal “should IBM keep improving SEU?” … YES!
Nobody screams “OMG old dinosaur” when I connect to a modern linux instance in cloud with SSH and I edit some files with VI or nano.
Should be the same using 5250 (over SSL or not) and using SEU.
Not adding a couple of syntax checks for RPG free in SEU is, IMHO, just plain lazy and not respectful if the “i”ntegrated phylosophy.
SEU is the institutional editor of the machine. It’s already installed. It’s ready for use in a second from everyone. It is served via 5250 that is the standard system protocol of the machine. All use the same version after a machine upgrade. It readily works for – say – quick program fixes even if only the console is up.
These are (fundamental) characteristics lacking in a fat client (like RDi).
Real life: I’ve fired up RDi 9.8 (new version) because I pride myself to keep up with tech eheh. Oh, it is a different installation style from 9.6. Oh I’ve lost all settings but maybe I can import them (unsupported?). Oh I launch a debug but now doesn’t work because (despite I’ve have last TR) the machine still lacks a particular backend debug PTF to work 9.8… and it cannot gracefully degrade to be backward compatible… so go back to 9.6… enjoy who have multiple customers-machines…
Of course this issue would be non-existent with a proper modern conversational display protocol IBM should have developed years ago evolving the 5250 : – P P P P P ; ))
As always, ema tissani is thoughtful, insightful, and correct.
YES, SEU suold be retained and enhanced as ema states:
“Of course this issue would be non-existent with a proper modern conversational display protocol IBM should have developed years ago evolving the 5250”
One of the actual fatal flaws for the IBM i relating to SEU and RDI is that programmers must use the 70 year ancient and primitive IBM Debug program to try to understand what is happening or happened during program execution.
That forces programmers to waste 75 % of their time and energy and capability in using the ancient and primitive IBM Debug program, wasting perhaps 30 Billion dollars of the 40 Billion dollars spend annually on IBM i programmers.
A truly modern and essentially free alternative to IBM Debug is the Real-Time Program Audit (RTPA) for IBM i software. Multiply IBM i Programmer Productivity, Capability, and Value with streaming video and automation
https://www.youtube.com/watch?v=Kv0L3e9Wqh4
Where have all the IBM visionaries gone?
It is like asking Should IBM kill IBM i? SEU is used by 75% of IBM i customers or even more. Killing it may just kill the platform.
Instead i would ask Ibm to improve it, Add at least some of the new RPG code syntax.
I love RDi and use it whenever it’s indicated but there are times when SEU is much easier/quicker. Right tool for the right job kind of thing. But I also wrote a utility using the FNDSTRPDM that lets me put every source member that contains a matching string into the same DB file so that I can SQL it to find all the occurrences of a string. It can really leverage the power of SQL to ask some sophisticated questions about my source library.
Even if IBM were to stop allowing creation/editing of source I still want that functionality as well as the ability to browse & compare source.