Re: 7.6 and SDA ? -- MIDRANGE-L

There goes the usual FUD.
IBM did not say they were taking away SEU.
Repeat that five times.
They are under the mistaken impression that all LPARs need it to do quick
changes from support line. That is the reason quoted for not taking it
away. Most of my LPARs do not have the development tools loaded as that
violates change management. Only the development LPAR does. For some
quick and dirty CL program in a restricted state, I could use EDTF. And
there's your lightweight equivalent to notepad.

On Mon, Feb 16, 2026 at 3:14 PM x y <xy6581@xxxxxxxxx> wrote:

IBM has to man up and fix the tools many of us rely on today. I have RDi
and use it daily; I have VS Code and I use it. And I still use SEU and SDA
because they're faster and more productive for the small changes often
required for program maintenance. In addition, green-screen tools give me
the opportunity to build a variety of developer productivity options. Am I
a Luddite? Maybe--but I'm a *productive* Luddite.

The "speed" issue for me may be my environment: I'm on a VPN through an 800
mbps Comcast connection to systems with plenty of resources. It's easy to
be spoiled: running across the country--Seattle to Long Island--through a
VPN, SEU loads a 6,000-line source member in the blink of an eye. RDi: 22
unproductive seconds; 8 seconds for a 35-line CL member.

The unintended consequences of losing SEU and SDA may be the acceleration
of the talent drain. War story: I proposed replacing a mainframe with my
application. The customer had worked with my app in the past and the
financial benefits of getting off the mainframe were staggering. But no
deal: he explained the moment he told his COBOL programmers an AS/400 was
coming, every one of them would retire on the spot. Some programmers don't
want to deal with the learning curve and the uncertainty of a new
development environment; others will decide to abandon the platform
entirely and commit to another. In both cases, the organization is stuck
and this may be the catalyst that triggers the move to another platform.

IIRC, there are issues with the development environment used for SEU and
SDA--unsupported languages, lack of knowledgeable personnel, etc. In the
real world, we call this "technical debt"; ignoring it seldom makes it go
away (Steve McConnell and Martin Fowler have interesting perspectives on
this topic; they're highly recommended reads). Since AI appears to be the
solution for everything, let's put watsonx to work and have it rewrite SEU
and SDA.

The practical solution is to create a partition locked to V7R5--ugly but it
will work for the dev's.

There's a reason a (relatively) lightweight text editor like Notepad++ is
popular and efficient: not every coding task requires a development
environment.

<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

Virus-free.www.avast.com
<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Feb 16, 2026 at 10:23 AM Rob Berendt <robertowenberendt@xxxxxxxxx>
wrote:

I can't recall when IBM came up with this silly notion that /tmp should
have some weird attributes, like *RSTDRNMUNL. Caused absolutely holy

heck

with emailing with IBM utilities. And if you changed that attribute IBM
just changed it at every IPL. The user community did get them to stop
that.
This is some of the kind of stuff I'm talking about.
If you don't know that *RSTDRNMUNL does, prompt CHGATR. Basically if you
had a program running under your user id and it created something in

/tmp,

then something running under one of those qtm* user profiles could not
delete it. It had NOTHING to do with security or special authorities.
Think of it like aix or linux trying a perversion of QTEMP and everyone
having their own copy, but totally different. :-)

On Mon, Feb 16, 2026 at 1:17 PM Rob Berendt <robertowenberendt@xxxxxxxxx

wrote:

I do not "know" of anything. However, just for FUD's sake, let's say

IBM

decides that anything that addresses a certain part of memory
(yadda,yadda,etc, or some such thing) is a security risk and locks that
down. Much like level 50 security. Now let's say that some of these
commands, that are unsupported, are affected. You will have little to

no

recourse.

I guess you can always use them until you can't. But if that day

comes,

you'd better be prepared to do without or have a plan B ready.

On Mon, Feb 16, 2026 at 1:08 PM <smith5646midrange@xxxxxxxxx> wrote:

As an added question...

Does anyone know if IBM has ever removed access to an unsupported

command

mid release? For example, removing access to CMPPFM now even though

7.6

has been out for almost a year or are we safe at least until 7.7 or
greater? I'm just trying to keep track so I know how hard to push my
clients to find alternatives to existing but future going away

commands.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Vern Hamberg via MIDRANGE-L
Sent: Monday, February 16, 2026 12:54 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx>
Subject: Re: 7.6 and SDA ?

The Memo to Users says that the commands are still available in 7.6,
without the menu options 54 and 55 for CPMPFM and MRGSRC, things I

have

used a lot - I especially like how MRGSRC worked, as a 3-stage merge

that

let me preview results.

Support will be limited to security-related fixes -

non-security-related

stuff will not change. That's not a problem for me, the operation of

these

commands has been fine for a really long time.

You can always add a user-defined option that runs these commands.

*Regards*

*Vern Hamberg*

IBM Champion 2025 <cid:part1.0i2m6fxu.OnP7bJ32@centurylink.net> CAAC
(COMMON Americas Advisory Council) IBM Influencer 2023

On 2/16/2026 10:51 AM, smith5646midrange@xxxxxxxxx wrote:

Am I reading that page correctly that CMPPFM is no longer going to

be

supported in 7.6 which means at some point it will drop off of the

face

of

the disk? Is there another command / utility that should be used to
compare source members that I am unaware of? I use CMPPFM on occasion

but

it is always a minor comparison and not a deep dive so I have never

had

to

look for a better alternative.

-----Original Message-----
From: MIDRANGE-L<midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf

Of

Rob Berendt

Sent: Monday, February 16, 2026 9:23 AM
To: Midrange Systems Technical Discussion<

midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: 7.6 and SDA ?

According to the Upgrade Planning site at
https://www.ibm.com/support/pages/node/7183543 SDA is not part of

the

supported products on IBM i 7.6. PDM is not being removed.

For a detailed list of what is, and what isn't, being removed read

the

following:

https://www.ibm.com/docs/en/i/7.6.0?topic=rdsi5w-commands-from-rational-development-studio-i-5770-wds-option-21-application-development-toolset

Now, if the question is "Is there some hack to stop the upgrade from

removing (SDA for example)?" then I do not know of one, nor would I
recommend using one if there was. Why? Well, because IBM has given

you

notice that it's not supported and will be removed.

Just to add FUD (Fear/Uncertainty/Doubt) what's to stop IBM from

having

a new PTF every cume which does a search and destroy on some of these
options? Or, instead of removing them, uses some new technique which
causes each of them to generate some weird program space violation

message

or some such thing? Then you're stopped hard without further notice.

IOW,

adapt in a planned controlled environment vs "crap, they meant it!".

On Sun, Feb 15, 2026 at 6:11 AM Gad Miron<gadmiron@xxxxxxxxx>

wrote:

Hello guys

I was recently told by an IBM CE that when upgrading 7.5 to 7.6 you
can opt to not remove SDA, PDM etc. so you end up with a 7.6 system
with operational SDA, PDM.

Can anyone confirm this is true?

TIA
Gad
--
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 contactsupport@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

athttps://

archive.midrange.com/midrange-l.

Please contactsupport@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.

--
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.