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:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Thursday, October 15, 2009 7:36 PM To: IBMVM@LISTSERV.UARK.EDU 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 <scott.rohl...@gmail.com<mailto: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<mailto: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:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of Scott Rohling Sent: Thursday, October 15, 2009 7:17 PM To: IBMVM@LISTSERV.UARK.EDU<mailto: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<mailto: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.
