Try using WRKOPTVOL to verify the optical instead. Use option 5 or 11 to
force it to read the image. It will fail if the connection is not correct.
Don't be lulled into complacency by the device and volume showing up. (By
the way F5 WILL NOT update the contents of the screen. I've had a long
running battle with IBM over that, finally giving up)
This technique will work with virtual optical regardless of if it's NFS (by
far the easiest once it's set up) and the virtual drives you refer to below.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Kevin
Monceaux
Sent: Tuesday, May 14, 2019 3:08 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Virtual Ethernet and NFS Image Catalogs
Rob,
On Tue, May 14, 2019 at 07:45:00PM +0000, Rob Berendt wrote:
Did you change all your NWSD's to only have one with ALWDEVRSC(*ALLOPT
*ALLTAPE) RSTDDEVRSC(*NONE)
And the rest have ALWDEVRSC(*UNRSTD) RSTDDEVRSC(*ALLOPT *ALLTAPE) ?
No, I've only made those changes on our development LPAR. I wanted to test
those changes there first before making any changes to production LPAR
NWSD's.
As soon as I run the following on the host:
LODIMGCLG IMGCLG(V7R3CUME) DEV(V7R3CUME) WRKOPTVOL I immediately see
the same thing I saw in WRKOPTVOL on the host appearing on the guest. It
just may be on a different device name. In this case, OPT17.
Well, I thought the image catalog was loaded, verified, and ready. A
WRKIMGCLG shows it's ready in OPTVRT01. But a WRKOBTVOL on the host doesn't
find any volumes, and a DSPOPT *MOUNTED OPTVRT01 says OPTVRT01 is empty.
Could our production LPAR's NWSD's that still need adjusting be causing
this?