Failure for device or member QPADEV0007 file QDPTDSP in library QSYS.

[Mr. K.V.B.L.]

I've gotten this message a couple of times recently (albeit with maybe a different device). The last time I was using the DSPSYSVAL command and I got the following:

Failure for device or member QPADEV0007 file QDPTDSP in library QSYS.
Error while processing file QDPTDSP in library *LIBL.

I simply pressed Enter again and got the DSPSYSVAL command to prompt me like it should.

Is this a "red flag" that I should involve IBM with?

[CRPence]

The implication is that the command was being prompted when the
failure occurred, as implied by the described effect; although one might
expect that the command itself might fail if prompting failed.

In the output of DSPCMD DSPSYSVAL, is there a "Prompt override
program" listed, other than *NONE?

Was an error expected when the command was prompted; e.g. was an
invalid system value name provided for the parameter, such that the
CPD0084 "&3 not valid for parameter SYSVAL." would have been
appropriately issued?

With the prior incident: Was that scenario also a prompted command?
The same command being prompted, or some other command? While which
device is unknown, was the same display file reported in the messages?

The given messages are purely text, missing both their message
identifiers and the context, aside from words describing the use of
Display System Value command. Provide the spooled joblog to include the
prior request message until the following request message, so the full
context of each message is included; i.e. the spooled joblog includes
the sending and receiving programs and other important information that
enables a review of those diagnosed conditions. As well, the
interactive subsystem to which the device was allocated at the time, may
have some messages spanning near the same time, and that joblog [if any
such messages] would also best be provided.

The first message is apparently CPF5257. That message implies there
should be a prior message logged. The second appears to be CPF9846; a
generic condition issued for any prior error during an I\O request. If
the first message had been unmonitored, then the default behavior of the
OS is to produce some dump data; the spool files for the job(s) that
experienced the issue should be reviewed for a QP

If something else can not be determined...

You could restore the *FILE QDPTDSP attribute DSPF into an alternate
library, restored from an old SAVSYS prior to the first incident, or
from IBM-supplied media, and then compare the DMPOBJ output of each
version of the file to try to determine if there might be some
corruption. Conveniently and suspiciously, that display file is named
in a document describing how to restore such objects from the media:

IBM Software Technical Document number 3335547 (KB article)
Restoring Subsystem Descriptions, QHST Files, Job Queues, or Commands
from a SAVSYS Tape
http://www-912.ibm.com/s_dir/SLKBase.nsf/1ac66549a21402188625680b0002037e/77286821c7169070862565c2007d226b?OpenDocument

--
Regards, Chuck

[Mr. K.V.B.L.]

On Tuesday, September 10, 2013 10:41:19 AM UTC-5, CRPence wrote:
>
> The implication is that the command was being prompted when the
>
> failure occurred, as implied by the described effect; although one might
>
> expect that the command itself might fail if prompting failed.
>

In this example, I simply typed "DSPSYSVAL" and pressed Enter. I got the program message, typed the command again and it took it as though there was nothing wrong.

>
> In the output of DSPCMD DSPSYSVAL, is there a "Prompt override
>
> program" listed, other than *NONE?
>

No, only *NONE

> Was an error expected when the command was prompted; e.g. was an
>
> invalid system value name provided for the parameter, such that the
>
> CPD0084 "&3 not valid for parameter SYSVAL." would have been
>
> appropriately issued?
>

No, only DSPSYSVAL was issued, no incorrect system value specified on the command line.

> With the prior incident: Was that scenario also a prompted command?
>
> The same command being prompted, or some other command? While which
>
> device is unknown, was the same display file reported in the messages?
>

I can't remember which command it was the first time. If it happens again I will get job log details and messsage ID codes. Thanks once more!

[CRPence]

On 10 Sep 2013 10:07, Mr. K.V.B.L. wrote:
> I can't remember which command it was the first time.

OK... but perhaps can you recall if the situation was identical; i.e.
if each time, a command was typed on the command line and Enter pressed
[rather than F4=Prompt], and thus the auto-prompting was effected, due
to a /required/ parameter [value] not having been specified?

Knowing that, would at least imply some apparent consistency for the
origin of the error. If each time it was that /same/ situation, then
the error could be [inferred likely to be] limited to cases when the
diagnostic error CPD0071 "Parameter &2 required." [e.g. F/QCAFLD] was
the expected effect [along with auto-prompting]. If so, then the
spooled output for the message might be of interest; i.e. the spooled
data created having issued the following two requests:

ovrprtf qpmsgd rplunprt(*yes '+') ovrscope(*job)
DSPMSGD CPD0071 DETAIL(*FULL) FMTTXT(*NO) OUTPUT(*PRINT)

--
Regards, Chuck

[CRPence]

On 10 Sep 2013 10:07, Mr. K.V.B.L. wrote:

> I can't remember which command it was the first time.

[sending this message again; client said "not sent", but the message
appears on the news server I use... so this is probably a duplicate]