IBM Begins the Purge of Old Greenscreen Utilities
July 10, 2024 Alex Woodie
IBM is prepping the IBM i community to prepare to adapt to some substantial changes that are coming with the next release of IBM i, including the end of support for a large swath of the Application Development ToolSet (ADTS) that ships with Rational Development Studio (RDS). Source Entry Utility (SEU) and Programming Development Manager (PDM) are not among the ADTS tools getting the boot, but that’s not stopping midrange professionals from speculating that their time in IBM i is limited, too.
As part of its May 7 Technology Refresh for IBM i 7.4 and 7.5, IBM issued a “software withdrawal and discontinuance” notice that stated it would be ending sales and support for Merlin 1.0, Rational Developer for i (RDi) version 9.6, and other selected functions.
It turns out, there’s quite a bit under the “other” heading, including many of the utilities IBM distributes with the ADTS component of the Rational Development Studio compilers for ILE languages. The list of ADTS utilities that IBM will discontinue support for on April 30, 2025, includes:
- Report Layout Utility (RLU)
- Screen Design Aid (SDA)
- File Compare and Merge Utility (FCMU)
- Advanced Printer Function (APF)
- Character Generator Utility (CGU)
- Data File Utility (DFU)
IBM says there are several options for replacing these ADTS components, including Rational Developer for i (RDi), Code for i, and others.
The midrange community reacted to the news by expressing a variety of concerns, including and how they will obtain replacement functionality for the deprecated software, how long the software would continue to work, whether it will stop working on new releases of IBM i, and what sort of events (such as bugs or security vulnerabilities) would render the old ADTS tools essentially unusable on IBM i. Some also speculated what this withdrawal might signify in terms of IBM’s willingness to support other tools.
IBM i Marketplace Survey for 2024.
In various forums, midrange professionals questioned whether RDi or Code for i could in fact handle some of the specific tasks performed by ADTS tools, including SDA, which is used to develop green screen menus, or DFU, which allows a developer to work with a remote file as if it’s a local file.
IBM i professionals worried that some of the functionality lost with these ADTS tools won’t be replaced by IBM or even other independent software vendors (ISVs). Instead, developers will be forced to write their own tools, they said, or simply change how they work, which they suspect may be IBM’s intent with the moves.
The legendary backwards compatibility that IBM provides with its IBM i platform is a subject of great debate within the midrange community, as well as a source of some controversy.
On the one hand, supporters of backwards compatibility argue that the ability to run code that’s effectively unchanged from the 1970s shows how committed IBM is to protecting investment in business logic and intellectual property. No other platform, except perhaps the venerable System Z mainframe, can provide such protection for a business, they argue.
On the other hand, detractors argue that IBM is actually hurting its customer base and preventing the community from moving forward with modern tooling by allowing them to run code from the 1970s. Some of these folks would prefer that IBM would kill off the 30-year-old tools that enable customer to keep maintaining business logic written in older languages, such as RPG II written in the System/36 era. Perhaps more importantly, the usage of old tools prevents developers from using modern DevOps techniques, they say.
Many years ago, IBM hinted it would pull support for System/36 and System/38 RPG compilers, but the uproar from the community forced them to backtrack and continue supporting it. Since then, about the only blip in the long run of backwards compatibility was the jump from IBM i 6.1 to 7.1, which turned out to not be as bad as it could have been.
One year ago, IBMer Liam Allan floated the idea of killing off SEU, a longtime mainstay of greenscreen midrange development going back to the AS/400 days. While SEU is undoubtedly old and would not likely be anyone’s choice of an editor for a new project, many midrange professionals still use SEU to maintain old code, and have resisted IBM’s urging to move to a modern tool like RDi or VSCode.
In the end, an informal poll conducted by Jesse Gorzinski, IBMI’s business architect for open source, found that about 72 percent of midrange professionals said IBM “definitely” or “probably” should keep SEU, while only 29 percent said IBM should “definitely” or “probably” drop it from IBM i.
What exactly is IBM’s plan for SEU and other pieces of ADTS, which is still used by 80 percent of midrange users, according to the Fortra IBM i Marketplace Study for 2024? There were a lot of rumors going around the recent COMMON POWERUp 2024 conference in Fort Worth, Texas, about what the future would hold for SEU, but not a lot of substance beyond the products IBM has already committed to sunsetting. In any case, it appears that IBM is beginning the process of pulling back on the old greenscreen tools, and it will be interesting to see how far it actually goes.
By the way, a number of other IBM i tools are getting the boot on April 30, 2025, including:
- Bootstream Protocol (BOOTP) server
- Dynamic Host Configuration Protocol (DHCP) server
- Remote Authentication Dial In User Service (RADIUS)
- Domain Name System (DNS) server
- IP Payload Compression protocol (IPComp)
- Quality of Service (QoS) Server
- FRCA (Fast Response Cache Accelerator) for HTTP Server
- Performance Graphics; Performance Advisor
- Graphical Data Display Manager (GDDM)
- OptiConnect
- IBM Management Central Server
- Business Graphics Utility
- IBM Technology for Java 11 64bit (Option 19 of product 5770-JV1)
- Management Central
In some cases, IBM is offering replacements for these sunsetted products. In other cases, there are no replacements, or IBM recommends using an open source offering or a product from an ISV. You can read IBM’s software withdrawal and support discontinuance letter here. Similar information is available in IBM’s software planning guidance.
RELATED STORIES
What the 2024 Marketplace Report Says About IBM i App Dev, Language Use
To Kill SEU Or Not Kill SEU – That Is The Question
This is all effect of the “original sin”, namely, not having developed an incremental thin client terminal protocol, 5250 compatible, on which build upon.
Would have costed much less that all the attempts to circumvent the 5250 with all sort of fat client tech.
Fat client tech (like rdi or visual) that is now dinosaur technology.
Now mainframe-style model is in fashion (like cloud and browser = thin client), despite HTML+js was from the start was nonsensical to build ERPs.
Disconnected tech tools doesn’t have any sense in IBMi because you develop on the machines themselves.
I use RDi, it is always out of sync in language capabilities in respect to the machine I connect to. And must be installed ( “install a thing” is a third world solution , I don’t see any modernity of efficiency in it).
Impossible to disagree with Emma above.
IBM is in profound trouble by still focusng on the programmer and without deliverable applications solutions with these feeble attempts. like the GENAI project ,and C++, RDI, Debug, and VS code, rather than on replacing the programmer with essentially turnkey sophisticated and powerful applications software solutions as have the wildly successful companies like Microsoft, Oracle, and SAP, which now surpass IBM, courtesy of IBM continued failures for decades (Emma above).
The Tesla Full Self Driving (FSD) imminent implementation replaces the driver (the programmer) totally and much more efficiently and economically, and FSD AI principles should be used by IBM now to replace the prograamer and to achieve success.
That will take different IBM.
I can offer a slightly different take, well a significant departure from the tools argument. The “original sin” was locking out entrepreneur’s access to internals. Back in the day and still on the mainframes machine code lives, I used it when creating commercial products. Assembler on the S/36 was replaced by MI on the AS/400 which then was gutted so much so that it became effectively worthless forcing patches to code for more “restricted” access. The whole IBM argument bolstered by some community lackeys was to “protect” the customer, ie no system crashes. Instead it was really to ensure no competition for IBM products which is now why they can just cut you off. Explain why I can still code assembler on the mainframes if it was so dangerous, that sandbox is huge, no restrictions as I recall. If there was really a thriving vendor market at the tools level no one would care. Microsoft and Windows is a perfect example, their developer ecosystem makes the /400’s look like a tiny grain of sand. For every single development language Microsoft has there’s an alternative 3rd party, for every development IDE, there’s an alternative. Choices abound. More importantly I never run into any internal roadblocks when coding on Windows that I can’t legally get around and not put in prison for. IBM simply didn’t believe in the free market when it comes to the /400 just free market in their defined sandbox. So yes you can regret it but IBM doesn’t. Looking at this in the modern era, I build powerful products on AWS creating networks, servers, database, etc. and coding in many languages and Lambda, their serverless computing platform using an amazing community SDK’s which has access to 100’s of their platform services and that’s using a very simple browser like coding tool might as well be SEU. Effectively spending pennies compared to the thousands on IBM systems. IBM was too slow and far too costly to let developers have their freedom of expression, including access to internals over 40 years ago. I remember when IBM got the FBI to raid Leif Svalgaard’s office to shut him down. That’s the IBM you’re dealing with, afraid of a man who’s now a senior researcher in the Stanford department of physics. He did nothing wrong, just was a threat to IBM controlling you. That’s why you have no choices and are locked in. It’s also why IBM had it’s lunch eaten.