another question adding allocating dasd

[Larry Macioce]

Thank you all for the answers on the last question it worked like a charm.
BUT (it's a big but isn't it..LOL)
When I do a q dasd on other simular devices I get this:

DASD 6397 CP SYSTEM L2DR04 1

So I thought that after I att'ed the dasd to system it would look the same.
BUT(another big but) what I get is this:

DASD 63F9 CP SYSTEM L2DR26 0

It looks (from the doc as if a 'link' to a mdisk is missing.
I put all devices in user direct:
MDISK A95 3390 000 001 L2DR26 R (in $alloc) &
MDISK 227 3390 1 3338 L2DR26 MR (under the user)
Then did a directxa user so it would read the user direct file.

I also added the dasd in the system config file in the user volume list:
User_Volume_List L2DR26

SO what am I'm missing. Why no link???
By the way the linux instance was brought down and back up.
I'm confused but that isn't that hard to do.
I need to add thme to an exsisting log vol group but I don't wnat to go any
further if I've messed something up or missed something.

thanks
Mace

[David Boyes]

-----Original Message-----
From: VM/ESA and z/VM Discussions
Sent: Wednesday, February 22, 2006 2:31 PM
Subject: another question adding allocating dasd
Thank you all for the answers on the last question it worked
like a charm .
BUT (it's a big but isn't it..LOL)
DASD 6397 CP SYSTEM L2DR04 1

You won't see that until the guest is actually linked to the disk.
Defining the disk in the directory does not automatically link it.

SO what am I'm missing. Why no link???
By the way the linux instance was brought down and back up.
I'm confused but that isn't that hard to do.

For the link to appear, you either need to:

1) completely log the userid off and back on (shutdown and reipl of
Linux doesn't do it -- CP reads the directory at logon time)

2) Log into the guest and do:

#CP LINK * nnn nnn MR
BEGIN

Where you replace nnn with the virtual address of the minidisk you
added. That will make it available during the current session, and the
directory entry will activate it the next time you log off/on.

[Shimon Lebowitz]

Post by David Boyes
1) completely log the userid off and back on (shutdown and reipl of
Linux doesn't do it -- CP reads the directory at logon time)
#CP LINK * nnn nnn MR
BEGIN
Where you replace nnn with the virtual address of the minidisk you
added. That will make it available during the current session, and the
directory entry will activate it the next time you log off/on.

Regarding #2, I think that
a) the MR is unnecessary, and possibly dangerous. Omitting a link
mode will give the user whatever was defined as the default mode in
the directory, which might possibly have been R/O.
b) if the user was in virtual machine input mode (or whatever it is
called) - as seems to be the case in your example, since you
specified #CP, then why add the BEGIN?

Shimon

[Larry Macioce]

OK I did a q names and it shows:

L2DRW01 - DSC

Doesn't this mean the user is on and disconnected?

In reading Davids answer it looks as if I need to log the instance off and
on.
If I do a xautolog won't that take the the instance down?
And if I do an autolog won't it show the instance already logged on?

My other instances show -dsc also but still show the link.

OH brother am I confused.

thanks
Mace

[Schuh, Richard]

When the directory is changed, the configuration of an already logged on user is not changed. The directory is used to configure the virtual machine at logon time. Any directory update is reflected in the machine configuration the next time a user logs on. There is a way to make the disk(s) available to a logged on user. You can link to disk from the logon console (e.g. LINK * 999 999 MR). Alternatively, you can do the same thing from a class C user via SEND CP (send cp userid link * 999 999 MR)

If JOEUSER is logged on, all an XAUTOLOG JOEUSER will accomplish is to generate an error message to the one who entered the command. It does not take the user down. You can do that by use of the FORCE command. After forcing the user, XAUTOLOG will work and the new directory definitions will be in effect.

Any logged on user who has a link to a disk will keep that link until either it is detached by/from the user or the user logs off. The "disconnected" refers to whether there is a console associated with the user. A disconnected user is logged on, but has no console. It does have all of the other resources defined in the directory or acquired after logon. DSC is an abbreviation of Disconnected.

Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Larry Macioce
Sent: Wednesday, February 22, 2006 12:09 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: another question adding allocating dasd

OK I did a q names and it shows:

L2DRW01 - DSC

Doesn't this mean the user is on and disconnected?

In reading Davids answer it looks as if I need to log the instance off an=
d
on.
If I do a xautolog won't that take the the instance down?
And if I do an autolog won't it show the instance already logged on?

My other instances show -dsc also but still show the link.

OH brother am I confused.

thanks
Mace

[David Boyes]

-----Original Message-----
From: VM/ESA and z/VM Discussions
Sent: Wednesday, February 22, 2006 3:15 PM
Subject: Re: another question adding allocating dasd
L2DRW01 - DSC
Doesn't this mean the user is on and disconnected?

Yes, it does. Like I said, defining the minidisk does not connect it or
link it to a logged-on user -- the CP directory entry is read once when
the virtual machine is created at logon time, and each time you execute
a LINK command. So, the trick is the second part of my note: telling CP
to do the LINK.

In reading Davids answer it looks as if I need to log the
instance off an d on.
If I do a xautolog won't that take the the instance down?
And if I do an autolog won't it show the instance already logged on?

If a userid is already logged on, AUTOLOG and XAUTOLOG will determine
this and just tell you that. They will not shut a running instance down
(you want the SIGNAL SHUTDOWN command for that -- don't do it, though).

You need to log in to the VM userid and do #CP LINK L2DRW01 nnn nnn MR
for each of the new disk addresses you added. After you've done that,
type BEGIN to resume Linux processing, and #CP DISConnect to go back to
normal Linux operations.

My other instances show -dsc also but still show the link.
OH brother am I confused.

It's easier if you think about it this way:

CP and it's directory entry define the container that Linux operates
within. You can plug in new hardware into the container, but that
doesn't necessarily force CP to present that hardware right now -- you
have to tell it to do that. You can do that in one of two ways: force CP
to destroy and recreate the userid (logon/logoff), or explicitly make
the new hardware available by connecting it to the virtual machine (the
LINK command). #CP LINK issues the command to CP without disturbing the
contents of the virtual machine -- it plugs that new hardware into the
virtual machine configuration.

Then you can tell the operating system in the virtual machine to do
something with it.

Does that help?

-- db

[David Boyes]

Post by Shimon Lebowitz
a) the MR is unnecessary, and possibly dangerous. Omitting a link
mode will give the user whatever was defined as the default mode in
the directory, which might possibly have been R/O.

In general, yes, but in the specific case, he was planning on writing on
the disks, so wanted to be specific.

Post by Shimon Lebowitz
b) if the user was in virtual machine input mode (or whatever it is
called) - as seems to be the case in your example, since you
specified #CP, then why add the BEGIN?

Safety. If he for some reason logged in, he'll get a console interrupt,
which will likely pause the guest. The BEGIN is just insurance that the
CP idle timer doesn't nuke him 15 minutes later.

[Bruce Hayden]

And actually, if you must have a write link, you should only specify
M, not MR. If some other user has a write link already, MR will give
you a read link, which won't let you do what you need to do and can
cause you other confusion when you get errors trying to write on the
disk. So specify M, and if you can't get the disk linked R/W, then it
will fail, and you will see in the error message what other user has
the disk already linked R/W.

I frequently see VM directory entries for Linux machines with the link
modes of the disks specified as MR instead of M. I'd rather have
Linux completely fail to start up if some other userid has one or more
of its disks linked R/W than to start up with a disk linked read only
and get a lot of errors, later failures, etc.

Post by David Boyes

Post by Shimon Lebowitz
a) the MR is unnecessary, and possibly dangerous. Omitting a link
mode will give the user whatever was defined as the default mode in
the directory, which might possibly have been R/O.

In general, yes, but in the specific case, he was planning on writing on
the disks, so wanted to be specific.

--
Bruce Hayden
IBM Global Services System z Linux
Endicott, NY

[Rob van der Heij]

Post by Bruce Hayden
I frequently see VM directory entries for Linux machines with the link
modes of the disks specified as MR instead of M. I'd rather have

Indeed. I have wasted many CPU hours by Linux servers getting their
disk in R/O while they really needed it R/W. I probably would have
noticed the problem earlier when it had no disk at all.

And for those that share /usr in R/O fashion it makes sense to use 'R'
rather than 'RR' to make sure your Linux server will not try to do
fsck that disk...

Rob
--
Rob van der Heij
Velocity Software, Inc

[Colin Allinson]

Post by Shimon Lebowitz
a) the MR is unnecessary, and possibly dangerous. Omitting a link
mode will give the user whatever was defined as the default mode in
the directory, which might possibly have been R/O.

It depends in which way you mean dangerous.

It is not dangerous to the disk because you only get a read link if
someone else has a write link. MW is the real dangerous one.

If, however, you code a link you probably want to use M rather than MR.
This way, if you cannot get a write link you will fail on the link
(obvious) rather than when you first try to write to the disk.

MR is great if you are doing it manually and can see what happens - so you
can see who DOES have the write link.

Colin Allinson
Amadeus Data Processing

[Larry Macioce]

And now that I've replied and thought about what I just said, if I attach
devices to system but don't link those devices to any one user can anyone
access those or can noone access those unlinked devices??

thanks
Mace

[Larry Macioce]

After rereading the replies I get it now.
Please remember I'm an mvs guy tring to pick this up, so when I vary a
device online,to mvs, it is then ready for use.
I related the attach as the the vary online ,but (correct me if I'm wrong)
because each user/instance has thier own machine and related devices those
devices must alloc'ed(linked) to each.
So I now need to 'link' the dev to the user to enable the user to access
the dev I brought online(attached).

Am I close???

Sorry for all the questions and thanks for the replies and understanding.

Mace

[David Boyes]

Post by Larry Macioce
Please remember I'm an mvs guy tring to pick this up, so when
I vary a
device online,to mvs, it is then ready for use.
I related the attach as the the vary online ,but (correct me
if I'm wrong
)

It's a three-step process. VARY nnn ON allows CP to know the device is
present. ATTACH nnn TO SYSTEM allows CP to access it for minidisk use.
Creating a minidisk in the CP directory for a userid allocates some or
all of a device to a user. LINK allows you to access minidisks defined
to a userid at a virtual address in your virtual machine -- the MDISK
may be yours or someone elses.

Think about the difference between beinging the volume online to z/OS,
and enabling allocation on the volume. That might help your mental model
of what's going on.