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)
midrange.com
