I don’t really have access to the receiving system yet to do a PIPEDDR RESTORE so I’m trying to test this by FTPing back to the sending system. I’ve been able to do this using a simple FTP command within a REXX exec but the FTP stage of the PIPEDDR receives the “PASVPORT” error
From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Scott Rohling Sent: Friday, October 16, 2009 4:54 PM To: [email protected] Subject: Re: CMSDDR & VMARC question 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]<mailto:[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]<mailto:[email protected]>] On Behalf Of Scott Rohling Sent: Thursday, October 15, 2009 7:36 PM To: [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>] On Behalf Of Scott Rohling Sent: Thursday, October 15, 2009 7:17 PM To: [email protected]<mailto:[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]<mailto:[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.
