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