× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



And, when you prompt the command, you see current values and not *SAME?

John McKee

On Fri, May 1, 2015 at 3:15 PM, Scott Mildenberger <
SMildenberger@xxxxxxxxxxxxxxxxxx> wrote:

Our system has the ? in the second record also so that must be normal.

Scott

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
John McKee
Sent: Friday, May 01, 2015 2:03 PM
To: Midrange Systems Technical Discussion
Subject: 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.


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


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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.