Re: WRKOPTVOL shows phantom volume

If the entry is phantom, I wonder what would be the [change in] effect from having specified *YES for Retrieve Extended Information (RTVEXTINFO) on the Work With Optical Volumes (WRKOPTVOL) request.

FWiW, if the information is coming from a database file member, a Trace "DATA" record will record the file(s) opened by the request that shows the Incorrect Output; e.g. trace the WRKOPTVOL, then from the command-line at the menu presented, stop the trace with the option to print, then review the spooled output. Not sure if\what appears revealing about STMF access however. A narrowed list of files would allow searching for the strings I_BASE and QOPTSEC; in case the data is not CCSID-tagged, I would search for hex strings for the ASCII equivalents too.

I just checked a trace on a system producing no output from that command invocation, and the DATA records show that the member QMOVAR of the database file QAMOVAR2 in QUSRSYS was opened, with a CPF5006 showing the file was empty. I am unauthorized to see those files on that same system, but by looking on another, I see that the opened file is an LF defined over the physical file QAMOVAR in QUSRSYS, and that the PF has just one member but allows *NOMAX. Would seem then that those Data Base Files [the DBF network for that physical file] should be validated to ensure that they have not been defiled [pun intended] by some improper restore activity [e.g. ALWOBJDIF(*ALL)] for which the relations were broken. I suppose a RUNQRY *N QUSRSYS/QAMOVAR2 might just show the /same/ data the WRKOPTVOL presents.?