Re: ISPF/PDF CMS MACLIB - Maintenance
We do have a home-grown utility that does this sort of thing for us, and it's how we normally update files on heavily-accessed resources. Unfortunately, the users would indeed have to re-access the disk...which, to them, will abort whatever they are doing (with unpredictable results) and, since they are mostly not VM-savvy, logging off and logging back on. Frankly, if all goes well, this old library system will be de-activated within a month, so this maintenance issue of the past 15 years is now of relatively low priority. What I'd REALLY like to know, as I've mentioned, is if read-only access to an ISPF/PDF MACLIB-based application and functionality (sans updates) can be achieved. Even though the old app is being supplanted, users will still wish to access pieces of it for historical reference. We simply want the MACLIB permanently frozen, but read-accessible via these local ISPF/PDF routines. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of A. Harry Williams Sent: Tuesday, August 18, 2009 7:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Tue, 18 Aug 2009 10:24:59 -0700 Llewellyn, Mark said: Dale, The MACLIB is maintained by a service machine which copies it to a large TEMP disk, compresses it, then copies it back to the prod disk. The copy FROM the prod disk always seems to be ok. The copy of the compressed MACLIB back to the prod disk seems to be where it can get hit. Users can access this old app anytime they want - we can break the links, which would cause them some grief, but a link could be established during this process. A related question is whether an ISPF/PDF-based application can be placed in a read-only mode. When this old app is retired, users are still going to want to reference it for historical reasons. We don't want them to be able to update it in any way at that point. If a read-only mode is possible, that could solve the compress issue as well. Not sure how the MW issues impact this, but how about on the copy back to the prod disk, you do a COPY to a different name, rename the uncompressed file, and then rename the compressed file to the correct name? Something like COPY PROD MACLIB P = = T compress the file COPY PROD MACLIB T = NEW P RENAME PROD MACLIB P = OLD P (NOUP RENAME PROD NEW P = MACLIB P all the users probably have to reaccess the disk, and that scares me. You'll need to test this idea. /ahw -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how dead things like to= stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. = - Kurt Vonnegut= = On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com = wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application = that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary,= I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this = maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being = updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a = better way of regulating the size of the maclib if possible. This is ou= r only ISPF/PDF application, and the folks who designed it are years gone = from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o= n the fly? If not, is there a safe way to ask ISPF to suspend all update = activity while the backup/compress is occurring, then resume when the = maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. 3D= = 3D= ===
Re: ISPF/PDF CMS MACLIB - Maintenance
Dale, The MACLIB is maintained by a service machine which copies it to a large TEMP disk, compresses it, then copies it back to the prod disk. The copy FROM the prod disk always seems to be ok. The copy of the compressed MACLIB back to the prod disk seems to be where it can get hit. Users can access this old app anytime they want - we can break the links, which would cause them some grief, but a link could be established during this process. A related question is whether an ISPF/PDF-based application can be placed in a read-only mode. When this old app is retired, users are still going to want to reference it for historical reasons. We don't want them to be able to update it in any way at that point. If a read-only mode is possible, that could solve the compress issue as well. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how dead things like to= stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. = - Kurt Vonnegut= = On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com = wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application = that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary,= I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this = maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being = updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a = better way of regulating the size of the maclib if possible. This is ou= r only ISPF/PDF application, and the folks who designed it are years gone = from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o= n the fly? If not, is there a safe way to ask ISPF to suspend all update = activity while the backup/compress is occurring, then resume when the = maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. = == ===
Re: ISPF/PDF CMS MACLIB - Maintenance
The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. ---Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 2:52 PM, Schuh, Richardrsc...@visa.com wrote: Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. How is simultaneous use of a library controlled? If I edit member A, does that lock it? If so, could the update process edit every member, do the update, then quit every member?
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Marcy, What is your network configuration like? Do you know what type of network hardware has been in place for the channel extension? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit FWIW, backing up about 360G of disk on the smaller system of our 2 traditional VM/CMS systems with HIDRO (uses 4 tapes, 2000 miles) takes a little less that 10 hours. The network is being beefed up. Then we will do full XRC mirroring instead (or too?). The restores are faster with HIDRO as well. Since we do monthly disaster tests, fast is good... (JR and Fran will tell you that too :) I figure too that using both vmbackup and hidro is some protection against sw bugs too that might corrupt both the primary and the secondary at the same time. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Thursday, June 05, 2008 2:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit That's another option I'll add to the list. The remote site is disaster-recovery only - it doesn't necessarily have to be pretty right off the bat. I'll have to figure out how it knows which tapes to call for where - it'll be a few months before we start real testing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- 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. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
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: VM:Backup: Twinning Tapes to Remote Tape Unit
Same here - we are operating on the scenario of our primary data center being destroyed and not coming back. If the offsite copy is a few hours older than the onsite, it's not a show-stopper. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 7:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit No one has told us that the two backup runs have to be the same. The DR backups are only used if the primary data center is a pile of rubble. Who cares if they're a few hours older or newer than a set of tapes that is now unusable, and may be irrecoverable? The disaster time is unpredictable. The backup tapes may be 2 hours old or 22 hours old. In either case, the users get what they get. We don't make backups when most of the users are doing their work, but beyond that, it really doesn't matter when they're made. The other advantage of separate onsite and offsite backup jobs is that your onsite backups aren't held up when your channel extension equipment is down. I'm certainly not advocating BLP. I was just pointing out one of the issues with a tape copy solution. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 18:24 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit This concept was considered, but is really last on the list - it's a bit of a mine field. Running two VM:Backup service machines has potential, though, instead of running two backups serially on the same machine. And how...there be dragons, big time. Two VM:Backup runs (even simultaneous runs) have a high probability of being different enough to drive auditors berserk. The system isn't the same as it was with the first set, and you can't stand up and give evidence that the two backups contain the same data, particularly if the system is live during the backup runs. Also, anything that uses BLP tape options is pretty much automatically suspect (and your tape librarians are probably going to get hostile as well -- things like that tend to mess with their worldview of having One True Identifier That Is Immutable In the Whole Enterprise).
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
That would be by far the easiest way, but VM:Backup is not able to handle copied tapes at a BRP site - it's catalog wouldn't match. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- 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. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
What you say is so true. However, even a 50% increase in time may not be a show-stopper for our shop, as opposed to running two complete backup jobs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 1:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit 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. This approach lives and dies on the speed of the link to the remote drives. I ran this configuration a long time ago with parallel channel extenders to an offsite 3490 and it worked OK with a dedicated DS3 between the channel extenders. With modern drives, the bandwidth requirements will probably be higher. The time to get the write completed to the remote drive was measurable, however, and the backup time did increase by about 15-20%. Didn't matter much for that site (it was less than 100 3370s), but that might screw you for modern large disk.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
This concept was considered, but is really last on the list - it's a bit of a mine field. Running two VM:Backup service machines has potential, though, instead of running two backups serially on the same machine. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- 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. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
This solution is our real hope. I believe we'll have dedicated bandwidth - our network guys are working on that one. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 1:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit What you say is so true. However, even a 50% increase in time may not be a show-stopper for our shop, as opposed to running two complete backup jobs. YMMV. Also, keep in mind that you'll probably need to mess with the MIH time values for class TAPE devices to compensate for the additional delay. You really, really want dedicated bandwidth for this if its in any way possible. Variable delays tend to make channel extenders cranky. Once we got that worked out and the proper expectations set and managed, it's a pretty slick setup.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
You have a pretty slick setup. We back up about 200G or less for a full backup, and 2 to 10G for our daily incremental. The kicker is the 3000 mile channel extension...coast-to-coast. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Thursday, June 05, 2008 1:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We have (forever) backed up using VM:Backup twins - reading disk once, writing concurrently to separate backup tapes about 3 miles apart (each with it's own volser). We do full file-level backups and critical system DASD physical-backups each Saturday to three 3590 drives in each data center (six spinning MagStar tapes). Over the past few weeks, each Saturday we've backed up about 350G-500G in 5.5-6.25 hours from an VM:Backup running on an olde z800. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Llewellyn, Mark [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/05/2008 03:44 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VM:Backup: Twinning Tapes to Remote Tape Unit That would be by far the easiest way, but VM:Backup is not able to handle copied tapes at a BRP site - it's catalog wouldn't match. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- 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. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post 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: VM:Backup: Twinning Tapes to Remote Tape Unit
That's another option I'll add to the list. The remote site is disaster-recovery only - it doesn't necessarily have to be pretty right off the bat. I'll have to figure out how it knows which tapes to call for where - it'll be a few months before we start real testing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- 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. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
This sounds like the optimal approach, really. Thanks! -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit FWIW, backing up about 360G of disk on the smaller system of our 2 traditional VM/CMS systems with HIDRO (uses 4 tapes, 2000 miles) takes a little less that 10 hours. The network is being beefed up. Then we will do full XRC mirroring instead (or too?). The restores are faster with HIDRO as well. Since we do monthly disaster tests, fast is good... (JR and Fran will tell you that too :) I figure too that using both vmbackup and hidro is some protection against sw bugs too that might corrupt both the primary and the secondary at the same time. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Thursday, June 05, 2008 2:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit That's another option I'll add to the list. The remote site is disaster-recovery only - it doesn't necessarily have to be pretty right off the bat. I'll have to figure out how it knows which tapes to call for where - it'll be a few months before we start real testing. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, June 05, 2008 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We run VM:Backup to local tapes and HIDRO to remote tapes. HIDRO is much faster and doesn't chew the CPU the way VM:Backup does. But the users are used to getting their stuff out of the much prettier vmbackup interface. If you twin remotely and locally, how does the restores work? Do you have to code to just use the local drives for that? Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit If you do a tape-to-tape copy, make sure your local and remote tape volsers match. VM:Backup has the tape volsers in its catalog. If you don't have the correct volsers at your remote site, you have a problem. You could probably get away with different volsers if you code VM:Backup's tape mount user exit to translate the local volser to the remote volser. VM:Backup will probably want to check the tape label, so you'll need to make sure that was copied as part of your tape copy. You'll need to mount the tapes with BLP at the remote site if you do this. Note: I haven't tested any of this. We run a separate backup job, from a separate VM:Backup service machine, for our DR backups. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Thursday, June 05, 2008 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:12 PM, in message [EMAIL PROTECTED], Mark Llewellyn [EMAIL PROTECTED] wrote: -snip- 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. Not if you do the backup to local tape drives, and then do a tape-to-tape copy to the remote drives. Mark Post
Re: Impromptu XEDIT Survey
While my session, like a well-carved halibut fillet, shall have no scale (it's toggled by a PF key when needed), it's good to see others employing the convenience of SET WRAP ON. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bob Levad Sent: Wednesday, February 20, 2008 12:36 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Impromptu XEDIT Survey 'SET CMDLINE TOP' 'SET PREFIX NULLS LEFT' 'SET NUMBER ON' 'SET SCALE ON 3' 'SET CURLINE ON 4' 'SET ENTER IGNORE COMMAND CURSOR HOME PRIORITY 30' 'SET MSGLINE ON -1 10 OVERLAY' 'SET FULLREAD ON' 'SET SPILL WORD' 'SET TOFEOF ON' 'SET STAY ON' 'SET WRAP ON' This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.
Re: Any Rumors?
According to Dr. Seuss, the final authority on all matters virtual (in his epic tome, On Beyond Zebra), the letters after Z are: Yuzz, Wum, Um, Humpf, Fuddle, Glikk, Nuh, Snee, Quan, Thnad, Spazz, Floob, Zatz, Jogg, Flunn, Itch, Yekk, Vroom, and Hi. Therefore, expect to see the shiny new yuzz/1 in a showroom near you soon. Mark Llewellyn Visa, Inc.
Re: Realy simple pipe insert ?
Assuming there aren't any compound versions of APPLES in the input file (like SNAPPLES): 'PIPE INPUT FILE A | change /APPLES/ORANGES APPLES/ | NEW FILE A' Mark Llewellyn VISA USA From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Tuesday, March 06, 2007 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Realy simple pipe insert ? Marty, Yes I want to pass the entire file to 'new file a' and insert ORANGES before APPLES. Thanks -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Marty Zimelis Sent: Tuesday, March 06, 2007 11:41 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Realy simple pipe insert ? I'm guessing you didn't give us the full request. I assume that records without the string APPLES pass unchanged. Records with the string APPLES: do you want to replace the string or the entire record with ORANGES? Or do you want to insert a new record (ORANGES)? If an insert, before or after the record with APPLES? Marty Martin Zimelis Principal maz/Consultancy From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Tuesday, March 06, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Realy simple pipe insert ? I want to do a simple insert of a record into the stream. pipe test file a | locate /APPLES/ | here I want to insert a literal ORANGES | new file a
Re: Realy simple pipe insert ?
PIPE literal D'oh! | console From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, March 06, 2007 10:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Realy simple pipe insert ? You've all fallen for it! It is a well known fact that you cannot mix APPLES and ORANGES. Won't work. Even PIPES can't do it! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Tuesday, March 06, 2007 12:03 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Realy simple pipe insert ? Assuming there aren't any compound versions of APPLES in the input file (like SNAPPLES): 'PIPE INPUT FILE A | change /APPLES/ORANGES APPLES/ | NEW FILE A' Mark Llewellyn VISA USA From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Tuesday, March 06, 2007 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Realy simple pipe insert ? Marty, Yes I want to pass the entire file to 'new file a' and insert ORANGES before APPLES. Thanks -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Marty Zimelis Sent: Tuesday, March 06, 2007 11:41 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Realy simple pipe insert ? I'm guessing you didn't give us the full request. I assume that records without the string APPLES pass unchanged. Records with the string APPLES: do you want to replace the string or the entire record with ORANGES? Or do you want to insert a new record (ORANGES)? If an insert, before or after the record with APPLES? Marty Martin Zimelis Principal maz/Consultancy From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Tuesday, March 06, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Realy simple pipe insert ? I want to do a simple insert of a record into the stream. pipe test file a | locate /APPLES/ | here I want to insert a literal ORANGES | new file a
