(actually - maybe the PIPEDDR DUMP/RESTORE over TCPIP is exactly what you want? if the zVM systems have connectivity, this lets you dump a disk directly from one system to another - and will save you steps...)
Scott On Thu, Oct 15, 2009 at 5:34 PM, Scott Rohling <scott.rohl...@gmail.com>wrote: > Maybe try a COPYFILE (PACK of the output file instead of using VMARC? > That way if you use F 1024 when FTPing to zVM, you can just COPYFILE (UNPACK > it.. I'm just assuming you were using VMARC to help ensure the xfer was > blocked correctly.. Using COPYFILE (PACK accomplishes the same thing. > Just not sure how they compare on 'compression'... > > You might also look at PIPEDDR -- and the PACK option .. (available on the > zVM download page. google 'zvm download' to find it). > > Scott > > > On Thu, Oct 15, 2009 at 5:18 PM, Henry, Bob <bob.he...@sungardhe.com>wrote: > >> I was going to do that, but some of the MDs are VSE full volume disks. >> >> >> >> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On >> Behalf Of *Scott Rohling >> *Sent:* Thursday, October 15, 2009 7:17 PM >> *To:* IBMVM@LISTSERV.UARK.EDU >> *Subject:* Re: CMSDDR & VMARC question >> >> >> >> Don't know about VMARC -- but CMSDDR is packing the entire minidisk - >> empty space and all... Why not just VMARC the files on the disk and >> forget about CMSDDR? >> >> Scott >> >> On Thu, Oct 15, 2009 at 5:05 PM, Henry, Bob <bob.he...@sungardhe.com> >> wrote: >> >> I’m using CMSDDR and VMARC to transfer some CMS minidisks via FTP. Both >> utilities seem to produce more output than the original data on the >> minidisk(s). Here’s an example. >> >> >> >> User has 25 files (mostly COBOL source and/or JCL) in a 4 cylinder 3390 >> minidisk, blocked 4096. A “Q DISK” shows 76 blocks used, 644 blocks left. >> >> CMSDDR on that minidisk shows 2,957,040 bytes IN, 2,634,392 bytes OUT, 41 >> tracks not compacted. The output file from CMSDDR has 101 records of >> LRECL=49152 using 644 blocks (size 4096). >> >> VMARC (of the CMSDDR output file) shows IN=2,634,392 and OUT=3,142,240. It >> produces a file of 38,736 records with LRECL=80 using 757 blocks (size >> 4096). >> >> >> >> Does anyone have any explanation why these utilities “grow” the amount of >> data to be transmitted rather than “shrinking” it? Am I missing something? >> I’m using just the default options for both programs. >> >> >> >> Any help would be appreciated. >> >> >> > >
