Dean Kent (dkent@realworldtech.com) on 1/29/09 wrote:
---------------------------
>Being only somewhat familiar with Unix attributes, let me see if I understand what you are saying...
>
>In the zOS world, we do have specific file formats supported by the OS. Some of
>these contain some internal formatting information (record sizes, data/index locations
>and/or offsets, etc.) - however, we have an external file called a 'catalog' that
>contains most of the metadata about the file. This metadata has such information
>as the various dates (creation, update), number of records, what volume(s) it resides
>on, how many extents it has, record format, size, etc.
>
>This information is stored by name. If a copy of the file is made, the metadata
>is copied as well unless it is specifically overridden. If the file is renamed,
>the record in the database is updated to reflect the new name.
>
>Security is also external. File names in zOS are different than Unix in that they
>can only be 44 chars long, and are comprised of 'nodes' separated by a period.
>A node can only be 8 chars long. This can be limiting, but allows me to create
>data sets like "deankent.prod.file" and "deankent.test.file", etc. The high level
>qualifier is a good way to group files for a specific application (or user), while
>the middle one is a good way to group by location/level/etc. You can have more
>than 3 groups as long as you don't violate the 44 character limit, or the 8 character
>groupname limit. BTW, I know this is somewhat limiting, but I mention it only so I can describe how the security works.
>
>Security is usually set up by high level node name, with optional middle level
>(or lower). For example, I can have everything with 'deankent' set up as read
>only by default, but anything with a middle qualifier of 'test' can be modified
>by some defined group of developers. If the name changes to 'linust.whatever',
>my security no longer applies - yours does. We have certain defaults, like 'public.whatever'
>that allows us to rename files so *anyone* can read/modify/remove it.
>
>Anyway - I am wondering if this sort of scheme is what you are trying to describe,
>or if it is something a bit different. The attributes-attached-to-files concept
>that Unix (and Windows) uses has always seemed a bit strange to me, and somewhat
>more interesting to work with when trying to manage files.

In fact, the method of organization isn't so different between what you describe for zOS and anything else. In DOS the attributes like file name, size, creation time, and some flags are stored in a Directory, which is analogous to your Catalog. (The difference is that a Directory is essentially just another file, not a specially reserved disk area. And directories can contain other directories... But of course, you still need a specially reserved Root Directory to find the first file data.) In Unix the metadata is split between the Directory and the Inode; the directory just contains the name and an inode pointer, while the inode contains the size, datestamps, and permission bits, etc... Most OS designers realize that there's a base level of metadata that you must maintain about data, and for sanity's sake you must maintain that separately from the data. (E.g., where does the data live? Though I also recall working with some filesystems where the catalog only pointed to the first sector of the data, and the first 2 bytes of each sector contained the sector number of the next data block. Made it a fairly expensive operation to ask "how big is this file?" ...)