Re: VM directory entry for shared DASD
Unsurprisingly, it looks as if I need to clarify a little ... Tom's not happy with, assuming R/R support for Reloc 0 Minidisks. My take here is that CP is not unilaterally adding any R/R activity - if the disk at Reloc 0 is a VSE minidisk and VSE doesn't issue any R/R then CP won't either - but if VSE DOES, feel the need then the R/R will be honoured by CP and protection from other systems running in other images will be provided - just as it would be in the, Real World. This being the case, I don't see how with R/R propagation at the, real level we're significantly worse off than we are today - if VSE doesn't do it then CP doesn't do it - if VSE DOES do it then it gets the protection it's asking for instead of a weak subset of what it's expecting. There IS a new impac t (in terms of responsiveness) for users of other minidisks that share the real volume - but I would far rather manage the impact of coping with the consequences of, safe behaviour than manage the impact of coping with the consequences of a data corruption caused by CP's failure to fully honour a request from a guest asking for short-term exclusive use of a minidisk. (I contend that the CPU overhead of checking for the need to drive R/R support is not worthy of consideration - we are talking a few tens of instructions increase in the normal pathlength at most and - to my mind - the benefit of consistent behaviour far outweighs the cost of these few instructions.) Richard's appears to be unhappy with me suggesting that XLINK has a part to play here. I think that Rob's response should have settled these concerns but, just to make sure, a reminder that XLINK extends the protection against, unintentional multi-write access that one gets on a single system to cover multiple systems sharing a single real volume. It does this via a, Compare-and-Swap mechanism on a cylinder-map that resides on the real volume and it requires no additional hardware or (onc e set up) support process. Again, as it's intrinsically dangerous to have multiple CP images sharing minidisks on a real volume without the protection of XLINK, and XLINK is part of the base system, why on Earth would anyone wish to operate a production system without it? That being the case, it seems natural to me to deliver real R/R in support of any virtual R/R issued by a guest to any minidisk with a, V in the MDISK statement (or starts at Cylinder 0) that's on a real volume under the control of XLINK. In the vast majority of cases the non-reloc-0 minidisks will be CMS minidisks and (because CMS doesn't use R/R) there will not be any reason to code the, V anyway - but having the support in CP gives u s the CAPABILITY (which we don't currently have) should we wish to make use of it for - say - a VSE LOCKFILE residence minidisk. (At least nobody's yet taking me to task for suggesting that volumes unde r XLINK control should default to SHARED when ATTACHED to SYSTEM! grin) Hopefully I've been able to make my points somewhat more clearly this tim e around. Tom and Richard - through your comments, thanks for giving me the opportunity to do so. Regards Jeff
Re: Saving a backup copy of NSSs with no tape drive
David Boyes [EMAIL PROTECTED] wrote: Related idea: I think a very useful addition/requirement to SPXTAPE would be to add a (STREAM option to SPXTAPE that presented the data as a CP IUCV service or accepted an IUCV connection to a service and wrote that data to spool. One could then connect a simple pipeline to the IUCV service and write to tape/disk/network socket/whatever the pipeline wanted to do with the output. The metadata for the spool file could easily be added to the stream (similar to the method used by DISK DUMP or CARD DUMP) and read on restore. Hmm...well, it wouldn't be (STREAM since it's a CP command, and CP commands don't use parens for options. But it seems ironic to suggest backing up spool files to spool; I think it would be simpler to do what V/SEG-PLUS does, and back them up (really just copy spool data pages) to virtual memory -- then the data could be written wherever you'd like. ...phsiii
Re: Saving a backup copy of NSSs with no tape drive
Wouldn't it be much simpler to just change SPXTAPE to work with SPOL-format disk volumes in addition to tapes? Then you could backup to dasd and then DDR to tape at your convenience. Or, just add the volume to the CP-owned list and it's a miracle: the spool files are on it are now in the system. Oh, and get SPXTAPE to support virtual input/output devices so you could use minidisks. All of your existing image-backup functions would work against spool files without having to use SPXTAPE-to-tape and you wouldn't have to worry about copying the live packs or having mindisk overlays of spool volumes. (It even enables us to have the system *prevent* a minidisk overlay.) It'd be a lot simpler and smarter long term to get SPXTAPE out of the business of doing direct device I/O entirely. That's a function that is trivially manageable in userspace; doesn't need to be in CP, and just complicates the maintenance of the service over time. See earlier suggestion wrt a system service, and then just connect the output of the pipeline (ex SPDUMP STREAM ALL | TAP1 or SPDUMP STREAM ALL | fn ft fm, etc. Restores could look like PIPE fn ft fm | SPREST STREAM All the selection and spool management code in SPXTAPE would be salvageable from the current implementation; you'd need a userspace exec to connect up the pipelines and the implementation of the IUCV service to present the data. No future mods for new device types, and a lot less testing needed. For high-tech backups, I'd tweak the *SPL system service to work with SDFs such that the guest would be notified when there's a new SDF, just like it's notified of new spool files that have specific DEST values. It could then read the SDF using the same mechanisms and do whatever it wanted. All of the spool metadata would be available. This infrastructure let's you perform immediate archives whenever something changes (e.g. an updated DCSS) rather than waiting for the nightly backup. Naturally a new WRITE function would be needed to allow the SDF to be restored. Interesting, but orthogonal to the problem, I think. I think that'd be a 2nd order gadget, once you've fixed the more basic problem of SPXTAPE having to deal directly with devices.
Re: Saving a backup copy of NSSs with no tape drive
That would solve the problem of using the VTAPE product from VSSI as the mechanism for reading and writing SPXTAPE files. There would be no need for vendor defined modifications to CP to accomplish the feat. I am for that (and I expect the folks at VSSI would welcome it too). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Rob van der Heij Sent: Friday, September 08, 2006 1:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Saving a backup copy of NSSs with no tape drive On 9/8/06, Jim Bohnsack [EMAIL PROTECTED] wrote: The other problem with DCSSBKUP and DCSSRSAV is that the DCSS creation time stamp is not restored. That and not being able to handle NSS's has put those two programs on a really far, back burner for me. It shouldn't be rocket science for IBM to come up with a DCSS/NSS copy to/from disk with time stamp retention, I wouldn't think. While we're at it, let's wish for a generic spool file back/restore so you can also do TRF files and what have you. Some time ago I think we talked about the benefits of generic emulated devices where a virtual machine does the emulation (FUSE, as Linux calls that). If you could direct SPXTAPE to an emulated tape device, the virtual machine could keep an index of saved files, issue commands to backup new files, capture the data on a disk file. Rob
Re: Saving a backup copy of NSSs with no tape drive
Well, to take that one step farther In the VSE world, they have VSE Virtual Tape. Can go to a VSE supported VSAM file or via IP to a JAVA platform (such as our PC). So, IBM does have the code, just the wrong group. CA has a virtual tape function for VM which is used for product distribution and maintenance. So, apparently, it wasn't too hard to do it under VM. So, we just need to combine the code from VSE, with the knowledge of how to do it under VM, and we can get rid of many of the requirements to modify a command to support a disk file also. But then, bringing up VSSI I wonder if there is some hesitation in IBM providing a free feature that wipes out a venders chargable product? Tom Duerbusch THD Consulting [EMAIL PROTECTED] 9/8/2006 10:58 AM That would solve the problem of using the VTAPE product from VSSI as the mechanism for reading and writing SPXTAPE files. There would be no need for vendor defined modifications to CP to accomplish the feat. I am for that (and I expect the folks at VSSI would welcome it too). Regards, Richard Schuh
Re: Saving a backup copy of NSSs with no tape drive
On 9/9/06, Thomas Kern [EMAIL PROTECTED] wrote: If you programmed the server to properly, it could keep N copies of older SDF files. N would of course be specified in the server's configuration file. You might also want to program in some exceptions. Sure :-) But for some reason those things need to go wrong first. You probably would not want to keep N copies of each NSS if that spans a long period of time. Let alone these huge DCSS files you have for Linux doing XIP. And if your coworker saves the wrong CMS 5 times you would not want to be left with just 5 backups of that. So you want a mix of the two. Having that nightly backup is not so bad at all because that probably also means that you still have the backup the entire day to recover. And in the unlikely event of a failure you'd have change management help you determine which needs to be redone. I think we used save the NSS files on the monday after a weekend with segment changes, and keep a few copies of those tapes. Rob
Re: Saving a backup copy of NSSs with no tape drive
What Tom suggests is exactly what CA V/Seg-Plus is configurable to do ... keep N copies by name, type, or any individual combination of both. 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 Thomas Kern Sent: Friday, September 08, 2006 06:57 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Saving a backup copy of NSSs with no tape drive If you programmed the server to properly, it could keep N copies of older SDF files. N would of course be specified in the server's configuration file. You might also want to program in some exceptions. /Tom Kern --- Rob van der Heij [EMAIL PROTECTED] wrote: On 9/8/06, Alan Altmark [EMAIL PROTECTED] wrote: For high-tech backups, I'd tweak the *SPL system service to work with SDFs such that the guest would be notified when there's a new SDF, just like it's notified of new spool files that have specific DEST values. It could then read the SDF using the same mechanisms and do whatever it wanted. All Not too fast... such a high tech backup only helps for hardware failure but not for the one between keyboard and chair. By the time you realize you just replaced the wrong NSS, the high-tech backup would already have replaced the old copy ;-) This brings back old memories... Back in the dark ages, we had some tooling in the startup of the system that would print a hardcopy UCB List which included the list of volumes we had online. After the weekend that hardcopy would be archived in some binder in the Operations area. It was rarely used, until I got paged for missing user volumes after IPL. So I asked them to find the missing volumes in the UCB list to understand which device ranges were missing. The process had been modernized already: the list got shipped to MVS and was kept online with all other documentation. After a few minutes the operator decided it was false alert since the volumes were not in his list. And his list was recent enough, made just 30 minutes before... and automatically replaced the only copy of the volumes at the previous IPL. Rob __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Saving a backup copy of NSSs with no tape drive
On: Thu, Sep 07, 2006 at 03:18:00PM -0500,Ed Zell Wrote: } Is there any way to copy/save/backup the system data } files (NSSs etc.) in the spool without a tape drive? } } Do a HELP on } } DCSSBKUP and DCSSRSAV } } and I think this will do what you want. Good luck Thats what I was about to suggest, but since Ed has beaten me to it, let me add that DCSSBKUP can not be used for IPLable NSS's. The only such NSS's you are likely to have are CMS GCS, and its easy enough to regen those if need be. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines:Val, Red Shasta (RIP),Red, Zero Casey, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L
Re: Applying PTFs to Z/VM 5.1
Ranga, The VPTF file contains the actual tersed PTF envelope (content). VLST contains documentation regarding the PTF that is normally not all that useful. Run DETERSE to unterse them (it sounds like you know about that). You should use VMFINFO (i.e VMFINFO ppfname compname) to query the status of PTFs on your system. At the Main Menu, select option PTFs/APARs. At the PTF/APAR Queries menu, enter the PTF number that you ordered (not the VLST or VPTF number; that's just an IBM delivery order number) in the corresponding field, then select option Status of PTF. If the PTF is received and/or applied, you'll see a line indicating that fact as well as the date/time on which it occurred (i.e. Apply status: APPLIED.11/22/05.16:19:10.MAINT). If its neither received nor applied, you'll see message WN:VMFSIP2481W No entries match search arguments. If your PTF was applied and thedates are not recent/today, then you probably did have the maintenance already applied. If the dates are current, then you probably just now applied it. Depending on what component the applied PTF alters, you might also need to go through some sort of build process (i.e. rebuild a nucleus, NSS, etc.) in order to implement the PTF. PUT2PROD would normally be the last part of that process. VMFINFO will not necessarily tell you whether the Build process was performed. See the Service Guide and the VMSES/E Introduction and Reference manuals for more specific assistance. Hope this helps. If not or if you have more specific questions, let us know. Dennis Schaffer Mutual of Omaha Ranga Nathan [EMAIL PROTECTED] To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Applying PTFs to Z/VM 5.1 09/08/2006 08:39 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I requested three services and got download instructions to download VPTF4792.BIN and VLST4792.BIN I am guessing that VPTF* contains the actual PTF and VLST contains some documentation. Is this right? When I serviced them on our test system after deterse and service commands, the VPTF4792 said all the PTFs were already applied. The VLST4792 said something similar. So I concluded that I dont need to apply these to production. Or should I? I still went ahead with the PUT2PROD process for the test system. -- __ Ranga Nathan Work: 714-442-7591
