Re: Changing processing program of IBM commands - Legality, etc

I'm sure there are some still using SNDDST and folders though.. or for
sending simple email messages. I thought I was done with QDLS years ago!
haha..

On Sat, Sep 13, 2025 at 8:54 AM Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
wrote:

True, in my customer set the only ones using SNDDST are the ones trying to
get migrated to new software. SNDSMTPEMM is far more prominent.




Jim Oberholtzer
Agile Technology Architects

On Sep 13, 2025, at 8:21 AM, Brad Stone <bvstone@xxxxxxxxx> wrote:

I am messing around with this and for some reason the Allow Change flag
for SNDSMTPEMM is set as 0, unable to change.

Any ideas why? SNDDST seems to be ok, but I have a feeling more are
using SNDSMTPEMM as SNDDST is pretty old and outdated and uses folders
instead of IFS files for attachments.

On Fri, Sep 12, 2025 at 9:37 AM Jim Oberholtzer <

midrangel@xxxxxxxxxxxxxxxxx>

wrote:

I highly doubt that using the suggested method of the command registry
method would run anyone into trouble with IBM legal. IBM built that
interface so you could safely, and securely (within the bounds of the
program anyway) make changes to behaviors such as the SMTP which by all
reckoning IBM really would like to stop supporting.

In short IBM built the registry and the command change APIs so you could
do exactly as needed. Change the behavior of the SNDDST command to call
your stuff instead of the IBM supplied versions.
--
Jim Oberholtzer
Agile Technology Architects

On Sep 12, 2025, at 8:01 AM, Brad Stone <bvstone@xxxxxxxxx> wrote:

Thanks for all the help.

I'm wondering now if maybe I should just put docs together to show

people

how to do it themselves instead of supporting it myself. I will dig

into

it. I have a few folks concerned about the OAuth change for O365 and

want

to be able to help one way or another.

Thanks again. As I said, my main concern is IBM coming after me for
something. haha.. I think I got put on their s list when I wrote my

eRPG

books at the same time they were pushing Websphere. ;)

On Thu, Sep 11, 2025 at 11:46 PM Gavin Inman <

midrangelist@xxxxxxxxxxxxxx>

wrote:

Hi Bradley,

I personally don't see any issues with using your own program in place
of an IBM program. I've done it for years.
Just be aware, on an upgrade or major TR, things may get undone. For
this reason, I always create a "syschgpgm" that has the documented
customization's in source to make all the "modifications" that your
system has. This way, after an upgrade when things are "undone", you
can simply run the syschgpgm and things are put back they way they

need

to be.

Also, I liked saw the reply about placing customized commands higher

in

the system Library List. This is an excellent Idea. Create your own
OVRSYS or something Library and place it in the system library List
above QSYS. This way, you can place all the customization's OVRSYS
library. It will minimize the Un-doing.

If you get too wild, you can always Remove your custom Library from

the

system library list before an upgrade or PTF Apply.

Gavin.

On 9/11/2025 4:55 PM, Brad Stone wrote:

<vendor>
I've been getting a lot of people asking me if they can keep using IBM
commands like SNDDST to send email but have MAILTOOL handle the

processing

in the background.

For a while I've toyed with the idea of either:

1. Renaming the IBM command in QSYS and duplicating the command(s)

and

using my own processing program to call MAILTOOL in the background,
basically so I know the full command details and parameters.

2. Changing the processing program to something else I can control.

This

of course would mean I'd need to find the parameter sizes, types, etc.

of

the IBM command, and if anything changes with OS versions, PTFs,

etc...

then being on top of that (which is why I like #1 better).

3. Other options?

My issue is I don't want to poke the IBM bear if that may cause legal
issues for myself or the IBM customer if I "teach them" how to do

such a

thing. And I realize OS updates and PTFs would most likely require

the

changes to be made again.

This really stems from MS setting their deadline for OAuth 2.0
authentication for SMTP in March 2026 (which has been pushed back a

couple

times and probably will again...)

I totally understand why they want to do this as they wouldn't need to
really change much, if anything, on the email processing side in

hundreds

or thousands of programs.

They also asked about incorporating it into other ISV email programs,

and

as I've told customers for years, that's totally up to the ISV if they

want

to work together for a solution for them. So far no takers.

Just curious if I were to go down this route would it be poking a

bear...

I mean it would be a great service for IBM users who need a solution.

Last

I heard IBM will not be providing an OAuth solution for IBM SMTP.
</vendor>

Vendor tags added "just in case." :)

Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any

Cloud

Provider!


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

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