I highly doubt that using the suggestion 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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.