Hi Tom, Yep, I've already thought about dropping DDR2CMS (see post I just sent) - at least it would eliminate the need to copy the file into an RECFM=F file.
Of course dd from local DASD to a Samba mounted file share would be perfect, just one little problem - it doesn't run under CMS(!). I've got literally thousands of lines of REXX code which automates our DR process entirely that I'm not prepared to re-write so that Linux can do the data delivery. The SnapShots would have to be done in VM/CMS anyhow since I'm not aware of a SnapShot command interface for Linux, and various VM-based servers would still have to be brought up/down, quiesced and such on VM/CMS so it would get a bit complicated (not undoable, just a lot of wheel-reinventing, and of course the end result is a process that runs in Linux, I'm a VM'er and like my important business processes written and running in VM/CMS). It was the very first thing I thought of when I realized CMS simply cannot mount remote EXT3 filesystems and easily read/write to them and NFS was out of the question anyhow. PS: Did you guys at DOE go the TS1120 route? -Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, June 17, 2008 11:59 AM To: [email protected] Subject: Re: DDR'ing 3390 DASD To Remote Location When experimenting with encrypting backups, I used PIPEDDR to write PACKED versions of the data to a CMS minidisk. These are RECFM F LRECL 1024 and can be ftped to Linux and back as binary files, forcing the RECFM/LRECL on return. PIPEDDR can then be used to read these files and restore your DASD. I also tried the CKDSVRST program from the IBM Downloads page, but that required the extra COPYFILE (PACK step, again reading/writing the data more than necessary. Have you thought about using Linux tools (dd ?) to read/write your DASD? /Tom Kern /U.S. Dept of Energy /301-903-2211 On Tue, 17 Jun 2008 11:42:13 -0400, Michael Coffin <[EMAIL PROTECTED]> wrote: >(Cross-posted on VMESA-L and LINUX-390) > >Hi Folks, > >I want to eliminate use of tapes in my weekly DR process. Currently we >DDR numerous 3390 spindles to 3590 tape cartridges. > >I have set up a Linux server at our DR site with a ton of free disk >space, but the question becomes what is the best method to get images >of our DASD stored on it? > >I've modified our procedures to use DDR2CMS to create CMS files >representing the 3390 DASD images, which are then FTP'd to the Linux >server - but the process is VERY inefficient: > >1. DDR2CMS produces RECFM=V files which are unsuitable for FTP >(I've NEVER had any luck successfully FTP'ing RECFM=V files to a >non-CMS environment and getting them back in the correct format later), so I >have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around >47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP >only takes around 17 minutes! So we are really wasting nearly 90 >minutes/spindle just prepping the data to be transmitted. >2. The output from DDR2CMS for a 3390-3 spindle may actually be >LARGER than a 3390-3 spindle (even using COMPACT), so we need to use >3390-9 spindles as "work space", something I'm not fond of doing (as a >general rule we don't use 3390-9's at this site, but I configured a >string of them just for this purpose). > >There is a great tool on the VM download page called PIPEDDR which >basically does what DDR2CMS does using PIPE TRACKREAD - and it can >write the output to a TCPIP stage. This is exactly what I'm looking >for, with ONE important difference - PIPEDDR only talks to a remote >VM/CMS system running PIPEDDR to receive the output, I need to be able >to PIPE the output to a remote Linux storage server. > >Can anyone recommend a nice client that can run on Linux and listen on >a TCPIP port, accept some authorization credentials and host commands >(i.e. MKDIR, CD to dir, etc.) and receive/write to disk a stream of >data similar to what PIPEDDR might write to it's TCPIP stage? I could >then skip creating the DDR2CMS file and COPYFILE (PACKing it, writing >"indirectly" to the Linux server. I'd rather not reinvent the wheel if >there's already something out there. :) > >PS: It would be sweet if there were just a way to mount a remote EXT3 >filesystem somehow on CMS, but it looks like the only way to do this is >with NFS, which is a problem because it is considered an "unsafe >protocol". :( > >-Mike >
