MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » December 2013

Re: SNDDST not working after V7 upgrade



fixed

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)






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact