MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » December 2013

RE: SNDDST not working after V7 upgrade



fixed

While troubleshooting/verifying the Change SMTP Attributes (CHGSMTPA) router settings,

Looking at the properties of an email for the correct Exchange server name, I found this.

Why, if we are on a V7R1 system, does the properties body of the email state Received by PENCOR)6.PENCOR.COM (IBM OS/400 ANYMAIL/400 MIME V5R4M0)

Where is the OS/400 ANYMAIL MINE V5R4M0 coming from?



[cid:image001.png@01CEFD9E.EF055FD0]



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Friday, December 20, 2013 8:46 AM
To: Midrange Systems Technical Discussion
Subject: Re: SNDDST not working after V7 upgrade



Did the IP address and/or name of the system change? Is your mail server configured to accept mail from that address?



Charles





On Thu, Dec 19, 2013 at 4:10 PM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx<mailto:PSteinmetz@xxxxxxxxxx>>wrote:



Ok, now we have some SNDDST failing intermittently via SWPUSRPRF.

We upgraded to V7R1 11/23/13



2000 - SWPUSRPRF USRPRF(PENCOR06) CMD(***) Send distribution

completed successfully.



NOT ABLE TO DELIVER MAIL TO SOME/ALL RECIPIENTS.

REPLY CODES WITH FIRST DIGIT = '4' OR '5' ARE ERROR REPLIES.

ERRORS THAT DO NOT HAVE ERROR REPLY CODES MAY EXIST.



HOST PENCOR06 NOT ABLE TO DELIVER MAIL TO FOLLOWING RECIPIENT(S):

<MISIcapiProgrammersNotifications@xxxxxxxxxx<mailto:MISIcapiProgrammersNotifications@xxxxxxxxxx>>

ERROR IN BATCH SMTP COMMAND SEQUENCE.

MAIL FROM:<PENCOR06@xxxxxxxxxx<mailto:PENCOR06@xxxxxxxxxx>>

530 5.7.1 Client was not authenticated



** TEXT OF MAIL FOLLOWS **

Received: by PENCOR06.PENCOR.COM (IBM OS/400 ANYMAIL/400 MIME V5R4M0)

Thu, 19 Dec 2013 15:23:31 -0500

MIME-Version: 1.0

Date: Thu, 19 Dec 2013 15:23:31 -0500

Message-Id: <105815R1312191523290000000003@xxxxxxxxxxxxxxxxxxx<mailto:105815R1312191523290000000003@xxxxxxxxxxxxxxxxxxx>>

Subject: TIVO deviceInfoSearch RXSEE61R QPADEV0008 DE

Sensitivity: none

Priority: normal

Importance: normal

From: PENCOR06@xxxxxxxxxx<mailto:PENCOR06@xxxxxxxxxx>

X-From-OFFICEVISION: <PENCOR06 PENCOR06>

To: MISIcapiProgrammersNotifications@xxxxxxxxxx<mailto:MISIcapiProgrammersNotifications@xxxxxxxxxx>

Content-Type: multipart/mixed;

boundary="PART.BOUNDARY.1"



--PART.BOUNDARY.1

Content-Type: text/plain; charset=ISO-8859-1





RXO RPG-XML Failed deviceInfoSearch



--PART.BOUNDARY.1--



-----Original Message-----

From: midrange-l-bounces@xxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxx> [mailto:

midrange-l-bounces@xxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxx>] On Behalf Of Evan Harris

Sent: Thursday, December 19, 2013 3:16 PM

To: Midrange Systems Technical Discussion

Subject: Re: SNDDST not working after V7 upgrade



Have you checked the directory entries are OK ?



WRKDIRE and check what users are in there Also look to see what system

name the users have assigned and check that it matches the system name

in DSPNETA



Seems like if QSECOFR can send it might be how your users are

registered in the directory, which SNDDST depends upon



You might be able to get further information in the distribution log

DSPDSTLOG or by looking at the distribution journal QZMF (I think)







On Fri, Dec 20, 2013 at 6:45 AM, <fbocch2595@xxxxxxx<mailto:fbocch2595@xxxxxxx>> wrote:





Hi Folks, I'm still having issues with SNDDST but...We can use

usrprf QSECOFR to successfully snddst to our home email address

(aol, etc.) but QSECOFR still not SNDDST to our internal outlook.



Thanks for the info on this and here's the answers to the questions

that you've raised in this thread;



QALWOBJRST is always *ALL on our systems



The consultant who did the work saved and restored from a SAV21 and

that brought us up to V6 and then upgraded to V7. He said he did an

unload reload to a different system, then upgrade.

Should I try to get any more info than that?

Should I try to get any more info than that?

Should I try to get any more info than that?



Regarding /QTCPTMM...I'm assuming that it was saved during the sav21

and restored when the rst of the SAV21 was done...right?...and

here's how it is now;



Work with Object Links



Directory . . . . : /QTCPTMM



Type options, press Enter.

2=Edit 3=Copy 4=Remove 5=Display 7=Rename 8=Display

attributes

11=Change current directory ...



Opt Object link Type Attribute Text

. DIR

.. DIR

ATTABOX DIR

DSN DIR

ENCODE DIR

FTRFILES DIR

LOCKBOX DIR

MAIL DIR

SMTPBOX DIR

TMP DIR







Any other ideas?



Thanks, Frank











-----Original Message-----

From: CRPence <CRPbottle@xxxxxxxxx<mailto:CRPbottle@xxxxxxxxx>>

To: midrange-l <midrange-l@xxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxx>>

Sent: Thu, Dec 19, 2013 11:24 am

Subject: Re: SNDDST not working after V7 upgrade





On 19-Dec-2013 05:57 -0800, rob@xxxxxxxxx<mailto:rob@xxxxxxxxx> wrote:

Paul,



Maybe you're right...



http://www.ibm.com/support/docview.wss?uid=nas27a11ff9db49db7f586256

ea

900714552



http://www.ibm.com/support/docview.wss?uid=nas28f129bd920f1fd4a86256

eb

0003cadcc



FWiW [for the archives, per the APARs\links will surely be purged

oon enough] those v5r3 APARs, SE16086 and SE15891 [one a

sysroute\copy f the other], suggest that the directories _under_ the

/QTCPTMM are not aved, *except* its MAIL directory; i.e. not an

issue with the Can Be aved (*ALWSAV) attribute of that directory

itself, but some\most of its ubdirectories.

SE15891 - TCPIP-SMTP-MSGCPFA09C CPFA09C WHEN SENDING MAIL AFTER A

FULL YSTEM SAVE AND RESTORE. DIRECTORIES FOR QTCPTMM ARE MISSING.

E16086 - TCPIP-SMTP-MSGCPFA09C CPFA09C WHEN SENDING MAIL AFTER A

FULL ...

Problem Summary_

System SAV/RST does not save QTCPTMM directories, except for MAIL.

All thers are suppose to be recreated once touched. This is not happening.

SF doesn't have authority.

..."

But with regard to the scenario as described by the OP whereby

"the NDDST command runs with no error but does not send to the email

ddress", that issue from the APARs seems unlikely to be an origin.

urely the OP would be happier to have such an obvious failure :-)

And hat those directories could be the origin for the issue for the

OP is urther diminished in likelihood, by the fact that the side

effects from he unsaved subdirectories were to have been _resolved

by_ the PTFs for hose APARs back in v5r3m0. The changes\fixes were

to ensure that the issing directories would be automatically created

by POP and SMTP, ather than only by MSF [server startups

presumably], if\when the issing directories condition was detected,

and that the owner and uthorities for those since-created

directories would be properly stablished, irrespective the user

[QMSF or QTCP] established for the rocess as provided in changes to the service program QTCP/QTMSUTL.

--

egards, Chuck

-

his is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing list o post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxx> o

subscribe, unsubscribe, or change list options,

isit: http://lists.midrange.com/mailman/listinfo/midrange-l

r email: MIDRANGE-L-request@xxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> efore posting, please take

a moment to review the archives t

http://archive.midrange.com/midrange-l.



--

This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto: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<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please

take a moment to review the archives at

http://archive.midrange.com/midrange-l.









--



Regards

Evan Harris

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto: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<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please take

a moment to review the archives at http://archive.midrange.com/midrange-l.



--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto: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<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please take

a moment to review the archives at

http://archive.midrange.com/midrange-l.





--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto: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<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.







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