" A spool file can span spool volumes, and we need a way to identify the volume where each piece of the file is located."
That explains why VM fussed about some specific spool entries and not others. Those specific entries must span volumes. Question: if I would have entered a "GO" instead of "STOP", VM would have reformatted/initialized the spool. During this process is that when VM makes the association between pointers and slots, etc? If this is true, then with future IPL's I won't get these messages (providing I don't move volumes and slots around)? John, thanks for the explanation. Steve -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of John Franciscovich Sent: Monday, November 09, 2009 4:09 PM To: [email protected] Subject: Re: SYSTEM CONFIG file and slots >The question begs to be asked, Why is it done this way? (cue historians >and philosophers). > >It seems a little restrictive and not in the spirit of VM, that being >flexibility. This behavior is documented in the Usage Notes for the CP_OWNED statement in the CP Planning and Administration manual. A spool file can span spool volumes, and we need a way to identify the volume where each piece of the file is located. Internally, the metadata for a spool file includes an array of pointers to individual data blocks on disk that comprise the spool file. Each pointer, called an "ASA", includes the slot number, which identifies the volume where the data block resides. The array of pointers also resides on disk, and is also pointed to by an ASA. This is used to locate and restore the files during IPL. While this may seem restrictive in one sense, it also provides flexibility, allowing: - The device addresses to change - The volsers to change These make it easy to copy a system and its spool. John Franciscovich (not a historian or philosopher, just a developer) z/VM Development
