And if you want to hear an angry ex-wife, goggle
on ‘twink mp3’. See also http://www.theregister.com/2006/09/13/phone_diatribe/.
-----Original
Message-----
From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED] On
Behalf Of Steve Gentry
Sent: September 13, 2006 14:21
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: mdisk/extension
search order question
All shall become clear (depending on
who/what else you might be snuggling with at the same time).
Woah,
this could start a major OT.
(Must
. . . resist . . . comments . . . about . . . . ex-wife . . .
.)
Who,
me? No, I'm not bitter.
8-)
|
|
Mike Walter
<[EMAIL PROTECTED]>
Sent
by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
09/13/2006 10:59 AM
Please
respond to The IBM z/VM Operating System
|
To: IBMVM@LISTSERV.UARK.EDU
cc:
Subject: Re: mdisk/extension
search order question
|
When attempting to perform fancy feats of magic with the CMS search order,
perhaps it might help to snuggle up to the "CMS Command Search Order"
topic in Chapter 5 of the "CMS User's Guide" (page 172 of
SC24-6079-00). All shall become clear (depending on who/what else you
might be snuggling with at the same time). :-)
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
|
"Steve Gentry"
<[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
<IBMVM@LISTSERV.UARK.EDU>
09/13/2006 09:59 AM
|
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
|
|
|
To
|
IBMVM@LISTSERV.UARK.EDU
|
|
cc
|
|
|
Subject
|
Re: mdisk/extension search order question
|
|
We have a QA process where programs to be tested are put on mdisk_a Only
those programs being
tested are on this mdisk. However, the program being tested may call
other programs not on mdisk_a
so, I (we) use the extension technique to also have access to the production
mdisks (i.e, modules, texts, etc).
There will be duplicate module names. The test module on mdisk_a, the
production module on mdisk_b.
I (we) need to be sure we have access to all modules/texts for testing. This
isn't the only technique (extensions)
we use; it just depends on the situation. For testing purposes, we want
to read mdisk_a first before mdisk_b
Thanks for the help.
Steve G.
|
|
"Bates, Bob"
<[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
09/13/2006 08:27 AM
Please respond to The IBM z/VM Operating System
|
To: IBMVM@LISTSERV.UARK.EDU
cc:
Subject: Re: mdisk/extension
search order question
|
1. Search the primary, then the extension for execution of an exec or module.
2. I believe state will find the first module and say I found one.
To me having a disk extension directly behind the primary doesn't do much of
anything except assure the extension is in read only mode. (Except in the case
of COPY and TAPE dump as previously noted). The best example I can think of is
190/19E. If the search makes it all the way through to the S disk and still
doesn't find what it is looking for it goes to Y next. Then back to T, U, V, W
and X if any of those are accessed.
Extensions are handy for changing the search order when other disks are already
in a certain place. Or when forcing a read only situation like doing ACC 191
A/A.
IMO
Bob
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Steve Gentry
Sent: Wednesday, September 13, 2006 7:36 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: mdisk/extension search order question
Thanks. ok, what happens in the following two cases:
1) mdisks are accessed as previously mentioned. mdisk1 is A mdisk2
is B/A
I have the same program (module) on both A and B I
want to run the module.
From which disk will the module
be used?
2) I use the STATE/STATEW/ESTATE/ESTATEW. Same scenario as 1 above
Where will the program be found first and will the STATE
command acknowledge/report
that I have the file on two mdisks?
Steve G.
|
|
"Schuh, Richard"
<[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
09/12/2006 04:57 PM
Please respond to The IBM z/VM Operating System
|
To: IBMVM@LISTSERV.UARK.EDU
cc:
Subject: Re: mdisk/extension
search order question
|
Be aware that not all commands search the search order in the same way. For
example, if you have disks accessed as A and A/H, you will see that LISTFILE
does not include the H disk when you
LIST * * A; however, in the commands TAPE DUMP * * A or COPYFILE * * A = = X,
the files from the H disk will be included.
Regards,
Richard Schuh
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> Behalf Of [EMAIL PROTECTED]
> Sent: Tuesday, September 12, 2006 8:27 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: mdisk/extension search order question
>
>
> H will be completely searched before going to I, which is the
> normal course of action. The I/H in this case forces R/o.
> -------------- Original message ----------------------
> From: Steve Gentry <[EMAIL PROTECTED]>
> > Hello. I've issued a Q DISK command and listed below is
> part of the
> > results:
> >
> > DSK4B0 4B0 H R/O 1625 3390 4096
> > DSK121 121 I/H R/O 900 3390 4096
> >
> > I issued a VMLINK command (could be ACCESS as well) to
> make the I disk an
> > extension of the H disk. What will the search order be?
> Will all of H
> > be searched first
> > and if file not found start searching the I disk or is the
> H and I disk
> > munged together
> > and searched concurrently?
> > Thanks,
> > Steve
> >
> Obsolescence is Just a Lack of Imagination
>
>
>
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.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error, please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail, or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
