RE: SNDDST not working after V7 upgrade

["Monnier, Gary" <Gary.Monnier@xxxxxxxxx>]

Is this the SWPUSRPRF command from PowerTech?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Thursday, December 19, 2013 1:10 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: SNDDST not working after V7 upgrade

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>
ERROR IN BATCH SMTP COMMAND SEQUENCE.
   MAIL FROM:<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>
Subject: TIVO deviceInfoSearch RXSEE61R QPADEV0008 DE
Sensitivity: none
Priority: normal
Importance: normal
From: PENCOR06@xxxxxxxxxx
X-From-OFFICEVISION: <PENCOR06 PENCOR06>
To: 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] 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> 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>
> To: midrange-l <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 wrote:
>  Paul,
>
>  Maybe you're right...
>
> http://www.ibm.com/support/docview.wss?uid=nas27a11ff9db49db7f586256ea
> 900714552
>
> http://www.ibm.com/support/docview.wss?uid=nas28f129bd920f1fd4a86256eb
> 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 o subscribe, 
> unsubscribe, or change list options,
> isit: http://lists.midrange.com/mailman/listinfo/midrange-l
> r email: 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 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.