Re: Email relay

On 01-May-2015 15:45 -0500, Scott Mildenberger wrote:

<<SNIP>> Here is what my file looks like, obviously some of your
values will be different. I would guess the one marked below might
be POPWDW which I have set to *NONE and the message you get indicates
yours is set to 'N' which is not valid. Check that value, if it isn't
the one then one of the other *NONE's that I have you have a 'N'
which you can change and that might fix the issue. I am at 7.1 so
there could be some minor differences in our files due to that.

10 003 0 0 Y
?
GATEWAY
N QSM QSMRMTAD TCPIP 1 00001
Y Y
*CCSID *CCSID
00819
Y
N
Y
02 001
N *NONE 0030
N N N N *NONE
QSYS/QSYSWRK
*NONE
N
*ALL
*NONE <------- Maybe POPWDW
*NONE
00000
N
Y
N
*NONE
N
*ALL
*NONE


V5R5M0

Although the RRN-18 has an expected and apparently appropriate and supported Special-Value of *NONE, the RRN-18 is unlikely to store the data for the POP Send Mail Window (POPWDW) parameter; unlikely, only because the POPWDW parameter data-type is an integer for which the apparent convention for the other _known stored parameter values_ of a numeric type are maintained as numeric digits. Thus the more likely value for the POPPWDW, is the RRN-20 with the value of 00000 [to which the mapping is presumably to the special value of *NONE; zero is disallowed, only a range 15 to 65535 is allowed]. That the data for that parameter requires mapping from an internal representation to a special value, however, makes the string being formed as 'POPWDW(N)' seem all that much more improbable.

BTW, I found a documented /recovery/ [albeit destructive] for the issue experienced by the OP. I will await the similar presentation of the data in the member CONFIG of the file QATMSMTP in QUSRSYS expected as part of the data in a followup reply on Monday; I should be able to offer what should be a mostly non-destructive recovery, if that might be more desirable than the effective reset-to-system-defaults path of /recovery/.