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

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!