Found it.
I took the 3rd level VSE machine, TSTESA5F and brought it back up
second level. Right after the "ipl restart has been bypassed" is the
normal stuff about the lock file.
LOCK FILE? Argggg
This is a standalone system from the normal systems. i.e. it is a
flash copy of our TSTESA5 machine, and that includes it's own copies of
any/all shared disks.
No problem when on 2nd level.
But....I took the minidisks statements, which included the MWV, for
shared disks and gave them to the VMTEST machine. Then in 3rd level,
the disks were dedicated. When the 1st "shared" disk, the lock file,
was being used, it apparently got some weird status back, that shouldn't
be there.
I updated the mdisk statements for VMTEST to just be MW, directxa, ipl
VMTEST and ipl TSTESA5F and got a little farther. At least I'm now
seeing a real reason for the IPL to be terminated:
BG 0000 0I41I LOCK FILE ON 140: NO VALID DASD
BG 0000 0J31A NO SHARING CAPABILITY. IPL TERMINATED
Tom Duerbusch
THD Consulting
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
On
Behalf Of Tom Duerbusch
Sent: December 20, 2006 1:48 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: VSE hard wait under z/VM 5.2 second level
As a lark, I tried bring up VSE/ESA 2.7.2 up under a second level z/VM
5.2 (z/VM Version 5 Release 2.0, service level 0602 (64-bit) ) system
that is running under z/VM 5.1 (z/VM Version 5 Release 1.0, service
level 0501 (64-bit)).
No go.
Right after "ipl restart point has been bypassed", I get:
HCPGIR450W CP entered; disabled wait PSW 000A0000 00001000
DISPLAY 0:15
R00000000 1A000FD0 00000061 00000000 00000000 06
R00000010 000073B0 000005C8
I read it as a VSE cancel code, IO error.
I buy that, but what device? It should be dasd at this point.
On the first level system, I created VMTEST (the second level system).
I copied over the mdisk statements from TSTESA5F to VMTEST. So now
all
minidisks needed by TSTESA5F, will appear to VMTEST as real disks. On
the second level system, I changed the mdisk statements for TSTESA5F
to
DED statements. Well, it worked in the past.
My immediate concern is, is there VSE maintenance that is needed to
run
on z/VM 5.2 over and above the maintenance that was needed to run on
z/VM 5.1? (I thought the maintenance to run under z/VM 5.1 was more
hardware related for the 64 bit z/890 then for running unde z/VM 5.1,
but that was a while back.)
Anyone hit this recently? I'm now concerned enough that, if I don't
get a solution, I will be in this Christmas weekend to bring up z/VM
5.2
first level and bring up some of the test VSE systems up to validate I
don't have any VSE related conversion problems.
Thanks
Tom Duerbusch
THD Consulting
