Hi, George. Unfortunately SPXTAPE only supports tape as an output device. The IBM supplied SDF files (CMS, GCS, SCEE, NLSAMEGN, etc.) can be regenerated using VM/SES tools and procedures.
As Brian mentioned you could also use the DCSSBKUP /DCSSRSAV utilities as well. You could also grab a copy of the SFB spool file backup/restore utility from here: http://www.vsoft-software.com/downloads.html It saves the backed up SDF files to CMS files that you can then move from system to system. Have a good one, too. On 10/06/2010 09:46 AM, George Henke/NYLIC wrote: > I IPLed L2 COLD, because I did not have the extra SPOOL volumes yet to > come up FORCE. > > So I do not have the SDF. > > I suppose I could SPXTAPE DUMP them from L1, except I do not have any > tape. > > Can I redirect SPXTAPE to disk to port the SDF to L2?. > > > > > Brian Nielsen <[email protected]> > Sent by: The IBM z/VM Operating System <[email protected]> > 10/05/2010 04:29 PM > Please respond to > The IBM z/VM Operating System <[email protected]> > > > To > [email protected] > cc > > Subject > Re: IPL VM/VM Issues > > > > > > > As others have pointed out, your L2 guest can't hurt your L1 system or > > other guests unless L2 has access to those disks. Stating it from a > different angle - you should never give your L2 guest access to anything > > you don't want it to have access to. It's no different than keeping your > > z/OS and Linux guests from stepping on each other or your L1 system. Thi > s > guest just happens to be running VM. > > For your IPL, if you've DDR'd your SPOOL volumes from L1 to L2, there is > > no reason to do a COLD start. Do a FORCE start instead. Otherwise you > > need to rebuild or SPXTAPE LOAD the SDF files. > > For TCP, what happens depends on what you have set up for your L2 guest. > > If you gave it access to a real hardware (OSA, hipersocket, etc) then you > > have other work to do to prevent IP conflicts. If instead you've given i > t > access to a disconnected VSWITCH and/or virtual LAN, then it won't cause > > any problems because it can't connect to anything. And, yes, defining > > GRAFs and using DIAL is a standard practice. > > Something you might want to look into is setting up your system so it > recognizes whether it's at L1 or L2 or at DR so that it does the "right > > thing" for that situation. There's several ways to do that, but you've > > gone down the path of diverging your L2 system from your L1 system. At m > y > site I have it setup so that I can DDR my L1 system into my L2 guest, int > o > a couple different setups at my DR site, or into some unknown site, and i > t > comes up the way I want it to in each instance even if the others are > running. It makes life easier. What you're doing is a great learning > > experience, and eventually you'll see the value in making your multiple > > systems easier to manage. > > Brian Nielsen > > > On Tue, 5 Oct 2010 15:28:01 -0400, George Henke/NYLIC > <[email protected]> wrote: > >> L2 is a cloned L1 directory except for the volsers in the Directory and > CF >> Parm files which have all been made unique, ie 540 becoming 54X. >> >> I plan to ipl as follows: >> >> system reset >> term conmode 3270 >> set mach esa >> I 125b clear loadparm 009 >> >> START COLD DRAIN >> >> To be safe, I suppose I should also add NOAUTO. >> >> L1 runs 5 z/OS machines and 3 Linuxes. >> >> They could be corrupted at L1 if I tried to bring them up in L2 at the >> same time without GRS, MIM, or some other serialization product. >> >> I doubt TCPIP will work at L2 without some reconfiguring. >> >> So I should define some GRAFs and dial them. >> >> Not sure if my L2 entry in the L1 Directory needs 54XRES, 54XPAG, 54XSPL > , >> 54XW01, 54XW02 or whether I can just specify the IPL vplume, 54XRES, and > >> CP finds the rest from the Parm disk. > > -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544
