>>That's correct and that's where I took the idea from. That concept >>needs improvements
>No doubt, but so far you haven't identified any defect that a new type >of catalog would resolve. I have identified the defect pretty well, except that you refuse to see that definition and go to circular arguments about semantics! I will explain rather than define: In z/OS you are confined to 44 characters and limited to however many levels could be expressed within that limit, but you do not need to tell the system where the file resides because that information is stored in the catalog. In Unix, you do not have those length and level limitations, but you need to be explicit in describing where the file is or go through the trouble of creating symbolic links. Both sides are awkward, require too much memorization and each one has a glaring defect as identified above. With the envisioned catalog, file names are not limited in length or form, yet the system would know where do they reside. In case of two (or more) files that share the same name, a sophisticated implementation may either decide by context (e.g. a file that is owned by the requester would be preferred to file owned by somebody else - THIS IS ONLY AN EXAMPLE, PLEASE DO NOT GET INTO SEMANTICS), or ask to disambiguate (e.g. supply only one level that is different between the files - AGAIN, THIS IS ONLY AN EXAMPLE, PLEASE DO NOT GET INTO SEMANTICS) ZA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
