On 24-Sep-2015 10:16 -0600, CRPence wrote:
On 24-Sep-2015 08:47 -0600, John McKee wrote:
<<SNIP>>
<<SNIP>>
But, this is different. This time, a problem was logged. The
symptom string is 5722 F/QTADMPDV.
A symptom that is generated as a result of FFDC, manifest as a
Problem Record visible in the Work With Problems (WRKPRB), and
produced if the Software Error Logging (QSFWERRLOG) system value says
to do so, in response to an unexpected failure.
I did attempt to Google this. But, I do not understand what I
received, as it appears to be related to MLB installation.
The generated symptom-string is both sparse and generic, from which
inferences from other issue with the same symptom are unlikely to be
telling.
The actual data would need to be reviewed to interpret the meaning
for the failure data being logged. IIRC the QTADMPDV is the program
[TA=Tape, DMP=Dump, DV=Device] of the Tape feature that will dump
the Device to include the Tape Flight Recorder information for that
device [and the corresponding tape MLB]; typically that is something
the user is asked to call, but the FFDC may invoke that feature in
response to whatever failure that feature was logging. The generated
symptom may merely indicate that a non-specific failure is logged to
include dump-tape info, rather than a failure of that dump-tape
feature itself.
<<SNIP>>
<<SNIP>>
Also, from WRKPRB, F11 display APAR library, shows 45 entries. Only
two do NOT text. The text for the others has this: Problem
1526634180 and system serial number.
Any distant bells ringing?
I do not recall, and I do not have any access, to see what WRKPRB
looks like [there is a dearth of panels in docs, and so I will not
even waste time to look for any], so I have no idea what the big
number is nor why the same number would appear. Also I have no idea
why any would appear devoid of text.
Without some specifics about symptoms [e.g. from the joblog and
other spooled results, or the problem entries themselves], a reader
is left with nothing but wanting to ask for details, before any
worthwhile reply\comment could be composed.
I did some research; because apparently my memory on the topic is
impaired ;-) Seems likely that the invocation of the Tape Dump Device
(QTADMPDV) feature is, by itself, the origin for that problem entry
being logged. The generated symptom-string, therefore, as I infer, will
always be the same and generally uninformative except to denote that the
dump-procedure was invoked. The text for that problem logging is
apparently expected to be "QTADMPDV - TAP##" to inform for what device
the API was asked to provide dump information.
Of course both for why and whatever code was responsible for invoking
that program is still unknown. But perhaps from whatever docs are made
available, that can be determined as well.
Anyhow, the Redbooks Redpaper document REDP-0508-00 "Backup Recovery
and Media Services for OS/400; More Practical Information" REDP0508.pdf
suggests [notably: "After a problem is created, use the Work with
Problems (WRKPRB) command.":
"...
B.6.2.2 QTADMPDV API: Tape Dump Flight Recorder
An API is provided to gather information for OS/400 tape debugging. Dump
Device (QTADMPDV) is provided to gather debugging information for tape
device and Media Storage Extension (MSE) support. Use the QTADMPDV API
to collect information for your IBM service representative. Use this API
immediately after a suspected device or tape management system failure.
If the API is not used immediately, other device operation can cause the
flight recorders to wrap and result in lost information.
After a problem is created, use the Work with Problems (WRKPRB) command.
Select option 8 next to the problem identifier to work with the problem
that was created. To save the information to be sent in, select option
30. Save APAR data to an APAR library to save the library with the
information that has been collected.
The Dump Device API currently supports the following device types to
receive the data:
• Tape (TAP) devices
• Tape media library (TAPMLB) devices
• Optical (OPT) devices
• Optical media library (OPTMLB) devices
• Diskette (DKT) devices
Here is an example of a call to the API from a command entry line:
CALL QTADMPDV TAP01
[+Note+]
The information provided and the number of spooled files can change at
any time. The information is intended for problem determination. The
spooled files are generated in the QEZDEBUG output queue in library
QUSRSYS if QEZDEBUG exists. If it does not exist, the spooled files are
generated in the users output queue.
[+Note+]
The Dump Device (QTADMPDV) API dumps the contents of the device flight
recorder for the device specified in the parameter passed to the
program. The information that is found in spooled files includes:
• QSYSARB job log
• QSYSOPR message queue
• Job logs of the active jobs that have used the device as indicated
in the flight recorder data
• The history log (QHST)
• Device description of the device
• Line, controller, and device description associated with a media
library device
• The job log executing this API
• Work with Configuration Status (WRKCFGSTS) listing
• Licensed internal code logs from the last 24 hours
• Error logs associated with the device resource (and each resource
within a media library device)
• Associated internal system objects
• Media Storage Extensions (MSE) flight recorder, if available. This
flight recorder traces the structures passed to a tape management system
registered with the registration facility and traces the response from
the registered program.
This flight recorder can be helpful in developing and maintaining a tape
management product.
[+Note+]
The QTADMPDV API generates multiple spooled files, which can become
large depending upon the job logs that are printed and the size of the
device information. Submitting the API call to be processed as a batch
job may be used if system performance is a concern. If the API is called
from the system console at high priority, it can degrade performance for
other critical processing.
[+Note+]
..."
midrange.com
