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 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, 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. 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.
