This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||
|
I'm confused about this article, is it a FILESYSTEM (like FAT, ext2, ReiserFS) or a FILE-FORMAT (magic numbers, file extension) system? Improfane
A: It's not about a specific file system, but rather the whole class of filesystems that support record-oriented operation. The key point is that the system calls used to access files are designed to access records, rather than chunks of data read or written in application-specific formats. Most mainframe operating systems support a rich variety of record-oriented record formats. Most commonly, records are fixed in length within any given file, or a file may have variable-length records. Unlike the stream-oriented systems found on systems like Unix, PC-DOS, Windows, and Mac, the data in the file is accessed strictly in terms of records. Variable-length records are preceded by a (usually) binary byte-count, and may contain any coded bytes at all, both binary and characters. There is no concept of an "end of line" delimiter, such as a carriage-return character.
Some people, particularly Unix advocates, dismiss record-oriented file systems as being based on punched-card technology, and therefore presumably "old-fashioned." The Unix-like stream-oriented approach is modelled after another 19th century technology, that of the paper-tapes used by the printing telegraph, used to mechanize the transmission of telegrams. These started being used for computers in the form of Teletype machines used as inexpensive input devices by the mini-computers of the '60s and '70s.
For its part, the Hollerith punched card was at least originally conceived for computational purposes.
This article, it seems to me, was written by a Unix advocate who wished to diminish the advantages of record-oriented file access methods. It is clearly not NPOV. I plan to fix it, when I find time to address the matter properly.
-- RussHolsclaw 04:23, 12 February 2006 (UTC)
IBM calls file systems Access Methods.
Paper tape as used for text message transmission actually contain individual records which are delimited by various control characters. Each line of text (aka record) is terminated be a carriage-return character (which sends the print head to the left) and a line-feed character which rolls the paper platen up a line in position for the next line.
A better example of a datastream used in punched tape is in a numerical controlled machine tools NC These use a stream of commands to define which cutting tool to use, the starting position, subsequent points along the cutting path and other control information.
A record oriented file has several advantages. After a program writes a collection of data as a record the program that reads that record has the understanding of that data as a collection. Although it is permitted to read only the beginning of a record, the next sequential read returns the next collection of data (record) that the writer intended to be grouped together. Another advantage is that the record has a length and there is no restriction on the bit patterns composing the data record, i.e. there is no delimiter character.
There is a cost associated with record oriented. The length definition takes up space. On a magnetic tape that definition takes the form of an inter-record gap. On a disk a meta data area must be allocated. This is minimal in a file where all the records are the same length. On a file composed of varying length records a maximum record length is defined to determine the size of the length metadata associated with each record.
DGerman ( talk) 01:09, 7 February 2008 (UTC)
After adding all this information in the discussion page, I decided it best to basically rewrite the article. I have saved the original article if anyone wants it. It is also available in the wiki history. Tired now. In the future I may locate and include some references. DGerman ( talk) 02:15, 7 February 2008 (UTC)
While it is true that current IBM mainframe operating systems have record-oriented file systems that do not use delimitor characters, that is not universally true. Even IBM used record delimitors on the 14xx/7010, and RCA used them on several different product lines. Shmuel (Seymour J.) Metz ( talk) 19:04, 1 June 2010 (UTC)
The first problem is that the section doesn't clearly indicate with what a record-oriented file system is being compared.
Is it being compared to a byte-stream file system such as those offered by UN*Xes and Windows, where the lowest-level file system operations are "read N bytes from the current location and advance the current location pointer by N bytes", "write N bytes to the current location and advance the current location pointer by N bytes", "move the current location pointer to byte N", "adjust the current location pointer by N bytes, N being positive or negative", and "move the current location pointer to the current end of the file and then adjust it by N bytes, N being positive or negative" (possibly with an additional operation to set the file size to a specified number of bytes)?
Is it being compared with a block-array file system, where the lowest-level file system operations are "read from N blocks starting from block M" and "write to N blocks starting from M", "block" here referring to some fixed physical block size, such as a "block" being a single disk sector? As I remember, the usual file system APIs of RSX-11M and VMS were record-oriented, but the layer offered by the file system code was more like a block array, with QIO calls to read from or write to a file, with, at least on VMS, user-mode code being required to go through RMS, but RMS, running in a more privileged mode, doing file I/O in response to requests by making those QIO calls?
Or is it being compared to other file system types, or to more than one file system type?
If it's being compared to byte-stream file systems (as used on most desktop/notebook computers, most smartphones and tablets, and a lot of servers), then note that a byte-stream file can be structured as a sequence of records, and there are frequently libraries for OSes with byte-stream files that do so (sometimes called, for example, "ISAM packages"), so it's not clear how some of the points apply.
A record oriented file has several advantages. After a program writes a collection of data as a record the program that reads that record has the understanding of those data as a collection.
What does it mean to "[have] the understanding of those data as a collection"? And, if the program that reads that record is doing so through a library that implements a record structure on a byte-stream file system, would that program also "[have] the understanding of those data as a collection"?
Often a file will contain several related records in sequence; after the program reads the beginning of the sequence, the next sequential read returns the next collection of data (record) that the writer intended to be grouped together.
That's the definition of a sequential read. Again, how is this different from a program using a record-oriented library for a byte-stream file?
Another advantage is that the record has a length and there is usually no restriction on the bit patterns composing the data record, i.e. there is no delimiter character.
Not all files in a byte-stream file system have delimiter characters. Text files typically do, but object file, executable image files, library files, database files, and many other file types do not. Many of them have structures in the file that are, in effect, records with a record length field in the record.
There is usually a cost associated with record oriented files. For fixed length records, some records may have unused space, while for variable length records the delimiter or length field takes up space. Variable length blocks may have overhead due to delimiters or length fields.
That would also apply to record structures atop a byte-oriented file system.
In addition, there is overhead imposed by the device. On a magnetic tape overhead typically takes the form of an inter-record gap.
That's a characteristic of a magnetic tape, not of a record-oriented file system; the only way to reduce that would be to accumulate many logical records in a physical record/block on the tape.
On a direct access device with fixed length sectors, there may be unused space in the last sector of a block.
That's true only if records aren't allowed to begin in the middle of a sector. Record-oriented file systems may choose to do so, so that they don't need to do the sort of buffering that byte-stream file systems do, but a library implementing records atop a byte-stream file system might also do so in order to avoid some of the buffering overhead.
On a direct access device with variable length physical records, that overhead typically takes the form of metadata and inter-record gaps.
True, although multiple logical records might be packed into a single physical record/block, just as on tape. This may be somewhat specific to S/360 and successors (and compatibles); minicomputers tended to use direct access devices with fixed block/sector sizes, as do personal computing devices and UN*X/Windows-based servers.
A major advantage of record-oriented file systems is that they abstract files kept on paper in earlier times. A record might contain data associated with a particular, e.g., building, contact, employee, part, venue.
Again, that's just a question of which software abstracts files; again, it's quite possible to implement records atop a byte-oriented - or block-array - file system.
A second motivator for the idea of record orientation is that it is in some sense the more natural orientation for persistent storage on a non-volatile but slow physical storage device. Most physical storage devices can communicate only in units of a block. Significant portions of modern operating system kernels and associated device drivers are devoted to hiding the naturally structured and delimited (and in some sense a block is just a physical record) nature of physical storage devices.
Operating system kernels, yes; the buffer caches of UN*Xes and Windows, and the per-open-file OS data structures that maintain the aforementioned current location pointer, do hide the block structure. However, given that records don't necessariy directly correspond to blocks, some code will have to hide the blocks, to some degree, from applications reading or writing records.
Associated device drivers, not really; they generally get "read from N sectors, starting at sector M of the disk" and "write to N sectors, starting at sector M of the disk" commands, with the - byte-stream, block-array, or record-oriented - file system code, some or all of which may be running in some privileged-mode section of the OS, translating block offsets within the file to physical sector numbers on the disk. (Or logical block numbers, if the disk itself maps logical block numbers to physical sector numbers; there may be further mapping with virtualized storage, etc..) Guy Harris ( talk) 10:17, 23 September 2023 (UTC)
Trying to emulate IBM’s record-oriented system in Linux for Iron-Spring PL/I I frequently found myself wishing for CKD disks to simplify other-than-sequential access to variable length records.The advantage of doing so on VMS would have been that somebody at DEC already may have wished for something to to simplify other-than-sequential access to variable length records, so you wouldn't have had to solve that problem, DEC already did it for you.
IBM had record oriented file systems before CKD. GE never had CKD, yet GEFRC in GECOS was record oriented. AFAIK, DEC never had CKD, yet RMS is record oriented.Yes, that's why I said "S/3x0 is different" and discussed DEC systems, where the service the hardware provides is "a disk is an array of fixed-length physical blocks"; the UNIX byte-stream APIs were originally implemented on DEC hardware, and the other hardware on which UN*Xes run include, with the exception(?) of S/3x0 and z/Architecture, secondary storage providing the "a disk is an array of fixed-length physical blocks" service. (I don't know what mechanism the drivers used and use on various UN*Xes for S/3x0 and z/Architecture, including Linux; I suspect they just write fixed-length physical records.)
Both byte oriented and record oriented are abstractions, and IBM has implemented byte oriented on top of record oriented.And libraries for UN*Xes and, presumably, Windows have implemented record-oriented on top of byte-oriented. Byte-oriented and record-oriented are characteristics of APIs, not of file systems. Some operating systems provide a byte-oriented API atop which record-oriented APIs can be implemented (UN*Xes, Windows); other operating systems provide an API that includes block-oriented and record-oriented APIs and that support byte-stream text files using the record-orinted APIs (VMS).
Access methods and file systems are closely related, but not identical. Yes. For the file systems (in the "on-disk data structures and lowest-level OS code" sense) on UN*Xes, Windows, and VMS, the file system code provides either block-oriented (VMS) or byte-stream oriented (UN*Xes, Windows) access.
In Linux there are still multiple file systems.In UN*Xes since at least SunOS 2.0, there have been mechanisms into which various various file system implementations can be plugged; not all of those implementations even work atop local storage devices. The non-specialized ones (for example, not /proc or /sys or other oddball ones) provide a byte-stream service; access methods rarely, if ever, have to care which particular file system they're using. This is likely to continue to be the case, for a variety of reasons, for the near-term future; I don't see "multiple file systems" going away soon. Guy Harris ( talk) 19:53, 26 September 2023 (UTC)
I like using access methods in the title, but some might view it as IBM-centric. What other vendors used the term?
A file system is associated with an API, although the API between phisical file system and logical file system might only be accessible by the access method. -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 12:56, 27 September 2023 (UTC)
The record access mode (RAC) field indicates the method of retrieving or inserting records in the file; that is, whether records are read (or written) sequentially, directly, or by record file address. Only one access method can be specified for any single record operation, but you can change the record access mode between record operations.
NTCreateFile
and byte-stream-oriented NtReadFile()
and NtWriteFile()
calls, atop which the byte-stream-oritned Windows file access API runs. I'm not sure where in the privileged-mode code the byte-stream abstraction is implemented; it probably involves the privileged-mode cache manager, as is the case in UN*Xes.Somewhere in the system - I would assume IOS rather than the access methods - "When an EXCP request is submitted for a DASD device MVS gets the seek address from the IOB, validates it against the DEB to verify it is contained within an extent of the dataset. If the seek address is not contained within a valid dataset extent the request is rejected. If the seek address is valid then MVS builds a SEEK CCW using the IOB seek address. A SET FILE MASK CCW is then chained on to the SEEK CCW. The SET FILE MASK specifies what types of CCW commands may follow....There may only be one SET FILE MASK command in a CCW sequence. This keeps the user CCW program from accessing tracks outside the dataset extents. It also enforces read-only for datasets opened for input. " [1]:*I have the impression that OS/360's access methods constructed channel programs, making EXCP and XDAP the lowest-level API, but, in OS/360 and its successors, were the access methods trusted not to go outside the bounds of a data set, did either of those SVCs(?) reject channel programs that went outside the bounds of the data set, or was something else done?
References
I've been sort of following the discussion over the name of this article. It seems to me that a "filesystem" has two parts - how the data is stored on disk, and the API offered to the users. IMO "record-oriented" vs. "byte-oriented" (or stream) is determined by the API. In OS/360, before the term "filesystem" was invented, The API is structured to read "records", of various types. You could certainly treat the data as a stream, but it would be a lot more work. Likewise, in Linux systems you can impose a record structure on top of an unstructured byte stream, but it requires effort. RO vs. BO is a data structuring convention. Peter Flass ( talk) 14:50, 28 September 2023 (UTC)
EXCP
would be called - "physical-record-oriented"?EXCP
I/O to files is allowed to be done by arbitrary applications on arbitrary files, arguably OS/360 also offers an API layer below the record-oriented APIs.iom_$<routine name>
or ios_$<routine name>
.iox_$<routine name>
. I seem to remember some MIT folk not thinking all that highly of it, perhaps finding it to suffer from "second system syndrome".Notes
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||
|
I'm confused about this article, is it a FILESYSTEM (like FAT, ext2, ReiserFS) or a FILE-FORMAT (magic numbers, file extension) system? Improfane
A: It's not about a specific file system, but rather the whole class of filesystems that support record-oriented operation. The key point is that the system calls used to access files are designed to access records, rather than chunks of data read or written in application-specific formats. Most mainframe operating systems support a rich variety of record-oriented record formats. Most commonly, records are fixed in length within any given file, or a file may have variable-length records. Unlike the stream-oriented systems found on systems like Unix, PC-DOS, Windows, and Mac, the data in the file is accessed strictly in terms of records. Variable-length records are preceded by a (usually) binary byte-count, and may contain any coded bytes at all, both binary and characters. There is no concept of an "end of line" delimiter, such as a carriage-return character.
Some people, particularly Unix advocates, dismiss record-oriented file systems as being based on punched-card technology, and therefore presumably "old-fashioned." The Unix-like stream-oriented approach is modelled after another 19th century technology, that of the paper-tapes used by the printing telegraph, used to mechanize the transmission of telegrams. These started being used for computers in the form of Teletype machines used as inexpensive input devices by the mini-computers of the '60s and '70s.
For its part, the Hollerith punched card was at least originally conceived for computational purposes.
This article, it seems to me, was written by a Unix advocate who wished to diminish the advantages of record-oriented file access methods. It is clearly not NPOV. I plan to fix it, when I find time to address the matter properly.
-- RussHolsclaw 04:23, 12 February 2006 (UTC)
IBM calls file systems Access Methods.
Paper tape as used for text message transmission actually contain individual records which are delimited by various control characters. Each line of text (aka record) is terminated be a carriage-return character (which sends the print head to the left) and a line-feed character which rolls the paper platen up a line in position for the next line.
A better example of a datastream used in punched tape is in a numerical controlled machine tools NC These use a stream of commands to define which cutting tool to use, the starting position, subsequent points along the cutting path and other control information.
A record oriented file has several advantages. After a program writes a collection of data as a record the program that reads that record has the understanding of that data as a collection. Although it is permitted to read only the beginning of a record, the next sequential read returns the next collection of data (record) that the writer intended to be grouped together. Another advantage is that the record has a length and there is no restriction on the bit patterns composing the data record, i.e. there is no delimiter character.
There is a cost associated with record oriented. The length definition takes up space. On a magnetic tape that definition takes the form of an inter-record gap. On a disk a meta data area must be allocated. This is minimal in a file where all the records are the same length. On a file composed of varying length records a maximum record length is defined to determine the size of the length metadata associated with each record.
DGerman ( talk) 01:09, 7 February 2008 (UTC)
After adding all this information in the discussion page, I decided it best to basically rewrite the article. I have saved the original article if anyone wants it. It is also available in the wiki history. Tired now. In the future I may locate and include some references. DGerman ( talk) 02:15, 7 February 2008 (UTC)
While it is true that current IBM mainframe operating systems have record-oriented file systems that do not use delimitor characters, that is not universally true. Even IBM used record delimitors on the 14xx/7010, and RCA used them on several different product lines. Shmuel (Seymour J.) Metz ( talk) 19:04, 1 June 2010 (UTC)
The first problem is that the section doesn't clearly indicate with what a record-oriented file system is being compared.
Is it being compared to a byte-stream file system such as those offered by UN*Xes and Windows, where the lowest-level file system operations are "read N bytes from the current location and advance the current location pointer by N bytes", "write N bytes to the current location and advance the current location pointer by N bytes", "move the current location pointer to byte N", "adjust the current location pointer by N bytes, N being positive or negative", and "move the current location pointer to the current end of the file and then adjust it by N bytes, N being positive or negative" (possibly with an additional operation to set the file size to a specified number of bytes)?
Is it being compared with a block-array file system, where the lowest-level file system operations are "read from N blocks starting from block M" and "write to N blocks starting from M", "block" here referring to some fixed physical block size, such as a "block" being a single disk sector? As I remember, the usual file system APIs of RSX-11M and VMS were record-oriented, but the layer offered by the file system code was more like a block array, with QIO calls to read from or write to a file, with, at least on VMS, user-mode code being required to go through RMS, but RMS, running in a more privileged mode, doing file I/O in response to requests by making those QIO calls?
Or is it being compared to other file system types, or to more than one file system type?
If it's being compared to byte-stream file systems (as used on most desktop/notebook computers, most smartphones and tablets, and a lot of servers), then note that a byte-stream file can be structured as a sequence of records, and there are frequently libraries for OSes with byte-stream files that do so (sometimes called, for example, "ISAM packages"), so it's not clear how some of the points apply.
A record oriented file has several advantages. After a program writes a collection of data as a record the program that reads that record has the understanding of those data as a collection.
What does it mean to "[have] the understanding of those data as a collection"? And, if the program that reads that record is doing so through a library that implements a record structure on a byte-stream file system, would that program also "[have] the understanding of those data as a collection"?
Often a file will contain several related records in sequence; after the program reads the beginning of the sequence, the next sequential read returns the next collection of data (record) that the writer intended to be grouped together.
That's the definition of a sequential read. Again, how is this different from a program using a record-oriented library for a byte-stream file?
Another advantage is that the record has a length and there is usually no restriction on the bit patterns composing the data record, i.e. there is no delimiter character.
Not all files in a byte-stream file system have delimiter characters. Text files typically do, but object file, executable image files, library files, database files, and many other file types do not. Many of them have structures in the file that are, in effect, records with a record length field in the record.
There is usually a cost associated with record oriented files. For fixed length records, some records may have unused space, while for variable length records the delimiter or length field takes up space. Variable length blocks may have overhead due to delimiters or length fields.
That would also apply to record structures atop a byte-oriented file system.
In addition, there is overhead imposed by the device. On a magnetic tape overhead typically takes the form of an inter-record gap.
That's a characteristic of a magnetic tape, not of a record-oriented file system; the only way to reduce that would be to accumulate many logical records in a physical record/block on the tape.
On a direct access device with fixed length sectors, there may be unused space in the last sector of a block.
That's true only if records aren't allowed to begin in the middle of a sector. Record-oriented file systems may choose to do so, so that they don't need to do the sort of buffering that byte-stream file systems do, but a library implementing records atop a byte-stream file system might also do so in order to avoid some of the buffering overhead.
On a direct access device with variable length physical records, that overhead typically takes the form of metadata and inter-record gaps.
True, although multiple logical records might be packed into a single physical record/block, just as on tape. This may be somewhat specific to S/360 and successors (and compatibles); minicomputers tended to use direct access devices with fixed block/sector sizes, as do personal computing devices and UN*X/Windows-based servers.
A major advantage of record-oriented file systems is that they abstract files kept on paper in earlier times. A record might contain data associated with a particular, e.g., building, contact, employee, part, venue.
Again, that's just a question of which software abstracts files; again, it's quite possible to implement records atop a byte-oriented - or block-array - file system.
A second motivator for the idea of record orientation is that it is in some sense the more natural orientation for persistent storage on a non-volatile but slow physical storage device. Most physical storage devices can communicate only in units of a block. Significant portions of modern operating system kernels and associated device drivers are devoted to hiding the naturally structured and delimited (and in some sense a block is just a physical record) nature of physical storage devices.
Operating system kernels, yes; the buffer caches of UN*Xes and Windows, and the per-open-file OS data structures that maintain the aforementioned current location pointer, do hide the block structure. However, given that records don't necessariy directly correspond to blocks, some code will have to hide the blocks, to some degree, from applications reading or writing records.
Associated device drivers, not really; they generally get "read from N sectors, starting at sector M of the disk" and "write to N sectors, starting at sector M of the disk" commands, with the - byte-stream, block-array, or record-oriented - file system code, some or all of which may be running in some privileged-mode section of the OS, translating block offsets within the file to physical sector numbers on the disk. (Or logical block numbers, if the disk itself maps logical block numbers to physical sector numbers; there may be further mapping with virtualized storage, etc..) Guy Harris ( talk) 10:17, 23 September 2023 (UTC)
Trying to emulate IBM’s record-oriented system in Linux for Iron-Spring PL/I I frequently found myself wishing for CKD disks to simplify other-than-sequential access to variable length records.The advantage of doing so on VMS would have been that somebody at DEC already may have wished for something to to simplify other-than-sequential access to variable length records, so you wouldn't have had to solve that problem, DEC already did it for you.
IBM had record oriented file systems before CKD. GE never had CKD, yet GEFRC in GECOS was record oriented. AFAIK, DEC never had CKD, yet RMS is record oriented.Yes, that's why I said "S/3x0 is different" and discussed DEC systems, where the service the hardware provides is "a disk is an array of fixed-length physical blocks"; the UNIX byte-stream APIs were originally implemented on DEC hardware, and the other hardware on which UN*Xes run include, with the exception(?) of S/3x0 and z/Architecture, secondary storage providing the "a disk is an array of fixed-length physical blocks" service. (I don't know what mechanism the drivers used and use on various UN*Xes for S/3x0 and z/Architecture, including Linux; I suspect they just write fixed-length physical records.)
Both byte oriented and record oriented are abstractions, and IBM has implemented byte oriented on top of record oriented.And libraries for UN*Xes and, presumably, Windows have implemented record-oriented on top of byte-oriented. Byte-oriented and record-oriented are characteristics of APIs, not of file systems. Some operating systems provide a byte-oriented API atop which record-oriented APIs can be implemented (UN*Xes, Windows); other operating systems provide an API that includes block-oriented and record-oriented APIs and that support byte-stream text files using the record-orinted APIs (VMS).
Access methods and file systems are closely related, but not identical. Yes. For the file systems (in the "on-disk data structures and lowest-level OS code" sense) on UN*Xes, Windows, and VMS, the file system code provides either block-oriented (VMS) or byte-stream oriented (UN*Xes, Windows) access.
In Linux there are still multiple file systems.In UN*Xes since at least SunOS 2.0, there have been mechanisms into which various various file system implementations can be plugged; not all of those implementations even work atop local storage devices. The non-specialized ones (for example, not /proc or /sys or other oddball ones) provide a byte-stream service; access methods rarely, if ever, have to care which particular file system they're using. This is likely to continue to be the case, for a variety of reasons, for the near-term future; I don't see "multiple file systems" going away soon. Guy Harris ( talk) 19:53, 26 September 2023 (UTC)
I like using access methods in the title, but some might view it as IBM-centric. What other vendors used the term?
A file system is associated with an API, although the API between phisical file system and logical file system might only be accessible by the access method. -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 12:56, 27 September 2023 (UTC)
The record access mode (RAC) field indicates the method of retrieving or inserting records in the file; that is, whether records are read (or written) sequentially, directly, or by record file address. Only one access method can be specified for any single record operation, but you can change the record access mode between record operations.
NTCreateFile
and byte-stream-oriented NtReadFile()
and NtWriteFile()
calls, atop which the byte-stream-oritned Windows file access API runs. I'm not sure where in the privileged-mode code the byte-stream abstraction is implemented; it probably involves the privileged-mode cache manager, as is the case in UN*Xes.Somewhere in the system - I would assume IOS rather than the access methods - "When an EXCP request is submitted for a DASD device MVS gets the seek address from the IOB, validates it against the DEB to verify it is contained within an extent of the dataset. If the seek address is not contained within a valid dataset extent the request is rejected. If the seek address is valid then MVS builds a SEEK CCW using the IOB seek address. A SET FILE MASK CCW is then chained on to the SEEK CCW. The SET FILE MASK specifies what types of CCW commands may follow....There may only be one SET FILE MASK command in a CCW sequence. This keeps the user CCW program from accessing tracks outside the dataset extents. It also enforces read-only for datasets opened for input. " [1]:*I have the impression that OS/360's access methods constructed channel programs, making EXCP and XDAP the lowest-level API, but, in OS/360 and its successors, were the access methods trusted not to go outside the bounds of a data set, did either of those SVCs(?) reject channel programs that went outside the bounds of the data set, or was something else done?
References
I've been sort of following the discussion over the name of this article. It seems to me that a "filesystem" has two parts - how the data is stored on disk, and the API offered to the users. IMO "record-oriented" vs. "byte-oriented" (or stream) is determined by the API. In OS/360, before the term "filesystem" was invented, The API is structured to read "records", of various types. You could certainly treat the data as a stream, but it would be a lot more work. Likewise, in Linux systems you can impose a record structure on top of an unstructured byte stream, but it requires effort. RO vs. BO is a data structuring convention. Peter Flass ( talk) 14:50, 28 September 2023 (UTC)
EXCP
would be called - "physical-record-oriented"?EXCP
I/O to files is allowed to be done by arbitrary applications on arbitrary files, arguably OS/360 also offers an API layer below the record-oriented APIs.iom_$<routine name>
or ios_$<routine name>
.iox_$<routine name>
. I seem to remember some MIT folk not thinking all that highly of it, perhaps finding it to suffer from "second system syndrome".Notes