Problem Reporting, was: Corrupted IPL Record
A few weeks ago we were seeing comments like this: As for the VM:Secure thing, I find that simply documenting how the product can screw up a system is not only an unacceptable answer, it borders on repugnance. A strategic product that should always be working should never violate the integrity of the system. There is no justification for it. The changed allocation on the disk must be respected. Reallocating a disk is a normal maintenance activity. I'll second this comment. This is a serious bug impacting system integrity. Documenting the bug is not an acceptable response. Yvonne then asked for any VM:Secure customers who were being impacted by this problem to call CA support and register their concern. Not one customer called in. For CA to allocate resources to customer problem resolution, the problems must be reported to CA technical support. VM:Secure has worked in the same manner, regarding the cached allocation map, for almost 25 years. One call from Mike in a quarter century does not sway management in the direction of allocating resources to do a design change in this area.. Complaining about something on the list is positive, in that it encourages discussion on issues. However, software vendors allocate resources based on submitted requirements and technical support calls. Speaking to Fran or Kitty is a very pleasant experience. It's easy to do and you'll enjoy it. Bob Bolch VM:Secure team
Re: Problem Reporting, was: Corrupted IPL Record
It is not just ones being impacted by it who should be considered. Anyone using VM:Secure is a potential victim. That is the consideration that should make this a priority problem. I know that VM:Secure was not at fault in my corrupted IPL record, the problem that prompted the thread. It was not installed on the system where the problem occurred. I am sure that we encountered the problem some time ago, but stumbled upon the solution without knowing that VM:Secure was the perpetrator. When we saw that the original PARM disk was used, we did a NOAUTO start to save time, changed the allocation map and then re-ipled. This time, the new allocation was honored. We did not know that VM:Secure was responsible for the original problem of the allocation map being overwritten. For all we knew, our changes may not have actually been written. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bob Bolch Sent: Thursday, November 16, 2006 5:10 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problem Reporting, was: Corrupted IPL Record A few weeks ago we were seeing comments like this: As for the VM:Secure thing, I find that simply documenting how the product can screw up a system is not only an unacceptable answer, it borders on repugnance. A strategic product that should always be working should never violate the integrity of the system. There is no justification for it. The changed allocation on the disk must be respected. Reallocating a disk is a normal maintenance activity. I'll second this comment. This is a serious bug impacting system integrity. Documenting the bug is not an acceptable response. Yvonne then asked for any VM:Secure customers who were being impacted by this problem to call CA support and register their concern. Not one customer called in. For CA to allocate resources to customer problem resolution, the problems must be reported to CA technical support. VM:Secure has worked in the same manner, regarding the cached allocation map, for almost 25 years. One call from Mike in a quarter century does not sway management in the direction of allocating resources to do a design change in this area.. Complaining about something on the list is positive, in that it encourages discussion on issues. However, software vendors allocate resources based on submitted requirements and technical support calls. Speaking to Fran or Kitty is a very pleasant experience. It's easy to do and you'll enjoy it. Bob Bolch VM:Secure team
Re: Corrupted IPL Record
Title: Re: Corrupted IPL Record Good Morning All, Yes, CA is watching the list and we have heard you. We are looking into what we can do to improve VM:Secure so the allocation map information on the object directory volume can be preserved when changed while VM:Secure is running. Though this is an excellent forum to discuss ideas, get help, and gather requirements please also be sure to call CA technical support when you have CA product questions or concerns. By doing that, you know your questions and concerns won't be missed. Yvonne DeMeritt CA - Technical Support
Corrupted IPL Record
Over the weekend, we upgraded our final system to 5.2. As a part of the migration, we changed old PARM extents to PERM and allocated new PARM extents. When we tried to ipl the system, there were errors that led me to the conclusion that the IPL program had been corrupted. Using DDR on another system, I observed that record 0 0 2 had been completely wiped out. There were a few scattered bits that were not 0 in the first 100-200 bytes, nothing that was any kind of pattern, and the rest of the record was all 0. Records 1, and 3-6 were all as they should have been. I had to run SALIPL to fix the IPL program. I am not blaming CPFMTXA ALLOCATE because I think it highly unlikely that it was the cause. I suspect that something else happened between the previous IPL and yesterday's failed attempt. Has anyone else seen this kind of corruption or are we, once again, unique? Regards, Richard Schuh
Re: Corrupted IPL Record
As for the VM:Secure thing, I find that simply documenting how the product can screw up a system is not only an unacceptable answer, it borders on repugnance. A strategic product that should always be working should never violate the integrity of the system. There is no justification for it. The changed allocation on the disk must be respected. Reallocating a disk is a normal maintenance activity. I'll second this comment. This is a serious bug impacting system integrity. Documenting the bug is not an acceptable response. -- db
Re: Corrupted IPL Record
Just ALLOCATE. Format would have been more devastating. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Monday, October 30, 2006 1:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject:Re: Corrupted IPL Record You didn't perform both FORMAT and ALLOCATE? Kris, IBM Belgium, VM customer support Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 2006-10-30 21:32 Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Corrupted IPL Record If this shows up twice, I apologize. I first sent it 2 hours ago and it hasn't hit the archives as yet. Over the weekend, we upgraded our final system to 5.2. As a part of the migration, we changed old PARM extents to PERM and allocated new PARM extents. When we tried to ipl the system, there were errors that led me to the conclusion that the IPL program had been corrupted. Using DDR on another system, I observed that record 0 0 2 had been completely wiped out. There were a few scattered bits that were not 0 in the first 100-200 bytes, nothing that was any kind of pattern, and the rest of the record was all 0. Records 1, and 3-6 were all as they should have been. I had to run SALIPL to fix the IPL program. I am not blaming CPFMTXA ALLOCATE because I think it highly unlikely that it was the cause. I suspect that something else happened between the previous IPL and yesterday's failed attempt. Has anyone else seen this kind of corruption or are we, once again, unique? Regards, Richard Schuh
Re: Corrupted IPL Record
It is almost funny. The only virus on our system is our ESM. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Tuesday, October 31, 2006 6:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject:Re: Corrupted IPL Record As for the VM:Secure thing, I find that simply documenting how the product can screw up a system is not only an unacceptable answer, it borders on repugnance. A strategic product that should always be working should never violate the integrity of the system. There is no justification for it. The changed allocation on the disk must be respected. Reallocating a disk is a normal maintenance activity. I'll second this comment. This is a serious bug impacting system integrity. Documenting the bug is not an acceptable response. -- db
Re: Corrupted IPL Record
Your symptoms sound very much like a FORMAT was done on cylinder 0 of the disk. If you do a FORMAT without the IPL data it will write in record 2 an IPL program to put the processor in a hard wait. It will also write the dummy VTOC and an allocation map showing the entire pack is PERM space. Then you did an ALLOCATE which fixed the allocation map for the disk. Look at the other tracks on cylinder 0. If they were erased then that is probably what happened. If the other tracks on cylinder 0 were not erased then I have no idea what could have happened. [EMAIL PROTECTED] wrote: Just ALLOCATE. Format would have been more devastating. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Monday, October 30, 2006 1:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject:Re: Corrupted IPL Record You didn't perform both FORMAT and ALLOCATE? Kris, IBM Belgium, VM customer support Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 2006-10-30 21:32 Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Corrupted IPL Record If this shows up twice, I apologize. I first sent it 2 hours ago and it hasn't hit the archives as yet. Over the weekend, we upgraded our final system to 5.2. As a part of the migration, we changed old PARM extents to PERM and allocated new PARM extents. When we tried to ipl the system, there were errors that led me to the conclusion that the IPL program had been corrupted. Using DDR on another system, I observed that record 0 0 2 had been completely wiped out. There were a few scattered bits that were not 0 in the first 100-200 bytes, nothing that was any kind of pattern, and the rest of the record was all 0. Records 1, and 3-6 were all as they should have been. I had to run SALIPL to fix the IPL program. I am not blaming CPFMTXA ALLOCATE because I think it highly unlikely that it was the cause. I suspect that something else happened between the previous IPL and yesterday's failed attempt. Has anyone else seen this kind of corruption or are we, once again, unique? Regards, Richard Schuh -- 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: Corrupted IPL Record
Neither one is on the system where the corruption occurred. It is so specialized and stable that there is rarely any need to even look at the directory, much less update it. We have access to the disks from our main VM system, so we allocate new M-disks there using VM:Secure and copy the resulting mdisk statements to the small system. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of O'Brien, Dennis L Sent: Tuesday, October 31, 2006 1:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Corrupted IPL Record Richard, Yes, ending VM:Secure before reallocating the object directory disk would be sufficient. I'd do the same on a system with DIRMAINT. Even if DIRMAINT doesn't cache the allocation map, I wouldn't want it updating the active cylinders while I was reallocating them. Dennis There are 10 kinds of people in the world; those that understand binary and those that don't. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Monday, October 30, 2006 16:19 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Corrupted IPL Record No VM:Secure. The problem occurred on a small, special purpose machine that is accessed only via Secure TN3270. There are only 4 terminal addresses defined and they are all logged on in a secure room. There are no network connections except for an NJE link to our main VM system. It is used for submitting jobs and sending files to the appropriate z/OS systems. It is one-way communication. There isnt any need for a heavyweight ESM. This was a new error to me. The normal sequence of an IPL is: Record 0/0/1 is read in to location 0. It contains the IPL PSW, IPL CCW1 and IPL CCW2. A TIC to IPL CCW1 is done. CCW1 reads the first record of the initialization program. CCW2 is executed. it either reads the rest of the IPL program or TICs to a location in the record just read to load the rest of the init pgm. When the channel program ends successfully, the IPL PSW is loaded and the init pgm loads and starts the O/S. The allocation map is not used until after CP is started. We were failing when step 4 was supposed to occur. The first record of the init pgm was the one that was corrupted. Record 4, where the allocation map lives, was not touched. Is there something in the system that arbitrarily rewrites these IPL records? How about record 3, the volume label? The pseudo VTOC (records 5 and 6)? As for the VM:Secure thing, I find that simply documenting how the product can screw up a system is not only an unacceptable answer, it borders on repugnance. A strategic product that should always be working should never violate the integrity of the system. There is no justification for it. The changed allocation on the disk must be respected. Reallocating a disk is a normal maintenance activity. If the documentation change is the answer, someone needs to update the documentation for CPFMTXA/ICKDSF with a very stern warning about the potential for disaster if VM:Secure is running when a disk is being reallocated. Would I be presumptuous in thinking that ending VM:Secure before reallocating the disk would be a sufficient precaution? Even that would be a problem for us. The Rules Facility is heavily used in our environment. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Mike Walter Sent: Monday, October 30, 2006 1:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Corrupted IPL Record Were you running VM:Secure on that system? Are the DRCT cylinders on that IPL DASD? If so, this may help. When VM:Secure starts up, it reads the whole allocation bit map of the DASD with the source directory minidisk (usually: VMSECURE 01B0). Each time VM:Secure rebuilds the object directory cylinders (msg: VMXRXB0740I The dynamic REBUILD has completed. Directory maintenance activity will now resume.) it completely re-writes ALL of the allocation bitmap (as it was when VM:Secure came up) from its cached copy, except for updates to the bits in the DRCT cyls. That bit us (excuse the pun) a couple Sunday IPLs in a row when the newly expanded PARM disk kept getting changed back to its old size. The back end of the newly updated SYSTEM CONFIG happened to have 4K blocks allocated on the new cylinders. When VM:Secure re-wrote the PARM allocation map size/location (begin location did not change, just the end), it chopped off the last half or so of the SYSTEM CONFIG. CP happily came up without error because the truncation just happened to be between SYSTEM CONFIG statements. To diagnose it, I wrapped SYSTEM CONFIG with confirmatory messages issued as it runs: Say Beginning: 'SYSTEM CONFIG' from MAINT's CF1 disk... TOLERATE_CONFIG_ERRORS NO ... rest of statements... Say Completed: 'SYSTEM
Re: Corrupted IPL Record
can you post the DDR dump of the corrupted record ? Schuh, Richard wrote: Neither one is on the system where the corruption occurred. It is so specialized and stable that there is rarely any need to even look at the directory, much less update it. We have access to the disks from our main VM system, so we allocate new M-disks there using VM:Secure and copy the resulting mdisk statements to the small system. Regards, Richard Schuh -- Chris Langford, Cestrian Software: Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. z/FM - A toolbox for VM MVS at http://zfm.cestrian.com Deva Woodcrafting: Furniture creation, House remodeling, Wagon restoration etc.
Re: Corrupted IPL Record
If the DASD is accessible by more than one system, perhaps some activity on the other system is the source of the corruption. Brian Nielsen On Tue, 31 Oct 2006 13:29:48 -0800, Schuh, Richard [EMAIL PROTECTED] wrot e: Neither one is on the system where the corruption occurred. It is so specialized and stable that there is rarely any need to even look at the directory, much less update it. We have access to the disks from our main VM system, so we allocate new M-disks there using VM:Secure and copy the resulting mdisk statements to the small system. Regards, Richard Schuh
Re: Corrupted IPL Record
We were under a lot of time pressure and I, unfortunately, did not have my console spooled :-( I can say that it was unusual for there to be more than one bit on in a byte. The 1s were well scattered with lots of zeros in between and were not in any regular pattern that I could see. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Chris Langford Sent: Tuesday, October 31, 2006 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject:Re: Corrupted IPL Record can you post the DDR dump of the corrupted record ? Schuh, Richard wrote: Neither one is on the system where the corruption occurred. It is so specialized and stable that there is rarely any need to even look at the directory, much less update it. We have access to the disks from our main VM system, so we allocate new M-disks there using VM:Secure and copy the resulting mdisk statements to the small system. Regards, Richard Schuh -- Chris Langford, Cestrian Software: Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. z/FM - A toolbox for VM MVS at http://zfm.cestrian.com Deva Woodcrafting: Furniture creation, House remodeling, Wagon restoration etc.
Re: Corrupted IPL Record
Dennis is correct: I meant the DRCT cyls, not the source directory disk. sigh As Richard is not running VM:Secure on that system it does not affect his situation, but my previous post should be corrected for future searchers of this list.. Perry also pointed out offlist that he recollected that VM:Secure also rewrote the volser (at least in older releases). Ouch!! Maybe (hopefully) someone from CA is watching the list and will report back regarding the problem and some of the pointed responses. Maybe one day we can further update the subject on the list saying all fixed. Mike Walter Hewitt Associates O'Brien, Dennis L Dennis.L.O'[EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/30/2006 05:27 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Corrupted IPL Record I think Mike meant to say that when VM:Secure starts up, it reads the allocation bit map of the volume that has the object directory, not the source directory. The two are not necessarily on the same volume. Dennis O'Brien There are 10 kinds of people in the world; those that understand binary and those that don't. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday, October 30, 2006 13:02 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Corrupted IPL Record Were you running VM:Secure on that system? Are the DRCT cylinders on that IPL DASD? If so, this may help. When VM:Secure starts up, it reads the whole allocation bit map of the DASD with the source directory minidisk (usually: VMSECURE 01B0). Each time VM:Secure rebuilds the object directory cylinders (msg: VMXRXB0740I The dynamic REBUILD has completed. Directory maintenance activity will now resume.) it completely re-writes ALL of the allocation bitmap (as it was when VM:Secure came up) from its cached copy, except for updates to the bits in the DRCT cyls. That bit us (excuse the pun) a couple Sunday IPLs in a row when the newly expanded PARM disk kept getting changed back to its old size. The back end of the newly updated SYSTEM CONFIG happened to have 4K blocks allocated on the new cylinders. When VM:Secure re-wrote the PARM allocation map size/location (begin location did not change, just the end), it chopped off the last half or so of the SYSTEM CONFIG. CP happily came up without error because the truncation just happened to be between SYSTEM CONFIG statements. To diagnose it, I wrapped SYSTEM CONFIG with confirmatory messages issued as it runs: Say Beginning: 'SYSTEM CONFIG' from MAINT's CF1 disk... TOLERATE_CONFIG_ERRORS NO ... rest of statements... Say Completed: 'SYSTEM CONFIG' from MAINT's CF1 disk. Be careful of TOLERATE_CONFIG_ERRORS NO. Don't just drop it in without trying it live. There are non-syntactical errors which will pass CPSYNTAX (everyone DOES run CPSYNTAX **EVERY TIME** after changing SYSTEM CONFIG, right?), but will cause an IPL error. In our case, the missing 'Completed' statement confirmed the suspicion. And... explained why the system came up so half-configured (missing the last half or so of SYSTEM CONFIG). After reporting it to CA, they said they would update the doc, showing how VM:Secure can cause these sorts of problems. By chance, I had a conversation with the CPSYNTAX developer about an open PMR just last week. I suggested some type of new statement pairs which, if present, must BOTH be present as the first and last non-comment records in SYSTEM CONFIG (and perhaps IMBED files) to diagnose just this sort of error. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/30/2006 02:32 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Corrupted IPL Record If this shows up twice, I apologize. I first sent it 2 hours ago and it hasn't hit the archives as yet. Over the weekend, we upgraded our final system to 5.2. As a part of the migration, we changed old PARM extents to PERM and allocated new PARM extents. When we tried to ipl the system, there were errors that led me to the conclusion that the IPL program had been corrupted. Using DDR on another system, I observed that record 0 0 2 had been completely wiped out. There were a few scattered bits that were not 0 in the first 100-200 bytes, nothing that was any kind of pattern, and the rest of the record was all 0. Records 1, and 3-6 were all as they should have been. I had to run SALIPL to fix the IPL program. I am not blaming CPFMTXA ALLOCATE because I think it highly unlikely that it was the cause. I suspect that something else happened between
Re: Corrupted IPL Record
No VM:Secure. The problem occurred on a small, special purpose machine that is accessed only via Secure TN3270. There are only 4 terminal addresses defined and they are all logged on in a secure room. There are no network connections except for an NJE link to our main VM system. It is used for submitting jobs and sending files to the appropriate z/OS systems. It is one-way communication. There isnt any need for a heavyweight ESM. This was a new error to me. The normal sequence of an IPL is: Record 0/0/1 is read in to location 0. It contains the IPL PSW, IPL CCW1 and IPL CCW2. A TIC to IPL CCW1 is done. CCW1 reads the first record of the initialization program. CCW2 is executed. it either reads the rest of the IPL program or TICs to a location in the record just read to load the rest of the init pgm. When the channel program ends successfully, the IPL PSW is loaded and the init pgm loads and starts the O/S. The allocation map is not used until after CP is started. We were failing when step 4 was supposed to occur. The first record of the init pgm was the one that was corrupted. Record 4, where the allocation map lives, was not touched. Is there something in the system that arbitrarily rewrites these IPL records? How about record 3, the volume label? The pseudo VTOC (records 5 and 6)? As for the VM:Secure thing, I find that simply documenting how the product can screw up a system is not only an unacceptable answer, it borders on repugnance. A strategic product that should always be working should never violate the integrity of the system. There is no justification for it. The changed allocation on the disk must be respected. Reallocating a disk is a normal maintenance activity. If the documentation change is the answer, someone needs to update the documentation for CPFMTXA/ICKDSF with a very stern warning about the potential for disaster if VM:Secure is running when a disk is being reallocated. Would I be presumptuous in thinking that ending VM:Secure before reallocating the disk would be a sufficient precaution? Even that would be a problem for us. The Rules Facility is heavily used in our environment. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Mike Walter Sent: Monday, October 30, 2006 1:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Corrupted IPL Record Were you running VM:Secure on that system? Are the DRCT cylinders on that IPL DASD? If so, this may help. When VM:Secure starts up, it reads the whole allocation bit map of the DASD with the source directory minidisk (usually: VMSECURE 01B0). Each time VM:Secure rebuilds the object directory cylinders (msg: VMXRXB0740I The dynamic REBUILD has completed. Directory maintenance activity will now resume.) it completely re-writes ALL of the allocation bitmap (as it was when VM:Secure came up) from its cached copy, except for updates to the bits in the DRCT cyls. That bit us (excuse the pun) a couple Sunday IPLs in a row when the newly expanded PARM disk kept getting changed back to its old size. The back end of the newly updated SYSTEM CONFIG happened to have 4K blocks allocated on the new cylinders. When VM:Secure re-wrote the PARM allocation map size/location (begin location did not change, just the end), it chopped off the last half or so of the SYSTEM CONFIG. CP happily came up without error because the truncation just happened to be between SYSTEM CONFIG statements. To diagnose it, I wrapped SYSTEM CONFIG with confirmatory messages issued as it runs: Say Beginning: 'SYSTEM CONFIG' from MAINT's CF1 disk... TOLERATE_CONFIG_ERRORS NO ... rest of statements... Say Completed: 'SYSTEM CONFIG' from MAINT's CF1 disk. Be careful of TOLERATE_CONFIG_ERRORS NO. Don't just drop it in without trying it live. There are non-syntactical errors which will pass CPSYNTAX (everyone DOES run CPSYNTAX **EVERY TIME** after changing SYSTEM CONFIG, right?), but will cause an IPL error. In our case, the missing 'Completed' statement confirmed the suspicion. And... explained why the system came up so half-configured (missing the last half or so of SYSTEM CONFIG). After reporting it to CA, they said they would update the doc, showing how VM:Secure can cause these sorts of problems. By chance, I had a conversation with the CPSYNTAX developer about an open PMR just last week. I suggested some type of new statement pairs which, if present, must BOTH be present as the first and last non-comment records in SYSTEM CONFIG (and perhaps IMBED files) to diagnose just this sort of error. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating
Re: Corrupted IPL Record
You didn't perform both FORMAT and ALLOCATE? Kris, IBM Belgium, VM customer support Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 2006-10-30 21:32 Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Corrupted IPL Record If this shows up twice, I apologize. I first sent it 2 hours ago and it hasn't hit the archives as yet. Over the weekend, we upgraded our final system to 5.2. As a part of the migration, we changed old PARM extents to PERM and allocated new PARM extents. When we tried to ipl the system, there were errors that led me to the conclusion that the IPL program had been corrupted. Using DDR on another system, I observed that record 0 0 2 had been completely wiped out. There were a few scattered bits that were not 0 in the first 100-200 bytes, nothing that was any kind of pattern, and the rest of the record was all 0. Records 1, and 3-6 were all as they should have been. I had to run SALIPL to fix the IPL program. I am not blaming CPFMTXA ALLOCATE because I think it highly unlikely that it was the cause. I suspect that something else happened between the previous IPL and yesterday's failed attempt. Has anyone else seen this kind of corruption or are we, once again, unique? Regards, Richard Schuh
Re: Corrupted IPL Record
I think Mike meant to say that when VM:Secure starts up,
itreads the allocation bit map of the volume that has the object
directory, not the source directory. The two are not necessarily on the
same volume.
DennisO'BrienThere
are 10 kinds of people in the world; those that understand binary and those that
don't.
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mike WalterSent:
Monday, October 30, 2006 13:02To:
IBMVM@LISTSERV.UARK.EDUSubject: Re: [IBMVM] Corrupted IPL
Record
Were you running VM:Secure on that system?
Are the DRCT cylinders on that IPL DASD? If so, this may
help. When VM:Secure starts up, it reads
the whole allocation bit map of the DASD with the source directory minidisk
(usually: VMSECURE 01B0). Each time VM:Secure rebuilds the object
directory cylinders (msg: "VMXRXB0740I The dynamic REBUILD has completed.
Directory maintenance activity will now resume.") it completely re-writes
ALL of the allocation bitmap (as it was when VM:Secure came up) from its cached
copy, except for updates to the bits in the DRCT cyls. That bit us (excuse the pun) a couple Sunday IPLs in a row when the
newly expanded PARM disk kept getting changed back to its old size. The
back end of the newly updated SYSTEM CONFIG happened to have 4K blocks allocated
on the new cylinders. When VM:Secure re-wrote the PARM allocation map
size/location (begin location did not change, just the end), it chopped off the
last half or so of the SYSTEM CONFIG. CP happily came up without error
because the truncation just happened to be between SYSTEM CONFIG statements.
To diagnose it, I wrapped SYSTEM CONFIG with confirmatory messages issued
as it runs: Say "Beginning:
'SYSTEM CONFIG' from MAINT's CF1 disk..." TOLERATE_CONFIG_ERRORS NO
... rest of
statements... Say "Completed:
'SYSTEM CONFIG' from MAINT's CF1 disk." Be
careful of "TOLERATE_CONFIG_ERRORS NO". Don't just drop it in without
trying it live. There are non-syntactical errors which will pass CPSYNTAX
(everyone DOES run CPSYNTAX **EVERY TIME** after changing SYSTEM CONFIG,
right?), but will cause an IPL error. In our case, the missing 'Completed'
statement confirmed the suspicion. And... explained why the system came up
so half-configured (missing the last half or so of SYSTEM CONFIG).
After reporting it to CA, they said they would update
the doc, showing how VM:Secure can cause these sorts of problems.
By chance, I had a conversation with the CPSYNTAX
developer about an open PMR just last week. I suggested some type of new
statement pairs which, if present, must BOTH be present as the first and last
non-comment records in SYSTEM CONFIG (and perhaps IMBED files) to diagnose just
this sort of error.Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of
Hewitt Associates.
"Schuh, Richard"
[EMAIL PROTECTED] Sent by: "The IBM z/VM Operating System"
IBMVM@LISTSERV.UARK.EDU
10/30/2006 02:32 PM
Please respond
to"The IBM z/VM Operating System"
IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Corrupted IPL
Record
If this shows up twice, I apologize. I first sent it 2 hours ago and
it hasn't hit the archives as yet.Over the weekend, we upgraded our
final system to 5.2. As a part of the migration, we changed old PARM extents to
PERM and allocated new PARM extents. When we tried to ipl the system, there were
errors that led me to the conclusion that the IPL program had been corrupted.
Using DDR on another system, I observed that record 0 0 2 had been completely
wiped out. There were a few scattered bits that were not 0 in the first 100-200
bytes, nothing that was any kind of pattern, and the rest of the record was all
0. Records 1, and 3-6 were all as they should have been. I had to run
SALIPL to fix the IPL program. I am not blaming CPFMTXA ALLOCATE because
I think it highly unlikely that it was the cause. I suspect that something else
happened between the previous IPL and yesterday's failed attempt. Has anyone
else seen this kind of corruption or are we, once again, unique?
Regards,Richard Schuh
The information contained in this e-mail and any
accompanying documents may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient of this
message, or if this message has been addressed to you in error, please
immediately alert the sender by reply e-mail and then delete this message,
i
