Another possibility, IFS folder QTCPMM by default is never saved.
When a system is restored, this folder and its subfolders are not restored.
They are auto created on 1st of SNDDST
However, if there is another issue, these folders may not get created, could result in failure of SNDDST.
Also check your directory entries, make sure they are correct.
I remember a SNDDST issue following the restore of an LPAR.
Check IBM doc 21111802 for email config.
Directory . . . . : /QTCPTMM
Type options, press Enter.
2=Edit 3=Copy 4=Remove 5=
11=Change current directory ...
Opt Object link Type
ATTABOX DIR
DSN DIR
ENCODE DIR
FTRFILES DIR
LOCKBOX DIR
MAIL DIR
SMTPBOX DIR
TMP DIR
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, December 18, 2013 7:02 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: SNDDST not working after V7 upgrade
On 17-Dec-2013 13:11 -0800, fbocch2595@xxxxxxx wrote:
any info regarding SNDDST not working after upgrading to V7 from V6
and prior to that we sav21 and rst21 to the new iSeries at V6 then
upgraded to V7.
So, based on a sav21/rst21 I thought we had everything we needed on
the new iSeries for SNDDST
Was a /scratch install/ performed from the "sav21" media to effect the V6 "to the new iSeries", or was some other media used to install the
V6R1 on "the new iSeries"? If some other media was used, was the installation of the V6 *only* the LIC and the OS, or possibly were the QGPL and QUSRSYS features also installed? If the QUSRSYS had been installed before restoring from the "sav21", versus merely having been restored from the save option-21 [into an empty QUSRSYS per lack of it having been installed], then the restore option-21 would likely [if
ALWOBJDIF(*ALL) had been used] cause problems; even possibly, problems that might be manifest as described.
IIRC the ALWOBJDIF() used on the restore options from the GO SAVE menu was changed on v7r1 to use the special value *COMPATIBLE instead of the SpcVal *ALL to avoid the effects of renamed database files. Renamed database files in QUSRSYS would appear [on US English systems] with object TEXT starting with "Old name ". The restore option-21 presumably still uses ALWOBJDIF(*ALL) on v6r1.
Regarding the above "IIRC", seems possible [only as clear as mud; at least equivocal] that the v7r1 was changed to ALWOBJDIF(*COMPATIBLE), per the included change flags in the text snippet below:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzarm/rzarmrst21.htm
_i Using restore menu options 21, 22, and 23 i_ "...
≤Start of change≥ ALWOBJDIF(*ALL) or ALWOBJDIF(*COMPATIBLE) will be specified on the restore commands ≤End of change≥
..."
and I think everything we need is started; servers active
Verify all the necessary jobs started and stayed active. There should be some (troubleshooting) TechNote documents; e.g.
www.ibm.com/support/docview.wss?uid=nas8N1017620
Reference #: N1017620 Historical Number: 21111802 _i Configuring OS/400 SMTP i_ " _Technote_ (troubleshooting)
_Problem_ (Abstract)
This document explains how to configure IBM Power Systems SMTP for sending e-mails. It also includes configuring the iSeries to use the native command SNDDST to send to Internet addresses.
_Resolving the problem_
This document explains how to configure IBM Power Systems SMTP for sending e-mails. It also includes configuring the iSeries to use the native command SNDDST to send to Internet addresses.
..."
cfgtcp copied to new i and same sysname and neta and IP's same
dire's
Had the system been scratch-installed using the original "Sav21"
data, there should have been nothing to _copy_ outside of the process to replace the physical system; and the upgrade would have kept all that the same as well.
Any ideas as to how to figure out why the SNDDST command runs with no
error but does not send to the email address?
I would look at the history since starting the necessary servers to see if any jobs ended unexpectedly, then review the spooled joblogs; also review the active joblogs of the other server jobs that started and remain active. I typically also look for T-AF entries in the audit log to see if perhaps there are some authority issues for the server jobs; e.g. a reason a server job might have ended abnormally, or might not be functional even if remaining active. Then figure out how to track the activity for the Send process; e.g.:
IIRC the QZMF Journal (*JRN) object tracks some of the activity for the Send Distribution (SNDDST) command; perhaps only since having
effected: CHGSMTPA JOURNAL(*YES)
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
