Hey Guys, Thought some would like to know what I did on this issue.
1) I created a USER DIRECT entry called DOSDASD (just used to own minidisks) (our test VSE is called DOS). Then I added a MDISK statement for the volume to be migrated, as such: USER DOSDASD DOSDASD 8M 8M ABCDEFG MDISK 5024 3390 000 END DOS907 MR RDOS WDOS MDOS 2) Added a link statement for the volume to DOS USER DIRECT entry, linking the volume as the vdev to be used on DOS : LINK DOSDASD 5024 907 MW MDOS 3) Removed direct access of volume to DOS (ATT 5024 DOS 907) 4) Added volume to SYSTEM CONFIG 5) SHUTDOWN DOS 6) Issued ATT 5024 to SYSTEM 7) IPL DOS 8) Update Backup and DR procedures This worked well. I plan on migrating the other (Unique named) TEST volumes tonight and on production over the weekend. Thanks for everyones input! Tim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Thigpen Sent: Friday, April 20, 2007 2:30 PM To: VSE Discussion List Subject: Re: Best procedure to migrate dedicated VSE volume to VM minidisk VM does NOT have to control the vtoc. It just has to read the VOLID, which it does ok with a VSE volid. You do not need to CPFMTXA a VSE volume. Just change the directory statement and you are done. I have to leave for the rest of the afternoon, so others will have to answer any additional questions. Tony Thigpen -----Original Message ----- From: Tim Joyce Sent: 04/20/2007 02:15 PM > Hey Tony, > > What you say makes since to me. I obviously should not have called > them "full volume" minidisks. But, does CPFMTXA not automatically set > up the first cyl. for its VTOC? Do I not use CPFMTXA to define the pack? > Sorry, I have not experience setting up a pack to VM without doing a > CPFMTXA and then attaching to VM SYSTEM and then . It seems that for > VM to manage the DASD, it would need to have control of the VTOC. > > Tim > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Tony Thigpen > Sent: Friday, April 20, 2007 2:04 PM > To: VSE Discussion List > Subject: Re: Best procedure to migrate dedicated VSE volume to VM > minidisk > > Tim, > I think you are misunderstanding VM volumes. > > If you want to convert VSE disk to full-volume minidisks, ALL that you > need to do is change the VM directory. There is no need to copy or > move the data. So, I think that the problem is that you are > misunderstanding what a "full-volume minidisk" is. > > Full-pack minidisks have the VSE cyl 0 in the physical cyl 0. VM sees > the VSE VOLID and uses it. > > Minidisks that start on cyl 1 (till the end of the pack) are NOT > full-pack minidisks. They are regular minidisks and VM has it's own > VOLID on cyl 0. > > The only reasons to put a VSE pack on cyl 1 is if you are spliting > packs into smaller chucks OR you need unique VM VOLIDs while having > non-unique VSE VOLIDs. You do NO have to start it at physical cyl 1 > just to get caching. > > Tony Thigpen > > > -----Original Message ----- > From: Tim Joyce > Sent: 04/20/2007 01:11 PM >> Hey Tony, >> >> Our DOSRES/SYSWK1 are not shares and are already minidisks. I plan to >> migrate all my other dedicated VSE DASD to Full Volume minidisks to >> take advantage of Minidisk Caching. Mostly our dedicated DASD >> consists > >> of full volumes of VSAM, ADABAS, and DYNAM. Some of the Volumes have >> a > mix. >> Tim >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf > >> Of Tony Thigpen >> Sent: Friday, April 20, 2007 11:48 AM >> To: VSE Discussion List >> Subject: Re: Best procedure to migrate dedicated VSE volume to VM >> minidisk >> >> Tim specified "full-volume minidisks". That would indicate that he >> does not want to start on cyl 2 and would need to follow Eric's >> advise. It really matters what he is trying to accomplish. If it's >> sharing one >> DOSRES/SYSWK1 with multiple VSE guests, then he can use full-pack >> minidisks. (He can still dedicate other alternate DOSRES/SYSWK1 packs >> to test machines.) >> >> Tim, why are you doing this? What are you trying to accomplish? >> >> Tony Thigpen >> >> >> -----Original Message ----- >> From: Wakser, David >> Sent: 04/20/2007 11:09 AM >>> Eric's suggestion will ONLY work if you only want a single DOSRES >>> volume on your system. If you need more than one (for example, a >>> test > >>> VSE system), then you would need to have DOSRES start as an offset >>> from the real volume. >>> >>> David Wakser >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>> Behalf Of Eric Schadow >>> Sent: Friday, April 20, 2007 11:05 AM >>> To: VSE Discussion List >>> Subject: Re: Best procedure to migrate dedicated VSE volume to VM >>> minidisk >>> >>> Tim >>> >>> No need to move the data. >>> >>> Just change the VM directory from from a DEDICATE statement to MDISK >>> C01 3390 00000 03339 CK3C70 MWV (3390-3) and you need to attach the >>> DASD to SYSTEM. We have autolog1 setup to do the SYSTEM attach. >>> >>> This works for regular -3 and -9. >>> >>> Now you can take advantage of Mini disk cache. >>> >>> eric >>> >>> >>> >>> >>> >>> At 10:25 AM 4/20/2007, you wrote: >>>> Hello, >>>> >>>> I am testing procedures to migrate my dedicated VSE volumes to VM >>>> full >>> volume minidisks. I have run into trouble when using DDR to copy my >>> dedicated 3390 (mod3) pack to the virtual (3390 mod3) volume. I get : >>>> HCPDDR725D SOURCE DASD DEVICE WAS (IS) LARGER THAN OUTPUT DEVICE. >>>> >>>> I assume this is because my minidisk is defined a 3338 and the >>> dedicated pack is 3339 .. is this correct? >>>> I figure many of you have done this is the past and may be able to >>> suggest the best way to do this. >>>> Thanks, Tim >>>> >>>> ~~~~~~~~~~~~~~~~~~~~~~~~<?xml:namespace prefix = o ns = >>>> "urn:schemas-microsoft-com:office:office" /> >>>> >>>> Tim Joyce >>>> Sr. Systems Programmer >>>> Alex Lee, Inc. >>>> Email : <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED] >>>> Phone: (828) 725-4448 >>>> Fax: (828) 725-4800 >>>> >>> Eric Schadow >>> Mainframe Technical Support >>> www.davisvision.com >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> - >>> - >>> -- The information contained in this communication is intended only >>> for the use of the recipient(s) named above. It may contain >>> information that is privileged or confidential, and may be protected >>> by State and/or Federal Regulations. If the reader of this message >>> is > >>> not the intended recipient, you are hereby notified that any >>> dissemination, distribution, or copying of this communication, or >>> any > >>> of its contents, is strictly prohibited. If you have received this >>> communication in error, please return it to the sender immediately >>> and delete the original message and any copy of it from your >>> computer system. If you have any questions concerning this message, >>> please contact the sender. >>> -------------------------------------------------------------------- >>> - >>> - >>> -- >>> >>> >> > >
