Re: Email relay

Not knowing exactly what I am looking for, the second record produced by
RUNQRY just seems unusual. This record has only a question mark. Same
thing using DSPPFM and CPYF. Nothing like that from output of the DSP
commands. That, of course, doesn't mean anything. Just looks odd.

John McKee

On Fri, May 1, 2015 at 2:29 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 01-May-2015 13:21 -0500, John McKee wrote:

When I try either ?CHGSMTPA and F4=Prompt or ?CHGSMTPA I see at the
bottom: "Error detected in prompt override program command string".

OK, so the error msg CPD680B "Error detected in prompt override program
command string." instead of the msg CPD680A "Current values could not be
retrieved."; essentially the same idea, the problem is diagnosed on the
prompted command, suggesting that the values that would have been retrieved
to replace the *SAME with actual-values, had failed. The difference is
effectively that the former indicates failure after invocation of the
Prompt Override Program (PMTOVRPGM) [aka POP] and the updated command
string was returned, whereas the latter suggests an error transpired and
the request terminated before the any attempt was made to provide the
updated command-string.

Joblog shows:
CPD0076 'N ' for parameter POPWDW must be numeric

And so instead of an issue for authority, there is an effective /defect/
by an unknown origin, possibly corruption of the stored data whence the
stored-values should have been retrieved; the apparently retrieved value,
that when stored into the command string, the replacement values were not
valid according to the definitional attributes of the parameter (PARM).

Whatever values are retrieved are effecting the generation of the
[partial] command string: CHGSMTPA POPWDW(N )

The expected error for that [just above] improperly composed command
request is the msg CPD0076 "'N ' for parameter POPWDW must be
numeric.", just as was diagnosed similarly for the failed POP processing.
Solving the problem involves finding what is the origin of that data, and
why that data is not as-expected.

Should have looked in joblog before I posted. Still, I did not see
anything but *SAME on green screen and nothing seems to jump out on
iNav screen. Not saying it isn't there. Just don't see it or
recognize it by text alone.

I do not have visibility to what iNav shows for that, so I would be
unable to describe what to look for\at.

Important thing is it is (mostly) fixed. At least I don't get error
messages reported by people higher up the food chain.

Sure, but there is still the problem with apparent corruption that
should probably get resolved.

The presumed corrupted data is database file member data of the file
QATMSMTP in QUSRSYS, member name CONFIG. A collection of the following
information about that file may be worthwhile:

dspobjd qusrsys/qatmsmtp *file *full output(*print)
dspobjd qusrsys/qatmsmtp *file *service output(*print)
dspfd qusrsys/QATMSMTP *all *print
CPYF QUSRSYS/QATMSMTP *PRINT FROMMBR(CONFIG)

That data should allow figuring out the likely source of the incorrect
data and possibly the origin for the /corruption/ of that data.

The data can be viewed alternatively with, for example, one of:
DSPPFM QUSRSYS/QATMSMTP MBR(CONFIG)
RUNQRY () ((QUSRSYS/QATMSMTP CONFIG)) *DISPLAY

--
Regards, Chuck

--
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.