listing active user directory
Hi listers, I have formatted the MAINT 191 disk with the user direct by accident. I have restored it from a backup which is one week old. I assume I have done all the changes to the user direct since then. Is there a way to list the currently installed directory for comparing with the source? I have zvm 5.3 but no dirmaint active. Thanks in advance for any hints kind regards Franz Josef Pohlen -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
Re: listing active user directory
On Mon, Mar 10, 2008 at 10:26 AM, Franz Josef Pohlen [EMAIL PROTECTED] wrote: I have formatted the MAINT 191 disk with the user direct by accident. I have restored it from a backup which is one week old. I assume I have done all the changes to the user direct since then. Is there a way to list the currently installed directory for comparing with the source? I have zvm 5.3 but no dirmaint active. There's a DIRENT package on the VM Download page that can pull a user entry from storage. It probably can also extract all directory entries for you, but any smart things like profiles would be lost. If you think that most of your changes were mini disks, it might be practical to use Q MDISK USER ... DIR and compare. A bit of plumbing would for that would not be too hard... Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: listing active user directory
On Mon, Mar 10, 2008 at 11:12 AM, Kris Buelens [EMAIL PROTECTED] wrote: Another way: Detach the 123, create a TDISK as 123 of a few cylinders, be sure the 123 is the T-disk, not the resident... Unless you're already very comfortable playing with this stuff, I would not recommend learning while fixingthe problem. This is a big gun and when one foot is already hurting... While the default is to have the sysres linked at 123, I have also seen installations who changed the address in the directory statement to match the *real* device (probably not understanding how this works). Following your recipe, that customer would place his old directory online... (problem solved ;-) Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: listing active user directory
DIRENT can indeed grab the whole CP directory. I would pass the old CP dir and the copy obtained with DIRENT to DIRMAP and compare both maps. More practical: - Get my DRM PACKAGE from VM's download lib - Issue DRM old-cp DIRECT, press PF16 this creates and shows you fn MDISKMAP Press PF4, this removes headers from the MDISKMAP and places the volser on every record. FILE this cleaned MDISKMAP - Do the same steps for the DIRENT copy of the CP directory. Then compare both MDISKMAPs with your usual compare tool (maybe look at COMPAIR from VM's download lib). To compare non-MDISK statements of both directories: DRM contains a tool that can help: DIRFLAT. DIRFLAT makes a single record for each userid, it resolves the INCLUDEd profiles. Running DIRFLAT against both source directories could help. Another way: Detach the 123, create a TDISK as 123 of a few cylinders, be sure the 123 is the T-disk, not the resident... Use ICKDSF to format it and allocate it as DRCT, as label give it the same as your current sysres, cpvol format unit(123) nvfy volid(VTERES) type(DRCT,1,3) run DIRECTXA to create an object directory based on the old CP directory (DIRECTXA should end with rc 5 as CP will not activate it), then run DIRENT to grab the just written object directory. Now compare both directories obtained with DIRENT. 2008/3/10, Rob van der Heij [EMAIL PROTECTED]: On Mon, Mar 10, 2008 at 10:26 AM, Franz Josef Pohlen [EMAIL PROTECTED] wrote: I have formatted the MAINT 191 disk with the user direct by accident. I have restored it from a backup which is one week old. I assume I have done all the changes to the user direct since then. Is there a way to list the currently installed directory for comparing with the source? I have zvm 5.3 but no dirmaint active. There's a DIRENT package on the VM Download page that can pull a user entry from storage. It probably can also extract all directory entries for you, but any smart things like profiles would be lost. If you think that most of your changes were mini disks, it might be practical to use Q MDISK USER ... DIR and compare. A bit of plumbing would for that would not be too hard... Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- Kris Buelens, IBM Belgium, VM customer support
Re: listing active user directory
thanks Kris an Rob for your valuable hints. With the mentioned tools I will check the directory against the source. Rob, don't worry, I'm familiar with this stuff. It was only a bit late and I was tired when I formatted the Maint 191. I wanted to format a temp disk but I entered the wrong device instead. (Sh... happens) kind regards Franz Josef Original-Nachricht Datum: Mon, 10 Mar 2008 12:12:56 +0200 Von: Kris Buelens [EMAIL PROTECTED] An: IBMVM@LISTSERV.UARK.EDU Betreff: Re: [IBMVM] listing active user directory DIRENT can indeed grab the whole CP directory. I would pass the old CP dir and the copy obtained with DIRENT to DIRMAP and compare both maps. More practical: - Get my DRM PACKAGE from VM's download lib - Issue DRM old-cp DIRECT, press PF16 this creates and shows you fn MDISKMAP Press PF4, this removes headers from the MDISKMAP and places the volser on every record. FILE this cleaned MDISKMAP - Do the same steps for the DIRENT copy of the CP directory. Then compare both MDISKMAPs with your usual compare tool (maybe look at COMPAIR from VM's download lib). To compare non-MDISK statements of both directories: DRM contains a tool that can help: DIRFLAT. DIRFLAT makes a single record for each userid, it resolves the INCLUDEd profiles. Running DIRFLAT against both source directories could help. Another way: Detach the 123, create a TDISK as 123 of a few cylinders, be sure the 123 is the T-disk, not the resident... Use ICKDSF to format it and allocate it as DRCT, as label give it the same as your current sysres, cpvol format unit(123) nvfy volid(VTERES) type(DRCT,1,3) run DIRECTXA to create an object directory based on the old CP directory (DIRECTXA should end with rc 5 as CP will not activate it), then run DIRENT to grab the just written object directory. Now compare both directories obtained with DIRENT. 2008/3/10, Rob van der Heij [EMAIL PROTECTED]: On Mon, Mar 10, 2008 at 10:26 AM, Franz Josef Pohlen [EMAIL PROTECTED] wrote: I have formatted the MAINT 191 disk with the user direct by accident. I have restored it from a backup which is one week old. I assume I have done all the changes to the user direct since then. Is there a way to list the currently installed directory for comparing with the source? I have zvm 5.3 but no dirmaint active. There's a DIRENT package on the VM Download page that can pull a user entry from storage. It probably can also extract all directory entries for you, but any smart things like profiles would be lost. If you think that most of your changes were mini disks, it might be practical to use Q MDISK USER ... DIR and compare. A bit of plumbing would for that would not be too hard... Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- Kris Buelens, IBM Belgium, VM customer support -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Re: listing active user directory
I did the same 25 years ago: at 10PM, just before starting the 1h drive home, quickly added a new userid to please the customer, wanted to format this new 191 and entered FORMAT 191 Z used to the prompts that always come one enters YES...Needless to say I wasn't home around 11PM But, since then I've got a FORMAT EXEC on my tools disk that gives a very different message when formatting a minidisks that can be ACCESSed. 2008/3/10, Franz Josef Pohlen [EMAIL PROTECTED]: thanks Kris an Rob for your valuable hints. With the mentioned tools I will check the directory against the source. Rob, don't worry, I'm familiar with this stuff. It was only a bit late and I was tired when I formatted the Maint 191. I wanted to format a temp disk but I entered the wrong device instead. (Sh... happens) kind regards Franz Josef -- Kris Buelens, IBM Belgium, VM customer support
Re: Using UDP port 514 in z/VM TCPIP...
I did find my problem, and as usual, it was of my own making I mis-read the PIPE UDP help, and had specified 514 as the sending port, rather than specifying 0 and allowing it to choose a port above 1024. I can fix this But, while I understand that, once a UDP message leaves my hands, there is no guarantee of delivery, I would think that the RFC would kick in once the message had actually been sent. The fact that the failure was still inside my box, and completely detectable, bothers me. Is it really right to say ³Oh, it¹s a UDP message, so I won¹t bother to check any return codes from anything I do, cause the RFC says I don¹t have¹ta care...² If you were reading a disk file, and writing the records out to another machine via UDP, and there was a disk failure, should you just ignore it because the RFC for UDP says that there¹s no guarantees? Are are you responsible for checking for disk errors, because your message isn¹t actually out on the wire as yet? -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 3/7/08 7:39 PM, David Boyes [EMAIL PROTECTED] wrote: Also: If I violate this using Pipe and the UDP stage, why don¹t I get a non-zero return code? Because there are no guarantees in the IP protocol specifications that UDP packets are ever delivered. UDP was designed to have those semantics, and thus if you use UDP, you're expected to handle missing packets yourself. If you want guaranteed delivery, you're expected to use TCP. Direct quote from the RFC: UDP does not guarantee reliability or ordering in the way that TCP does. Datagrams may arrive out of order, appear duplicated, or go missing without notice.
Re: Recycling Bus and Tag cables
We took ours to a metal recycler. They were mildly happy to take all but the ends. We had to remove the ends. There is a lot of plastic in those cables which the recycler has to strip. You only get paid for the metal. By the way, you may need proof that you are the owner of the cables as there have been lots of people stealing metals for the cash. Several communities and police departments are cracking down on the recyclers. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Friday, March 07, 2008 4:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Recycling Bus and Tag cables We are cutting up a bunch of old bus and tag cables that have been under the machine room floor in order to pull them out a little more easily. The blue ones don't seem to be made of copper. Lots of plastic and a little aluminum. When others have dumped their old bus and tag cables, what did you do with them? Did any recycling business care to take them? Is there any type of green initiative, that might dispose of them in a earth friendly manor? Tom Duerbusch THD Consulting (making an attempt to keep them out of a land fill) 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: Using UDP port 514 in z/VM TCPIP...
On Mon, Mar 10, 2008 at 2:55 PM, RPN01 [EMAIL PROTECTED] wrote: But, while I understand that, once a UDP message leaves my hands, there is no guarantee of delivery, I would think that the RFC would kick in once the message had actually been sent. The fact that the failure was still inside my box, and completely detectable, bothers me. Is it really right to say Oh, it's a UDP message, so I won't bother to check any return codes from anything I do, 'cause the RFC says I don't have'ta care... Use LISTRC option on your pipeline to see whether you're hiding something. My pipeline says: PIPTCQ1015E ERRNO 13: EACCES. PIPMSG003I ... Issued from stage 1 of pipeline 1. PIPMSG001I ... Running udp 53 user tcposdl. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Using UDP port 514 in z/VM TCPIP...
But, while I understand that, once a UDP message leaves my hands, there is no guarantee of delivery, I would think that the RFC would kick in once the message had actually been sent. The fact that the failure was still inside my box, and completely detectable, bothers me. Is it really right to say Oh, it's a UDP message, so I won't bother to check any return codes from anything I do, 'cause the RFC says I don't have'ta care... That's the way it works because there's no other way to do it if you use UDP. If you use UDP, the U stands for user - it is *your* problem. The only thing the API return code can tell you in a UDP-based application is that the stack accepted the packet - which it did; the packet was accepted by the stack, and you got a RC=0. UDP does not offer anything else, and there is no mechanism in IP to tell you anything else. How is the API supposed to return anything else? If you were reading a disk file, and writing the records out to another machine via UDP, and there was a disk failure, should you just ignore it because the RFC for UDP says that there's no guarantees? Are are you responsible for checking for disk errors, because your message isn't actually out on the wire as yet? You are completely responsible for *all* the application function. UDP guarantees *nothing* other than the packet is constructed and handed to the stack. Take a look at the way NFS is constructed - all the timeouts, responses, error checking, etc is ALL in the application. Anything above the physical act of transferring data is done in the RPC layer, and everything in NFS is stateless to allow it to fit in the UDP cast it out in the void and pray design model. So, yes, working as designed. You want guarantees, use TCP. You want lightweight transport without the TCP overhead, you gotta do the work yourself if you want more reliable semantics.
Re: Using UDP port 514 in z/VM TCPIP...
On Monday, 03/10/2008 at 08:56 EDT, RPN01 [EMAIL PROTECTED] wrote: But, while I understand that, once a UDP message leaves my hands, there is no guarantee of delivery, I would think that the RFC would kick in once the message had actually been sent. The fact that the failure was still inside my box, and completely detectable, bothers me. Is it really right to say ?Oh, it?s a UDP message, so I won?t bother to check any return codes from anything I do, ?cause the RFC says I don?t have?ta care...? Whoever said you don't have to check return codes is smoking something. I don't know of any RFC that says you don't have to check return codes on APIs. (You'll notice that they don't talk about APIs at all!) Can you quote your source? You could have buffer shortages, interface failures, a bad specification, authorization errors, or something else unrelated to the success or failure of the other guy receiving your datagram. Alan Altmark z/VM Development IBM Endicott
Re: Recycling Bus and Tag cables
On Mon, Mar 10, 2008 at 2:16 PM, Stracka, James (GTI) [EMAIL PROTECTED] wrote: We took ours to a metal recycler. They were mildly happy to take all but the ends. We had to remove the ends. There is a lot of plastic in those cables which the recycler has to strip. You only get paid for the metal. I would expect the connectors to have a fair amount of interesting materials (like plated pins etc) well beyond even copper and aluminum. But maybe only interesting for large shops that can grind and separate stuff. Maybe I can find on http://www.recycleinme.com/ someone interested in a decent supply of tape rings. Not yet, but isn't the saying that you can't take your tape rings when your time has come... and I also see demand for my old pipeline stages. Rob
Re: listing active user directory
Maybe it would be better to keep the USER DIRECT file (or whatever you're using as the source directory) off the 191 disk altogether, placing it on a separate disk, and at known address? Known address could be defined in two parts: 1) Perhaps at cylinder 1 of a particular volser that you know and love (and can remember in a crisis)? 2) A new MAINT MDISK, maybe 5DD (following VMSES/E's convention of the '5' looking a bit like an 'S' when one squints ones eyes - the 5DD reminds one of the SDD or 'S'ource 'D'irectory 'D'isk )? Or, following the SYSTEM CONFIG CF1/CF2/CF3 disk standards, a paranoid sysprog could set up SD1, and SD2 disks. Where the live directory is on the SD1 directory (at a known extent on a known volume), always make a backup copy to the SD2 disk (at a known extent on a known volume) before making any changes. That way if anything goes wrong you can always go back one generation without needing to mount a tape. It vastly reduces the chances of formatting *both* disks. It depends on your level of paranoia. By placing it on a disk other than 191 one must be very sure to never copy or save it to the 191 disk by accident or on purpose (just for a test, of course) because then you have the opportunity to figure out which is the real USER DIRECT, or worse - which has some of the real entries and which has the rest of the real entries. A good PROFILE EXEC could easily check for such duplicate errors. 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 03/10/2008 07:21 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: listing active user directory I did the same 25 years ago: at 10PM, just before starting the 1h drive home, quickly added a new userid to please the customer, wanted to format this new 191 and entered FORMAT 191 Z used to the prompts that always come one enters YES...Needless to say I wasn't home around 11PM But, since then I've got a FORMAT EXEC on my tools disk that gives a very different message when formatting a minidisks that can be ACCESSed. 2008/3/10, Franz Josef Pohlen [EMAIL PROTECTED]: thanks Kris an Rob for your valuable hints. With the mentioned tools I will check the directory against the source. Rob, don't worry, I'm familiar with this stuff. It was only a bit late and I was tired when I formatted the Maint 191. I wanted to format a temp disk but I entered the wrong device instead. (Sh... happens) kind regards Franz Josef -- Kris Buelens, IBM Belgium, VM customer support 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: listing active user directory
We've got MAINT B91 as backup of MAINT 191 since the VM/SP days. Our DIRBKP EXEC keep the last 9 levels of the CP directory there, as well as SYSTEM CONFIG; the result of a QUERY DASD and Q ALLOC. DIRBKP does not only maintain these backups but also performs some checks each night such as: is MDISK MAINT 298 (i.e. VTAM) still in the directory. Additionally, the 9 copies of the directory co are also copied to a central SFS: so when a system is down due to disk errors, we know what is lost (touching wood: didn't need this for more than 10 years). 2008/3/10, Mike Walter [EMAIL PROTECTED]: Maybe it would be better to keep the USER DIRECT file (or whatever you're using as the source directory) off the 191 disk altogether, placing it on a separate disk, and at known address? Known address could be defined in two parts: 1) Perhaps at cylinder 1 of a particular volser that you know and love (and can remember in a crisis)? 2) A new MAINT MDISK, maybe 5DD (following VMSES/E's convention of the '5' looking a bit like an 'S' when one squints ones eyes - the 5DD reminds one of the SDD or 'S'ource 'D'irectory 'D'isk )? Or, following the SYSTEM CONFIG CF1/CF2/CF3 disk standards, a paranoid sysprog could set up SD1, and SD2 disks. Where the live directory is on the SD1 directory (at a known extent on a known volume), always make a backup copy to the SD2 disk (at a known extent on a known volume) before making any changes. That way if anything goes wrong you can always go back one generation without needing to mount a tape. It vastly reduces the chances of formatting *both* disks. It depends on your level of paranoia. By placing it on a disk other than 191 one must be very sure to never copy or save it to the 191 disk by accident or on purpose (just for a test, of course) because then you have the opportunity to figure out which is the real USER DIRECT, or worse - which has some of the real entries and which has the rest of the real entries. A good PROFILE EXEC could easily check for such duplicate errors. 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, IBM Belgium, VM customer support
Re: listing active user directory
Then again, we use VM:Backup and copy our data to tape. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Monday, March 10, 2008 10:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: listing active user directory We've got MAINT B91 as backup of MAINT 191 since the VM/SP days. Our DIRBKP EXEC keep the last 9 levels of the CP directory there, as well as SYSTEM CONFIG; the result of a QUERY DASD and Q ALLOC. DIRBKP does not only maintain these backups but also performs some checks each night such as: is MDISK MAINT 298 (i.e. VTAM) still in the directory. Additionally, the 9 copies of the directory co are also copied to a central SFS: so when a system is down due to disk errors, we know what is lost (touching wood: didn't need this for more than 10 years). 2008/3/10, Mike Walter [EMAIL PROTECTED]: Maybe it would be better to keep the USER DIRECT file (or whatever you're using as the source directory) off the 191 disk altogether, placing it on a separate disk, and at known address? Known address could be defined in two parts: 1) Perhaps at cylinder 1 of a particular volser that you know and love (and can remember in a crisis)? 2) A new MAINT MDISK, maybe 5DD (following VMSES/E's convention of the '5' looking a bit like an 'S' when one squints ones eyes - the 5DD reminds one of the SDD or 'S'ource 'D'irectory 'D'isk )? Or, following the SYSTEM CONFIG CF1/CF2/CF3 disk standards, a paranoid sysprog could set up SD1, and SD2 disks. Where the live directory is on the SD1 directory (at a known extent on a known volume), always make a backup copy to the SD2 disk (at a known extent on a known volume) before making any changes. That way if anything goes wrong you can always go back one generation without needing to mount a tape. It vastly reduces the chances of formatting *both* disks. It depends on your level of paranoia. By placing it on a disk other than 191 one must be very sure to never copy or save it to the 191 disk by accident or on purpose (just for a test, of course) because then you have the opportunity to figure out which is the real USER DIRECT, or worse - which has some of the real entries and which has the rest of the real entries. A good PROFILE EXEC could easily check for such duplicate errors. 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, IBM Belgium, VM customer support 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: listing active user directory
On Monday, 03/10/2008 at 10:40 EDT, Stracka, James (GTI) [EMAIL PROTECTED] wrote: Then again, we use VM:Backup and copy our data to tape. The point is that it doesn't matter what you do, as long as you keep a backup of your source directory in a place you can get to it. That would typically mean a locally archived version for system programmer errors and limited h/w failures and a DR copy in the event of a disaster. Alan Altmark z/VM Development IBM Endicott
Re: listing active user directory
z/VM has come with the directory defaulting to MAINT 2c2 disk accessed as c. I have always left it there because the 191 disk has too many accesses and changes. It seem to me that if you leave the directory on 2c2 it would less vulnerable to an accidental deletion or in my case, it would result in one less hole in my foot! Loren Charnley, Jr. IT Systems Engineer Family Dollar Stores, Inc. (704) 847-6961 Ext. 3327 (704) 814-3327 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Monday, March 10, 2008 10:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: listing active user directory We've got MAINT B91 as backup of MAINT 191 since the VM/SP days. Our DIRBKP EXEC keep the last 9 levels of the CP directory there, as well as SYSTEM CONFIG; the result of a QUERY DASD and Q ALLOC. DIRBKP does not only maintain these backups but also performs some checks each night such as: is MDISK MAINT 298 (i.e. VTAM) still in the directory. Additionally, the 9 copies of the directory co are also copied to a central SFS: so when a system is down due to disk errors, we know what is lost (touching wood: didn't need this for more than 10 years). 2008/3/10, Mike Walter [EMAIL PROTECTED]: Maybe it would be better to keep the USER DIRECT file (or whatever you're using as the source directory) off the 191 disk altogether, placing it on a separate disk, and at known address? Known address could be defined in two parts: 1) Perhaps at cylinder 1 of a particular volser that you know and love (and can remember in a crisis)? 2) A new MAINT MDISK, maybe 5DD (following VMSES/E's convention of the '5' looking a bit like an 'S' when one squints ones eyes - the 5DD reminds one of the SDD or 'S'ource 'D'irectory 'D'isk )? Or, following the SYSTEM CONFIG CF1/CF2/CF3 disk standards, a paranoid sysprog could set up SD1, and SD2 disks. Where the live directory is on the SD1 directory (at a known extent on a known volume), always make a backup copy to the SD2 disk (at a known extent on a known volume) before making any changes. That way if anything goes wrong you can always go back one generation without needing to mount a tape. It vastly reduces the chances of formatting *both* disks. It depends on your level of paranoia. By placing it on a disk other than 191 one must be very sure to never copy or save it to the 191 disk by accident or on purpose (just for a test, of course) because then you have the opportunity to figure out which is the real USER DIRECT, or worse - which has some of the real entries and which has the rest of the real entries. A good PROFILE EXEC could easily check for such duplicate errors. 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, IBM Belgium, VM customer support NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you.
Re: Recycling Bus and Tag cables
Rob, As a Scout leader and husband of a Guide leader, your tape rings would be of use to just about any organization that entertains youth with things like ring toss games. When my company's 3420's went out the door, the tape rings came home with me! They have been used at lots of events and camps. Ron On 3/10/08, Rob van der Heij [EMAIL PROTECTED] wrote: On Mon, Mar 10, 2008 at 2:16 PM, Stracka, James (GTI) [EMAIL PROTECTED] wrote: We took ours to a metal recycler. They were mildly happy to take all but the ends. We had to remove the ends. There is a lot of plastic in those cables which the recycler has to strip. You only get paid for the metal. I would expect the connectors to have a fair amount of interesting materials (like plated pins etc) well beyond even copper and aluminum. But maybe only interesting for large shops that can grind and separate stuff. Maybe I can find on http://www.recycleinme.com/ someone interested in a decent supply of tape rings. Not yet, but isn't the saying that you can't take your tape rings when your time has come... and I also see demand for my old pipeline stages. Rob
Disaster Recovery question
We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks!
I have 2 devices in use
When I query 47E or 49E, here is the response: DASD 047E CP SYSTEM Z3Z1P1 2 DASD 049E CP SYSTEM Z3Z1S1 2 The '2' at the end indicates how many systems have the device. 47E and 49E are full-pack minidisks defined to MVSDASD which is not logged on. I have two users and that have a INCLUDE MVSLINK profile. Both and are MVS systems. I have changed the USER DIRECT to comment out 47E and 49E in the PROFILE MVSLINK and the USER MVSDASD. I have done a DIRECTXA USER DIRECT. I have tried to detach the devices from and . That did not work. What else can I do ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: Disaster Recovery question
Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Disaster Recovery question
Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) 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 Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Disaster Recovery question
You could use the volume serial in any DEDICATE statements in place of the real address (DEDICATE vdev volid or DEDICATE vdev VOLID volid). That could save you from having to make that kind of directory change. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, March 10, 2008 10:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery question snip Your ATTACHes or DEDICATEs have a virtual address and a real address. You will need to update the real addresses to match your DR config. Leave the virtual addresses alone. Remember, ATTACH and DEDICATE have significantly different syntax: ATTACH rdev vdev DEDICATE vdev rdev Alan Altmark z/VM Development IBM Endicott
Re: Disaster Recovery question
Ooo, wait. You said Linux devices are DEDICATE. Does that mean DASD too? Do you have duplicate VOLSERS on your system? If not, you can probably change the DEDICATEs to MDISK 000 END and be OK, or if you'd like DEDICATE nnn VOLID VOLXXX ... That'll get you around that use of real addresses. 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 Cortes, Marcy D. Sent: Monday, March 10, 2008 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) 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 Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: I have 2 devices in use
I have issued the following commands: q system 47e DASD 047E ATTACHED SYSTEM 0002 Z3Z1P1 D00A 047E R/W , BH3A 047E R/W q system 49e DASD 049E ATTACHED SYSTEM 0002 Z3Z1S1 D00A 049E R/W , BH3A 049E R/W I have tried the following: #CP DETACH 47E FROM BH3A HCPDTG121E DASD 047E not attached to BH3A Both 47E and 49E are linked by PROFILE MVSLINK to MVSDASD (who is not logged on). Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 Serena Software - The Mashups Are Coming -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, March 10, 2008 10:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I have 2 devices in use On Monday, 03/10/2008 at 01:24 EDT, Daniel Allen [EMAIL PROTECTED] wrote: When I query 47E or 49E, here is the response: DASD 047E CP SYSTEM Z3Z1P1 2 DASD 049E CP SYSTEM Z3Z1S1 2 The '2' at the end indicates how many systems have the device. 47E and 49E are full-pack minidisks defined to MVSDASD which is not logged on. I have two users and that have a INCLUDE MVSLINK profile. Both and are MVS systems. I have changed the USER DIRECT to comment out 47E and 49E in the PROFILE MVSLINK and the USER MVSDASD. I have done a DIRECTXA USER DIRECT. I have tried to detach the devices from and . That did not work. What do you mean did not work? If you #CP DETACH the mdisks from the users, then QUERY DASD Z3Z1P1 and QUERY DASD Z3Z1S1 should show no linked users. Does it? Does QUERY SYSTEM 47E and QUERY SYSTEM 49E match your expectations? Alan Altmark z/VM Development IBM Endicott ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: Disaster Recovery question
On Monday, 03/10/2008 at 01:52 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You could use the volume serial in any DEDICATE statements in place of the real address (DEDICATE vdev volid or DEDICATE vdev VOLID volid). That could save you from having to make that kind of directory change. Cool. I did not know that. But for OSAs and FCPs, you still need to do the reconfig. Using a VSWITCH instead of dedicating OSAs reduces the effort even further. Alan Altmark z/VM Development IBM Endicott
Re: Disaster Recovery question
Right. Not a problem using DEDICATE nn VOLID VOLSER. We also have hipersockets and OSA devices defined with DEDICATE statements. That's where the big question comes into play. How do we handle these. Marcy Cortes [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 01:50 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Disaster Recovery question Ooo, wait. You said Linux devices are DEDICATE. Does that mean DASD too? Do you have duplicate VOLSERS on your system? If not, you can probably change the DEDICATEs to MDISK 000 END and be OK, or if you'd like DEDICATE nnn VOLID VOLXXX ... That'll get you around that use of real addresses. 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 Cortes, Marcy D. Sent: Monday, March 10, 2008 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) 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 Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: I have 2 devices in use
Thanks, Dennis. That did the trick. Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Monday, March 10, 2008 10:50 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I have 2 devices in use Daniel, From a userid with privilege class B, enter Q SYS 47E and Q SYS 49E. This will tell you what virtual addresses your MVS guests are using to link those minidisks. Vary those volumes offline to MVS. Assuming the virtual addresses are 47E and 49E, from a userid with privilege class C, enter CP SEND CP DETACH 47E 49E and CP SEND CP DETACH 47E 49E. Dennis O'Brien Just because we spent the night together doesn't mean we're on a first name basis. -- Miss Glick, in Lucky Stiff From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Monday, March 10, 2008 10:23 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] I have 2 devices in use When I query 47E or 49E, here is the response: DASD 047E CP SYSTEM Z3Z1P1 2 DASD 049E CP SYSTEM Z3Z1S1 2 The '2' at the end indicates how many systems have the device. 47E and 49E are full-pack minidisks defined to MVSDASD which is not logged on. I have two users and that have a INCLUDE MVSLINK profile. Both and are MVS systems. I have changed the USER DIRECT to comment out 47E and 49E in the PROFILE MVSLINK and the USER MVSDASD. I have done a DIRECTXA USER DIRECT. I have tried to detach the devices from and . That did not work. What else can I do ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: Disaster Recovery question
For the TCPIP machines, it's not too difficult. You have an alternate machine or config files and in the dtcparms something like :nick.TCPIPDR :type.server :class.stack :attach.3000-3002 And you can bring up that service machine instead. Or change the system netids to make it something like DRSYS and instead of picking up say PROFILE TCPIP it will pick up DRSYS TCPIP with appropriate DRSYS DTCPARMs. Marcy Cortes Team Lead, http://ehs.homestead.wellsfargo.com/Mainframe/zSS/zSE/zVM-zLinux/Pages/defa ult.aspx Enterprise Virtualization - z/VM and z/Linux Enterprise Hosting Services w. (415) 243-6343 c. (415) 517-0895 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. _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Karl Kingston Sent: Monday, March 10, 2008 10:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Right. Not a problem using DEDICATE nn VOLID VOLSER. We also have hipersockets and OSA devices defined with DEDICATE statements. That's where the big question comes into play. How do we handle these. Marcy Cortes [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 01:50 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Disaster Recovery question Ooo, wait. You said Linux devices are DEDICATE. Does that mean DASD too? Do you have duplicate VOLSERS on your system? If not, you can probably change the DEDICATEs to MDISK 000 END and be OK, or if you'd like DEDICATE nnn VOLID VOLXXX ... That'll get you around that use of real addresses. 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 Cortes, Marcy D. Sent: Monday, March 10, 2008 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) 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 Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Disaster Recovery question
We do ours via NAT translation in the router. The network people make it transparent to the OS be it z/VM or z/OS. On the systems we maintain the same IP addresses as production. Then when we go to the DR site (which is an internal site) we translate 10.9 to 10.25. Then no need to change anything on the local systems in DR mode. Andy Internet: Mailto:[EMAIL PROTECTED] We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: I have 2 devices in use
On Monday, 03/10/2008 at 01:24 EDT, Daniel Allen [EMAIL PROTECTED] wrote: When I query 47E or 49E, here is the response: DASD 047E CP SYSTEM Z3Z1P1 2 DASD 049E CP SYSTEM Z3Z1S1 2 The '2' at the end indicates how many systems have the device. 47E and 49E are full-pack minidisks defined to MVSDASD which is not logged on. I have two users and that have a INCLUDE MVSLINK profile. Both and are MVS systems. I have changed the USER DIRECT to comment out 47E and 49E in the PROFILE MVSLINK and the USER MVSDASD. I have done a DIRECTXA USER DIRECT. I have tried to detach the devices from and . That did not work. What do you mean did not work? If you #CP DETACH the mdisks from the users, then QUERY DASD Z3Z1P1 and QUERY DASD Z3Z1S1 should show no linked users. Does it? Does QUERY SYSTEM 47E and QUERY SYSTEM 49E match your expectations? Alan Altmark z/VM Development IBM Endicott
Re: Disaster Recovery question
On Monday, 03/10/2008 at 01:23 EDT, Karl Kingston [EMAIL PROTECTED] wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? If you're going to come up 1st level, you will HAVE to make config changes. Your ATTACHes or DEDICATEs have a virtual address and a real address. You will need to update the real addresses to match your DR config. Leave the virtual addresses alone. Remember, ATTACH and DEDICATE have significantly different syntax: ATTACH rdev vdev DEDICATE vdev rdev Alan Altmark z/VM Development IBM Endicott
Education announcement - VM and Linux Performance Workshop
We have finalized the 2008 schedule for the VM and Linux Performance Workshop. See http://velocitysoftware.com/seminar/workshop.html; for details.
Re: I have 2 devices in use
Daniel, In your e-mail you said that you changed the directory (remove volumes from profiles) and then tried to detach the volumes from MVSUSERS. I think that the reason that you got an error is that you activated the changes BEFORE you tried to detach them. I may be wrong, but if I am right, you will need to reverse the directory changes, detach the volumes and then activate the changes. Loren Charnley, Jr. IT Systems Engineer Family Dollar Stores, Inc. (704) 847-6961 Ext. 3327 (704) 814-3327 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Monday, March 10, 2008 1:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I have 2 devices in use I have issued the following commands: q system 47e DASD 047E ATTACHED SYSTEM 0002 Z3Z1P1 D00A 047E R/W , BH3A 047E R/W q system 49e DASD 049E ATTACHED SYSTEM 0002 Z3Z1S1 D00A 049E R/W , BH3A 049E R/W I have tried the following: #CP DETACH 47E FROM BH3A HCPDTG121E DASD 047E not attached to BH3A Both 47E and 49E are linked by PROFILE MVSLINK to MVSDASD (who is not logged on). Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 Serena Software - The Mashups Are Coming -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, March 10, 2008 10:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I have 2 devices in use On Monday, 03/10/2008 at 01:24 EDT, Daniel Allen [EMAIL PROTECTED] wrote: When I query 47E or 49E, here is the response: DASD 047E CP SYSTEM Z3Z1P1 2 DASD 049E CP SYSTEM Z3Z1S1 2 The '2' at the end indicates how many systems have the device. 47E and 49E are full-pack minidisks defined to MVSDASD which is not logged on. I have two users and that have a INCLUDE MVSLINK profile. Both and are MVS systems. I have changed the USER DIRECT to comment out 47E and 49E in the PROFILE MVSLINK and the USER MVSDASD. I have done a DIRECTXA USER DIRECT. I have tried to detach the devices from and . That did not work. What do you mean did not work? If you #CP DETACH the mdisks from the users, then QUERY DASD Z3Z1P1 and QUERY DASD Z3Z1S1 should show no linked users. Does it? Does QUERY SYSTEM 47E and QUERY SYSTEM 49E match your expectations? Alan Altmark z/VM Development IBM Endicott ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you.
Re: Disaster Recovery question
Take a look at:
http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_Orlando/S9120MW085956.pdf
In particular, slides 43 to 46. Unfortunately, SHARE's conversion from
PPT to PDF stripped off the Speaker Notes pages - which contain a lot of
explanatory information. I can send you the PPT file if you'd like.
But basically, the SYSTEM NETID reflects the node defined in response to
the CMS command IDENTIFY.
The SYSTEM CONFIG file statement 'System_Identifier' matches the CPU
serial number and displays that in response to 'CP QUERY USERID'.
The response to 'CP QUERY USERID' (from SYSTEM CONFIG) can be parsed by
service virtual machines so that they can perform different work based on
the CPUID they are starting on. For example:
In your SYSTEM CONFIG, include:
System_ID dtyp %% MYHOMEID GATEWAY ATHOME
/* Change above to your system device type, serial number, and nodename
*/
/* Use DISASTER only when we're not at home so that */
/* extensive D.R. automation can take place on various*/
/* service machines when running PROFILE EXEC/GCS's. */
System_Identifier_Default DISASTER GATEWAY DISASTER
Add to the TCPIP DTCPARMS:
:Nick.TCPIP :Type.server :Class.stack
:Exit.LC$TCPXT
And include on the TCPMAINT 198 DISK:
/* Prolog; See Epilog for additional information
* Exec Name - LC$TCPXT EXEC*
* Unit Support - OSS/VM *
* Status- Version 1, Release 1.0 *
/
address 'COMMAND'
parse source xos xct xfn xft xfm xcmd xenvir .
parse upper arg parms 1 operands '(' options ')' parmrest
Signal ON Syntax
Signal ON NoValue
Signal ON ERROR
parse value diag(08,'QUERY USERID') with . . ConfigSysId . '15'x .
/* The above is the SYSTEM CONFIG value */
?home=(ConfigSysId='MYHOMEID')/* --- Change to your nodename */
?recover=(ConfigSysId='RECOVERY') /* We use this for on-site D.R. */
?disaster=(ConfigSysId='DISASTER') /* This for off-site D.R. */
src=0
Select
When ?home1 then
Do
Call Trycmd 'CP ATTACH 0140 * 0140' /* Prod OSA's */
Call Trycmd 'CP ATTACH 0141 * 0141' /* Prod OSA's */
Call Trycmd 'CP ATTACH 0142 * 0142' /* Prod OSA's */
End
When ?recovery then
Do
Call Trycmd 'CP ATTACH 6051 * 0140' /* D.R. OSA's */
Call Trycmd 'CP ATTACH 6052 * 0141' /* D.R. OSA's */
Call Trycmd 'CP ATTACH 6053 * 0142' /* D.R. OSA's */
End
Otherwise
'CP MSG OP TCPIP Not running at myhomeID or RECOVERY,' ,
'ABORTing start-up.'
End /* Select */
If rc0 then
Do
say xfn';' cmd', rc='rc
Return src cmd
End
Else Return rc
//
/* Sub-Routines below this point */
//
Trycmd:
parse arg cmd
SIGNAL OFF ERROR
cmd
src=rc
If rc=0 then Return
If rc=122 then/* rc=122 is 'Already Attached' */
Do
rc=0 /* Override std rc */
Return 0
End
SIGNAL ON ERROR
cmd /* Issue again to SIGNAL ON ERROR error message */
Return rc
Exit:
parse arg exitrc .
If verify(exitrc,'-0123456789')=0 then Exit exitrc
else Exit 99
Error:
trace i
etxt.1='+++ ERROR: error rtn entered in:' ,
rexxback('*','OWNER')', rc='rc
etxt.2='+++ from line:' sigl', which reads:'
etxt.3='+++'sourceline(sigl)
cmdline=strip(sourceline(sigl),'B')
parse var cmdline cmdline '/*' . /* Strip trailing comments */
cmdline=value( strip(value('CMDLINE'),'B') )
etxt.4='+++ which translates to:' cmdline
etxt.0=4
'PIPE STEM etxt. | CONS'
Call Exit 20
Syntax:
etxt.1='+++ SYNTAX: error rtn entered in:' ,
rexxback('*','OWNER')', rc='rc
etxt.2='+++ from line:' sigl', which reads:'
etxt.3='+++'sourceline(sigl)
cmdline=strip(sourceline(sigl),'B')
cmdline=value('CMDLINE')
etxt.4='+++ which translates to:' cmdline
etxt.0=4
'PIPE STEM etxt. | CONS'
Call Exit 20
NoValue:
etxt.1='+++ NoValue: error rtn entered in:' ,
rexxback('*','OWNER')', rc='rc
etxt.2='+++ from line:' sigl', which reads:'
etxt.3='+++'sourceline(sigl)
etxt.4='+++ which translates to:' value(strip(sourceline(sigl),'B'))
etxt.5='+++ Variable with no value is:' condition('Description')
etxt.0=5
'PIPE STEM etxt. | CONS'
Call Exit 24
/* Epilog ***
* Function - TCPIP svm startup exit. *
* Component of - TCPIP at Some
I just wiped out my 49E disk (LE) by accident.
No DDR backup exists. I do have a DFDSS backup. We have not put any maintenance on 49E (LE) unless it came with the installation. Two questions. 1. How can I tell if any maintenance went on LE with the installation of z/VM 5.2 ? 2. Is there a map of the installation tape to point me to where 49E data exists so I can reload it ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: I just wiped out my 49E disk (LE) by accident.
Daniel, The LE shipped with z/VM 5.2.0 consists of the base LE shipped with z/VM 4.4.0 plus all service up through the end of z/VM 5.2.0 development. There used to be a table somewhere that listed where the various minidisks were on the installation DDR. I don't remember where that table is documented though. Sorry. You can have VMSES/E reconstruct the contents of the 49E at the latest level of applied service by issuing from MAINT, the command VMFBLD PPF 4VMVMQ40 LE ( ALL, sans quotation marks. This will take a while to run as there are a lot of parts to rebuild from scratch. Mike Donovan Daniel Allen [EMAIL PROTECTED] m To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU I just wiped out my 49E disk (LE) by accident. 03/10/2008 03:07 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU No DDR backup exists. I do have a DFDSS backup. We have not put any maintenance on 49E (LE) unless it came with the installation. Two questions. 1. How can I tell if any maintenance went on LE with the installation of z/VM 5.2 ? 2. Is there a map of the installation tape to point me to where 49E data exists so I can reload it ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 Serena Software - The Mashups Are Coming ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: I just wiped out my 49E disk (LE) by accident.
And if the various recent posts to the list about wiped out files and mdisks has not convinced your management to take regular backups, now is the time to point out the follies of not doing so and get them scheduled. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Michael Donovan [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 02:44 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: I just wiped out my 49E disk (LE) by accident. Daniel, The LE shipped with z/VM 5.2.0 consists of the base LE shipped with z/VM 4.4.0 plus all service up through the end of z/VM 5.2.0 development. There used to be a table somewhere that listed where the various minidisks were on the installation DDR. I don't remember where that table is documented though. Sorry. You can have VMSES/E reconstruct the contents of the 49E at the latest level of applied service by issuing from MAINT, the command VMFBLD PPF 4VMVMQ40 LE ( ALL, sans quotation marks. This will take a while to run as there are a lot of parts to rebuild from scratch. Mike Donovan Daniel Allen [EMAIL PROTECTED] Daniel Allen [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 03:07 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject I just wiped out my 49E disk (LE) by accident. No DDR backup exists. I do have a DFDSS backup. We have not put any maintenance on 49E (LE) unless it came with the installation. Two questions. 1. How can I tell if any maintenance went on LE with the installation of z/VM 5.2 ? 2. Is there a map of the installation tape to point me to where 49E data exists so I can reload it ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** 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: I just wiped out my 49E disk (LE) by accident.
I have run the command as suggested. Here is the response: VMFBLD PPF 4VMVMQ40 LE ( ALL VMFBLD2760I VMFBLD processing started VMFBLD1836E This program requires LOCAL 4C4 to be accessed VMFBLD1836E This program requires LOCAL 4C2 to be accessed VMFBLD1836E This program requires DELTA 4D2 to be accessed VMFBLD1836E This program requires APPLY 4A6 to be accessed as R/W because it is a target of Software Inventory files VMFBLD1836E This program requires APPLY 4A4 to be accessed VMFBLD1836E This program requires APPLY 4A2 to be accessed VMFBLD1836E This program requires BASE 4B2 to be accessed VMFBLD1836E This program requires BUILD0 49E to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD2 49B to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD5 19D to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD9 402 to be accessed as R/W because it is a target of build lists VMFBLD2760I VMFBLD processing completed unsuccessfully Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Donovan Sent: Monday, March 10, 2008 12:45 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I just wiped out my 49E disk (LE) by accident. Daniel, The LE shipped with z/VM 5.2.0 consists of the base LE shipped with z/VM 4.4.0 plus all service up through the end of z/VM 5.2.0 development. There used to be a table somewhere that listed where the various minidisks were on the installation DDR. I don't remember where that table is documented though. Sorry. You can have VMSES/E reconstruct the contents of the 49E at the latest level of applied service by issuing from MAINT, the command VMFBLD PPF 4VMVMQ40 LE ( ALL, sans quotation marks. This will take a while to run as there are a lot of parts to rebuild from scratch. Mike Donovan Inactive hide details for Daniel Allen [EMAIL PROTECTED]Daniel Allen [EMAIL PROTECTED] Daniel Allen [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 03:07 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject I just wiped out my 49E disk (LE) by accident. No DDR backup exists. I do have a DFDSS backup. We have not put any maintenance on 49E (LE) unless it came with the installation. Two questions. 1. How can I tell if any maintenance went on LE with the installation of z/VM 5.2 ? 2. Is there a map of the installation tape to point me to where 49E data exists so I can reload it ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 Serena Software - The Mashups Are Coming ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: I just wiped out my 49E disk (LE) by accident.
I do not have a z/VM DDR backup. I do have a z/OS DFDSS backup. Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday, March 10, 2008 12:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I just wiped out my 49E disk (LE) by accident. And if the various recent posts to the list about wiped out files and mdisks has not convinced your management to take regular backups, now is the time to point out the follies of not doing so and get them scheduled. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Michael Donovan [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 02:44 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: I just wiped out my 49E disk (LE) by accident. Daniel, The LE shipped with z/VM 5.2.0 consists of the base LE shipped with z/VM 4.4.0 plus all service up through the end of z/VM 5.2.0 development. There used to be a table somewhere that listed where the various minidisks were on the installation DDR. I don't remember where that table is documented though. Sorry. You can have VMSES/E reconstruct the contents of the 49E at the latest level of applied service by issuing from MAINT, the command VMFBLD PPF 4VMVMQ40 LE ( ALL, sans quotation marks. This will take a while to run as there are a lot of parts to rebuild from scratch. Mike Donovan Daniel Allen [EMAIL PROTECTED] Daniel Allen [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 03:07 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject I just wiped out my 49E disk (LE) by accident. No DDR backup exists. I do have a DFDSS backup. We have not put any maintenance on 49E (LE) unless it came with the installation. Two questions. 1. How can I tell if any maintenance went on LE with the installation of z/VM 5.2 ? 2. Is there a map of the installation tape to point me to where 49E data exists so I can reload it ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** 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: I just wiped out my 49E disk (LE) by accident.
you may have to run the setup command to access needed m disks Daniel Allen [EMAIL PROTECTED] m To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: I just wiped out my 49E disk (LE) by accident. 03/10/2008 03:55 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I have run the command as suggested. Here is the response: VMFBLD PPF 4VMVMQ40 LE ( ALL VMFBLD2760I VMFBLD processing started VMFBLD1836E This program requires LOCAL 4C4 to be accessed VMFBLD1836E This program requires LOCAL 4C2 to be accessed VMFBLD1836E This program requires DELTA 4D2 to be accessed VMFBLD1836E This program requires APPLY 4A6 to be accessed as R/W because it is a target of Software Inventory files VMFBLD1836E This program requires APPLY 4A4 to be accessed VMFBLD1836E This program requires APPLY 4A2 to be accessed VMFBLD1836E This program requires BASE 4B2 to be accessed VMFBLD1836E This program requires BUILD0 49E to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD2 49B to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD5 19D to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD9 402 to be accessed as R/W because it is a target of build lists VMFBLD2760I VMFBLD processing completed unsuccessfully Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 (Embedded image moved to file: pic29510.gif)Serena Software - The Mashups Are Coming From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Donovan Sent: Monday, March 10, 2008 12:45 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I just wiped out my 49E disk (LE) by accident. Daniel, The LE shipped with z/VM 5.2.0 consists of the base LE shipped with z/VM 4.4.0 plus all service up through the end of z/VM 5.2.0 development. There used to be a table somewhere that listed where the various minidisks were on the installation DDR. I don't remember where that table is documented though. Sorry. You can have VMSES/E reconstruct the contents of the 49E at the latest level of applied service by issuing from MAINT, the command VMFBLD PPF 4VMVMQ40 LE ( ALL, sans quotation marks. This will take a while to run as there are a lot of parts to rebuild from scratch. Mike Donovan Inactive hide details for Daniel Allen [EMAIL PROTECTED]Daniel Allen [EMAIL PROTECTED] Daniel Allen [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System To [EMAIL PROTECTED] .EDU [EMAIL PROTECTED] .EDU 03/10/2008 03:07 PMcc Please respond to
Re: I just wiped out my 49E disk (LE) by accident.
I was able to restore the 49E disk using the z/OS DFDSS backup I made. Thanks, Mike. Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday, March 10, 2008 12:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I just wiped out my 49E disk (LE) by accident. And if the various recent posts to the list about wiped out files and mdisks has not convinced your management to take regular backups, now is the time to point out the follies of not doing so and get them scheduled. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Michael Donovan [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 02:44 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: I just wiped out my 49E disk (LE) by accident. Daniel, The LE shipped with z/VM 5.2.0 consists of the base LE shipped with z/VM 4.4.0 plus all service up through the end of z/VM 5.2.0 development. There used to be a table somewhere that listed where the various minidisks were on the installation DDR. I don't remember where that table is documented though. Sorry. You can have VMSES/E reconstruct the contents of the 49E at the latest level of applied service by issuing from MAINT, the command VMFBLD PPF 4VMVMQ40 LE ( ALL, sans quotation marks. This will take a while to run as there are a lot of parts to rebuild from scratch. Mike Donovan Daniel Allen [EMAIL PROTECTED] Daniel Allen [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 03:07 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject I just wiped out my 49E disk (LE) by accident. No DDR backup exists. I do have a DFDSS backup. We have not put any maintenance on 49E (LE) unless it came with the installation. Two questions. 1. How can I tell if any maintenance went on LE with the installation of z/VM 5.2 ? 2. Is there a map of the installation tape to point me to where 49E data exists so I can reload it ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** 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: I just wiped out my 49E disk (LE) by accident.
Any physical full pack backup, whether using VM's DDR or z/OS's DFDSS, or any other system's anybackup, is of little use without a hardcopy of the directory, or a diskmap. You can only restore an mdisk if you know what cylinders to restore. In your case, since the system that lost the mdisk is still up and running, I would suggest doing: Q MDISK USER MAINT 49E LOC DRCT This will display the cylinders in use by MAINT 49E. Hopefully, the DFDSS backup/restore program includes the ability to restore specific cylinders??? Good luck, Shimon Original message Date: Mon, 10 Mar 2008 12:57:40 -0700 From: Daniel Allen [EMAIL PROTECTED] Subject: Re: I just wiped out my 49E disk (LE) by accident. To: IBMVM@LISTSERV.UARK.EDU I do not have a z/VM DDR backup. I do have a z/OS DFDSS backup. Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 Serena Software - The Mashups Are Coming From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday, March 10, 2008 12:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I just wiped out my 49E disk (LE) by accident. And if the various recent posts to the list about wiped out files and mdisks has not convinced your management to take regular backups, now is the time to point out the follies of not doing so and get them scheduled. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Michael Donovan To IBMVM@LISTSERV.UARK.EDU [EMAIL PROTECTED] cc Subject Re: I just wiped out my Sent by: The IBM z/VM49E disk (LE) by Operating System accident. IBMVM@LISTSERV.UARK.EDU 03/10/2008 02:44 PM +---+ | Please respond to | | The IBM z/VM Operating | | System | | IBMVM@LISTSERV.UARK.EDU | +---+ Daniel, The LE shipped with z/VM 5.2.0 consists of the base LE shipped with z/VM 4.4.0 plus all service up through the end of z/VM 5.2.0 development. There used to be a table somewhere that listed where the various minidisks were on the installation DDR. I don't remember where that table is documented though. Sorry. You can have VMSES/E reconstruct the contents of the 49E at the latest level of applied service by issuing from MAINT, the command VMFBLD PPF 4VMVMQ40 LE ( ALL, sans quotation marks. This will take a while to run as there are a lot of parts to rebuild from scratch. Mike Donovan Daniel Allen [EMAIL PROTECTED] Daniel Allen To IBMVM@LISTSERV.UARK.EDU [EMAIL PROTECTED]cc Sent by: The IBM z/VM Subject I just wiped out my 49E Operating System disk (LE) by accident. IBMVM@LISTSERV.UARK.EDU 03/10/2008 03:07 PM +---+ | Please respond to | | The IBM z/VM Operating | | System | | IBMVM@LISTSERV.UARK.EDU | +---+ No DDR backup exists. I do have a DFDSS backup. We have not put any maintenance on 49E (LE) unless it came with the installation. Two questions. 1. How can I tell if any maintenance went on LE with the installation of z/VM 5.2 ? 2. Is there a map of the installation tape to point me to where 49E data exists so I can reload it ? Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** 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
Re: I just wiped out my 49E disk (LE) by accident.
Daniel, Sorry. I forgot that SETUP is not a default option on the VMFBLD command. Try adding SETUP after the ALL in the command string. Mike Donovan Daniel Allen [EMAIL PROTECTED] m To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: I just wiped out my 49E disk (LE) by accident. 03/10/2008 03:55 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I have run the command as suggested. Here is the response: VMFBLD PPF 4VMVMQ40 LE ( ALL VMFBLD2760I VMFBLD processing started VMFBLD1836E This program requires LOCAL 4C4 to be accessed VMFBLD1836E This program requires LOCAL 4C2 to be accessed VMFBLD1836E This program requires DELTA 4D2 to be accessed VMFBLD1836E This program requires APPLY 4A6 to be accessed as R/W because it is a target of Software Inventory files VMFBLD1836E This program requires APPLY 4A4 to be accessed VMFBLD1836E This program requires APPLY 4A2 to be accessed VMFBLD1836E This program requires BASE 4B2 to be accessed VMFBLD1836E This program requires BUILD0 49E to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD2 49B to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD5 19D to be accessed as R/W because it is a target of build lists VMFBLD1836E This program requires BUILD9 402 to be accessed as R/W because it is a target of build lists VMFBLD2760I VMFBLD processing completed unsuccessfully Daniel Allen | Senior Systems Programmer | 1-800-457-3736x11241 Serena Software - The Mashups Are Coming From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Donovan Sent: Monday, March 10, 2008 12:45 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: I just wiped out my 49E disk (LE) by accident. Daniel, The LE shipped with z/VM 5.2.0 consists of the base LE shipped with z/VM 4.4.0 plus all service up through the end of z/VM 5.2.0 development. There used to be a table somewhere that listed where the various minidisks were on the installation DDR. I don't remember where that table is documented though. Sorry. You can have VMSES/E reconstruct the contents of the 49E at the latest level of applied service by issuing from MAINT, the command VMFBLD PPF 4VMVMQ40 LE ( ALL, sans quotation marks. This will take a while to run as there are a lot of parts to rebuild from scratch. Mike Donovan Inactive hide details for Daniel Allen [EMAIL PROTECTED]Daniel Allen [EMAIL PROTECTED] Daniel Allen [EMAIL PROTECTED] Sent by: The IBM z/VM Operating To System [EMAIL PROTECTED] [EMAIL PROTECTED] K.EDU EDU cc 03/10/2008 03:07 PM Subject Please respond to
Re: listing active user directory
My method. A. I always rename the user direct to user dirmmddyy copy user dirmmddyy to user direct make changes. I keep so many backups Your option on how many. # of months or items B. I log on as the new user and format the disk as them. -Original Message- From: LOREN CHARNLEY [EMAIL PROTECTED] Sent: Mar 10, 2008 8:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: listing active user directory z/VM has come with the directory defaulting to MAINT 2c2 disk accessed as c. I have always left it there because the 191 disk has too many accesses and changes. It seem to me that if you leave the directory on 2c2 it would less vulnerable to an accidental deletion or in my case, it would result in one less hole in my foot! Loren Charnley, Jr. IT Systems Engineer Family Dollar Stores, Inc. (704) 847-6961 Ext. 3327 (704) 814-3327 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Monday, March 10, 2008 10:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: listing active user directory We've got MAINT B91 as backup of MAINT 191 since the VM/SP days. Our DIRBKP EXEC keep the last 9 levels of the CP directory there, as well as SYSTEM CONFIG; the result of a QUERY DASD and Q ALLOC. DIRBKP does not only maintain these backups but also performs some checks each night such as: is MDISK MAINT 298 (i.e. VTAM) still in the directory. Additionally, the 9 copies of the directory co are also copied to a central SFS: so when a system is down due to disk errors, we know what is lost (touching wood: didn't need this for more than 10 years). 2008/3/10, Mike Walter [EMAIL PROTECTED]: Maybe it would be better to keep the USER DIRECT file (or whatever you're using as the source directory) off the 191 disk altogether, placing it on a separate disk, and at known address? Known address could be defined in two parts: 1) Perhaps at cylinder 1 of a particular volser that you know and love (and can remember in a crisis)? 2) A new MAINT MDISK, maybe 5DD (following VMSES/E's convention of the '5' looking a bit like an 'S' when one squints ones eyes - the 5DD reminds one of the SDD or 'S'ource 'D'irectory 'D'isk )? Or, following the SYSTEM CONFIG CF1/CF2/CF3 disk standards, a paranoid sysprog could set up SD1, and SD2 disks. Where the live directory is on the SD1 directory (at a known extent on a known volume), always make a backup copy to the SD2 disk (at a known extent on a known volume) before making any changes. That way if anything goes wrong you can always go back one generation without needing to mount a tape. It vastly reduces the chances of formatting *both* disks. It depends on your level of paranoia. By placing it on a disk other than 191 one must be very sure to never copy or save it to the 191 disk by accident or on purpose (just for a test, of course) because then you have the opportunity to figure out which is the real USER DIRECT, or worse - which has some of the real entries and which has the rest of the real entries. A good PROFILE EXEC could easily check for such duplicate errors. 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, IBM Belgium, VM customer support NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you. Jan Canavan [EMAIL PROTECTED] VSE/VM SYSTEMS PROGRAMMER
Re: listing active user directory
On Monday, 03/10/2008 at 10:15 EDT, Mike Walter [EMAIL PROTECTED] wrote: Maybe it would be better to keep the USER DIRECT file (or whatever you're using as the source directory) off the 191 disk altogether, placing it on a separate disk, and at known address? If you could GLOBALV SELECT DIRECTXA SETLP BACKUP_TARGET MAINT 555 or GLOBALV SELECT DIRECTXA SETLP BACKUP_TARGET B and DIRECTXA would place a copy of a directory *successfully* placed online on MAINT 555 or filemode B, would that be sufficient to help protect you from casual SNAFUs? You could envision GLOBALV SELECT DIRECTXA SETLP BACKUP_GENERATIONS 3 to make that a bit more sophisticated. While trying to reconstruct a source directory from an object directory might seem logical, far too much information is lost in translation. Alan Altmark z/VM Development IBM Endicott
