On 24-Sep-2015 10:16 -0600, CRPence wrote:
On 24-Sep-2015 08:47 -0600, John McKee wrote:

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

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.



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:


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.

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.

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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 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.