In a recent note, McKown, John said: > Date: Fri, 15 Jul 2005 10:41:15 -0500 > > However, remember that many of the z/OS UNIX tools were not written by > IBM. IIRC, a company named MKS ported a number of the tools from some > other UNIX. I doubt that they rewrote any code using open() to use > fopen() so that MVS datasets would be supported. Of course, one could > wonder why open() was not written to support MVS datasets like fopen() > was. > This has been discussed at length in MVS-OE. It's not a tools issue; it's a kernel issue.
Think allocation. open() creates a descriptor which is inherited by the child process on fork(). fork() creates the child process in a separate address space. So, it's possible to open() a file in one address space and read() it in another. IBM chose not to inherit TIOTs, JFCBs, or open DCBs on fork(). How would you propagate to a different address space an allocation with an exclusive ENQ? You could invent a family of address spaces and make that the scope of ENQ. That would be a radical change to MVS, and would violate the protocol of process isolation from the POSIX point of view. IBM implemented fopen() to conform to ANSI C, which does not require descriptors, before ever conceiving of OpenEdition; then fudged POSIX, which does require fopen(), mightily by not propagating the (FILE *) created by fopen() in an effective manner to child processes. The alternative, without radically changing z/OS, would be to perform the allocation and actual I/O in a separate address space created specifically for that purpose. In effect this what NFS does. Try NFS sometime; you won't entirely like it. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
