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
>
>
>




Reply via email to