The allocation bit map created by CPFMTXA does not protect PERM space from being allocated to user MDISKs; rather, it indicates that the space does not contain any of the areas belonging to CP and that it is available for allocation to normal MDISKs. If you want cylinder 0 from being listed as FREE in a disk map, it must be included as the starting cylinder of a minidisk. It does not matter what the value of the entry in the allocation bit map, it is the MDISK definition that affords the protection. Even with that "protection", it is still possible for you to shoot yourself in the foot, it is just a little more difficult for you to do so. The protection is only as good as the sysprog or directory management software that enforces it. It is sort of like a lock, whose only function is to keep the honest folk out.
As pointed out in an earlier note, It is still possible to CPFMTXA allocate 0-end to page or spool and define cylinder 0 as a minidisk. The volume label and allocation map will occupy part of 0/0/0, leaving the remaining tracks of cylinder 0 for use as PAGE or SPOL if you wish to do so. That is supported by CP. There is no compelling reason for making cylinder 0 PERM on a page or spool disk, as that designation does nothing to protect the vital area of the cylinder. Why not allocate cylinder 0 as PAGE or SPOL when appropriate and still create the cylinder 0 minidisk. I heartily agree with the practice of allocating whole volumes to page or to spool, and have done so for many, many years. I am sure that all of the performance gurus and many others on this list would agree with the idea. That said, thinking that allocating cylinder 0 as PERM somehow protects the space is an urban myth, much like the earlier idea that making files mode 0 hid them. In fact, PERM actually opens cyl 0 up to being allocated and overwritten. If the space is PERM, CP does not even try to protect it. On the other hand, having it PAGE or SPOL on a volume that is in use by the system will cause CP to protect it from all but willful intent. That is more like a lock enforced by S&W. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of John P. Baker > Sent: Tuesday, June 24, 2008 3:51 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Allocating Cyl Zero as Perm (Was: Performance > toolkit under zVM 5.3) > > Every site that I have been associated with has operated > under the premise that, with the exception of full pack > minidisks, cylinder zero (0) is ALWAYS allocated PERM, and a > one (1) cylinder reserved space minidisk is placed in the > directory for each volume in recognition of that fact. > > Since at least VM/ESA 2.4.0, and probably significantly > earlier, CP does not use the page slots which would be > located on cylinder zero (0) track zero (0), see HCPMSACR > MACRO for more information, so there is no likelihood of the > volume label being overwritten by CP. > > However, a problem can arise if paging or spooling space is > allocated starting on cylinder zero (0), and subsequently > that space is reallocated for user minidisks without taking > into account the need to allocate a one > (1) cylinder placeholder. > > To my mind, best practices should dictate either (1) page and > spool space will ALWAYS be segregated onto volumes used > solely for that purpose, or (2) all volumes SHALL be > allocated with a permanent one (1) cylinder type(PERM) > placeholder at cylinder zero (0). > > John P. Baker > > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern > Sent: Tuesday, June 24, 2008 5:35 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Allocating Cyl Zero as Perm (Was: Performance > toolkit under zVM > 5.3) > > I have never seen a problem with CP stepping on the Label. I > have stepped on it myself and seen other inexperienced people > step on it. > That is why I always allocate cylinder zero of a VM volume as > perm and allocate a one cylinder minidisk owned by VMDASD > there. That is the "best practices" guideline that I follow. > > /Tom Kern >
