Re: Backup and Restore Manager V1.2 startup problem
*** Received device 0181, a 3590-11 which is empty or not ready. write-enabled, and positioned at load point. *** Return code 32 attempting to obtain VOL1 label. *** TAPE DVOL1 replied: DMSP2C431E TAP1(181) VOL1 label missing You gave it a unlabeled tape. BRM expects IBM SL tapes. You need to label the tape with TAPE WVOL1 before you can use it with BRM.
Re: Backup and Restore Manager V1.2 startup problem
On Jun 17, 2011, at 6:16 AM, Lu GL Gao wrote: Our client installed Backup and Restore Manager V1.2 on z/VM V5.4. We had successfully installed and configured this tool. However when I firstly logon BKRBKUP user and execute its PROFILE EXEC, many error messages were shown like this: BKRCAT9174E No value has been specified for variable MD5TEXT in file BKRSYSTM CONFIG. *-* 'PIPE CMS BKRMD5' FoundFN FoundFT FoundFM '| VAR MD5TEXT' +++ RC(-3) +++ My installation and configuration is strictly basd on Installation Guide and Administration Guide, and there was no error message during installing process. The complete error information: (See attached file: BKRBKUP.LOGON.ERROR) The PROFILE EXEC file for BKRBKUP: (See attached file: BKRBKUP.PROFILE.EXEC) The configuration file for Backup and Restore Manager: (See attached file: BKRSYSTM.CONFIG) Attachments are stripped off e-mail to this list; if you really need us to see them, embed them in the e-mail. Based solely on my knowledge of VM, without any specific knowledge of the product to which you refer, I'd conclude you haven't finished installing or configuring the user interface for this product so that your CMS users can see it. A return code of -3 means command not found, such as BKRMD5 in this case. Something it trying to compute an MD5 checksum, but it can't find the program to do so. Maybe it got installed on 19E, but you forgot to save CMS after you put it out there? Maybe it's on a minidisk you don't have accessed? Maybe the server released its minidisks and re-accessed the ones it wants, dropping where you had installed BKRMD5 and the rest of the odds and ends? That's the first thing I'd track down about this set of problems: why can't it find BKRMD5, which is probably a MODULE. Sir Nick the Ardent VM SysProg Emeritus, since VM/SP 3 (1984)
Re: Backup and Restore Manager V1.2 startup problem
On Jun 17, 2011, at 6:16 AM, Lu GL Gao wrote: Our client installed Backup and Restore Manager V1.2 on z/VM V5.4. We h ad successfully installed and configured this tool. However when I firstly logon BKRBKUP user and execute its PROFILE EXEC, many error messages were shown like this: --- - BKRCAT9174E No value has been specified for variable MD5TEXT in file BKRSYSTM CONFIG. *-* 'PIPE CMS BKRMD5' FoundFN FoundFT FoundFM '| VAR MD5TEXT' +++ RC(-3) +++ This is a known error in the most recent SDO that includes Backup and Restore Manager for z/VM V1.2. (Customers installing previous levels of the SDO and then applying service themselves will not see this error.) The file BKRMD5 MODULE is missing from the 5697J06B 491 and 591 disks. As a work around, please copy BKRMD5 MODULE from the 5697J06B 492 disk to the 491 and 591 disks. Tracy Dean, IBM Product Manager
Re: Backup Problem
On Tuesday, 09/07/2010 at 01:30 EDT, Mario Izaguirre mizagui...@circulo.es wrote: I'm wanting to backup the VSE POWER queue and when I execute the BACKUP command I get this error in the system console. Mario, I think your question is best posted to VSE-L, or, even better, given to the IBM Support Center. Alan Altmark z/VM Development IBM Endicott
Re: RELABEL SYSRES was: Re: Backup RES Labeling Question
Shimon, Thanks for the corrections! They have all been included in V1R1. Before sending V1R1 to the list, ... Oops! Note to self: check the To: address very carefully before replying! :-( Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: RELABEL SYSRES was: Re: Backup RES Labeling Question
If you override the console device on the SAPL screen at IPL time, it overrides, as in negates, the lists in the SYSTEM CONFIG, both Operator_Consoles and Emergency_Operator_Consoles. AFAIR, this is true whether you have the CONS= parameter in the default or override SAPL parameters. If you want the config file lists to remain active, you cannot use the SAPL to specify the console address. At least, that is how it works in 5.3. I hope that either 5.4 or the looming 6.1 corrects this design flaw. The one specified should, IMHO, be inserted at the head of the lists, rather than replacing them. The treatment of the IPL pack is a good example - it is inserted as the first CP_Owned volume if it is not in the list. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Saturday, September 05, 2009 11:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RELABEL SYSRES was: Re: Backup RES Labeling Question Good work Mike! A few comments after a brief scan of your document are embedded below: 6) When the STAND ALONE PROGRAM LOADER: screen appears, under the line IPL PARAMETERS enter: cons=console_vdev E.g. cons=0009 Then press F10 to IPL with that virtual console address used as your OPERATOR console. 7) If you receive a Wait State 1010, it means that the SYSTEM CONFIG file does not have the console_vdev you entered listed as one of the Operator_Consoles. Change the console virtual address to match one of those specified in SYSTEM CONFIG. Nota bene: The SYSTEM CONFIG distributed by IBM for z/VM 5.4.0 had: Operator_Consoles 0020 0021 0022 0023 0E20 0E21 1020 , System_3270 System_Console AFAIR - the SAPL option CONS= acts as if the address was added to that list. The reason for a 1010 would be forgetting the conmode 3270.
Re: RELABEL SYSRES was: Re: Backup RES Labeling Question
Sorry, Howard, I left off the :-) at the end of the note DJ Howard Rifkind wrote: Easy there big fella... --- On *Fri, 9/4/09, Dave Jones /d...@vsoft-software.com/* wrote: From: Dave Jones d...@vsoft-software.com Subject: Re: RELABEL SYSRES was: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 1:04 PM EHowardit's at the bottom of Mike's note Howard Rifkind wrote: How and where can I (we) retrieve you write up? --- On *Fri, 9/4/09, Mike Walter /mike.wal...@hewitt.com /mc/compose?to=mike.wal...@hewitt.com/* wrote: From: Mike Walter mike.wal...@hewitt.com /mc/compose?to=mike.wal...@hewitt.com Subject: RELABEL SYSRES was: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU /mc/compose?to=ib...@listserv.uark.edu Date: Friday, September 4, 2009, 12:55 PM Howard, You already have your answer: Use CPFMTXA to Label the output volume. But just yesterday I completed a draft document describing how to change a sysres (and page and SPOOL) volser in details sufficient for most newbies. The change would let that relabeled sysres IPL on 1st of 2nd level. This document was created partly because I had recently pointed out on the list that IBM had no written documentation on how to do that, then David Boyes said that he'd add it to his someday list, I received an off-list request for help with a problem that may have been caused by duplicate 540xxx volsers. And then I had a need to change a sysres volser, too - perfect timing to test the process. The stars aligned, the clouds parted, and a document came out. The pasted document (file attachments do not make it to this list) is in a format suitable to be saved to a CMS file (ours is called RELABEL SYSRES) on a CMS minidisk or filespace. That leads to a document which is not as pretty as one created with your choice of word processor products, but one which is always available on your VM system without any word processor software. This is V1R0, aimed at newbies, trying to give enough information to get the job done without so much information that it becomes difficult to keep up to date. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544 -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: Backup RES Labeling Question
DIRECT file are different from the spool data in the currently running system. Finally, you are ready to issue a SHUTDOWN command. Shutting down your system and restarting it To test the changes you must shut your system down and then restart it. You cannot do a SHUTDOWN REIPL in this situation because you have to do a FORCE start as follows: == shutdown SYSTEM SHUTDOWN STARTED HCPSHU960I System shutdown may be delayed for up to 210 seconds You lose your 3270 session. Perform the following steps to restart the system: 1. Go back to the HMC to IPL your system. 2. Click the LOAD icon in the CPC Recovery menu. 3. Select the Clear radio button. All the other parameters must be correct from the previous IPL. Click OK. 4. Click Yes on the Load Task Confirmation panel. 5. Go back to the Integrated 3270 console. After a few minutes the Standalone Program Loader panel opens. Use the Tab key to traverse to the section IPL Parameters and enter the value cons=sysg. 6. Press the F10 key to continue the IPL of your z/VM system. This takes around three minutes. 7. At the start prompt, you have to specify a FORCE start, again because the spool volume label has changed. Enter the following: == force drain 8. Do not change the time of day clock. == no 9. When the IPL completes, DISCONNECT from the OPERATOR user ID and log in to MAINT. == disc Now your z/VM system volumes must be relabeled. Verify with the QUERY CPOWNED command, as Example 4-42 shows. Example 4-42 Verifying z/VM volumes with QUERY CPOWNED == q cpowned Slot Vol-ID Rdev Type Status 1 VM1RES A770 Own Online and attached 2 VM1SP1 A771 Own Online and attached 3 VM1PG1 A772 Own Online and attached 4 VVA773 A773 Own Online and attached 5 VVA774 A774 Own Online and attached 6 VPA775 A775 Own Online and attached 7 VPA776 A776 Own Online and attached 8 VPA777 A777 Own Online and attached 9 VPA778 A778 Own Online and attached 10 VPA779 A779 Own Online and attached 11 -- - Reserved ... In the event that you IPL a system with duplicate system volumes, it is possible that you may have destroyed your saved segments. You can identify this situation when you are unable to IPL CMS. In this case, you have to IPL 190. Important: Do this only if your saved segments have been destroyed. To rebuild saved segments, try the following commands: == vmfsetup zvm cms == sampnss cms == i 190 cl parm savesys cms == vmfbld ppf segbld esasegs segblist ( all -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 9:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Thanks Scott, --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 1:11 PM Changing VM VOLSERs Logon as MAINT. Attach nnnRES volume to the base z/VM system. ATTACH rdev TO SYSTEM ç nnnRES Add the following full pack minidisk statements for xxxRES to MAINT on the base system and put the directory online. MDISK F123 3390 000 END nnnRES MW MDISK FCF1 3390 039 120 nnnRES MW READ WRITE MULTIPLE MDISK F2CC 3390 506 005 nnnRES MW READ WRITE MULTIPLE Logoff/Logon to MAINT. Access the new system’s minidisks. ACCESS FCF1 W ACCESS F2CC U Edit the “NEW” directory on the F2CC “U” minidisk, changing all the VOLID's to the new VOLID’s. IBM Default Production Description nnnRES mmxRES SYSRES nnnSPL mmxSP1 Spool Volume 1 nnnPAG mmxPG1 Page Volume 1 nnnW01 mmxW01 Work Volume 1 Where nnn is the base release, i.e. 530 Where mm is the base release, i.e. 53 and x is an identification letter, i.e. “A” ZVMESA5 = “A” Z800ZVM = “B” ODCZVM52 = “C” Edit the “NEW” SYSTEM CONFIG file on the FCF1 “W” minidisk, changing all the VOLID's to the new VOLID’s. Define '123' as 'FFF' and 'F123' as '123' to place the newly modified directory online for the second level VM system. Use QUERY V DASD to verify. DEFINE 123 AS FFF DEFINE F123 AS 123 DIRECTXA user direct u Re-Define the ‘123’ disk. Use QUERY V DASD to verify. DEFINE 123 AS F123 DEFINE FFF AS 123 Attach the remaining new system DASD addresses to MAINT. DETACH rdev FROM SYSTEM ç nnnRES ATTACH rdev TO MAINT ç nnnRES ATTACH rdev TO MAINT ç nnnSPL ATTACH rdev TO MAINT ç nnnPAG ATTACH rdev TO MAINT ç nnnW01 ATTACH rdev TO MAINT ç nnnW02 Change the VOLID's to what they were changed to in the new directory. Execute ICKDSF. REFORMAT UNIT(rdev) VERIFY(nnnRES) VOLID(nnxRES) REFORMAT
Re: Backup RES Labeling Question
Thanks Paul, All of the details and suggestions posted on the list are great. I had most of this down in my Notes Log and really just wanted to get a flavor of how different people are handling this situation. Thanks again. BTW, I'll be sending you a note off list. Please be kind enough to read it and advise. --- On Sat, 9/5/09, Paul, Thomas thomas.p...@iso.com wrote: From: Paul, Thomas thomas.p...@iso.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Saturday, September 5, 2009, 10:00 AM Howard, Here is the attachment and how to do this. Please remember to make changes that fits to your environment. Regards Tom _Modifying labels in the SYSTEM CONFIG file _ Modifying labels in the USER DIRECT file _ Changing the labels on the five volumes _ Shutting down your system and restarting it Modifying labels in the SYSTEM CONFIG file Note the first five CP-owned volumes with the QUERY CPOWNED command in Example 4-36. Example 4-36 QUERY CPWONED output == q cpowned Slot Vol-ID Rdev Type Status 1 520RES A770 Own Online and attached 2 520SPL A771 Own Online and attached 3 520PAG A772 Own Online and attached 4 520W01 A773 Own Online and attached 5 520W02 A774 Own Online and attached 6 VPA775 A775 Own Online and attached 7 VPA776 A776 Own Online and attached 8 VPA777 A777 Own Online and attached 9 VPA778 A778 Own Online and attached 10 VPA779 A779 Own Online and attached 11 -- - Reserved 12 -- - Reserved ... == cprel a == link * cf1 cf1 mr == acc cf1 f == copy system config f = confBKUP = (oldd rep == x system config f Issue follow on the command line to reach the CP_Owned volumes /cp_owned /* CP_Owned Volume Statements */ /**/ CP_Owned Slot 1 VM1RES CP_Owned Slot 2 VM1SP1 CP_Owned Slot 3 VM1PG1 CP_Owned Slot 4 VVA771 CP_Owned Slot 5 VVA772 CP_Owned Slot 6 VPA776 CP_Owned Slot 7 VPA778 CP_Owned Slot 8 VPA775 CP_Owned Slot 9 VPA777 file Verify to make sure that there are no syntax errors: == acc 193 g == cpsyntax system config f CONFIGURATION FILE PROCESSING COMPLETE -- NO ERRORS ENCOUNTERED. Release and detach the F disk, CPACCESS the A disk, and verify, as Example 4-39 shows. Example 4-39 Releasing and detaching the F disk, and verifying the A disk == rel f (det DASD 0CF1 DETACHED == cpacc * cf1 a CPACCESS request for mode A scheduled. Ready; T=0.01/0.01 09:19:57 HCPZAC6732I CPACCESS request for MAINT's 0CF1 in mode A completed. == q cpdisk Label Userid Vdev Mode Stat Vol-ID Rdev Type StartLoc EndLoc MNTCF1 MAINT 0CF1 A R/O 520RES A770 CKD 39 83 MNTCF2 MAINT 0CF2 B R/O 520RES A770 CKD 84 128 MNTCF3 MAINT 0CF3 C R/O 520RES A770 CKD 129 188 You have now changed the labels of the system volumes in the SYSTEM CONFIG file. It is critical that you proceed as your system is now in a state where it will not IPL. 60 IBM z/VM and Linux on IBM System z: Virtualization Cookbook for Red Hat Enterprise Linux 4 Modifying labels in the USER DIRECT file Now modify the labels in the USER DIRECT file. You see many more occurrences of the labels being changed, as Example 4-40 shows. Example 4-40 Modifying labels in USER DIRECT == copy user direct c = direwrks = (oldd rep == x user direct c Stay on set case m i top ch /510RES/VM1RES/ * * all /510RES/ all Do the previous 3 commands for each volser that needs to be changed. file You have now changed the labels of the system volumes in the USER DIRECT and SYSTEM CONFIG files. It is critical that you proceed with the remaining steps. Changing the labels on the five volumes Change the labels on the five volumes using the CPFMTXA command. You can do this one volume at a time with the CPFMTXA LABEL command. Gain read/write access to the system res volume. link maint 123 123 mr Ready; T=0.01/0.01 13:07:07 q v 123 DASD 0123 3390 510RES R/W 3339 CYL ON DASD 7130 SUBCHANNEL = 000B Ready; T=0.01/0.01 13:08:22 The following command will place the VM1RES label on the volume at virtual address 123. cpfmtxa 123 VM1RES label HCPCCF6209I INVOKING ICKDSF. ICK030E DEFINE INPUT DEVICE: FN FT FM, CONSOLE, OR READER CONSOLE ICK031E DEFINE OUTPUT DEVICE: FN FT FM, CONSOLE, OR PRINTER CONSOLE ICKDSF - CMS/XA/ESA DEVICE SUPPORT FACILITIES 17.0 TIME: 13 ENTER INPUT COMMAND: CPVOL LABEL UNIT(0123) VOLID(VM1RES) NOVFY ICK00700I DEVICE INFORMATION FOR 0123 IS CURRENTLY AS FOLLOWS: PHYSICAL DEVICE = 3390 STORAGE CONTROLLER = 3990 STORAGE CONTROL DESCRIPTOR = E9 DEVICE DESCRIPTOR = 0A ADDITIONAL DEVICE INFORMATION = 4A001B35 ICK04000I DEVICE IS IN SIMPLEX STATE ICK00703I DEVICE IS OPERATED AS A MINIDISK ICK00091I 0123 NED= 2105. .IBM.13.00014076 ICK091I 0123 NED= 2105. .IBM.13.00014076 ICK03090I VOLUME SERIAL = 510RES ICK003D REPLY U TO ALTER VOLUME 0123 CONTENTS, ELSE T U ICK03000I CPVOL REPORT FOR 0123 FOLLOWS: VOLUME SERIAL NUMBER IS NOW = VM1RES ICK1I FUNCTION COMPLETED
Re: RELABEL SYSRES was: Re: Backup RES Labeling Question
Good work Mike! A few comments after a brief scan of your document are embedded below: 6) When the STAND ALONE PROGRAM LOADER: screen appears, under the line IPL PARAMETERS enter: cons=console_vdev E.g. cons=0009 Then press F10 to IPL with that virtual console address used as your OPERATOR console. 7) If you receive a Wait State 1010, it means that the SYSTEM CONFIG file does not have the console_vdev you entered listed as one of the Operator_Consoles. Change the console virtual address to match one of those specified in SYSTEM CONFIG. Nota bene: The SYSTEM CONFIG distributed by IBM for z/VM 5.4.0 had: Operator_Consoles 0020 0021 0022 0023 0E20 0E21 1020 , System_3270 System_Console AFAIR - the SAPL option CONS= acts as if the address was added to that list. The reason for a 1010 would be forgetting the conmode 3270. 9) Once the IPL is completed skip over the 1st level procedure,below. jump to the Post-IPL procedures: 2nd level procedure: 1) IPL from the HMC, using the LOAD ADDRESS of the existing (example 540RES) sysres, and a LOADPARM of your console real device (rdev) address. Umm... didn't you mean to title this section 1st level procedure ? If you don't have a local non-SNA 3270 console (perhaps an emulator) attached to this LPAR, you can use the Integrated 3270 Console on the HMC as the console address. In either case, include during the IPL on the HMC, the LOADPARM of either the local non-SNA 3270 terminal (or emulator), or System_3270 (maybe System_Console, but I never tried that). I believe the loadparm value needed to have SAPL come up on the integrated 3270 in the HMC is SYSG. Post-IPL procedures: ... ... Enter: XEDIT SYSTEM CONFIG W 6) Change the old new to new volser. Enter: TOP Enter: C/540RES/VMR540/ * * That should be the old volser to new volser 3) Edit the file, changing 540RES to VMR540 (just an example). Enter: XEDIT USER DIRECT C 4) Change the old new to new volser. Enter: TOP Enter: C/540RES/VMR540/ * * Same typo again. You do not need to shut the system down to change the PAGE and SPOOL DASD volsers. CP only reads the volsers when the DASD is *attached*... to the system. So they can be changed ahead of time for the next IPL. Hmmm... you seem to have attached the same document *twice*, and the second version has this line which was missing in the first version: varied online, and the Allocation Bitmaps when the DASD is ATTACHed So it goes where I commented attached above. Thanks, Shimon
Re: Backup RES Labeling Question
Are you referring to cloning a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Backup RES Labeling Question
Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to “cloning” a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Backup RES Labeling Question
The CPFMTXA command can relabel the volume. This is required after you co py the orginal volume. CPFMTXA vdev volid Label Then you have the problem that the object (and maybe the source) director y on 54GBRS has all of the volsers pointing at 54GRES. Now, this may not be a problem if your recover procedure is to us Standalone DDR and ICKDSF to c opy and relabel (or just relabel) back to 54GRES. But if you want to use 54GB RS as an IPLable system onto itself, then you need to change the object directory on that volume to reflect the new volume label. To do this, get a monlithic copy of the directory, change /54GRES/54GBRS/ * * , file as 54GBRS DIRECT A, get a link or attach of 54GBRS as 0123 (or whatever vdev is used in the control section of that directory), DIRECTXA 54GBRS DIRECT A. You should get a return code of 5 which means that the object directory was written to the volume, but NOT brought online, becau se the target volume is not the same as the Online directory. This is correc t for this situation. Then you need to update the real source of the directory and that depends on where you really keep the source directory. /Tom Kern /301-903-2211 On Fri, 4 Sep 2009 09:12:39 -0700, Howard Rifkind vmes...@yahoo.com wro te: Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks.
Re: Backup RES Labeling Question
Here is the procedure I use to change VM VOLSERs after cloning the volumes, maybe you can adapt to your needs. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to “cloning” a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Backup RES Labeling Question
Scott, think you forgot to attach your procedure... And thanks all. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:38 PM Here is the procedure I use to change VM VOLSERs after cloning the volumes, maybe you can adapt to your needs. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to “cloning” a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Backup RES Labeling Question
Attachments are not forwarded by the LISTSERV, you have to include the procedure in the text of the note. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Scott, think you forgot to attach your procedure... And thanks all. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:38 PM Here is the procedure I use to change VM VOLSERs after cloning the volumes, maybe you can adapt to your needs. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to cloning a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Backup RES Labeling Question
Scott, Just forward it to my email address. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:38 PM Here is the procedure I use to change VM VOLSERs after cloning the volumes, maybe you can adapt to your needs. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to “cloning” a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: RELABEL SYSRES was: Re: Backup RES Labeling Question
EHowardit's at the bottom of Mike's note Howard Rifkind wrote: How and where can I (we) retrieve you write up? --- On *Fri, 9/4/09, Mike Walter /mike.wal...@hewitt.com/* wrote: From: Mike Walter mike.wal...@hewitt.com Subject: RELABEL SYSRES was: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:55 PM Howard, You already have your answer: Use CPFMTXA to Label the output volume. But just yesterday I completed a draft document describing how to change a sysres (and page and SPOOL) volser in details sufficient for most newbies. The change would let that relabeled sysres IPL on 1st of 2nd level. This document was created partly because I had recently pointed out on the list that IBM had no written documentation on how to do that, then David Boyes said that he'd add it to his someday list, I received an off-list request for help with a problem that may have been caused by duplicate 540xxx volsers. And then I had a need to change a sysres volser, too - perfect timing to test the process. The stars aligned, the clouds parted, and a document came out. The pasted document (file attachments do not make it to this list) is in a format suitable to be saved to a CMS file (ours is called RELABEL SYSRES) on a CMS minidisk or filespace. That leads to a document which is not as pretty as one created with your choice of word processor products, but one which is always available on your VM system without any word processor software. This is V1R0, aimed at newbies, trying to give enough information to get the job done without so much information that it becomes difficult to keep up to date. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: Backup RES Labeling Question
Yes - relabel the volume.. it was unnecessary to label and format the new volume in the first place - you could have just done the DDR and run CPFMTXA to relabel it. If you really needed to IPL from it - you'd likely need to change the volume to 54GRES first.. (and relabel the 'real' 54GRES to something else) Scott On Fri, Sep 4, 2009 at 10:12 AM, Howard Rifkind vmes...@yahoo.com wrote: Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks.
Re: Backup RES Labeling Question
Changing VM VOLSERs 1. Logon as MAINT. 2. Attach nnnRES volume to the base z/VM system. ATTACH rdev TO SYSTEM çnnnRES 3. Add the following full pack minidisk statements for xxxRES to MAINT on the base system and put the directory online. MDISK F123 3390 000 END nnnRES MW MDISK FCF1 3390 039 120 nnnRES MW READ WRITEMULTIPLE MDISK F2CC 3390 506 005 nnnRES MW READ WRITEMULTIPLE 4. Logoff/Logon to MAINT. 5. Access the new system’s minidisks. ACCESS FCF1 W ACCESS F2CC U 6. Edit the “NEW” directory on the F2CC “U” minidisk, changing all the VOLID's to the new VOLID’s. IBM Default Production Description nnnRES mmxRES SYSRES nnnSPL mmxSP1 Spool Volume 1 nnnPAG mmxPG1 Page Volume 1 nnnW01 mmxW01 Work Volume 1 Where nnn is the base release, i.e. 530 Where mm is the base release, i.e. 53 and x is an identification letter, i.e. “A” ZVMESA5 = “A” Z800ZVM = “B” ODCZVM52 = “C” 7. Edit the “NEW” SYSTEM CONFIG file on the FCF1 “W” minidisk, changing all the VOLID's to the new VOLID’s. 8. Define '123' as 'FFF' and 'F123' as '123' to place the newly modified directory online for the second level VM system. Use QUERY V DASD to verify. DEFINE 123 AS FFF DEFINE F123 AS 123 DIRECTXA user direct u 9. Re-Define the ‘123’ disk. Use QUERY V DASD to verify. DEFINE 123 AS F123 DEFINE FFF AS 123 10. Attach the remaining new system DASD addresses to MAINT. DETACH rdev FROM SYSTEM çnnnRES ATTACH rdev TO MAINTçnnnRES ATTACH rdev TO MAINTçnnnSPL ATTACH rdev TO MAINTçnnnPAG ATTACH rdev TO MAINTçnnnW01 ATTACH rdev TO MAINTçnnnW02 11. Change the VOLID's to what they were changed to in the new directory. Execute ICKDSF. REFORMAT UNIT(rdev) VERIFY(nnnRES) VOLID(nnxRES) REFORMAT UNIT(rdev) VERIFY(nnnSPL) VOLID(nnxSP1) REFORMAT UNIT(rdev) VERIFY(nnnPAG) VOLID(nnxPG1) REFORMAT UNIT(rdev) VERIFY(nnnW01) VOLID(nnxW01) REFORMAT UNIT(rdev) VERIFY(nnnW02) VOLID(nnxW02) 12. Detach the volumes from MAINT. DETACH rdev FROM MAINT çWas nnnRES DETACH rdev FROM MAINT çWas nnnSPL DETACH rdev FROM MAINT çWas nnnPAG DETACH rdev FROM MAINT çWas nnnW01 DETACH rdev FROM MAINT çWas nnnW02 13. Vary offline/online the new volumes. 14. IPL the new system. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Scott, think you forgot to attach your procedure... And thanks all. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:38 PM Here is the procedure I use to change VM VOLSERs after cloning the volumes, maybe you can adapt to your needs. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to “cloning” a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended
Re: Backup RES Labeling Question
Oops sorry – Try this Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Scott, think you forgot to attach your procedure... And thanks all. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:38 PM Here is the procedure I use to change VM VOLSERs after cloning the volumes, maybe you can adapt to your needs. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to “cloning” a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Backup RES Labeling Question
I did not know that - Thank you - I have resent with the info in the body. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, September 04, 2009 11:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Attachments are not forwarded by the LISTSERV, you have to include the procedure in the text of the note. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Scott, think you forgot to attach your procedure... And thanks all. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:38 PM Here is the procedure I use to change VM VOLSERs after cloning the volumes, maybe you can adapt to your needs. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to cloning a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM. I then ran DDR and did a COPY ALL and that worked with out any problems. Of course now the volume which was 54GBRS is now 54GRES. Now there are two volumes with the same volume id and the only way to identify which is which is by the DASD address. This seems to me to now present a problem. Should I now go and re label the back up volume to 54GBRS? What is the best way to handle this and how would we go ahead and test the backup SYSRES? Thanks. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: RELABEL SYSRES was: Re: Backup RES Labeling Question
Easy there big fella... --- On Fri, 9/4/09, Dave Jones d...@vsoft-software.com wrote: From: Dave Jones d...@vsoft-software.com Subject: Re: RELABEL SYSRES was: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 1:04 PM EHowardit's at the bottom of Mike's note Howard Rifkind wrote: How and where can I (we) retrieve you write up? --- On *Fri, 9/4/09, Mike Walter /mike.wal...@hewitt.com/* wrote: From: Mike Walter mike.wal...@hewitt.com Subject: RELABEL SYSRES was: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:55 PM Howard, You already have your answer: Use CPFMTXA to Label the output volume. But just yesterday I completed a draft document describing how to change a sysres (and page and SPOOL) volser in details sufficient for most newbies. The change would let that relabeled sysres IPL on 1st of 2nd level. This document was created partly because I had recently pointed out on the list that IBM had no written documentation on how to do that, then David Boyes said that he'd add it to his someday list, I received an off-list request for help with a problem that may have been caused by duplicate 540xxx volsers. And then I had a need to change a sysres volser, too - perfect timing to test the process. The stars aligned, the clouds parted, and a document came out. The pasted document (file attachments do not make it to this list) is in a format suitable to be saved to a CMS file (ours is called RELABEL SYSRES) on a CMS minidisk or filespace. That leads to a document which is not as pretty as one created with your choice of word processor products, but one which is always available on your VM system without any word processor software. This is V1R0, aimed at newbies, trying to give enough information to get the job done without so much information that it becomes difficult to keep up to date. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: Backup RES Labeling Question
Thanks Scott, --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 1:11 PM Changing VM VOLSERs Logon as MAINT. Attach nnnRES volume to the base z/VM system. ATTACH rdev TO SYSTEM ç nnnRES Add the following full pack minidisk statements for xxxRES to MAINT on the base system and put the directory online. MDISK F123 3390 000 END nnnRES MW MDISK FCF1 3390 039 120 nnnRES MW READ WRITE MULTIPLE MDISK F2CC 3390 506 005 nnnRES MW READ WRITE MULTIPLE Logoff/Logon to MAINT. Access the new system’s minidisks. ACCESS FCF1 W ACCESS F2CC U Edit the “NEW” directory on the F2CC “U” minidisk, changing all the VOLID's to the new VOLID’s. IBM Default Production Description nnnRES mmxRES SYSRES nnnSPL mmxSP1 Spool Volume 1 nnnPAG mmxPG1 Page Volume 1 nnnW01 mmxW01 Work Volume 1 Where nnn is the base release, i.e. 530 Where mm is the base release, i.e. 53 and x is an identification letter, i.e. “A” ZVMESA5 = “A” Z800ZVM = “B” ODCZVM52 = “C” Edit the “NEW” SYSTEM CONFIG file on the FCF1 “W” minidisk, changing all the VOLID's to the new VOLID’s. Define '123' as 'FFF' and 'F123' as '123' to place the newly modified directory online for the second level VM system. Use QUERY V DASD to verify. DEFINE 123 AS FFF DEFINE F123 AS 123 DIRECTXA user direct u Re-Define the ‘123’ disk. Use QUERY V DASD to verify. DEFINE 123 AS F123 DEFINE FFF AS 123 Attach the remaining new system DASD addresses to MAINT. DETACH rdev FROM SYSTEM ç nnnRES ATTACH rdev TO MAINT ç nnnRES ATTACH rdev TO MAINT ç nnnSPL ATTACH rdev TO MAINT ç nnnPAG ATTACH rdev TO MAINT ç nnnW01 ATTACH rdev TO MAINT ç nnnW02 Change the VOLID's to what they were changed to in the new directory. Execute ICKDSF. REFORMAT UNIT(rdev) VERIFY(nnnRES) VOLID(nnxRES) REFORMAT UNIT(rdev) VERIFY(nnnSPL) VOLID(nnxSP1) REFORMAT UNIT(rdev) VERIFY(nnnPAG) VOLID(nnxPG1) REFORMAT UNIT(rdev) VERIFY(nnnW01) VOLID(nnxW01) REFORMAT UNIT(rdev) VERIFY(nnnW02) VOLID(nnxW02) Detach the volumes from MAINT. DETACH rdev FROM MAINT ç Was nnnRES DETACH rdev FROM MAINT ç Was nnnSPL DETACH rdev FROM MAINT ç Was nnnPAG DETACH rdev FROM MAINT ç Was nnnW01 DETACH rdev FROM MAINT ç Was nnnW02 Vary offline/online the new volumes. IPL the new system. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Scott, think you forgot to attach your procedure... And thanks all. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:38 PM Here is the procedure I use to change VM VOLSERs after cloning the volumes, maybe you can adapt to your needs. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup RES Labeling Question Just creating a copy of the sysres volume to use for testing. --- On Fri, 9/4/09, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: From: Wandschneider, Scott scott.wandschnei...@infocrossing.com Subject: Re: Backup RES Labeling Question To: IBMVM@LISTSERV.UARK.EDU Date: Friday, September 4, 2009, 12:29 PM Are you referring to “cloning” a system or just providing a backup of the RES volume? Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Howard Rifkind Sent: Friday, September 04, 2009 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup RES Labeling Question Hello all, I had been asked to make a backup copy of the SYSRES volume, volulme id 54GRES, and was provide with a DASD address of 6027 and a new volume id of 54GBRS. I did a CPFMTXA on 6027 with the volume id of 54GBRS and formatted the entire volume as PERM
Re: Backup: Twinning Tapes to Remote Tape Unit
Perhaps by measuring the amount of tape left on the spindle? A light, possibly laser, shining on a tangent to the spindle at a specified height could be detected only when the tape remaining is not thick enough to block the light. This would remove any dependence on stickers which are supposed to be x feet or x inches from the physical end of the tape. There are other possibilities. For example, compare the speed in RPM of the two spindles. When the take-up spindle is over half full, it moves at a slower RPM than the other in order to keep the same linear rate for the tape. This could be used to determine the EOT. I would hope that the use of stickers to denote EOT would have gone out way back in my career. We used stickers in pre-S/360 days and they were fraught with problems then. Have you ever had to clean the heads and capstans of a tape drive that had become fouled with a sticker that did not stay stuck? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTS) Sent: Friday, June 06, 2008 8:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Now that is interesting. How does that OS/390 utility know where the EOT reflector is located unless it spins the entire tape first? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, June 06, 2008 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Backup: Twinning Tapes to Remote Tape Unit
On Monday, 06/09/2008 at 04:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: I would hope that the use of stickers to denote EOT would have gone out way back in my career. Reflective stickers went away with the 3480. It introduced a servo track that the drive uses to know the position of the tape at all times. EOT is at a certain physical block number, x. Every time. Bigger tape? Then you have a bigger value for x. The tape may be skipping bad data blocks on the tape, but they are at known locations and EOT still occurs at x, so the effective length will be less than the physical length. This is why degaussing today's tape cartridges results in a useless tape: the servo track is destroyed in the process. If you look at the sense data for today's drives, you'll see that it contains tons of block counters AND a [fuzzy] tape length indication. Alan Altmark z/VM Development IBM Endicott
Re: Backup: Twinning Tapes to Remote Tape Unit
I just knew that you (IBM) had to have done something about those stickers. They were a PITA. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, June 09, 2008 3:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit On Monday, 06/09/2008 at 04:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: I would hope that the use of stickers to denote EOT would have gone out way back in my career. Reflective stickers went away with the 3480. It introduced a servo track that the drive uses to know the position of the tape at all times. EOT is at a certain physical block number, x. Every time. Bigger tape? Then you have a bigger value for x. The tape may be skipping bad data blocks on the tape, but they are at known locations and EOT still occurs at x, so the effective length will be less than the physical length. This is why degaussing today's tape cartridges results in a useless tape: the servo track is destroyed in the process. If you look at the sense data for today's drives, you'll see that it contains tons of block counters AND a [fuzzy] tape length indication. Alan Altmark z/VM Development IBM Endicott
Re: Backup: Twinning Tapes to Remote Tape Unit
I think in the case of having to run 2 backups jobs I would run one backup job and then run a utility job to copy the 1st set of tapes to the remote set of tapes. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Llewellyn Sent: Thursday, June 05, 2008 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one local tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: Backup: Twinning Tapes to Remote Tape Unit
Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. You would also need to a complete copy of the tapes, labels and all, because the tapes are chained together with user labels. If you couldn't do that, then the copy utility would have have to be smart enough to generate the user label records according to VM:Backup specs. Since the VMBACKUP catalog wouldn't know about these tapes, any restores would have to be done using VMBRITS or VMBSAR. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Dodds, Jim [EMAIL PROTECTED] duTo Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Backup: Twinning Tapes to Remote Tape Unit 06/06/2008 08:29 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I think in the case of having to run 2 backups jobs I would run one backup job and then run a utility job to copy the 1st set of tapes to the remote set of tapes. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Llewellyn Sent: Thursday, June 05, 2008 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one local tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: Backup: Twinning Tapes to Remote Tape Unit
Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. Not that I'm aware of. Mark Wheeler
Re: Backup: Twinning Tapes to Remote Tape Unit
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Friday, June 06, 2008 8:39 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. You would also need to a complete copy of the tapes, labels and all, because the tapes are chained together with user labels. If you couldn't do that, then the copy utility would have have to be smart enough to generate the user label records according to VM:Backup specs. Since the VMBACKUP catalog wouldn't know about these tapes, any restores would have to be done using VMBRITS or VMBSAR. Mark L. Wheeler Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Backup: Twinning Tapes to Remote Tape Unit
And after having run into the (barely) shorter-output-tape situation after a major, self-induced problem with VM:Backup here (accidentally scratching hundreds of tapes, but of those none from the same twin set), I opened an enhancement request (now called a DAR) with perhaps then Systems Center (been a long time) asking for such a capability It was never implemented. I don't recall any more if it was canned, or still sits there queued in DAR limbo. BTW, someone suggested in this thread the idea of making manual copies after the backup completes, but then only being able to restore them with VMBRITS and VMBSAR. Warning: VMBSAR does not support 3590+ tapes. VM:Backup will happily make physical backups to 3590 tapes, but there's no way to restore them without a running VMBACKUP svm, and access to the VM:Backup catalog containing the physical tape backups. A chicken-and-egg problem. Works for us, but you really need to think of all the aspects to make it work. HiDRO is the alternative which circumvents the lack of 3590 support in VMBSAR. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Mark Wheeler [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/06/2008 08:50 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Backup: Twinning Tapes to Remote Tape Unit Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. Not that I'm aware of. Mark Wheeler The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Backup: Twinning Tapes to Remote Tape Unit
That is a good point that I had not completely thought thru about the tape lengths. So forget about what I said. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Friday, June 06, 2008 9:39 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. You would also need to a complete copy of the tapes, labels and all, because the tapes are chained together with user labels. If you couldn't do that, then the copy utility would have have to be smart enough to generate the user label records according to VM:Backup specs. Since the VMBACKUP catalog wouldn't know about these tapes, any restores would have to be done using VMBRITS or VMBSAR. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Dodds, Jim [EMAIL PROTECTED] du To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Backup: Twinning Tapes to Remote Tape Unit 06/06/2008 08:29 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I think in the case of having to run 2 backups jobs I would run one backup job and then run a utility job to copy the 1st set of tapes to the remote set of tapes. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Llewellyn Sent: Thursday, June 05, 2008 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one local tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: Backup: Twinning Tapes to Remote Tape Unit
Now that is interesting. How does that OS/390 utility know where the EOT reflector is located unless it spins the entire tape first? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, June 06, 2008 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Backup: Twinning Tapes to Remote Tape Unit
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTS) Sent: Friday, June 06, 2008 10:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Now that is interesting. How does that OS/390 utility know where the EOT reflector is located unless it spins the entire tape first? Well, it doesn't really __know__. It does know the approprimate length of the tape from a sense command. The drive knows what type of tape medium is mounted on it. It then estimates how many blocks it should write. The 3490 and later drives will tell, via a sense command, the current block id (this accounts for compression on the drive). When the current block id is greater than the estimate, then the utility does an FEOV to force an end-of-volume switch. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Backup: Twinning Tapes to Remote Tape Unit
There is a round about way of doing this. Fran and I came up with it about 4 years ago. VMBACKUP can backup to DASD. With that, you need to specify the size of a tape file that will exist on disk. Then, you do, in my case, a twin backup specifying a disk file and tape. When the disk file is full, it will start a new disk and a new tape file. I do believe there is a triple option of running a backup against 3 output devices. So this may help with a twin. Anyway, if you are running twin backups from VMBACKUP both copies will be the same size as the smallest media. You shouldn't have a problem there. Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. Mark Wheeler [EMAIL PROTECTED] 6/6/2008 8:50 AM Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. Not that I'm aware of. Mark Wheeler
Re: Backup: Twinning Tapes to Remote Tape Unit
My enhancement request suggested to writing until EOV, then back up to the beginning of that VM:Backup domain, close the tape (with all the usual EOV, and cross-linked User Header and Trailer Labels), and re-write that domain on the fresh tape. It got more complex when a single domain would not fit on a single tape, but with newer tape technologies that may no longer be a significant problem. Food for fresh thoughts. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Stracka, James (GTS) [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/06/2008 10:35 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Backup: Twinning Tapes to Remote Tape Unit Now that is interesting. How does that OS/390 utility know where the EOT reflector is located unless it spins the entire tape first? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, June 06, 2008 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/ . By messaging with Merrill Lynch you consent to the foregoing. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Backup: Twinning Tapes to Remote Tape Unit
Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. That's yet another complication for us if were to use twins. We use 9840 (STK high capacity) tapes for our local backups and 3490 (in a VTS) for our remote backups. We'd have to change our local backups to 3490 tapes, and we don't have enough silo slots to do that. A full backup for us is 6 9840 tapes, or 145 virtual tapes. I tested a small backup of 11 3390-3 volumes with twins. It took seven 3490E cartridges, and seven 9840 cartridges. Mark is right, both streams get a new tape when the first one hits EOT, even if they have vastly different capacities. Dennis Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier
Re: Backup: Twinning Tapes to Remote Tape Unit
Copying tapes is fraught with enough potential issues (many illuminated here) that we are not going to consider it... -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Friday, June 06, 2008 6:39 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. You would also need to a complete copy of the tapes, labels and all, because the tapes are chained together with user labels. If you couldn't do that, then the copy utility would have have to be smart enough to generate the user label records according to VM:Backup specs. Since the VMBACKUP catalog wouldn't know about these tapes, any restores would have to be done using VMBRITS or VMBSAR. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Dodds, Jim [EMAIL PROTECTED] du To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Backup: Twinning Tapes to Remote Tape Unit 06/06/2008 08:29 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I think in the case of having to run 2 backups jobs I would run one backup job and then run a utility job to copy the 1st set of tapes to the remote set of tapes. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Llewellyn Sent: Thursday, June 05, 2008 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one local tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: Backup CMS files
This sounds like a good way to go...what platform are you running TSM on? We are running it under AIX. Thanks, Alyce -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Romanowski, John (OFT) Sent: Friday, February 22, 2008 5:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Alyce, We use TSM for file-level backups of SLES 9 SLES 10 guests. Works well for us. Having file-level backups we can leave the Linux servers up 24 x 7 and never have to shut them down to get a static image backup. And since the guests use SAN disk and not dasd we can't backup their disks from z/VM anyway. John This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Austin, Alyce (CIV) Sent: Tuesday, February 19, 2008 11:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Are you using TSM for file level backups? If so, are you happy with it? Thanks, Alyce -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Sunday, February 17, 2008 7:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Not really. If you are willing to take a Linux guest down, you can back up the full minidisks with VM:Backup or the corresponding IBM product, but you can only restore a full minidisk. If you want to do file level restores on Linux, or backups while Linux is up, you will have to use Linux based tools, such as Netbackup or Bacula or TSM. We have been struggling with this question ourselves. We licensed a CA product called Brightstore Archive Bakup (BAB) two years ago. After two years of fighting with it, we just decided to delete it. It never worked reliably. The reason to choose BAB was that it will backup to mainframe tapes (such as our STK Silos). The other Linux products want to use midrange tapes instead. You might want to ask about Linux backups on the LINUX-390 list instead of this list. See http://www2.marist.edu/htbin/wlvindex?linux-390. On Wed, 13 Feb 2008 13:52:49 -0700, Brent Litster [EMAIL PROTECTED] wrote: One thing I forget to mention is that we will be running Linux instances under z/VM as well. Do the CA and IBM products address Linux files as well? Brent Litster Zions Management Services Company 2185 South 3270 West West Valley City 84119 (801) 844-5545 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, February 13, 2008 12:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files I have to agree with Ed. Some human had to write the code does it really matter who paid his salary? It also depends on what you are backing up. If your z/VM is used almost entirely to host other operating systems and very little ever happens in CMS one solution may be proper, but on the other hand if you have millions of lines of source code (or production files) in CMS you may want to consider a more sophisticated approach. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, February 13, 2008 1:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Oh I wouldn't go quite that far. We have been running our home grown CMS backup system for about 19 years now. It isn't too complicated, just a series of LINK, ACCESS, VMFPLC2 DUMP commands. And it is very reliable too. We keep our yearly generations for 10 years and I can still easily recover a single file from any minidisk on those tapes. And only 143 lines in the EXEC, with 20 or so of them being comments!! I do agree that given the proper dollars in the budget, a purchased, supported package would be a much better choice. But back in the VM/SP 6 days, a CMS backup solution was very expensive for a little bitty 8 MIP, 4381 shop. So I did what I had to do, write some code and save some money. It isn't perfect, but as I said before, the price was right. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete
Re: Backup CMS files
Alyce, running TSM on AIX -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Austin, Alyce (CIV) Sent: Friday, February 22, 2008 12:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files This sounds like a good way to go...what platform are you running TSM on? We are running it under AIX. Thanks, Alyce -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Romanowski, John (OFT) Sent: Friday, February 22, 2008 5:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Alyce, We use TSM for file-level backups of SLES 9 SLES 10 guests. Works well for us. Having file-level backups we can leave the Linux servers up 24 x 7 and never have to shut them down to get a static image backup. And since the guests use SAN disk and not dasd we can't backup their disks from z/VM anyway. John This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Austin, Alyce (CIV) Sent: Tuesday, February 19, 2008 11:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Are you using TSM for file level backups? If so, are you happy with it? Thanks, Alyce -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Sunday, February 17, 2008 7:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Not really. If you are willing to take a Linux guest down, you can back up the full minidisks with VM:Backup or the corresponding IBM product, but you can only restore a full minidisk. If you want to do file level restores on Linux, or backups while Linux is up, you will have to use Linux based tools, such as Netbackup or Bacula or TSM. We have been struggling with this question ourselves. We licensed a CA product called Brightstore Archive Bakup (BAB) two years ago. After two years of fighting with it, we just decided to delete it. It never worked reliably. The reason to choose BAB was that it will backup to mainframe tapes (such as our STK Silos). The other Linux products want to use midrange tapes instead. You might want to ask about Linux backups on the LINUX-390 list instead of this list. See http://www2.marist.edu/htbin/wlvindex?linux-390. On Wed, 13 Feb 2008 13:52:49 -0700, Brent Litster [EMAIL PROTECTED] wrote: One thing I forget to mention is that we will be running Linux instances under z/VM as well. Do the CA and IBM products address Linux files as well? Brent Litster Zions Management Services Company 2185 South 3270 West West Valley City 84119 (801) 844-5545 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, February 13, 2008 12:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files I have to agree with Ed. Some human had to write the code does it really matter who paid his salary? It also depends on what you are backing up. If your z/VM is used almost entirely to host other operating systems and very little ever happens in CMS one solution may be proper, but on the other hand if you have millions of lines of source code (or production files) in CMS you may want to consider a more sophisticated approach. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, February 13, 2008 1:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Oh I wouldn't go quite that far. We have been running our home grown CMS backup system for about 19 years now. It isn't too complicated, just a series of LINK, ACCESS, VMFPLC2 DUMP commands. And it is very reliable too. We keep our yearly generations for 10 years and I can still easily recover a single file from any minidisk on those tapes. And only 143 lines in the EXEC, with 20 or so of them being comments!! I do agree that given the proper dollars in the budget, a purchased, supported package would be a much better choice. But back in the VM/SP 6 days, a CMS backup solution was very expensive for a little bitty 8 MIP, 4381 shop. So I did what I had to do, write some code and save some money. It isn't perfect, but as I said before, the price was right. Ed Zell Illinois Mutual Life (309) 674-8255 x-107
Re: Backup CMS files
On Tue, 19 Feb 2008 08:54:52 -0800, Austin, Alyce (CIV) [EMAIL PROTECTED] wrote: Are you using TSM for file level backups? If so, are you happy with it? Thanks, Alyce No. At present we have no working file-level backups. Just VM:Backup back ups of Linux machines that are (supposed to be) down. But we know we will need file-level backu ps as we get into productions. (In theory this year...) That was why we licensed BAB. The B ank standard is NetBackup, but we don't currently use it. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: Backup CMS files
Are you using TSM for file level backups? If so, are you happy with it? Thanks, Alyce -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Sunday, February 17, 2008 7:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Not really. If you are willing to take a Linux guest down, you can back up the full minidisks with VM:Backup or the corresponding IBM product, but you can only restore a full minidisk. If you want to do file level restores on Linux, or backups while Linux is up, you will have to use Linux based tools, such as Netbackup or Bacula or TSM. We have been struggling with this question ourselves. We licensed a CA product called Brightstore Archive Bakup (BAB) two years ago. After two years of fighting with it, we just decided to delete it. It never worked reliably. The reason to choose BAB was that it will backup to mainframe tapes (such as our STK Silos). The other Linux products want to use midrange tapes instead. You might want to ask about Linux backups on the LINUX-390 list instead of this list. See http://www2.marist.edu/htbin/wlvindex?linux-390. On Wed, 13 Feb 2008 13:52:49 -0700, Brent Litster [EMAIL PROTECTED] wrote: One thing I forget to mention is that we will be running Linux instances under z/VM as well. Do the CA and IBM products address Linux files as well? Brent Litster Zions Management Services Company 2185 South 3270 West West Valley City 84119 (801) 844-5545 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, February 13, 2008 12:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files I have to agree with Ed. Some human had to write the code does it really matter who paid his salary? It also depends on what you are backing up. If your z/VM is used almost entirely to host other operating systems and very little ever happens in CMS one solution may be proper, but on the other hand if you have millions of lines of source code (or production files) in CMS you may want to consider a more sophisticated approach. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, February 13, 2008 1:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Oh I wouldn't go quite that far. We have been running our home grown CMS backup system for about 19 years now. It isn't too complicated, just a series of LINK, ACCESS, VMFPLC2 DUMP commands. And it is very reliable too. We keep our yearly generations for 10 years and I can still easily recover a single file from any minidisk on those tapes. And only 143 lines in the EXEC, with 20 or so of them being comments!! I do agree that given the proper dollars in the budget, a purchased, supported package would be a much better choice. But back in the VM/SP 6 days, a CMS backup solution was very expensive for a little bitty 8 MIP, 4381 shop. So I did what I had to do, write some code and save some money. It isn't perfect, but as I said before, the price was right. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Backup CMS files
Not really. If you are willing to take a Linux guest down, you can back u p the full minidisks with VM:Backup or the corresponding IBM product, but you can only restore a fu ll minidisk. If you want to do file level restores on Linux, or backups while Linux is up, you wil l have to use Linux based tools, such as Netbackup or Bacula or TSM. We have been struggling with this question ourselves. We licensed a CA pr oduct called Brightstore Archive Bakup (BAB) two years ago. After two years of fighting with it, w e just decided to delete it. It never worked reliably. The reason to choose BAB was that it will backup to mainframe tapes (such as our STK Silos). The other Linux products want to use midrange tapes instead. You might want to ask about Linux backups on the LINUX-390 list instead o f this list. See http://www2.marist.edu/htbin/wlvindex?linux-390. On Wed, 13 Feb 2008 13:52:49 -0700, Brent Litster [EMAIL PROTECTED] corp.com wrote: One thing I forget to mention is that we will be running Linux instances under z/VM as well. Do the CA and IBM products address Linux files as well? Brent Litster Zions Management Services Company 2185 South 3270 West West Valley City 84119 (801) 844-5545 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, February 13, 2008 12:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files I have to agree with Ed. Some human had to write the code does it really matter who paid his salary? It also depends on what you are backing up. If your z/VM is used almost entirely to host other operating systems and very little ever happens in CMS one solution may be proper, but on the other hand if you have millions of lines of source code (or production files) in CMS you may want to consider a more sophisticated approach. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, February 13, 2008 1:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Oh I wouldn't go quite that far. We have been running our home grown CMS backup system for about 19 years now. It isn't too complicated, just a series of LINK, ACCESS, VMFPLC2 DUMP commands. And it is very reliable too. We keep our yearly generations for 10 years and I can still easily recover a single file from any minidisk on those tapes. And only 143 lines in the EXEC, with 20 or so of them being comments!! I do agree that given the proper dollars in the budget, a purchased, supported package would be a much better choice. But back in the VM/SP 6 days, a CMS backup solution was very expensive for a little bitty 8 MIP, 4381 shop. So I did what I had to do, write some code and save some money. It isn't perfect, but as I said before, the price was right. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Backup CMS files
We want to have a good backup/restore process in place where we can backup minidisks/CMS files with the ability to restore any 1 or more individual files if we need to. What is everyone out there using? Brent, If you are looking for a no cost solution, I have a REXX EXEC that we have been using here for years. You would be welcome to have a copy of it if you like. It reads a control file that lists all mini disks you want to have backed up. There are some negatives: - non labeled tapes - not much automation - manual restores, very easy to do though But the price is right! Let me know if you are interested. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Backup CMS files
On Wednesday, 02/13/2008 at 01:11 EST, Brent Litster [EMAIL PROTECTED] wrote: Hello all. We are a new z/VM 5.2 shop. We are in the process of hardening our z/VM environment prior to installing our first production system. We want to have a good backup/restore process in place where we can backup minidisks/CMS files with the ability to restore any 1 or more individual files if we need to. What is everyone out there using? We have heard of Amanda and Bacula. Is there a product used by a large number of shops like FDR for z/OS? We are a z/OS 1.7 shop with 1 lpar running z/VM 5.2 and it is this z/VM environment we are concerned about. IBM Backup and Restore Manager (and maybe IBM Tape Manager). http://www-306.ibm.com/software/stormgmt/zvm/index.html Alan Altmark z/VM Development IBM Endicott
Re: Backup CMS files
and ... as far as we (well, CA sales people) are concerned VM:Backup and HiDRO are a *single* product. You license VM:Backup and it comes with the VM:Backup HiDRO Feature! So between that product you have lots of options for configuring and addressing your z/VM backup requirements. JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, February 13, 2008 01:45 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Oops, Richard's correct. Change my mention of CA's Syback (an ancient name) to CA's HiDRO. Something was nagging me when I wrote that, Richard provided the confirmation why. :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. In reply to: VM:Backup from CA if you are interested in the ability to restore individual files from CMS format minidisks or from SFS. They also have a product called Hidro for disk image backups. You might want to check out IBM's products for backup. Make sure that whatever you choose is a product that you can live with as changing at a later date, when you have a large collection of backup tapes, can be a troublesome task. Regards, Richard Schuh The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.
Re: Backup CMS files
Oops, Richard's correct. Change my mention of CA's Syback (an ancient name) to CA's HiDRO. Something was nagging me when I wrote that, Richard provided the confirmation why. :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. In reply to: VM:Backup from CA if you are interested in the ability to restore individual files from CMS format minidisks or from SFS. They also have a product called Hidro for disk image backups. You might want to check out IBM's products for backup. Make sure that whatever you choose is a product that you can live with as changing at a later date, when you have a large collection of backup tapes, can be a troublesome task. Regards, Richard Schuh The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.
Re: Backup CMS files
VM:Backup from CA (formerly Sterling) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Brent Litster Sent: Wednesday, February 13, 2008 12:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup CMS files Hello all. We are a new z/VM 5.2 shop. We are in the process of hardening our z/VM environment prior to installing our first production system. We want to have a good backup/restore process in place where we can backup minidisks/CMS files with the ability to restore any 1 or more individual files if we need to. What is everyone out there using? We have heard of Amanda and Bacula. Is there a product used by a large number of shops like FDR for z/OS? We are a z/OS 1.7 shop with 1 lpar running z/VM 5.2 and it is this z/VM environment we are concerned about. Thanks, Brent Litster Zions Management Services Company Salt Lake City This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Backup CMS files
VM:Backup from CA if you are interested in the ability to restore individual files from CMS format minidisks or from SFS. They also have a product called Hidro for disk image backups. You might want to check out IBM's products for backup. Make sure that whatever you choose is a product that you can live with as changing at a later date, when you have a large collection of backup tapes, can be a troublesome task. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Brent Litster Sent: Wednesday, February 13, 2008 9:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup CMS files Hello all. We are a new z/VM 5.2 shop. We are in the process of hardenin= g our z/VM environment prior to installing our first production system. We = want to have a good backup/restore process in place where we can backup = minidisks/CMS files with the ability to restore any 1 or more individual = files if we need to. What is everyone out there using? We have heard of Amanda and Bacula. Is there a product used by a large number of sho= ps like FDR for z/OS? We are a z/OS 1.7 shop with 1 lpar running z/VM 5.2 an= d it is this z/VM environment we are concerned about. Thanks, Brent Litster Zions Management Services Company Salt Lake City
Re: Backup CMS files
While CA's VM:Backup or Syback (and maybe CA's VM:Tape tape management system) and IBM's IBM Backup and Restore Manager (and maybe IBM Tape Manager) are IMHO the de facto backup solutions for z/VM (like FDR and IBM's DFwhatever solution for z/OS), there are other less palatable options for backing up CMS files from z/VM. Those less palatable solutions would include home-grown tools using the TAPE DUMP and TAPE LOAD commands. But as someone wrote on this very list recently: there be dragons there. Consider that you are backing up the VM volumes (both the CMS file systems files, as well as CP-owned areas) in a manner required to provide a reliable, stable backup. I.e. something that is working WITH the CMS file systems, not something running from another system while VM is running and potentially changing those files while the system backing them up is unaware of VM's in-flight file changes. You run backups to be 100% certain that your system can be recovered if something goes wrong (be it hardware failure, software failure, or human error -- oops didn't mean to erase/replace/change *THAT* file!!). Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Brent Litster [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/13/2008 11:42 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Backup CMS files Hello all. We are a new z/VM 5.2 shop. We are in the process of hardenin g our z/VM environment prior to installing our first production system. We want to have a good backup/restore process in place where we can backup minidisks/CMS files with the ability to restore any 1 or more individual files if we need to. What is everyone out there using? We have heard of Amanda and Bacula. Is there a product used by a large number of sho ps like FDR for z/OS? We are a z/OS 1.7 shop with 1 lpar running z/VM 5.2 an d it is this z/VM environment we are concerned about. Thanks, Brent Litster Zions Management Services Company Salt Lake City The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.
Re: Backup CMS files
Thanks everyone. And thanks for the offer for the REXX exec Ed. I think what my company wants to bring in is something that supports standard label tapes and some automation. Brent Brent Litster Zions Management Services Company 2185 South 3270 West West Valley City 84119 (801) 844-5545 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Wednesday, February 13, 2008 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files We want to have a good backup/restore process in place where we can backup minidisks/CMS files with the ability to restore any 1 or more individual files if we need to. What is everyone out there using? Brent, If you are looking for a no cost solution, I have a REXX EXEC that we have been using here for years. You would be welcome to have a copy of it if you like. It reads a control file that lists all mini disks you want to have backed up. There are some negatives: - non labeled tapes - not much automation - manual restores, very easy to do though But the price is right! Let me know if you are interested. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Backup CMS files
Brent, As much as I love IBM and the people who work for IBM ;-) The CA-VM:Manager Suite of products are a complete package: VM:Secure is a Security and Directory product in one. VM:Backup, VM:Backup-HiDRo, and VM:Archive for cms and dasd backup. there are other products but these are the most widely used, by most VM shops. good luck VM System Programmer Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Brent Litster wrote: Hello all. We are a new z/VM 5.2 shop. We are in the process of hardenin g our z/VM environment prior to installing our first production system. We want to have a good backup/restore process in place where we can backup minidisks/CMS files with the ability to restore any 1 or more individual files if we need to. What is everyone out there using? We have heard of Amanda and Bacula. Is there a product used by a large number of sho ps like FDR for z/OS? We are a z/OS 1.7 shop with 1 lpar running z/VM 5.2 an d it is this z/VM environment we are concerned about. Thanks, Brent Litster Zions Management Services Company Salt Lake City
Re: Backup CMS files
Thanks, Mike. Something that's supported and will likely continue to be supported in the future tends to get managements attention. Brent Litster Zions Management Services Company 2185 South 3270 West West Valley City 84119 (801) 844-5545 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, February 13, 2008 11:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files While CA's VM:Backup or Syback (and maybe CA's VM:Tape tape management system) and IBM's IBM Backup and Restore Manager (and maybe IBM Tape Manager) are IMHO the de facto backup solutions for z/VM (like FDR and IBM's DFwhatever solution for z/OS), there are other less palatable options for backing up CMS files from z/VM. Those less palatable solutions would include home-grown tools using the TAPE DUMP and TAPE LOAD commands. But as someone wrote on this very list recently: there be dragons there. Consider that you are backing up the VM volumes (both the CMS file systems files, as well as CP-owned areas) in a manner required to provide a reliable, stable backup. I.e. something that is working WITH the CMS file systems, not something running from another system while VM is running and potentially changing those files while the system backing them up is unaware of VM's in-flight file changes. You run backups to be 100% certain that your system can be recovered if something goes wrong (be it hardware failure, software failure, or human error -- oops didn't mean to erase/replace/change *THAT* file!!). Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Brent Litster [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/13/2008 11:42 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Backup CMS files Hello all. We are a new z/VM 5.2 shop. We are in the process of hardenin g our z/VM environment prior to installing our first production system. We want to have a good backup/restore process in place where we can backup minidisks/CMS files with the ability to restore any 1 or more individual files if we need to. What is everyone out there using? We have heard of Amanda and Bacula. Is there a product used by a large number of sho ps like FDR for z/OS? We are a z/OS 1.7 shop with 1 lpar running z/VM 5.2 an d it is this z/VM environment we are concerned about. Thanks, Brent Litster Zions Management Services Company Salt Lake City The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.
Re: Backup CMS files
I have to agree with Ed. Some human had to write the code does it really matter who paid his salary? It also depends on what you are backing up. If your z/VM is used almost entirely to host other operating systems and very little ever happens in CMS one solution may be proper, but on the other hand if you have millions of lines of source code (or production files) in CMS you may want to consider a more sophisticated approach. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, February 13, 2008 1:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Oh I wouldn't go quite that far. We have been running our home grown CMS backup system for about 19 years now. It isn't too complicated, just a series of LINK, ACCESS, VMFPLC2 DUMP commands. And it is very reliable too. We keep our yearly generations for 10 years and I can still easily recover a single file from any minidisk on those tapes. And only 143 lines in the EXEC, with 20 or so of them being comments!! I do agree that given the proper dollars in the budget, a purchased, supported package would be a much better choice. But back in the VM/SP 6 days, a CMS backup solution was very expensive for a little bitty 8 MIP, 4381 shop. So I did what I had to do, write some code and save some money. It isn't perfect, but as I said before, the price was right. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Backup CMS files
Also not good if you consider those who follow in your footsteps. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, February 13, 2008 10:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files erase/replace/change *THAT* file!!). Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates.
Re: Backup CMS files
Well put, Thomas - what is being backed up makes a BIG difference. When I was in charge of such things, I was constantly bothered by users who mistakenly erased important files. So, when DITTO started supporting the DDR format, I wrote an EXEC (dated 1995) that could be used by the users. It would restore either an entire minidisk or a single file. For the latter, the user was prompted for the name, the EXEC scanned the directory to find which DDR backup tape needed to be mounted, and then invoked DITTO to restore the minidisk to a TDSK area. It then spooled the restored file to the user's reader. This was in use (the last I heard) for many years after I left the shop. Of course, we had no VM tape management system and all backups were done with DDR (full-pack). But, as Ed mentioned, the price was right! David Wakser From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, February 13, 2008 2:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files I have to agree with Ed. Some human had to write the code does it really matter who paid his salary? It also depends on what you are backing up. If your z/VM is used almost entirely to host other operating systems and very little ever happens in CMS one solution may be proper, but on the other hand if you have millions of lines of source code (or production files) in CMS you may want to consider a more sophisticated approach. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, February 13, 2008 1:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Oh I wouldn't go quite that far. We have been running our home grown CMS backup system for about 19 years now. It isn't too complicated, just a series of LINK, ACCESS, VMFPLC2 DUMP commands. And it is very reliable too. We keep our yearly generations for 10 years and I can still easily recover a single file from any minidisk on those tapes. And only 143 lines in the EXEC, with 20 or so of them being comments!! I do agree that given the proper dollars in the budget, a purchased, supported package would be a much better choice. But back in the VM/SP 6 days, a CMS backup solution was very expensive for a little bitty 8 MIP, 4381 shop. So I did what I had to do, write some code and save some money. It isn't perfect, but as I said before, the price was right. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Backup CMS files
Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Oh I wouldn't go quite that far. We have been running our home grown CMS backup system for about 19 years now. It isn't too complicated, just a series of LINK, ACCESS, VMFPLC2 DUMP commands. And it is very reliable too. We keep our yearly generations for 10 years and I can still easily recover a single file from any minidisk on those tapes. And only 143 lines in the EXEC, with 20 or so of them being comments!! I do agree that given the proper dollars in the budget, a purchased, supported package would be a much better choice. But back in the VM/SP 6 days, a CMS backup solution was very expensive for a little bitty 8 MIP, 4381 shop. So I did what I had to do, write some code and save some money. It isn't perfect, but as I said before, the price was right. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Backup CMS files
Don't forget VM:Tape. It or a similar product from another vendor is pretty much required if you want to automats the operation. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bill Munson Sent: Wednesday, February 13, 2008 10:49 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Brent, As much as I love IBM and the people who work for IBM ;-) The CA-VM:Manager Suite of products are a complete package: VM:Secure is a Security and Directory product in one. VM:Backup, VM:Backup-HiDRo, and VM:Archive for cms and dasd backup. there are other products but these are the most widely used, by most VM shops. good luck VM System Programmer Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Brent Litster wrote: Hello all. We are a new z/VM 5.2 shop. We are in the process of hardenin g our z/VM environment prior to installing our first production system. We want to have a good backup/restore process in place where we can backup minidisks/CMS files with the ability to restore any 1 or more individual files if we need to. What is everyone out there using? We have heard of Amanda and Bacula. Is there a product used by a large number of sho ps like FDR for z/OS? We are a z/OS 1.7 shop with 1 lpar running z/VM 5.2 an d it is this z/VM environment we are concerned about. Thanks, Brent Litster Zions Management Services Company Salt Lake City
Re: Backup CMS files
One thing I forget to mention is that we will be running Linux instances under z/VM as well. Do the CA and IBM products address Linux files as well? Brent Litster Zions Management Services Company 2185 South 3270 West West Valley City 84119 (801) 844-5545 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, February 13, 2008 12:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files I have to agree with Ed. Some human had to write the code does it really matter who paid his salary? It also depends on what you are backing up. If your z/VM is used almost entirely to host other operating systems and very little ever happens in CMS one solution may be proper, but on the other hand if you have millions of lines of source code (or production files) in CMS you may want to consider a more sophisticated approach. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, February 13, 2008 1:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup CMS files Relying on home-grown, unsupported tools is probably not something anyone wants to do when considering a long-term career. :-) Oh I wouldn't go quite that far. We have been running our home grown CMS backup system for about 19 years now. It isn't too complicated, just a series of LINK, ACCESS, VMFPLC2 DUMP commands. And it is very reliable too. We keep our yearly generations for 10 years and I can still easily recover a single file from any minidisk on those tapes. And only 143 lines in the EXEC, with 20 or so of them being comments!! I do agree that given the proper dollars in the budget, a purchased, supported package would be a much better choice. But back in the VM/SP 6 days, a CMS backup solution was very expensive for a little bitty 8 MIP, 4381 shop. So I did what I had to do, write some code and save some money. It isn't perfect, but as I said before, the price was right. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Backup lmp key
Hello Phillip, I have CA-VMWEBGATEWAY. Go to VMRMAINT, and enter VMRMAINT (command). Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, September 25, 2007 2:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup lmp key anybody running VM:Backup that can tell me where to put the LMP key? there is no reference to it in the VM:Backup manuals. prg Phillip Gramly Systems Programmer Communications Data Group Champaign, IL
Re: Backup lmp key
It goes in file CALMP KEYS on VMRMAINT 192. Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: September 25, 2007 14:42 To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup lmp key anybody running VM:Backup that can tell me where to put the LMP key? there is no reference to it in the VM:Backup manuals. prg Phillip Gramly Systems Programmer Communications Data Group Champaign, IL The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: Backup lmp key
It goes in file CALMP KEYS on VMRMAINT 192. great - thanks everyone. prg Phillip Gramly Systems Programmer Communications Data Group Champaign, IL
Re: backup prior to maintenance
I would be applying on a first level system. I have no idea what minidisks are affected. I've only done maintenance twice, once the long way (with IBM here and it was no picnic) and the second time where it was a complete mess. Can I use DDRXA and just backup 510RES and 510SPL? Will that be good enough? If there are problems, can I restore both and be ok? Sorry, I guess I wasn't clear enough! [EMAIL PROTECTED] 2/8/2007 11:23 AM If you are running a second-level guest to do your maintenance in, then t= he best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from= the first level MAINT userid. Then bring up your second-level guest, appl= y and test the maintenance (shutting down and restoring as necessary). Then= migrate the good maintenance to your first-level production system. If you are applying your maintenance to minidisks on a first-level system= , then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL= or user minidisks. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] = wrote: I would like to know what the recommended procedure is for backing up th= e system prior to applying maintenance (and how to restore if there is a problem!!). The last time I did maintenance, I backed up 510RES with DDR= XA and when PUT2PROD had errors, restored 510RES from that tape. To make a long story short, it really messed up the spool and I ended up on the pho= ne for hours with IBM. I need to put maintenance on again and want to make sure and do it right this time. = == ===
Re: backup prior to maintenance
Anne, I would use DDRXA to backup 510res, 510w01, 510w02 then use SPXTAPE to backup the spool files. Tom -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Anne Crabtree Sent: Thursday, February 08, 2007 10:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: backup prior to maintenance I would be applying on a first level system. I have no idea what minidisks are affected. I've only done maintenance twice, once the long way (with IBM here and it was no picnic) and the second time where it was a complete mess. Can I use DDRXA and just backup 510RES and 510SPL? Will that be good enough? If there are problems, can I restore both and be ok? Sorry, I guess I wasn't clear enough! [EMAIL PROTECTED] 2/8/2007 11:23 AM If you are running a second-level guest to do your maintenance in, then t= he best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from= the first level MAINT userid. Then bring up your second-level guest, appl= y and test the maintenance (shutting down and restoring as necessary). Then= migrate the good maintenance to your first-level production system. If you are applying your maintenance to minidisks on a first-level system= , then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL= or user minidisks. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] = wrote: I would like to know what the recommended procedure is for backing up th= e system prior to applying maintenance (and how to restore if there is a problem!!). The last time I did maintenance, I backed up 510RES with DDR= XA and when PUT2PROD had errors, restored 510RES from that tape. To make a long story short, it really messed up the spool and I ended up on the pho= ne for hours with IBM. I need to put maintenance on again and want to make sure and do it right this time. = == === __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: backup prior to maintenance
Your first message was clear. The answer is still the same. If you are applying your maintenance to minidisks on a first-level system, then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL or user minidisks. [EMAIL PROTECTED] wrote: I would be applying on a first level system. I have no idea what minidisks are affected. I've only done maintenance twice, once the long way (with IBM here and it was no picnic) and the second time where it was a complete mess. Can I use DDRXA and just backup 510RES and 510SPL? Will that be good enough? If there are problems, can I restore both and be ok? Sorry, I guess I wasn't clear enough! [EMAIL PROTECTED] 2/8/2007 11:23 AM If you are running a second-level guest to do your maintenance in, then t= he best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from= the first level MAINT userid. Then bring up your second-level guest, appl= y and test the maintenance (shutting down and restoring as necessary). Then= migrate the good maintenance to your first-level production system. If you are applying your maintenance to minidisks on a first-level system= , then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL= or user minidisks. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] = wrote: I would like to know what the recommended procedure is for backing up th= e system prior to applying maintenance (and how to restore if there is a problem!!). The last time I did maintenance, I backed up 510RES with DDR= XA and when PUT2PROD had errors, restored 510RES from that tape. To make a long story short, it really messed up the spool and I ended up on the pho= ne for hours with IBM. I need to put maintenance on again and want to make sure and do it right this time. = == ===
Re: backup prior to maintenance
Anne, We do our maintenance on the first level system. We rely on our daily backup process as our safety net. Since we keep backups for several months, we can go back to any prior day's image. Because we don't do maintenance every day, the MAINT disks are reasonably stable and this type of backup is, we feel, sufficient. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of StephenPFrazieVM Sent: Thursday, February 08, 2007 8:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: backup prior to maintenance Your first message was clear. The answer is still the same. If you are applying your maintenance to minidisks on a first-level system, then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL or user minidisks. [EMAIL PROTECTED] wrote: I would be applying on a first level system. I have no idea what minidisks are affected. I've only done maintenance twice, once the long way (with IBM here and it was no picnic) and the second time where it was a complete mess. Can I use DDRXA and just backup 510RES and 510SPL? Will that be good enough? If there are problems, can I restore both and be ok? Sorry, I guess I wasn't clear enough! [EMAIL PROTECTED] 2/8/2007 11:23 AM If you are running a second-level guest to do your maintenance in, then t= he best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from= the first level MAINT userid. Then bring up your second-level guest, appl= y and test the maintenance (shutting down and restoring as necessary). Then= migrate the good maintenance to your first-level production system. If you are applying your maintenance to minidisks on a first-level system= , then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL= or user minidisks. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] = wrote: I would like to know what the recommended procedure is for backing up th= e system prior to applying maintenance (and how to restore if there is a problem!!). The last time I did maintenance, I backed up 510RES with DDR= XA and when PUT2PROD had errors, restored 510RES from that tape. To make a long story short, it really messed up the spool and I ended up on the pho= ne for hours with IBM. I need to put maintenance on again and want to make sure and do it right this time. = == ===
Re: backup prior to maintenance
Don't worry about the clarity of your postings, we all need to refine our descriptions through repetition. Okay, you are running maintenance on first-level and you do not have a CMS or minidisk level product to backup your allocations. Figuring out what minidisks VMSES will use for any particular component is possible via the PPF and the user directory, but is too detailed for what you want to do. You want to run one quick process t o backup everything, then apply maintenance and if necessary run one proces s to restore everything. We can't quite give you that yet. But Tom Huegel has it right. A two part process, one part to backup your entire DASD subsystem (510RES, 510W01, 510W02, 510Wxx, etc). Do not backup the page or spool volumes with DDR. T he second part is to backup all of the SPOOL files using the SPXTAPE command . When you do have to restore back to this point-in-time, you can use DDR standalone to restore the DASD, then IPL and do a CLEAN NOAUTOLOG start. At this point, you can be on OPERATOR, mount the tape containing your SPXTAP E backup and use SPXTAPE LOAD to restore all the files, and then shutdown reipl to restart your restored system. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 11:33:58 -0500, Anne Crabtree [EMAIL PROTECTED] wrote: I would be applying on a first level system. I have no idea what minidi sks are affected. I've only done maintenance twice, once the long way (with IBM here and it was no picnic) and the second time where it was a complete me ss. Can I use DDRXA and just backup 510RES and 510SPL? Will that be good enough? If there are problems, can I restore both and be ok? Sorry, I guess I wasn't clear enough!
Re: backup prior to maintenance
ok thanks will try that... [EMAIL PROTECTED] 2/8/2007 11:39 AM Anne, I would use DDRXA to backup 510res, 510w01, 510w02 then use SPXTAPE to backup the spool files. Tom -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Anne Crabtree Sent: Thursday, February 08, 2007 10:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: backup prior to maintenance I would be applying on a first level system. I have no idea what minidisks are affected. I've only done maintenance twice, once the long way (with IBM here and it was no picnic) and the second time where it was a complete mess. Can I use DDRXA and just backup 510RES and 510SPL? Will that be good enough? If there are problems, can I restore both and be ok? Sorry, I guess I wasn't clear enough! [EMAIL PROTECTED] 2/8/2007 11:23 AM If you are running a second-level guest to do your maintenance in, then t= he best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from= the first level MAINT userid. Then bring up your second-level guest, appl= y and test the maintenance (shutting down and restoring as necessary). Then= migrate the good maintenance to your first-level production system. If you are applying your maintenance to minidisks on a first-level system= , then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL= or user minidisks. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] = wrote: I would like to know what the recommended procedure is for backing up th= e system prior to applying maintenance (and how to restore if there is a problem!!). The last time I did maintenance, I backed up 510RES with DDR= XA and when PUT2PROD had errors, restored 510RES from that tape. To make a long story short, it really messed up the spool and I ended up on the pho= ne for hours with IBM. I need to put maintenance on again and want to make sure and do it right this time. = == === __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: backup prior to maintenance
Anne, Just a quick FYI about SPXTAPE you want to be sure to backup the system data files, (IMG, NLS, NSS, TRFILES, and UCR)I think the option is SDF. These are the spool files you would want to restore. Tom -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Anne Crabtree Sent: Thursday, February 08, 2007 11:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: backup prior to maintenance The only backups we do are full volume backups once a week on z/os, but I want to go back to prior to maintenance if I have a problem. So, gonna try to do what Tom suggested. [EMAIL PROTECTED] 2/8/2007 12:04 PM Anne, We do our maintenance on the first level system. We rely on our daily backup process as our safety net. Since we keep backups for several months, we can go back to any prior day's image. Because we don't do maintenance every day, the MAINT disks are reasonably stable and this type of backup is, we feel, sufficient. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of StephenPFrazieVM Sent: Thursday, February 08, 2007 8:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: backup prior to maintenance Your first message was clear. The answer is still the same. If you are applying your maintenance to minidisks on a first-level system, then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL or user minidisks. [EMAIL PROTECTED] wrote: I would be applying on a first level system. I have no idea what minidisks are affected. I've only done maintenance twice, once the long way (with IBM here and it was no picnic) and the second time where it was a complete mess. Can I use DDRXA and just backup 510RES and 510SPL? Will that be good enough? If there are problems, can I restore both and be ok? Sorry, I guess I wasn't clear enough! [EMAIL PROTECTED] 2/8/2007 11:23 AM If you are running a second-level guest to do your maintenance in, then t= he best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from= the first level MAINT userid. Then bring up your second-level guest, appl= y and test the maintenance (shutting down and restoring as necessary). Then= migrate the good maintenance to your first-level production system. If you are applying your maintenance to minidisks on a first-level system= , then you need to backup the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL= or user minidisks. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] = wrote: I would like to know what the recommended procedure is for backing up th= e system prior to applying maintenance (and how to restore if there is a problem!!). The last time I did maintenance, I backed up 510RES with DDR= XA and when PUT2PROD had errors, restored 510RES from that tape. To make a long story short, it really messed up the spool and I ended up on the pho= ne for hours with IBM. I need to put maintenance on again and want to make sure and do it right this time. = == === __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: backup prior to maintenance
OK, have never used SPXTAPE so after looking at manual, is this right? SPX DUMP 181 SPOOL ALL and this will get all standard spool files and system files. [EMAIL PROTECTED] 2/8/2007 12:10 PM Don't worry about the clarity of your postings, we all need to refine our= descriptions through repetition. Okay, you are running maintenance on first-level and you do not have a CMS or minidisk level product to backup= your allocations. Figuring out what minidisks VMSES will use for any particular component is possible via the PPF and the user directory, but = is too detailed for what you want to do. You want to run one quick process t= o backup everything, then apply maintenance and if necessary run one proces= s to restore everything. We can't quite give you that yet. But Tom Huegel has it right. A two part= process, one part to backup your entire DASD subsystem (510RES, 510W01, 510W02, 510Wxx, etc). Do not backup the page or spool volumes with DDR. T= he second part is to backup all of the SPOOL files using the SPXTAPE command= . When you do have to restore back to this point-in-time, you can use DDR standalone to restore the DASD, then IPL and do a CLEAN NOAUTOLOG start. = At this point, you can be on OPERATOR, mount the tape containing your SPXTAP= E backup and use SPXTAPE LOAD to restore all the files, and then shutdown reipl to restart your restored system. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 11:33:58 -0500, Anne Crabtree [EMAIL PROTECTED] = wrote: I would be applying on a first level system. I have no idea what minidi= sks are affected. I've only done maintenance twice, once the long way (with = IBM here and it was no picnic) and the second time where it was a complete me= ss. Can I use DDRXA and just backup 510RES and 510SPL? Will that be good enough? If there are problems, can I restore both and be ok? Sorry, I guess I wasn't clear enough!
Re: backup prior to maintenance
I would use: spxtape dump 181 sdf all run See Chapter 4 Step 6 of the Guide for Automated Installation and Service (GC24-6099-03) for examples. Also Step 7 covers the system backup aspects. Regards, Kevin -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Thursday, February 08, 2007 9:57 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: backup prior to maintenance OK, have never used SPXTAPE so after looking at manual, is this right? SPX DUMP 181 SPOOL ALL and this will get all standard spool files and system files.
Re: backup prior to maintenance
Yes. When I am at risk of damaging all of spool, like restoring the sysre s volume, I backup SPOOL ALL. If I am just risking a system data file, like redefining/resaving a DCSS or NSS then I backup SDF ALL, because I don't have to restore sysres before restoring just the DCSS/NSS that got mangle d. /Tom Kern /301-903-2211 On Thu, 8 Feb 2007 12:56:38 -0500, Anne Crabtree [EMAIL PROTECTED] wrote: OK, have never used SPXTAPE so after looking at manual, is this right? SPX DUMP 181 SPOOL ALL and this will get all standard spool files and system files.
Re: backup prior to maintenance
I still use the MAINT 490/190; 493/193 as alternate disks (all products have two copies of runtime disks). Fixes land on 490/493. When I place it in production, I swap the minidisk addresses in the CP directory. When it is not OK, swap again and you're done. (I also added a 49E) But, PUT2PROD makes this impossible, it overwrites the backup copies. But, what prevents you from adding yet another copy, for example MAINT 1190 and 1193. Then you can either use my swap address technique, or use DDR to copy 190 onto 1190 etc. I've got a COPYDDR EXEC that makes copying a minidisk as easy as COPYFILE. For example COPYDDR MAINT 190 = 1190 Part of my swap address technique is also that I use the 3 Minidisk password fields in the directory as description (these passwords are not used if you've got RACF); Example MDISK 190 3390 nnn sss RR ALL ZVM520 DEC2006 Another change -that I already explained once here- is that the MDISK label on MAINT 190/490/x90 tells which CMS must be IPLed, so I've got CMS20A, CMS22B, and things alike. The other CMS segments get similary named, eg CMS20FA and CMS22FB (corresponds to CMSFILES segment). One needs a change in SYSPROF and some small program that is saved as system CMS. Your users IPL that, it reads the 190 disk label and IPLs a CMS named like that. Refer to IPLER on the VM download lib, it contains all what is required. -- Kris Buelens, IBM Belgium, VM customer support
Re: Backup
Thank you everyone for the feed back. I now have some options to study. prg Phillip Gramly Systems Programmer Communications Data Group Champaign, IL
Re: Backup
IBM has a 'Backup and Restore Manager' also an 'Archive Manager' along with 'Operations Manager' forms thier new automation suite. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 2:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup I am looking for a replacement for VM:Backup. It could be a collection of utilities. What other tools are available - both IBM supplied utilities and/or third party utilities. prg Phillip Gramly Systems Programmer Communications Data Group Champaign, IL _ ella for Spam Control has removed 9871 VSE-List messages and set aside 7444 VM-List for me You can use it too - and it's FREE! www.ellaforspam.com http://www.ellaforspam.com
Re: Backup
I am looking for a replacement for VM:Backup. It could be a collection of utilities. What other tools are available - both IBM supplied utilities and/or third party utilities. Phillip, If you are doing only CMS mini disks, I have some REXX utilities that I run in service machines that I would be willing to share. They read a control file for a list of user's to back up and create a tape file that looks something like this: MYUSER 191 A Tape mark files from MYUSER's 191 . Tape mark MYCMS 191 A Tape mark files from MYCMS's 191 . Tape mark What you can do for restore then is to VMFPLC2 SCAN MYCMS 191 (EOT And it will position the tape to the proper spot. Nothing really fancy but the price is right! Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: Backup of z/VM and z/VSE
A gotcha with z/OS DFDSS is that you cannot use the stand alone DFDSS to restore CPVOL initialized dasd. In a D/R situation, you have to have z/OS restored enough to be able to run DFDSS under it to bring back the VM system. This may be what Doug was meant when he referred to the restore considerations. Jim Doug Shupe wrote: Daniel, You can get a valid/usable backup the z/VSE guest dasd with DDR -ONLY IF- the z/VSE guest is shutdown while performing the backup. You can use z/OS DFDSS to backup the z/VM and z/VSE dasd but (IMHO) it is not a wise solution because of the restore considerations. With enough practice you could make it work. Problem is the z/VSE guest would never work correctly unless it were shutdown during the backup. You can backup the running z/VM system with DDR (minus the page and spool volumes - format the page and spool volumes, cold start the spool after recovery). You would have to re-save CMS and other DCSS or use SPXTAPE to save the information in the spool. Since you have a z/VM system, this would be a good time to try using z/VM under z/VM to validate your recovery process. If you forgot something just scrape the 2nd level system and start over. (kind of like using Changeman to maintain Changeman). Would be glad to discuss with you offline. Best Regards, Doug Shupe - Original Message - From: Daniel Allen [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Sent: Thursday, December 28, 2006 12:48 PM Subject: Backup of z/VM and z/VSE I have been given an assignment to backup our z/VM and z/VSE systems. We also run z/OS. I know about DDR. Can I backup/restore both z/VM and = z/VSE using DDR ? Can z/OS backup/restore z/VM ? -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: Backup of z/VM and z/VSE
There may be another gotcha. A year ago last June, our shop was in the middle of a migration to a new datacenter. The concept was simple: - Copy disks that were to be migrated into a bunker box - a SHARK facility equipped to synchronize data between the two centers. - Dress rehearsals to discover an fix any problems in the migration plans. These included synchronizing the data in the two centers ahead ago time and doing a final incremental sync when ready to try the migration. - Final migration. The DASD Storage Management Group, all z/OS-oriented people, scheduled time to move VM into the bunker box. In the week leading up to the move, they discovered that the utility they planned to use (and were assured by the vendor, who shall remain nameless but whose initials are IBM, that it could handle the task) would not copy the dasd used by VM. They had worked frantically with IBM trying to fix the problem. As a last-ditch effort, they were even sent another utility used internally by IBM that definitely would work. It also failed. In near panic, it was 4:45 PM on Thursday and the move was supposed to take place at 9:00 AM Saturday, they asked me if I had any suggestions that would save the schedule. The answer was to build a one-pack system on DASD that was not being migrated and use several virtual machines to DDR the disks. Task accomplished, and the copying took only half the time that had been calculated for the z/OS utility. Unless they have been fixed, the z/OS utilities may fail when working with VM DASD. I imagine that DFDSS was the first of the utilities that failed. I do not even know the name of the one cloaked in black. Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Wednesday, January 03, 2007 4:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup of z/VM and z/VSE A gotcha with z/OS DFDSS is that you cannot use the stand alone DFDSS to restore CPVOL initialized dasd. In a D/R situation, you have to have z/OS restored enough to be able to run DFDSS under it to bring back the VM system. This may be what Doug was meant when he referred to the restore considerations. Jim Doug Shupe wrote: Daniel, You can get a valid/usable backup the z/VSE guest dasd with DDR -ONLY IF- the z/VSE guest is shutdown while performing the backup. You can use z/OS DFDSS to backup the z/VM and z/VSE dasd but (IMHO) it is not a wise solution because of the restore considerations. With enough practice you could make it work. Problem is the z/VSE guest would never work correctly unless it were shutdown during the backup. You can backup the running z/VM system with DDR (minus the page and spool volumes - format the page and spool volumes, cold start the spool after recovery). You would have to re-save CMS and other DCSS or use SPXTAPE to save the information in the spool. Since you have a z/VM system, this would be a good time to try using z/VM under z/VM to validate your recovery process. If you forgot something just scrape the 2nd level system and start over. (kind of like using Changeman to maintain Changeman). Would be glad to discuss with you offline. Best Regards, Doug Shupe - Original Message - From: Daniel Allen [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Sent: Thursday, December 28, 2006 12:48 PM Subject: Backup of z/VM and z/VSE I have been given an assignment to backup our z/VM and z/VSE systems. We also run z/OS. I know about DDR. Can I backup/restore both z/VM and = z/VSE using DDR ? Can z/OS backup/restore z/VM ? -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: Backup of z/VM and z/VSE
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, January 03, 2007 11:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup of z/VM and z/VSE There may be another gotcha. A year ago last June, our shop was in the middle of a migration to a new datacenter. The concept was simple: - Copy disks that were to be migrated into a bunker box - a SHARK facility equipped to synchronize data between the two centers. - Dress rehearsals to discover an fix any problems in the migration plans. These included synchronizing the data in the two centers ahead ago time and doing a final incremental sync when ready to try the migration. - Final migration. The DASD Storage Management Group, all z/OS-oriented people, scheduled time to move VM into the bunker box. In the week leading up to the move, they discovered that the utility they planned to use (and were assured by the vendor, who shall remain nameless but whose initials are IBM, that it could handle the task) would not copy the dasd used by VM. They had worked frantically with IBM trying to fix the problem. As a last-ditch effort, they were even sent another utility used internally by IBM that definitely would work. It also failed. In near panic, it was 4:45 PM on Thursday and the move was supposed to take place at 9:00 AM Saturday, they asked me if I had any suggestions that would save the schedule. The answer was to build a one-pack system on DASD that was not being migrated and use several virtual machines to DDR the disks. Task accomplished, and the copying took only half the time that had been calculated for the z/OS utility. Unless they have been fixed, the z/OS utilities may fail when working with VM DASD. I imagine that DFDSS was the first of the utilities that failed. I do not even know the name of the one cloaked in black. Richard Schuh That is very strange. I have successfully dumped and restored z/VM DASD using DFDSS on z/OS 1.6. The z/VM system was down at the time. Oh, but this was via TAPE, not disk-to-disk. That may be the difference. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Backup of z/VM and z/VSE
That is strange, because I've used DFDSS to restore z/VM dasd. That was where I discovered the sentence in the DFDSS manual that says that you can't use the S/A version. Our D/R backups here are done with Shark flashcopy and then ADRDSSU to dump from the flashed target to tape. I have restored dumped tapes to DASD and have been able to IPL the restored volume. Jim McKown, John wrote: -Original Message- From: The IBM z/VM Operating System=20 [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, January 03, 2007 11:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup of z/VM and z/VSE =20 =20 There may be another gotcha. A year ago last June, our shop was in the middle of a migration to a new datacenter. The concept was simple: =20 - Copy disks that were to be migrated into a bunker box - a SHARK facility equipped to synchronize data between the two centers. - Dress rehearsals to discover an fix any problems in the migration plans. These included synchronizing the data in the two centers ahead ago time and doing a final incremental sync when ready to try the migration. - Final migration. =20 The DASD Storage Management Group, all z/OS-oriented people, scheduled time to move VM into the bunker box. In the week leading up=20 to the move, they discovered that the utility they planned to use (and were assured by the vendor, who shall remain nameless but whose initials are IBM, that it could handle the task) would not copy the dasd used=20 by VM. They had worked frantically with IBM trying to fix the problem. As a last-ditch effort, they were even sent another utility used internally by IBM that definitely would work. It also failed. In near panic, it was 4:45 PM on Thursday and the move was supposed to take=20 place at 9:00 AM Saturday, they asked me if I had any suggestions that=20 would save the schedule. The answer was to build a one-pack system on DASD=20 that was not being migrated and use several virtual machines to DDR the disks. Task accomplished, and the copying took only half the time that had been calculated for the z/OS utility. =20 Unless they have been fixed, the z/OS utilities may fail when working with VM DASD. I imagine that DFDSS was the first of the utilities that failed. I do not even know the name of the one cloaked in black.=20 =20 =20 Richard Schuh=20 That is very strange. I have successfully dumped and restored z/VM DASD using DFDSS on z/OS 1.6. The z/VM system was down at the time. Oh, but this was via TAPE, not disk-to-disk. That may be the difference. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.=20 -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: Backup of z/VM and z/VSE
It may be a failure in the disk to disk path. Also, our dasd farm has been growing around us for years, some 15 years before I arrived on the scene and nearly another nine since. There is no telling how some of the disks may have been initialized. I am sure that some were inherited from our other mainframe operating systems, both MVS and derivatives and TPF. Some may even have been formatted as CMS disks. It may be a device label or VTOC problem. I know that there were problems with VTOCs early in the days of ACP. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, January 03, 2007 9:56 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup of z/VM and z/VSE -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, January 03, 2007 11:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup of z/VM and z/VSE There may be another gotcha. A year ago last June, our shop was in the middle of a migration to a new datacenter. The concept was simple: - Copy disks that were to be migrated into a bunker box - a SHARK facility equipped to synchronize data between the two centers. - Dress rehearsals to discover an fix any problems in the migration plans. These included synchronizing the data in the two centers ahead ago time and doing a final incremental sync when ready to try the migration. - Final migration. The DASD Storage Management Group, all z/OS-oriented people, scheduled time to move VM into the bunker box. In the week leading up to the move, they discovered that the utility they planned to use (and were assured by the vendor, who shall remain nameless but whose initials are IBM, that it could handle the task) would not copy the dasd used by VM. They had worked frantically with IBM trying to fix the problem. As a last-ditch effort, they were even sent another utility used internally by IBM that definitely would work. It also failed. In near panic, it was 4:45 PM on Thursday and the move was supposed to take place at 9:00 AM Saturday, they asked me if I had any suggestions that would save the schedule. The answer was to build a one-pack system on DASD that was not being migrated and use several virtual machines to DDR the disks. Task accomplished, and the copying took only half the time that had been calculated for the z/OS utility. Unless they have been fixed, the z/OS utilities may fail when working with VM DASD. I imagine that DFDSS was the first of the utilities that failed. I do not even know the name of the one cloaked in black. Richard Schuh That is very strange. I have successfully dumped and restored z/VM DASD using DFDSS on z/OS 1.6. The z/VM system was down at the time. Oh, but this was via TAPE, not disk-to-disk. That may be the difference. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Backup of z/VM and z/VSE
Daniel, You can get a valid/usable backup the z/VSE guest dasd with DDR -ONLY IF- the z/VSE guest is shutdown while performing the backup. You can use z/OS DFDSS to backup the z/VM and z/VSE dasd but (IMHO) it is not a wise solution because of the restore considerations. With enough practice you could make it work. Problem is the z/VSE guest would never work correctly unless it were shutdown during the backup. You can backup the running z/VM system with DDR (minus the page and spool volumes - format the page and spool volumes, cold start the spool after recovery). You would have to re-save CMS and other DCSS or use SPXTAPE to save the information in the spool. Since you have a z/VM system, this would be a good time to try using z/VM under z/VM to validate your recovery process. If you forgot something just scrape the 2nd level system and start over. (kind of like using Changeman to maintain Changeman). Would be glad to discuss with you offline. Best Regards, Doug Shupe - Original Message - From: Daniel Allen [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Sent: Thursday, December 28, 2006 12:48 PM Subject: Backup of z/VM and z/VSE I have been given an assignment to backup our z/VM and z/VSE systems. We also run z/OS. I know about DDR. Can I backup/restore both z/VM and = z/VSE using DDR ? Can z/OS backup/restore z/VM ?
Re: Backup of z/VM and z/VSE
I would beg to differ w/ this you can recover any component of a backed up running VSE system how many system crashes are planned ? w/ op system down ? what good is a DR plan if you can only restore from a planned outage ? VSE utilities should also be used as fallback , such as power off-loads, fcopy etc. Doug Shupe [EMAIL PROTECTED] .net To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Backup of z/VM and z/VSE 01/01/2007 10:25 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Daniel, You can get a valid/usable backup the z/VSE guest dasd with DDR -ONLY IF- the z/VSE guest is shutdown while performing the backup. You can use z/OS DFDSS to backup the z/VM and z/VSE dasd but (IMHO) it is not a wise solution because of the restore considerations. With enough practice you could make it work. Problem is the z/VSE guest would never work correctly unless it were shutdown during the backup. You can backup the running z/VM system with DDR (minus the page and spool volumes - format the page and spool volumes, cold start the spool after recovery). You would have to re-save CMS and other DCSS or use SPXTAPE to save the information in the spool. Since you have a z/VM system, this would be a good time to try using z/VM under z/VM to validate your recovery process. If you forgot something just scrape the 2nd level system and start over. (kind of like using Changeman to maintain Changeman). Would be glad to discuss with you offline. Best Regards, Doug Shupe - Original Message - From: Daniel Allen [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Sent: Thursday, December 28, 2006 12:48 PM Subject: Backup of z/VM and z/VSE I have been given an assignment to backup our z/VM and z/VSE systems. We also run z/OS. I know about DDR. Can I backup/restore both z/VM and = z/VSE using DDR ? Can z/OS backup/restore z/VM ?
Re: Backup of z/VM and z/VSE
I hope you understand that backing up a running z/VM system may not yield a relyable backup: if a CMS minidisk is being updated while you back it up (using DDR or FDR) it is possible that after a restore the minidisk cannot be ACCESSed anymore. Kris, IBM Belgium, VM customer support Stracka, James (GTI) [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 2006-12-28 18:59 Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Backup of z/VM and z/VSE FDR does a very good job of backup/restore of z/VM DASD. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Thursday, December 28, 2006 12:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup of z/VM and z/VSE I have been given an assignment to backup our z/VM and z/VSE systems. We also run z/OS. I know about DDR. Can I backup/restore both z/VM and z/VSE using DDR ? Can z/OS backup/restore z/VM ? If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: Backup of z/VM and z/VSE
Yes, DDR or FDR or ADRDSSU can do Disaster Backups of your z/VM, z/VSE or z/OS DASD. There are two catches with this. These Disaster backups do not work well for dynamic data such as SPOOL, Shared File Systems, Databases, Linux filesystems. You must make sure that these dynamic areas are not being updated. I always do separate backups of the SPOOL and SFS data. Database s and Linuxes should be logged off for data consistency. The second catch i s that DDR, FDR ADRDSSU backups of z/VM data are not for file level restores. Not knowing enough about the VTOC requirements, I am unwilling to try a track level restore of z/OS or z/VSE datasets. /Tom Kern /301-903-2211 On Thu, 28 Dec 2006 11:48:00 -0600, Daniel Allen [EMAIL PROTECTED] wrot e: I have been given an assignment to backup our z/VM and z/VSE systems. We also run z/OS. I know about DDR. Can I backup/restore both z/VM and z/VSE using DDR ? Can z/OS backup/restore z/VM ? = ===
Re: Backup of z/VM and z/VSE
That said (backing up a running z/VM system may not yield a reliable backup), for probably a decade or so our MVS system took FDR backups of our running VM system before we were permitted to use VM:Backup (which was backing up our CMS files) for D.R. backups. In those dozen-or-so years we never failed to be able to restore the system at the D.R. site using FDR restore. We did SPTAPE (before SPXTAPE was available) backups for the SDFs (but not user SPOOL files which were proclaimed transitory). Now... that said, CMS file systems are different beasts than Linux file systems. CMS did not cache at that time, while Linux file systems seem to (if I understand them correctly) really love to cache for a while before committing to disk. If you want reliable VM, VSE and Linux guest backups, as Kris said, ensure that no changes are being made while MVS backs them up. That's tough to do without shutting down the systems. An alternative is to use a backup system that is actually running on those systems, which is aware of the file systems they use and take them into consideration. That also permits you, if you choose that form of backup, to restore individual files. Unless the systems shutdown are SPOOL systems generally require system-specific utility commands/programs. H backup alternatives, their pros and cons would make a pretty good session at SHARE and other user group meetings, no? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Kris Buelens [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/28/2006 12:23 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Backup of z/VM and z/VSE I hope you understand that backing up a running z/VM system may not yield a relyable backup: if a CMS minidisk is being updated while you back it up (using DDR or FDR) it is possible that after a restore the minidisk cannot be ACCESSed anymore. Kris, IBM Belgium, VM customer support Stracka, James (GTI) [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 2006-12-28 18:59 Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Backup of z/VM and z/VSE FDR does a very good job of backup/restore of z/VM DASD. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Thursday, December 28, 2006 12:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Backup of z/VM and z/VSE I have been given an assignment to backup our z/VM and z/VSE systems. We also run z/OS. I know about DDR. Can I backup/restore both z/VM and z/VSE using DDR ? Can z/OS backup/restore z/VM ? If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: Backup of z/VM and z/VSE
Rick Barlow used to do a very good DR presentation at SHARE showing VM:Backup and VM:Backup HiDRo in all there best. Bill Munson IT Specialist Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Mike Walter wrote: H backup alternatives, their pros and cons would make a pretty good session at SHARE and other user group meetings, no? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates.
Re: Backup of z/VM and z/VSE
I have been given an assignment to backup our z/VM and z/VSE systems. We also run z/OS. I know about DDR. Can I backup/restore both z/VM and z/VSE using DDR ? DDR is OS-agnostic. If it's got bits in the standard formats, DDR can dump and restore it. You do need to be cautious about dumping running systems; spool, warmstart, checkpoint areas will tend not to be consistent, and require a little repair after restores. It's also wise to ensure that you have a SPXTAPE dump of your spool files and NSS files. Can z/OS backup/restore z/VM ? ADRDSSU can (it's roughly analogous to DDR). Same caveats apply.
Re: Backup of z/VM and z/VSE
H backup alternatives, their pros and cons would make a pretty good session at SHARE and other user group meetings, no? Already scheduled for WAVV, with a preview at the next Hillgang. 8-)
