Re: Transferring stuff from Mainframe to a RDz/UT clone of itself
On 5/28/2012 1:26 AM, melvinjac...@iinet.net.au wrote: On Friday, 25 May 2012 22:13:55 UTC+10, Thomas Conley wrote: On 5/25/2012 2:03 AM, mpjac...@comcen.com.au wrote: Hi all Can't readily see how to search the group, so apologies if this info is in here somewhere I'm just after opinion as to the best way to transfer files across from a normal MF Lpar , including some USS directories, to a copy of this Lpar running on RDz/UT under RedHat linux on a VM server. I'm told that shared DASD is not possible between the MF Lpar the RDz instance, we have FTP or NJE (don't know which is quicker). The basic scenario is to do regular incremental refreshes of the RDz/UT environment from it's big brother MF instance I'm posting this last thing on a Fri arvo, so may not get back to it before Monday (it's just gone 4pm here in Sydney) Thx Melvyn Jacobs Melvyn, I would run DFDSS DUMP, TERSE, FTP binary, DETERSE, then DFDSS RESTORE. Regards, Tom Conley dumb question - the plan that I was given just said basically DFDSS DUMP, FTP, RESTORE - what advantage does On Friday, 25 May 2012 22:13:55 UTC+10, Thomas Conley wrote: On 5/25/2012 2:03 AM, mpjac...@comcen.com.au wrote: Hi all Can't readily see how to search the group, so apologies if this info is in here somewhere I'm just after opinion as to the best way to transfer files across from a normal MF Lpar , including some USS directories, to a copy of this Lpar running on RDz/UT under RedHat linux on a VM server. I'm told that shared DASD is not possible between the MF Lpar the RDz instance, we have FTP or NJE (don't know which is quicker). The basic scenario is to do regular incremental refreshes of the RDz/UT environment from it's big brother MF instance I'm posting this last thing on a Fri arvo, so may not get back to it before Monday (it's just gone 4pm here in Sydney) Thx Melvyn Jacobs Melvyn, I would run DFDSS DUMP, TERSE, FTP binary, DETERSE, then DFDSS RESTORE. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Hi Tom Thanks for that - any particular reason for including TERSE, over just DFDSS FTP ? cheers Melvyn Melvyn, The DFDSS dump dataset is a RECFM=U file. I've had difficulty in transferring RECFM=U files with FTP, so TERSEing them creates a nice FB 1024 format that can FTP cleanly in binary mode. I also get the compression for a faster FTP. Someone else in this thread recommended TSO XMIT which basically does the same thing without compression, by creating an FB 80 format record. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Transferring stuff from Mainframe to a RDz/UT clone of itself
I believe that MFNetDisk could be used to replicate volumes to a PC. I wonder if you could convert the MFNetDisk volume file to the volume-file format used by zPDT? Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Transferring stuff from Mainframe to a RDz/UT clone of itself
http://www.mail-archive.com/ibm-main@bama.ua.edu/msg124717.html On Sun, May 27, 2012 at 9:38 AM, Kirk Wolf k...@dovetail.com wrote: I believe that MFNetDisk could be used to replicate volumes to a PC. I wonder if you could convert the MFNetDisk volume file to the volume-file format used by zPDT? Kirk Wolf Dovetailed Technologies http://dovetail.com -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Transferring stuff from Mainframe to a RDz/UT clone of itself
To add a couple comments, NFS could be part of the loop. It's more convenient than FTP, I think. Moreover, SCLM (which is part of z/OS) with an appropriate exit seems like a good idea, with better organization and control (and therefore better mistake avoidance) for the sort of stuff you'd be doing with RDz. For any network transmissions think about whether intercept is possible. IPSec or a secure file transfer could be prudent, even on an internal network. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Transferring stuff from Mainframe to a RDz/UT clone of itself
On 5/25/2012 2:03 AM, mpjac...@comcen.com.au wrote: Hi all Can't readily see how to search the group, so apologies if this info is in here somewhere I'm just after opinion as to the best way to transfer files across from a normal MF Lpar , including some USS directories, to a copy of this Lpar running on RDz/UT under RedHat linux on a VM server. I'm told that shared DASD is not possible between the MF Lpar the RDz instance, we have FTP or NJE (don't know which is quicker). The basic scenario is to do regular incremental refreshes of the RDz/UT environment from it's big brother MF instance I'm posting this last thing on a Fri arvo, so may not get back to it before Monday (it's just gone 4pm here in Sydney) Thx Melvyn Jacobs Melvyn, I would run DFDSS DUMP, TERSE, FTP binary, DETERSE, then DFDSS RESTORE. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Transferring stuff from Mainframe to a RDz/UT clone of itself
Another, possibly too weird, technique would be to use GIMZIP. GIMZIP supports the packaging of both z/OS datasets and z/OS UNIX files into a container file. It is also compressed and needs to be transferred in BINary mode. And then there is the CBT tape method. Use TSO XMIT for all the z/OS datasets. Put each XMIT in a separate member of a PDS. Use z/OS UNIX pax to make an archive of all the UNIX files. pax can output that directly into another member in the same PDS. Then either XMIT that PDS and transfer it, or TERSE it. Just pointing out some alternatives. I, personally, have done the latter (XMIT) but only because I submitted it to the CBT Tape and that's how they wanted it done. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Conley Sent: Friday, May 25, 2012 7:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Transferring stuff from Mainframe to a RDz/UT clone of itself On 5/25/2012 2:03 AM, mpjac...@comcen.com.au wrote: Hi all Can't readily see how to search the group, so apologies if this info is in here somewhere I'm just after opinion as to the best way to transfer files across from a normal MF Lpar , including some USS directories, to a copy of this Lpar running on RDz/UT under RedHat linux on a VM server. I'm told that shared DASD is not possible between the MF Lpar the RDz instance, we have FTP or NJE (don't know which is quicker). The basic scenario is to do regular incremental refreshes of the RDz/UT environment from it's big brother MF instance I'm posting this last thing on a Fri arvo, so may not get back to it before Monday (it's just gone 4pm here in Sydney) Thx Melvyn Jacobs Melvyn, I would run DFDSS DUMP, TERSE, FTP binary, DETERSE, then DFDSS RESTORE. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
