You could skip the FTP: - On the receiving side -- PIPEDDR RESTORE BSTEA 191 (LISTEN
- Note the IP port being listened on - let's say it's 2034 - On the sending side - PIPEDDR DUMP BSTEA 191 168.162.215.71 2034 You'll need write access to bstea 191 on the receiving side, and read on the sending. Scott p.s. You can also specify a port to listen listen on -- if you're looking to automate several disks.. On Fri, Oct 16, 2009 at 1:36 PM, Henry, Bob <[email protected]> wrote: > I finally got all the pieces together for PIPEDDR (I think) I downloaded > PIPEDDR, the PRINCETON Runtime Library, and DRPC from the VM download site. > In the DRPC doc it says to run the DRPC command to load a nucleus extension, > which I did. > > > > I tried to run the following command > > > > pipeddr dump bstea 191 (ftp(-h 168.162.215.71 -u xxxxx -p xxxxx -f > bstea.ddr191 > > -debug) > RUNNING ESAV5R30 > > > > And I got this result: > > > > > > RCVD: 227 Data transfer will passively listen to > 168,162,215,71,6,110 > > 326 +++ > PASVPORT=256*PORT1+PORT2 > > 173 +++ CALL OPEN_DATA_SOCKET > HOSTIPAD > > DMSREX476E Error 41 running FTPPUT REXX, line 326: Bad arithmetic > conversion > > Dump failed. > > > > > Has anyone seen this error before? What have I missed? > > > > > > *From:* The IBM z/VM Operating System [mailto:[email protected]] *On > Behalf Of *Scott Rohling > *Sent:* Thursday, October 15, 2009 7:36 PM > *To:* [email protected] > *Subject:* Re: CMSDDR & VMARC question > > > > (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 <[email protected]> > 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 <[email protected]> > 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:[email protected]] *On > Behalf Of *Scott Rohling > *Sent:* Thursday, October 15, 2009 7:17 PM > *To:* [email protected] > *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 <[email protected]> > 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. > > > > > > >
