Help us to get up to speed on what you did during the installation
attempt:
1) Were you installing using the "z/VM Guide for Automated Installation
and Service" manual?
2) Did you choose the (IMHO, the far easier, as long as you have a
pre-existing z/VM system installed) "Second-Level DDR Installation
method"?
If the answer to all those questions is "yes", then how could the
"first-level userid" have successfully executed the INSTPLAN and INSTIIS
commands? Those commands write files to the "first-level userid" 191
mdisk.
Perhaps you had another mdisk linked by that "first-level userid", or you
used a Tdisk (or Vdisk)? If so, go back and create a real 191 mdisk on
"first-level userid", then rerun INSTPLAN and INSTIIS. You're not very
far into the installation process, won't lose much time by doing so, and
will gain a "repeat experience". Going back and carefully executing each
and every step in this particular situation is far better than trying to
cobble together pieces of what was done from various places. You want
some evidence left over if you should have to go back to see what you did
even later, restarting and following every step will help that evidence be
recreated.
Or, perhaps you executed INSTPLAN and INSTIIS from a userid on a different
system, then tried to run the rest from a different system (been there,
done that). If so, same recommendation. Go back and start again, running
it all from one system.
Here's a tip from my (not delivered recently) SHARE "z/VM Installation -
>From Cardboard Box to IPL" session: When executing each step in the "z/VM
Guide for Installation and Automated Service", write the date and time in
the margin next to the step as it is executed. This helps when looking
back to see if you missed a step (been there, done that, too -several
times!). If there are problems or questions later, with the date and time
written next to each step, it becomes a lot easier to find the matching
SPOOLed console log from that step to search for entered command
arguments, or informational/error messages that may have been missed the
first time.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"ASIFF AMAHED" <asiff...@gmail.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
02/16/2010 02:02 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: ZVM V6 "instvm tape"
i think my problem was that LEV2VM user didn't have 191 MDISK, but now i
geting this message.
instvm
tape
**** NOW EXECUTING INSTVM EXEC ON 16 Feb 2010 AT 14:59:25
****
HCPIND8342E THE COMMAND PIPE CMS COPYFILE $ITEMMD$ $TABLE$ Z = = C (OLDD
REPL FA
ILED WITH
RC=28
549 *-* logmsg "HCPIND8376E INSTDIR EXEC ENDED IN
ERROR"
+++ RC(-3)
+++
HCPIND8342E THE COMMAND PIPE CMS COPYFILE $ITEMMD$ $TABLE$ Z = = C (OLDD
REPL FA
ILED WITH
RC=28
HCPIVM8342E THE COMMAND ' EXEC INSTDIR ' FAILED WITH
RC=100
HCPIVM8376E INSTVM EXEC ENDED IN
ERROR
Ready(00100); T=0.01/0.01
14:59:25
On 2/16/10, Rich Smrcina <r...@velocitysoftware.com> wrote:
When you did installation planning what did you enter for the tape device
address?
On 02/16/2010 10:05 AM, ASIFF AMAHED wrote:
Why do i need Device 191 to build the directory? and why is asking for
191, in 5.4 i did not have this problem, why now? thats anyone know what
i have to do now?
--
Rich Smrcina
Phone: 414-491-6001
http://www.linkedin.com/in/richsmrcina
Catch the WAVV! http://www.wavv.org
WAVV 2010 - Apr 9-13, 2010 Covington, KY
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
