Hubbry Logo
ISAMISAMMain
Open search
ISAM
Community hub
ISAM
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
ISAM
ISAM
ISAM
View on Wikipedia
from Wikipedia

Indexed Sequential Access Method (ISAM) is a method for creating, maintaining, and manipulating computer files of data so that records can be retrieved sequentially or randomly by one or more keys. Indexes of key fields are maintained to achieve fast retrieval of required file records in indexed files. IBM originally developed ISAM for mainframe computers, but implementations are available for most computer systems.

The term ISAM is used for several related concepts:

  • The IBM ISAM product and the algorithm it employs.[1]
  • A database system where an application developer directly uses an application programming interface to search indexes in order to locate records in data files. In contrast, a relational database uses a query optimizer which automatically selects indexes.[2]
  • An indexing algorithm that allows both sequential and keyed access to data.[3] Most databases use some variation of the B-tree for this purpose, although the original IBM ISAM and VSAM implementations did not do so.
  • Most generally, any index for a database. Indexes are used by almost all databases.

Organization

[edit]

In an ISAM system, data is organized into records which are composed of fixed length fields, originally stored sequentially in key sequence. Secondary set(s) of records, known as indexes, contain pointers to the location of each record, allowing individual records to be retrieved without having to search the entire data set. This differs from the contemporaneous navigational databases, in which the pointers to other records were stored inside the records themselves. The key improvement in ISAM is that the indexes are small and can be searched quickly, possibly entirely in memory, thereby allowing the database to access only the records it needs. Additional modifications to the data do not require changes to other data, only the table and indexes in question.

When an ISAM file is created, index nodes are fixed, and their pointers do not change during inserts and deletes that occur later (only content of leaf nodes change afterwards). As a consequence of this, if inserts to some leaf node exceed the node's capacity, new records are stored in overflow chains. If there are many more inserts than deletions from a table, these overflow chains can gradually become very large, and this affects the time required for retrieval of a record.[4]

Relational databases can easily be built on an ISAM framework with the addition of logic to maintain the validity of the links between the tables. Typically the field being used as the link, the foreign key, will be indexed for quick lookup. While this is slower than simply storing the pointer to the related data directly in the records, it also means that changes to the physical layout of the data do not require any updating of the pointers—the entry will still be valid.

ISAM is simple to understand and implement, as it primarily consists of direct access to a database file. The trade-off is that each client machine must manage its own connection to each file it accesses. This, in turn, leads to the possibility of conflicting inserts into those files, leading to an inconsistent database state. To prevent this, some ISAM implementations[5][6] provide whole-file or individual record locking functionality. Locking multiple records runs the risk of deadlock unless a deadlock prevention scheme is strictly followed. The problems of locking, and deadlock are typically solved with the addition of a client–server framework which marshals client requests and maintains ordering. Full ACID transaction management systems are provided by some ISAM client–server implementations.[5] These are the basic concepts behind a database management system (DBMS), which is a client layer over the underlying data store.

ISAM was replaced at IBM with a methodology called VSAM (virtual storage access method). Still later, IBM developed SQL/DS and then Db2 which IBM promotes as their primary database management system. VSAM is the physical access method used in Db2.[citation needed]

OpenVMS

[edit]

The OpenVMS operating system uses the Files-11 file system in conjunction with RMS (Record Management Services). RMS provides an additional layer between the application and the files on disk that provides a consistent method of data organization and access across multiple 3GL and 4GL languages. RMS provides four different methods of accessing data; sequential, relative record number access, record file address access, and indexed access.

The indexed access method of reading or writing data only provides the desired outcome if in fact the file is organized as an ISAM file with the appropriate, previously defined keys. Access to data via the previously defined key(s) is extremely fast. Multiple keys, overlapping keys and key compression within the hash tables are supported. A utility to define/redefine keys in existing files is provided. Records can be deleted, although "garbage collection" is done via a separate utility.

Design considerations

[edit]

IBM engineers designed the ISAM system to use a minimum amount of computer memory. The tradeoff was that the Input/Output channel, control unit, and disk were kept busier. An ISAM file consists of a collection of data records and two or three levels of index. The track index contains the highest key for each disk track on the cylinder it indexes. The cylinder index stores the highest key on a cylinder, and the disk address of the corresponding track index. An optional master index, usually used only for large files, contains the highest key on a cylinder index track and the disk address of that cylinder index. Once a file is loaded data records are not moved; inserted records are placed into a separate overflow area. To locate a record by key the indexes on disk are searched by a complex self-modifying channel program.[7] This increased the busy time of the channel, control unit, and disk. With increased physical and virtual memory sizes in later systems this was seen as inefficient, and VSAM was developed to alter the tradeoff between memory usage and disk activity.

ISAM's use of self-modifying channel programs later caused difficulties for CP-67 support of OS/360, since CP-67 copied an entire channel program into fixed memory when the I/O operation was started and translated virtual addresses to real addresses.[8]

ISAM-style implementations

[edit]

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

ISAM

View on Grokipedia
from Grokipedia
The Indexed Sequential Access Method (ISAM) is a data file organization technique that enables efficient sequential and direct access to records in large databases by maintaining a multi-level hierarchical index structure based on key fields. Developed by in the , ISAM emerged as one of the earliest methods for managing sizable datasets in commercial environments, serving as a foundational approach before the widespread adoption of more advanced structures like B-trees. It organizes records in sequential order within data blocks while using a multi-level primary index to point to block locations, with records within blocks accessed sequentially, thereby balancing ordered storage with rapid key-based lookups. This dual-access capability made ISAM particularly suitable for read-intensive applications, such as systems or early database management, where sequential processing for batch operations and random retrieval for queries were both essential. Key advantages of ISAM include its simplicity in implementation for static datasets and its ability to minimize seek times on by clustering related , which improved in the hardware-constrained era of mainframe computing. However, it suffers from notable limitations, such as inefficiency in handling insertions or deletions, which can cause index fragmentation and require periodic reorganization to maintain ; this rigidity often led to wasted storage space due to reserved gaps for future entries. ISAM was later improved upon by 's VSAM in the 1970s. In modern contexts, ISAM has largely been superseded by more flexible indexed methods in systems, though its principles influenced subsequent technologies and it remains relevant in legacy environments.

History and Development

Origins in Early Computing

The Indexed Sequential Access Method (ISAM) was invented by engineers in the early 1960s as part of efforts to enhance on mainframe systems, particularly in conjunction with the IBM 1410 and the development of OS/360, alongside maturing disk-based storage technologies such as the introduced in 1956. This development addressed the growing demand for efficient file organization amid the transition from punched cards and magnetic tapes to direct-access storage devices (DASD). ISAM combined sequential file ordering with indexing to enable both ordered traversal and rapid location of specific records, marking a pivotal advancement in file access techniques for the era's computing infrastructure. The primary motivation for ISAM's creation stemmed from the limitations of methods prevalent in tape-based systems, which required scanning entire reels to reach a desired record, rendering them inefficient for applications demanding frequent random lookups. In fields like payroll , inventory management, and —core to mid-20th-century commercial computing—such delays could bottleneck operations on systems like the , where users needed to update or retrieve individual employee or transaction without the full . By leveraging disk drives' ability to seek specific tracks, ISAM allowed keys to index stored in physical sequence, balancing with direct access for interactive queries, thus optimizing performance for these real-time needs. ISAM's first commercial implementation arrived with IBM's OS/360 operating system, released in 1966 following its announcement in 1964, where it was integrated as a core access method supporting both basic (BISAM) and queued (QISAM) variants for disk files. This integration extended to early disk systems compatible with the , building on prior work for the . A key milestone was the publication of ISAM specifications in the 1964 OS/360 system manuals, which detailed its use of count-key-data (CKD) formatting on DASD to facilitate indexed operations. These specifications enabled widespread adoption in enterprise environments, solidifying ISAM's role in early database and file management.

Evolution and Standardization

In the late , ISAM played a pivotal role in the development of early database management systems, notably through its integration into IBM's Information Management System (IMS), released in 1968. IMS utilized Hierarchical ISAM (HISAM), an extension of ISAM that supported hierarchical structures for efficient segment access via indexes, marking ISAM's transition from a basic file organization method to a foundational component of transaction-oriented DBMS precursors. The brought significant refinements to ISAM, exemplified by 's introduction of the (VSAM) in 1972 as part of OS/VS release 1 and 2. VSAM enhanced ISAM by incorporating virtual storage capabilities, improved indexing for better performance, and support for variable-length records, addressing limitations in overflow management and direct access on mainframe systems. This variant became a standard access method in environments, influencing subsequent file handling in operating systems like . Standardization efforts in the further solidified ISAM's place in standards, particularly through its influence on file access methods in , where ANSI X3.23-1985 defined support for indexed sequential files, enabling portable implementation of ISAM-like structures across platforms. These standards, aligned with ISO 1989:1985, facilitated interoperability for indexed file processing in business applications. Additionally, ISAM concepts were integrated into systems via libraries such as ndbm (new dbm), introduced in 4.3BSD in 1986, providing an ISAM-based key-value store for Unix applications. By the 1990s, ISAM's prominence waned with the widespread adoption of management systems (RDBMS), which offered superior flexibility for complex queries and through SQL and normalized structures, leading to a shift away from file-based ISAM in favor of integrated DBMS solutions.

Core Concepts and Organization

File Structure and Data Storage

In ISAM, data is organized into a prime data area where records are stored in sequential order based on their , ensuring that the file maintains a sorted structure for efficient sequential processing. This prime area is divided into fixed-length blocks, with records packed sequentially within each block to optimize space utilization on direct-access storage devices. The block size is determined by parameters such as DCBBLKSI or DCBBLKSIZE, allowing for configurations that accommodate the record length (DCBLRECL) while supporting both fixed-length and variable-length record formats. The initial file allocation divides the prime area into a fixed number of blocks, typically organized by tracks and on disk, with a master index providing entry points to the cylinder index blocks that indicate the starting locations of blocks. Each in the prime area contains multiple tracks, and the first track of each holds a track index for quick reference to within that . Records are inserted into these blocks in order, filling blocks from the beginning of the file and progressing sequentially, which minimizes fragmentation in the initial setup. For expansions when the prime area fills, ISAM employs a overflow technique, reserving additional tracks within the same to allocate extra blocks contiguously with the prime data. This method reduces seek times by keeping overflow data on the same physical , linking overflow blocks via a 10-byte field to maintain the sequential integrity of the order. In cases of further growth, independent overflow areas on separate cylinders can be used, but the overflow provides the primary mechanism for initial efficient scaling.

Index Design and Block Management

The index file in ISAM serves as a separate structure, resembling a static multi-level that predates modern B-trees, organized into , , and entry levels to facilitate efficient location of data records. This design, pioneered by in the for mainframe systems, maintains the index apart from the file to enable both sequential and direct access while keeping records in key-sorted order. The level, often called the master index, contains entries pointing to branch-level cylinder indexes for large files, ensuring beyond single-cylinder datasets. At the branch level, the cylinder index holds one entry per track within a cylinder, with each entry consisting of a key value—typically the highest or lowest key on that track—and a block address specifying the cylinder, head, and record location in cylinder-head-record (CCHHR) notation. The entry level, known as the track index, provides finer granularity, with one sparse index entry per data block on a track; this entry includes the key value and the precise block address, allowing the system to jump directly to the relevant track and scan sequentially within it for the target record. These key-block address pairs form the core of ISAM indexing, where keys are fixed-length and sorted, and addresses use relative or absolute disk positioning to minimize seek times on early direct-access storage devices. Block management in ISAM relies on fixed-size blocks, typically aligned with disk track capacities (e.g., 256-byte directory blocks or larger blocks), which often result in partial fills as records are added or space is reserved for sequential growth. The index is updated dynamically to reflect these block boundaries, with the track index pointing to the start of each block rather than individual records, promoting dense packing while accommodating variable-length records through overflow linkages if a block overflows. This approach ensures that blocks remain contiguous where possible, but partial utilization is inherent due to the fixed allocation, influencing overall storage efficiency. To handle large files, ISAM employs multi-level indexing, where the fan-out ratio—the number of child pointers or entries per index block—typically ranges from 100 to 200, depending on block size, key length, and pointer overhead, allowing logarithmic search depths even for millions of records. For instance, in implementations, the cylinder index might fan out to 10-20 tracks per cylinder, while track indexes support higher branching to data blocks, reducing the number of disk accesses to 2-3 levels for most operations. This static , rebuilt periodically for reorganization, provides a balance between access speed and maintenance overhead in pre-relational database environments.

Operations and Access Methods

Sequential and Direct Access

ISAM supports two primary access modes: and direct, which leverage its indexed file structure to enable efficient record retrieval without requiring full file scans. involves reading records in key order by linearly traversing the prime data blocks, cylinder index entries, and any associated overflow chains as needed. This method is particularly suited for tasks, such as generating reports or performing bulk data analysis, where records must be processed in sorted sequence from the beginning or a specified starting point. Direct access, in contrast, allows retrieval of specific records by utilizing the multi-level index (including track, , and master indexes) to compute the precise block location corresponding to a given key, followed by a partial scan within that block or track to locate the exact record. This process typically achieves an average of O(log n), where n is the number of records, due to the logarithmic depth of the index levels that narrows down the search path efficiently. The index search begins at the highest level and descends through entries to identify the target track or , enabling rapid random lookups ideal for interactive or query-driven applications. A key advantage of ISAM's is its hybrid nature, which permits sequential reads to commence from any arbitrary point determined via a direct index lookup, combining the strengths of both modes for flexible processing. For instance, an application can perform a direct key search to position the file pointer and then switch to sequential traversal for subsequent records. In implementations, this is realized through the READ NEXT statement for sequential access, which retrieves the next record in key order from the current position, and the READ statement with a specified key for direct access, which fetches the targeted record based on the index.

Record Insertion, Update, and Deletion

In ISAM systems, record insertion begins by locating the appropriate position in the sequential using the primary index, which points to the block containing the insertion point based on key comparison. If space is available within the target block, the new record is added, and existing records may be shifted to maintain sequential order by key value; otherwise, the record is placed in an overflow area, and the index is updated with a pointer to this location to preserve logical sequencing. This process ensures index integrity across all levels, including track and indexes in multi-level structures, without requiring immediate file reorganization. For record updates, the system first retrieves the record via direct access using the index to identify its block. If the update does not alter the , the record is overwritten in place, and the index remains unchanged unless secondary indexes are affected, which are then adjusted accordingly. However, if the key changes, the operation is typically handled as a deletion of the old record followed by an insertion of the new one, repositioning it in the sequential order and updating all relevant index entries to reflect the new key and location. This approach maintains the file's ordered structure while avoiding disruptions to index pointers. Record deletion involves locating the target via the index and either physically removing it or marking it as deleted (often with a tombstone flag) to avoid immediate shifts in the sequential file. The index is then updated by removing or invalidating the corresponding entry, ensuring subsequent searches skip the deleted record while preserving pointers for active . Space from deletions is not immediately reclaimed; instead, it accumulates until periodic compaction or reorganization, which shifts surviving records to restore and sequential contiguity, thereby optimizing access . This deferred helps balance modification costs with but requires scheduled file rebuilding to address fragmentation.

Design Considerations and Trade-offs

Performance Optimization

Performance optimization in ISAM systems involves careful selection of structural parameters and periodic to minimize I/O operations, reduce storage overhead, and maintain efficient access times, particularly in environments with frequent record insertions and deletions. Block size selection plays a critical role, as larger blocks decrease the number of I/O operations for sequential reads but can lead to internal fragmentation if records do not fully utilize the space, resulting in wasted storage. Optimal block sizes are determined based on average record length and predominant access patterns; for instance, recommends a 4 KB block size as a baseline for data components in hierarchical ISAM variants, increasing it when average record lengths exceed 1000 bytes to better align with hardware track capacities and reduce seek times. To counteract fragmentation from ongoing insertions and deletions, which scatter records and degrade performance, ISAM systems require scheduled reorganization routines. These typically involve unloading the dataset to a sequential file, redefining the physical structure, and reloading to compact free space and rebuild indexes, using utilities like IBM's IEBISAM for classical ISAM files. Reorganization frequency should be tuned to the update rate; heavy maintenance workloads necessitate more frequent cycles to restore optimal layout and prevent performance degradation from excessive free space. A key metric for balancing space utilization and access speed is the block fill factor, targeted at 80-90% during initial loading and reorganization to allow room for insertions without immediate overflows while minimizing wasted space. In ISAM implementations like Ingres, an 80% fill factor is standard for uncompressed tables to accommodate growth and sustain efficient random access.

Handling Overflows and Deletions

In ISAM systems, overflow resolution occurs when a primary data block becomes full during record insertion, prompting the allocation of an overflow area, such as a dedicated track or chained pages, to store additional records. The index entry for the affected key then references the primary block followed by pointers to the overflow chain, allowing retrieval by traversing these links. This chaining mechanism maintains the logical sequential order while accommodating growth without immediate reorganization. Deletion in ISAM typically involves logical marking of records, such as setting a delete (e.g., X'FF' in byte 1 for fixed-length records), which leaves physical occupied and creates fragmentation through scattered holes in blocks. Physical deletion, which reclaims , requires more complex operations like splitting full blocks or joining adjacent ones to consolidate free space, often necessitating periodic reorganization to mitigate fragmentation. These processes can exacerbate overflow chains if not managed, as deleted records in chains may not be immediately de-allocated. A key drawback of overflow in ISAM is the progressive degradation of , as longer chains increase the number of block accesses needed to traverse in order, potentially requiring reorganization when overflow accumulate. To address minor expansions before resorting to full overflows, IBM's VSAM implementation reserves free space within control intervals—typically 10-20% of the interval size—to allow insertions without immediate splits or . This distributed free space reduces fragmentation from both insertions and deletions by enabling in-place adjustments, though excessive growth still demands broader maintenance.

Implementations and Variants

IBM and Mainframe Systems

The Indexed Sequential Access Method (ISAM) was first introduced as part of 's OS/360 operating system, released in 1966, to provide efficient indexed access to data stored on Direct Access Storage Devices (DASD). ISAM in OS/360 utilized a multi-level index structure, including a track index that pointed to specific disk tracks based on the highest key value per track, enabling both sequential and direct record retrieval via track addressing. This design was optimized for the fixed-block architecture of early System/360 DASD volumes, supporting fixed-length or blocked records while managing overflows by allocating overflow tracks when primary tracks filled. In 1972, introduced (VSAM) as a successor to ISAM, enhancing for virtual storage environments in OS/VS1 and OS/VS2. VSAM expanded on ISAM by introducing key-sequenced data sets (KSDS), relative record data sets (RRDS), and entry-sequenced data sets (ESDS), with tunable control interval sizes (CISZ) to optimize I/O performance and buffer usage for varying record lengths and access patterns. The KSDS variant serves as the primary ISAM analog in VSAM, maintaining an index of keys to relative byte addresses (RBA) within control intervals, allowing efficient insertion, retrieval, and maintenance of ordered records. VSAM datasets, particularly KSDS, integrated deeply with IBM's systems, such as IMS/DB for hierarchical database management and for , enabling high-volume, concurrent access to shared data. These integrations supported critical enterprise applications by providing locked control intervals for consistency during updates and reads. As of 2025, VSAM remains fully supported in , with KSDS capable of managing extremely large datasets, including those containing billions of records across multiple volumes, to meet modern mainframe workloads.

OpenVMS and Other OS Integrations

In , the Record Management Services (RMS) have provided support for Indexed Sequential Access Method (ISAM) files since the initial release of VMS version 1.0 in 1977. RMS enables the creation and management of indexed files that utilize structures for efficient key-based access, allowing applications to perform rapid lookups, insertions, and sequential traversals on structured data. This integration has been fundamental to OpenVMS's file handling capabilities, supporting both relative files—accessed by record number—and indexed files with up to 255 keys, though practical implementations typically employ fewer for performance reasons. Key features of RMS ISAM include support for variable-length records, with a maximum size of 32,767 bytes when block spanning is enabled, facilitating flexible in environments requiring high reliability and . Relative files offer direct access similar to array-like structures, while indexed files leverage B-trees to maintain sorted order and handle dynamic updates without full file reorganization. Over time, RMS evolved to accommodate modern requirements; notably, with the introduction of On-Disk Structure level 5 (ODS-5) in version 7.2 in 1999, RMS gained support for (UCS-2) characters in file names and extended character sets, enhancing while preserving the core ISAM functionality for . Beyond , ISAM implementations appeared in other operating systems during the 1980s as portable libraries for non-mainframe environments. In UNIX systems, C-ISAM, introduced in 1982, provided a library of C functions for managing ISAM files, supporting indexed with multi-level indexes for efficient record retrieval and updates. On Windows, —originally developed in 1982 and later rebranded as Pervasive PSQL—offered ISAM-based file management for client-server applications, supporting indexed across networked environments and integrating with development tools for transactional handling. These integrations allowed ISAM principles to extend to distributed and multi-platform applications, distinct from proprietary mainframe systems.

Modern ISAM-Style Databases

, first released in the mid-1990s, represents an open-source evolution of ISAM principles through its use of B+ trees for efficient indexed access to key-value pairs. This embedded library supports sorted keys, duplicate handling, and range queries, making it suitable for high-performance data management without a separate server process. It has been integrated into numerous applications, including DNS servers for storage in systems like early versions of . LevelDB, developed by and released in 2011, draws inspiration from ISAM for its ordered key-value storage but employs log-structured merge-trees (LSM-trees) to optimize write performance and sequential access. , a 2012 fork of LevelDB by , extends these capabilities with multi-threaded operations and specific tuning for SSDs, reducing and improving endurance on flash storage through leveled compaction strategies. Both systems prioritize embeddability and low-latency access, enabling efficient handling of large datasets in resource-constrained environments. In contemporary applications as of , ISAM-style databases like these offer low-overhead storage ideal for embedded systems, where minimal resource usage and fast local access are critical. Their lightweight design supports IoT devices for sensor data logging and edge processing, as well as mobile apps for offline caching and synchronization, outperforming full relational systems in footprint and startup time. For instance, powers stateful components in streaming services and mobile frameworks, ensuring reliable persistence without network dependencies. SQLite, primarily a engine, incorporates ISAM-like functionality through its core implementation for tables and indexes, providing efficient sequential and indexed access to records. While its default mode emphasizes SQL-based relational operations, extensions such as (FTS5) enable ISAM-style optimizations for specific access patterns, like keyword indexing without full relational joins. This contrasts with its relational defaults by allowing direct, file-based key access in embedded scenarios, enhancing performance for non-relational workloads.

References

  1. https://www.geeksforgeeks.org/dbms/isam-in-database/
  2. https://www.tutorialspoint.com/dbms/dbms_file_organization
  3. https://www.ibm.com/docs/en/zos/3.1.0?topic=sets-using-indexed-sequential-access-method
  4. https://ibm-1401.info/OS-early1410-7090-S360.html
  5. https://link.springer.com/content/pdf/10.1007/1-4020-8136-7_5.pdf
  6. https://www.dremio.com/wiki/index-sequential-access-method/
  7. https://vtda.org/docs/computing/IBM/Mainframe/IBM_OS_Timeline_v37.5_Feb2018.pdf
  8. https://www.jaymoseley.com/hercules/downloads/pdf/$OSTL33.pdf
  9. https://www.ibm.com/docs/en/ims/15.4.0?topic=types-hisam-databases
  10. https://www.ibm.com/history/information-management-system
  11. http://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_1_1972/GC26-3799-0_OS_VS_Virtual_Storage_Access_Method_VSAM_Planning_Guide_Jul72.pdf
  12. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub21-2.pdf
  13. http://archive.opengroup.org/publications/archive/CDROM/d010.pdf
  14. https://www.quickbase.com/articles/timeline-of-database-history
  15. http://www.bitsavers.org/pdf/ibm/360/os/isam/GY28-6618-5_OS_ISAM_Logic_Rel_21_Feb72.pdf
  16. https://publibz.boulder.ibm.com/epubs/pdf/dgt2d400.pdf
  17. http://edwardbosworth.com/My3121Textbook_HTM/MyText3121_Ch27_01.htm
  18. https://courses.cs.duke.edu/fall12/compsci316/lectures/19-index-notes.pdf
  19. https://www.ibm.com/docs/en/SSLTBW_2.4.0/pdf/idad400_v2r4.pdf
  20. https://dl.acm.org/doi/10.1145/355602.361304
  21. https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=statements-read-statement
  22. https://publibfp.dhe.ibm.com/epubs/pdf/7115.pdf
  23. https://digital.library.unt.edu/ark:/67531/metadc663738/m2/1/high_res_d/1002772864-Rogers.pdf
  24. https://www.cs.purdue.edu/homes/bb/cs448f18/ch17.pdf
  25. https://www.ibm.com/docs/en/ims-dbsolutionpack/2.2.0?topic=databases-is-block-size-ci-size-appropriate
  26. https://www.jaymoseley.com/hercules/isam_cobol/index.htm
  27. https://docs.actian.com/ingres/12.0/DatabaseAdmin/Options_to_the_Modify_Procedure.htm
  28. https://dl.acm.org/doi/10.1145/319628.319665
  29. https://www.ibm.com/docs/en/zos/2.4.0?topic=method-maintaining-indexed-sequential-data-set
  30. https://www.ibm.com/docs/en/zos/2.5.0?topic=performance-optimizing-free-space-distribution
  31. https://www.redbooks.ibm.com/redbooks/pdfs/sg246105.pdf
  32. https://www.ibm.com/docs/en/zos/3.1.0?topic=sets-vsam-data-sets
  33. https://www.ibm.com/docs/en/ims/15.5.0?topic=databases-vsam-options
  34. https://www.ibm.com/docs/en/cics-ts/6.x?topic=control-vsam-data-sets-ksds-esds-rrds
  35. https://www.ibm.com/docs/en/zos/3.1.0?topic=methods-virtual-storage-access-method
  36. https://wiki.vmssoftware.com/VAX/VMS_Version_1.0
  37. https://docs.vmssoftware.com/guide-to-openvms-file-applications/
  38. http://odl.sysworks.biz/disk%24axpdocmar991/opsys/vmsos72/4506/4506pro_005.html
  39. https://wiki.vmssoftware.com/OpenVMS_Version_7.2
  40. https://docs.vmssoftware.com/docs/VSI_Gd_Ext_File_Spec_23Jul19.pdf
  41. https://public.dhe.ibm.com/software/data/informix/pubs/whitepapers/cisam_wp.pdf
  42. https://aosabook.org/en/v1/bdb.html
  43. https://www.usenix.org/legacy/events/usenix99/full_papers/olson/olson.pdf
  44. https://opensource.googleblog.com/2011/07/leveldb-fast-persistent-key-value-store.html
  45. https://github.com/facebook/rocksdb
  46. https://github.com/google/leveldb
  47. https://hackernoon.com/a-closer-look-at-the-top-3-embedded-databases-sqlite-rocksdb-and-duckdb
  48. https://objectbox.io/the-best-iot-databases-for-the-edge-an-overview-and-compact-guide/
  49. https://dzone.com/articles/rocksdb-the-bedrock-of-modern-stateful-application
  50. https://sqlite.org/btreemodule.html
  51. https://sqlite.org/fts5.html
  52. https://www.explo.co/blog/embedded-sql-databases
Add your contribution
Related Hubs
User Avatar
No comments yet.