Re: How many of you will stay at V7R5 lower due to SDA removal ? -- MIDRANGE-L

"Some green screen editor is required".
This may be true, for those rare cases when the system is in restricted
condition and one needs to do a quickie CL to fix something. A prominent
IBMer in the IBM i environment gave this reason why IBM has no plans to
scrap SEU.

However, there seems to be an assumption that all systems have SEU loaded.
I can assure you this is false. Often it is not on non development lpars
due to change management control environments, etc.
For those cases where such CL crisis use may be required EDTF can be
counted on to be on all LPARs. And for editing completely free format RPG
is just as useful as SEU.

On Sat, Jul 26, 2025 at 12:11 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

The language in question, Jim, is PL/MI. It had a "brother" in the
mainframe world, PL/X, I believe. While there are surface similarities to
PL/1 the tie is not that strong. I'd show you a sample if I had kept any.

While C and C++ have seen increasing usage in more recent times (i.e. post
V2R3 and the arrival of ILE) as far as I am aware very little if any of the
older code was ever rewritten. C is used for the more recent stuff like the
ILE RPG and COBOL compilers.

And while x y's assumption that nobody who worked in IBM dev had a clue
about building commercial apps has a little validity, there were many
contractors and staff, such as myself and my partner, Susan, who were
professional hires who had significant real-world experience.

I could understand all this fuss if SDA were any good or if DDS were being
withdrawn. DDS lives on and can still be edited in SEU. SEU itself will
probably hang around if for no other reason than some green screen editor
is required.

Jon Paris
Jon.Paris@xxxxxxxxxxxxxx

On Jul 25, 2025, at 7:53 PM, Jim Oberholtzer <

midrangel@xxxxxxxxxxxxxxxxx> wrote:

That one off was a variation of PL/1 if I remember it correctly.
iBM Changed to C about 6.1?

Again my memory is fading.

Jim Oberholtzer
Agile Technology Architects

On Jul 25, 2025, at 5:38 PM, x y <xy6581@xxxxxxxxx> wrote:

IMO, Patrik's explanation is exactly right. IIRC, there was a one-off
language used to develop System/38's CPF and utilities; it would make

sense

that SDA was built using that tooling. With the move to RISC and the

great

emphasis on secure software, it's likely parts of the SDA app would not

get

through a code review or a systems assurance test today. Hence, IBM's
trying to kill SDA because key components are borderline unusable.
Meanwhile, IBM is whistling by the graveyard hoping thousands of

customers

and applications developers don't miss it.

But here's one big problem with Patrik's scenario: why hasn't SEU been
end-of-life'd? It likely uses the same development framework and one

would

think it suffers from the same ailments as SDA. SDA appears to be the
stalking horse to gauge customer reaction to killing off ADTS and PDM.

Hey IBM: how about inviting a couple of user Big Brains, folks with no

IBM

history as an employee or contractor, to your dev locations and show

them

what tools you use in your labs? That would pull back the kimono a bit

but

it ignores one area: interactive development. Do you have any apps

other

than SDA and SDA that use *DS4 mode? Interactive app development is

harder

than you think; how many on the lab staff have built and managed a
real line-of-business application? A tactical solution is to kill SDA

in

the expectation/hope/bet that a VS Code plug-in will provide a better

and

cheaper solution but the unintended consequence of that is leaving RDi

and

Merlin behind in favor of VS Code.

Some favoring euthanizing SDA and SEU point to the importance of

adopting

modern development practices supported by modern development tools. But
conflation isn't the answer: great art--paintings, shotguns, a garden,
wooden boats, software applications--can be created in humble

surroundings

with low-tech tools (one notable exception: fancy web pages are

essentially

beyond human comprehension and require a robust tool to keep track of
everything). Applications developed in a steel-and-glass monolith

aren't

inherently better but there's no question that modern dev tools greatly

aid

the development process. Colorizing tokens, RDi's CTRL+2, and RDi's

ALT+Z

provide measurable productivity increases but they don't contribute
directly to the product.

And that other thing about the OS being green-screen...well, yes.

What's

notable about that truth is the lack of movement by IBM. That suggests
resources are directed to other areas. There are changes coming and

it's

just a matter of time; IBM's Merlin may signal how we develop in the
future. Pardon me while I check my life expectancy chart.

On Fri, Jul 25, 2025 at 8:10 AM Patrik Schindler <poc@xxxxxxxxxx>

wrote:

Hello Gavin,

Am 25.07.2025 um 14:56 schrieb Gavin Inman <

midrangelist@xxxxxxxxxxxxxx>:

If you want to push your remaining dedicated base off a platform IBM,

eliminate 5250.

Matches my thinking. When I started exploring the system as a
retrocomputing hobbyist in 2007 and soon after found it extremely easy

to

write full screen text UI applications — compared to Libcurses on

Linux.

Sadly, TUIs are (outside of nerd niches) generally considered outdated
nowadays, and the limitations of the 5250 forms based approach limits
possible interactions with the user even further. Everything has to be

GUI

and clickable, despite the fact that requested information is still

text.

Mostly.

But then, I'm not a commercial user, and consider myself being part of
that nerd niche mentioned above.

:wq! PoC

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.