Input/Output statements divide into categories by both the type of access (sequential or stream, direct or "random", indexed, SQL) and the general file structure/organization (linked list, contiguous linear address space, index/data pairs, database). On the AMOS platform, sequential and direct access files are physically distinct at the OS level, whereas on all other platforms, there is no physical distinction; it's just a question of how they are accessed. AMOS used the somewhat misleading term "random" to refer to the ability to access any record in a file by its record number, i.e. as if randomly, to contrast it with sequential access. In the Unix and Windows world, all files can be accessed directly, so that "random access" loses its sense at multiple levels. Still the terminology persists. Under A-Shell, "sequential files" are equivalent to "streams", while "random files" consist of fixed length records accessed by record number, possibly with the aid of separate index. SQL database access is supported via a separate API (ASQL) and is not otherwise discussed here.
File Access Methods
Sequential (aka stream) access is used for non-record-oriented data (binary or text). Sequential files are opened for either read or write access, but not both at the same time. And although it's possible to reposition the "cursor" to a specific byte offset within an existing file, access is normally sequential. I/O operations can be byte oriented or logical line (terminated with LF or CRLF) oriented. See MX_FILEPOS. In output mode, files grow automatically. In input mode, programs typically read bytes or lines at a time until the EOF status is returned. Typical uses are for programs, reports, documents, graphics, interface files, configuration files, structured text such as HTML, XML, JSON, CSV, etc.
Random (aka direct) access is used for accessing sets of fixed-length records. Reads and writes may be intermixed within a single file open session, unless explicitly opened for read-only access. I/O operations are always one record at a time, with the record length specified in the open statement, and based on a record number. Record and file level locking is possible. There is no inherent indexing, but applications are free to construct indexes—possibly themselves random access files—to allow efficient access to individual records. Typical uses are for structured data, where the layout of a record is specified via a set of MAP Statements grouped under a MAP1 heading, or DEFSTRUCT).
ISAM (Indexed Sequential Access Method) combines a random access data file with one or more index files, along with a set of special ISAM File Statements for performing the requisite operations, such as lookup by key, sequential access in key order, add and delete keys and records, etc. For those migrating from the AMOS platform, A-Shell's ISAM supports the original AMOS ISAM format, but also supports an extended format allowing for much more efficient organization of very large files both through variable size index blocks and variable numbers of index levels.
ISAM-A is an alternate implementation of ISAM, based on the Informix C-ISAM standard, that offers some advantages over the original ISAM, such as automatic integration of the index and data operations, the ability to add/delete keys without completely rebuilding the file, keys combining several non-contiguous fields, multiple key types, variable length records, push/pop, transaction support, etc.
SQL operations are supported via the ASQL module which currently supports MySQL/MariaDB and anything with an ODBC connector. Under Windows, ODBC drivers are typically included or available at no charge; under Linux, a third-party ODBC driver may be required.
Comments
| • | Unlike in AMOS, there is really no such thing as a "contiguous" (aka RANDOM) file in Windows or Unix. The underlying files are sequentially allocated; the random access feature is supported in a layer above that, partly in the OS, partly in A-Shell. |
| • | Because of that, A-Shell in some cases has to guess whether a file was intended to be RANDOM or not, based on whether it is a multiple of 512 bytes as all AMOS RANDOM files would be. This mainly becomes an issue when using the LOOKUP statement, which returns a negative # for "random" files, and a positive # for "sequential" files. Some applications might actually depend on that and thus misbehave, for example, if a sequential file just happened to be a multiple of 512 bytes. In general, modern programs should not rely on the arbitrary unit of 512-byte blocks and instead should use the size in bytes (see SIZE.LIT, Xcall SIZE). Also see the system options ABSLOOKUP and EXTFIO. |
| • | For SEQUENTIAL files (aka "streams"), A-Shell (unlike AMOS) supports the ability to seek directly to a byte position; see MX_FILEPOS. |
| • | For RANDOM files, A-Shell (unlike AMOS) supports the ability to expand them incrementally in place, whether manually (see MX_EXPFIL), or automatically (see system options , and MX_GETOPTIONS, MX_SETOPTIONS GOP_AUTOX_RAN) |
See Also
Subtopics
