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.
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.”
“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?