JR, 

Can you confirm if the "Something makes me think we have not completed 
this implementation for "defrag" (compress) ... but I think it is on the 
list for the next ServicePack." (cross-volume compress) is in the plan for 
a relatively forthcoming release?
 
It would be wonderful to not have to run our own utility for cross-volume 
compressions!  BTW, prior to spending time moving lots of MDISKs in a 
subpool around each night we compute a "Fragmentation Index" to decide if 
it's even worth compressing a specific subpool. 

And... we NEVER automatically compress the "PP" (our Program Product) 
subpool because it has some minidisks which are not good candidates to 
move blindly.  E.g. minidisks with should be kept on separate physical 
DASD for backup purposes (not that SCSI DASD emulating real 3390 are on 
different volumes any more anyway), ones where you ALWAYS want to know the 
location for D.R. purposes (the directory source MDISK, the backup 
catalog, etc.).  Sure, we could spend time defined sub-subpools defining 
Program Product subpools on different volumes, but there's not enough 
fragmentation in that subpool to make it worth the effort. 

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.

"VM/ESA and z/VM Discussions" <[email protected]> wrote on 
12/28/2005 08:24:04 AM:

> I've confirmed that the VM:Secure/VM:Direct compress function does/can
> call the DISKCOPY EXIT that permits you to specify the "tool of your
> choice" to be used in place of IBM's DDR, CMS COPYFILE, and CMS FORMAT
> routines ... for example XCOPY or HiDRO. 
> 
> I believe this was introduced in VM:Secure/VM:Direct 2.7 SP01 ...
> 
> <<< Original Note >>>
> I know we've updated the UserExit behind the various MiniDisk functions
> of the VM:Secure/VM:Direct MANAGE screens to be able to use the "Tool of
> your Choice" to accomplish FORMAT, CHANGE, MOVE, functions ... for
> example you can use the HIDRO MODULE to perform any/all of these
> functions (which I do!  HiDRO being much faster!) ... on either CMS or
> "physical" MiniDisks ... to replace the defaults of CMS FORMAT and
> COPYFILE for CMS disks, and DDR for "physical" disks.
> 
> Something makes me think we have not completed this implementation for
> "defrag" (compress) ... but I think it is on the list for the next
> ServicePack.  However, I could be wrong, the functionality for compress
> might be in the current SP of VM:Secure/VM:Direct!
> 
> JR Imler
> 
> JR (Steven) Imler
> Computer Associates
> Senior Software Engineer
> Work: +1 703 708 3479
> Fax:  +1 703 708 3267
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
> 
> -----Original Message-----
> From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On
> Behalf Of Rich Greenberg
> Sent: Saturday, December 24, 2005 07:04 PM
> To: [email protected]
> Subject: Re: Minidisk defragger?
> 
> On: Sat, Dec 24, 2005 at 04:13:43PM -0600,Mike Walter Wrote:
> 
> } VMSECURE COMPRESS (and assumedly VMDIRECT COMPRESS) uses DDR under the
> 
> } covers.  Thus, any minidisk.
> 
> Thanks Mike.  Thats a VMS function I never used.  So you can do Linux
> disks, just can't resize a CMS disk.
> 
> -- 
> Rich Greenberg N6LRT Marietta, GA, USA richgr atsign panix.com + 1 770
> 321 6507
> Eastern time zone.   I speak for myself & my dogs only.     VM'er since
> CP-67
> Canines:Val, Red & Shasta (RIP),Red, husky
> Owner:Chinook-L
> Atlanta Siberian Husky Rescue. www.panix.com/~richgr/   Asst
> Owner:Sibernet-L
> 


 
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.

Reply via email to