IDMS дерекқоры: тарихы, даму жолы, B.F. Goodrich, Cullinet, CA Technologies, Broadcom сияқты компаниялардағы өзгерістері. Көне деректерді басқару жүйесі.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Изотопты сұйыту массалық спектрометриясы
Isotope Dilution Mass Spectrometry
Интегралды деректерді басқару жүйесі (IDMS) – негізгі компьютерлер үшін желілік модель (CODASYL) деректерді басқару жүйесі. Ол алғаш рет B. F. Goodrich компаниясында әзірленді, кейін Cullinane Database Systems (1983 жылы Cullinet деп қайта аталды) компаниясы тарапынан саудаға ұсынылды. 1989 жылдан бастап өнім Computer Associates (қазір CA Technologies) компаниясына тиесілі болды, олар оны Advantage CA IDMS деп, кейін CA IDMS деп атады. 2018 жылы Broadcom CA Technologies компаниясын сатып алып, оны қайта IDMS деп атады.
The Integrated Database Management System (IDMS) is a network model (CODASYL) database management system for mainframes. It was first developed at B. F. Goodrich and later marketed by Cullinane Database Systems (renamed Cullinet in 1983). Since 1989 the product has been owned by Computer Associates (now CA Technologies), who renamed it Advantage CA IDMS and later simply to CA IDMS. In 2018 Broadcom acquired CA Technologies, renaming it back to IDMS.
Тарих
IDMS-тің тамыры 1964 жылы General Electric компаниясында Чарльз Бахман басқарыған команда әзірлеген және алғаш рет шығарылған Integrated Data Store (IDS) деп аталатын базалық деректерді басқарудың ізашарлық жүйесіне салады. 1960 жылдардың басында IDS B. F. Goodrich химиялық бөлімшесінің компьютерлік тобымен бастапқы түрінен алынып, аралық жүйелік тіл (ISL) деп аталатын тілде қайта жазылды. ISL – әртүрлі мақсатты машиналар үшін код жасай алатын портативті жүйелік бағдарламалау тілі ретінде құрылды. ISL іс жүзінде ISL-де жазылғандықтан, оны басқа машина архитектураларына салыстырмалы түрде оңай көшіруге болады, содан кейін олармен орындалатын кодты шығаруға болады. Химиялық бөлімнің компьютерлік тобы IDMS көшірмелерін басқа компанияларға сатуды ойлады, бірақ басшылық олардың бағдарламалық өнімдер бизнесімен айналыспайтынын айтты. Ақырында Джон Куллиненмен келісімшарт жасалып, ол құқықтарды сатып алып, өнімді нарыққа шығарады. Cullinane компаниясы B. F. Goodrich компаниясына авторлық жарналарды қайтаруды талап еткендіктен, барлық қосымша өнімдер жеке өнімдер ретінде тізімделіп, есептелді, тіпті олар негізгі IDMS өнімінің жұмыс істеуі үшін міндетті болса да. Бұл кейде клиенттерді шатастыратын. Бастапқы платформалар GE 235 компьютері және GE DATANET 30 хабарлама коммутациялау компьютері болды: кейін өнім IBM мейнфреймдеріне және DEC және ICL аппараттарына көшірілді. IBM портталған нұсқасы IBM негізгі компьютерлік жүйелерінде (System/360, System/370, System/390, zSeries, System z9) жұмыс істейді. 1980 жылдардың ортасында IDMS-тің шамамен 2500 лицензиясы сатылды деп хабарланды. Пайдаланушылардың арасында Стратегиялық әуе командасы, Канаданың Ford, Еуропаның Ford, Jaguar Cars, Clarks Shoes UK, AXA/PPP, MAPFRE, Royal Insurance, Tesco, Manulife, Hudson's Bay Company, Кливленд клиникасы, Канада банкі, General Electric (Ұлыбританияда), Aetna және BT компаниялары болды. Digital Equipment Corporation PDP 11 компьютерлер сериясында пайдалану үшін нұсқасы DEC-ке сатылды және DBMS 11 ретінде таныстырылды. 1976 жылы бастапқы код ICL-ге лицензияланды, олар бағдарламалық жасақтаманы 2900 сериялы мейнфреймдерде, содан кейін 1900 сериясында орындауға арналған. ICL бағдарламалық жасақтаманы Cullinane-ден тәуелсіз түрде әзірлеуді жалғастырды, бастапқы портталған өнімді ICL 2900 IDMS атауымен және IDMSX ретінде жетілдірілген нұсқамен сатуды жалғастырды. Бұл формада оны көптеген ірі Ұлыбритания пайдаланушылары қолданды, мысалы, Inland Revenue компаниясы жүргізген "Pay As You Earn" жүйесі. Ұлыбритания үкіметінің IDMSX жүйелерінің көбі 2013 жылы әлі де жұмыс істеп тұрды. 1980 жылдардың басында және ортасында аппараттық қуаттылықтың артуы және миникомпьютерлер мен клиент-сервер архитектурасына көшу арқасында реляциялық деректер қорын басқару жүйелері танымал бола бастады. Реляциялық деректер базалары CODASYL жүйелеріне қарағанда даму өнімділігін арттырды, ал нашар өнімділікке негізделген дәстүрлі қарсылықтар баяу азайып барады. Cullinet IBM-нің DB2 және басқа реляциялық деректер базаларына қарсы бәсекелесуді жалғастыруға тырысты, соның ішінде автоматты жүйелік құрылғы (ASF) жасады, ол LRF (логикалық жазба құрылғысы) деп аталатын бұрыннан бар IDMS функциясын пайдаланды. ASF – кестелерді сақтау үшін шағын қосымшаны да құрайтын бос орынға деректер қорының генераторы. Мұндай мүмкіндіктер өнімнің сатылу мерзімін ұзартуда табысты болғанын бағалау қиын, бірақ олардың ұзақ мерзімді әсері шамалы болды. IDMS-те қалған пайдаланушылар, ең алдымен, оның қатынастық мүмкіндіктеріне емес, оның жоғары өнімділігіне қызығушылық танытты. Бұл кеңінен танылды (электрондық байланыс моделінің әкесі Э. Ф. Коддтың жоғары деңгейдегі науқаны арқылы), реляциялық деректер қоры мен реляциялық қаптамасы бар желілік деректер қоры арасында айтарлықтай айырмашылық бар екендігі. 1989 жылы Computer Associates Cullinet сатып алғаннан кейін дамуды жалғастырды және 1992–93 жылдары толық SQL-мен 12.0 нұсқасын шығарды. CA Technologies CA IDMS-ті және одан кейінгі релиздерде TCP/IP қолдауын, екі фазалы коммит қолдауын, XML жариялауды, zIIP арнайы процессорды қолдауды, CA IDMS Серверімен, SQL Option-мен және CA IDMS Visual DBA құралы арқылы GUI деректер қорын басқару арқылы веб-желісін қамтамасыз етуді және қолдауды жалғастырды. CA IDMS жүйелері бүкіл әлем бойынша бизнестің жұмысын қамтамасыз етеді. Көптеген клиенттер CA Technologies компаниясының қос дерекқор стратегиясының бөлігі болып табылатын CA IDMS SQL опциясы арқылы өздерінің қосымшаларын веб-желіге қосуды таңдады.
The roots of IDMS go back to the pioneering database management system called Integrated Data Store (IDS), developed at General Electric by a team led by Charles Bachman and first released in 1964. In the early 1960s IDS was taken from its original form, by the computer group of the B. F. Goodrich Chemical Division, and re written in a language called Intermediate System Language (ISL). ISL was designed as a portable system programming language able to produce code for a variety of target machines. Since ISL was actually written in ISL, it was able to be ported to other machine architectures with relative ease, and then to produce code that would execute on them. The Chemical Division computer group had given some thought to selling copies of IDMS to other companies, but was told by management that they were not in the software products business. Eventually, a deal was struck with John Cullinane to buy the rights and market the product. Because Cullinane was required to remit royalties back to B. F. Goodrich, all add on products were listed and billed as separate products – even if they were mandatory for the core IDMS product to work. This sometimes confused customers. The original platforms were the GE 235 computer and GE DATANET 30 message switching computer: later the product was ported to IBM mainframes and to DEC and ICL hardware. The IBM ported version runs on IBM mainframe systems (System/360, System/370, System/390, zSeries, System z9). In the mid 1980s, it was claimed that some 2,500 IDMS licenses had been sold. Users included the Strategic Air Command, Ford of Canada, Ford of Europe, Jaguar Cars, Clarks Shoes UK, AXA/PPP, MAPFRE, Royal Insurance, Tesco, Manulife, Hudson's Bay Company, Cleveland Clinic, Bank of Canada, General Electric, Aetna and BT in the UK. A version for use on the Digital Equipment Corporation PDP 11 series of computers was sold to DEC and was marketed as DBMS 11. In 1976 the source code was licensed to ICL, who ported the software to run on their 2900 series mainframes, and subsequently also on the older 1900 range. ICL continued development of the software independently of Cullinane, selling the original ported product under the name ICL 2900 IDMS and an enhanced version as IDMSX. In this form it was used by many large UK users, an example being the Pay As You Earn system operated by Inland Revenue. Many of these IDMSX systems for UK Government were still running in 2013. In the early to mid 1980s, relational database management systems started to become more popular, encouraged by increasing hardware power and the move to minicomputers and client–server architecture. Relational databases offered improved development productivity over CODASYL systems, and the traditional objections based on poor performance were slowly diminishing. Cullinet attempted to continue competing against IBM's DB2 and other relational databases by developing a relational front end and a range of productivity tools. These included Automatic System Facility (ASF), which made use of a pre existing IDMS feature called LRF (Logical Record Facility). ASF was a fill in the blanks database generator that would also develop a mini application to maintain the tables. It is difficult to judge whether such features may have been successful in extending the selling life of the product, but they made little impact in the long term. Those users who stayed with IDMS were primarily interested in its high performance, not in its relational capabilities. It was widely recognized (helped by a high profile campaign by E. F. Codd, the father of the relational model) that there was a significant difference between a relational database and a network database with a relational veneer. In 1989 Computer Associates continued after Cullinet acquisition with the development and released Release 12.0 with full SQL in 1992–93. CA Technologies continued to market and support the CA IDMS and enhanced IDMS in subsequent releases by TCP/IP support, two phase commit support, XML publishing, zIIP specialty processor support, Web enabled access in combination with CA IDMS Server, SQL Option and GUI database administration via CA IDMS Visual DBA tool. CA IDMS systems are today still running businesses worldwide. Many customers have opted to web enable their applications via the CA IDMS SQL Option which is part of CA Technologies' Dual Database Strategy.
Біріктірілген деректер сөздігі
IDMS-тің күрделі мүмкіндіктерінің бірі – оның кіріктірілген деректер сөздігі (IDD) болды. IDD негізінен деректер базасының анықтамаларын сақтау үшін әзірленді. Оның өзі IDMS дерекқоры еді. Деректер қорының әкімшілері (DBA) және басқа қолданушылар IDD-мен деректер сөздігінің анықтама тілі (DDDL) деп аталатын тіл арқылы байланысты. IDD IDMS отбасының басқа өнімдерінің, мысалы ADS/Online және IDMS DC анықтамалары мен кодтарын сақтау үшін де қолданылды. IDD-нің басты артықшылығы – оның кеңейтілуге қабілеттілігі және дерлік кез келген нәрсенің анықтамасын жасауға мүмкіндік беруі. Кейбір компаниялар оны ішкі құжаттаманы жасау үшін пайдаланды.
One of the sophisticated features of IDMS was its built in Integrated data dictionary (IDD). The IDD was primarily developed to maintain database definitions. It was itself an IDMS database. DBAs (database administrators) and other users interfaced with the IDD using a language called Data Dictionary Definition Language (DDDL). IDD was also used to store definitions and code for other products in the IDMS family such as ADS/Online and IDMS DC. IDD's power was that it was extensible and could be used to create definitions of just about anything. Some companies used it to develop in house documentation.
Логикалық деректер моделі
Пайдаланушыларға ұсынылатын деректер моделі – CODASYL желілік моделі. Бұл модельдегі негізгі құрылымдық ұғымдар – жазбалар және жиынтар. Жазбалар негізінен COBOL үлгісін ұстанады, түрлі типтегі өрістерден тұрады: бұл қайталанатын элементтер мен қайталанатын топтар сияқты күрделі ішкі құрылымдарды құруға мүмкіндік береді. Codasyl моделінің ең ерекше құрылымдық ұғымы – жиын. Математикалық жиынмен шатастырмау керек, Codasyl жиыны жазбалар арасындағы бір-көп қатынасты көрсетеді: бір иесі, көптеген мүшелері. Жазба бірнеше жиынның мүшесі бола алады, бұл желілік модельді бұрынғы иерархиялық модельден ерекшелейтін маңызды фактор. Жазбалар сияқты, әр жиын аталатын жиын типіне жатады (әр түрлі жиын типтері әртүрлі логикалық қатынастарды моделейді). Жиындар реттелген, ал жиын ішіндегі жазбалардың тізбегі ақпаратты жеткізу үшін пайдаланылуы мүмкін. Жазба кез келген жиынның иесі де, мүшесі де бола алады. Жазбалардың идентификаторы бар, ол деректер қорының кілті деп аталатын мәнмен көрсетіледі. IDMS-де, көптеген басқа Codasyl жүзеге асыруларындағыдай, деректер қорының кілті дискідегі жазбаның физикалық мекенжайымен тікелей байланысты. Деректер қорының кілттері сондай-ақ тізімдер мен ағаштар түріндегі жиындарды іске асыру үшін көрсеткіштер ретінде қолданылады. Логикалық модель мен физикалық іске асыру арасындағы осы тығыз сәйкестік (Codasyl моделінің міндетті бөлігі емес, бірақ барлық табысты жүзеге асырулардың ерекшелігі) деректерді іздеудің тиімділігін қамтамасыз етеді, бірақ деректерді жүктеу және қайта құрылымдау сияқты операцияларды қымбатқа соқтырады. Жазбаларға деректер қорының кілті арқылы, жиын қатынастарын орындау арқылы немесе кілт мәндерін пайдалану арқылы тікелей қол жеткізуге болады. Бастапқыда тікелей қол жеткізу тек хэштей отырып мүмкін болды, бұл механизм Codasyl моделінде CALC қол жеткізуі деп белгілі. IDMS-де CALC қол жеткізуі ішкі жиын арқылы іске асырылады, ол бірдей хэш-мәні бар барлық жазбаларды иеленуші жазбамен байланыстырады, ол әр дискі бетінің алғашқы бірнеше байтын алады. Кейінгі жылдары IDMS-тің кейбір нұсқалары BTree сияқты индекстерді пайдалану арқылы жазбаларға қол жеткізу мүмкіндігін қосты.
The data model offered to users is the CODASYL network model. The main structuring concepts in this model are records and sets. Records essentially follow the COBOL pattern, consisting of fields of different types: this allows complex internal structure such as repeating items and repeating groups. The most distinctive structuring concept in the Codasyl model is the set. Not to be confused with a mathematical set, a Codasyl set represents a one to many relationship between records: one owner, many members. The fact that a record can be a member in many different sets is the key factor that distinguishes the network model from the earlier hierarchical model. As with records, each set belongs to a named set type (different set types model different logical relationships). Sets are in fact ordered, and the sequence of records in a set can be used to convey information. A record can participate as an owner and member of any number of sets. Records have identity, the identity being represented by a value known as a database key. In IDMS, as in most other Codasyl implementations, the database key is directly related to the physical address of the record on disk. Database keys are also used as pointers to implement sets in the form of linked lists and trees. This close correspondence between the logical model and the physical implementation (which is not a strictly necessary part of the Codasyl model, but was a characteristic of all successful implementations) is responsible for the efficiency of database retrieval, but also makes operations such as database loading and restructuring rather expensive. Records can be accessed directly by database key, by following set relationships, or by direct access using key values. Initially the only direct access was through hashing, a mechanism known in the Codasyl model as CALC access. In IDMS, CALC access is implemented through an internal set, linking all records that share the same hash value to an owner record that occupies the first few bytes of every disk page. In subsequent years, some versions of IDMS added the ability to access records using BTree like indexes.
Сақтау
IDMS деректер қорын файлдар тізбегі ретінде ұйымдастырады. Бұл файлдар картаға түсіріліп, алдын ала форматына келтіріледі. Аймақтар дискідегі физикалық блоктарға сәйкес келетін беттерге бөлінеді. Деректер базасының жазбалары осы блоктардың ішінде сақталады. ДБА әр аймаққа файлдағы беттердің белгілі бір санын бөледі. Содан кейін ДБА әр аймақта қандай жазбалар сақталуын және оларды қалай сақтау керектігін анықтайды. IDMS деректер базасының бойымен арнайы орын бөлу беттерін орналастырады. Бұл беттер деректер базасының әрбір бетіндегі бос орынды қадағалау үшін қолданылады. I/O талаптарын азайту үшін бос орын тек аймақтың бос орыны 30%-дан төмен түскенде барлық беттер үшін қадағаланады. IDMS деректер базасында жазбаларды сақтау үшін төрт әдіс бар: Тікелей, Реттік, CALC және VIA. Fujitsu/ICL IDMSX нұсқасы осы әдістерді екі қосымша әдіспен толықтырады: Page Direct және Random. Тікелей режимде пайдаланушы мақсатты деректер қорының кілтін көрсетеді және ол осы ДБ кілтіне мүмкіндігінше жақын сақталады, ал жазба сақталған нақты ДБ кілті қолданба бағдарламасына қайтарылады. Реттік орналастыру (индекстелген реттікпен шатастырмаңыз) жаңа жазбаны аймақтың соңына орналастырады. Бұл опция сирек қолданылады. CALC жазбаны қайда орналастыру керектігін шешу үшін хэш алгоритмін пайдаланады; хэш кілті кейін жазбаны тиімді іздеуді қамтамасыз етеді. Барлық CALC аймағы әрқайсысы арнайы CALC "иесі" жазбасынан тұратын бас жазбамен алдын ала форматына келтіріледі. Хэш алгоритмі бет нөмірін анықтайды (одан физикалық дискінің мекенжайын анықтауға болады), содан кейін жазба осы бетке немесе оған мүмкіндігінше жақын сақталады және CALC жиынтығын пайдаланып осы беттің бас жазбасына байланыстырылады. CALC жазбалары беттің CALC иесі жазбасына бір сілтеме тізімі (нұсқаулар) арқылы байланыстырылады. Бет басында орналасқан CALC иесі оның нақты бетіне бағытталған немесе басқа бетке ашқан жазбалардың барлық жиынтығына ие. CALC өте тиімді сақтау және іздеуді қамтамасыз етеді: IDMS 1.1 I/O операциясында CALC жазбасын іздеуге болады. Алайда, бұл әдіс негізгі кілттің мәнінің өзгеруіне жақсы төтеп бермейді және беттер санын кеңейту қажет болса, қымбат қайта ұйымдастыру қажет. Аймақты кеңейту және содан кейін әр CALC жазбасы үшін аймақты ретті түрде сканерлейтін бағдарламаны іске қосу, содан кейін әр жазбаны жаңарту үшін MODIFY операторын пайдалану осының шешімі болып табылады. Бұл әрбір CALC жазбасының аймақтың жаңа беттер диапазоны үшін есептелген дұрыс мақсатты беттің CALC жиынтығына байланыстырылуына әкеледі. Бұл әдістің кемшілігі - көптеген CALC жазбаларының мақсатты беттерінде болмайды және әр беттің CALC жиынтығында жүруге көптеген I/O операциялары қажет болуы мүмкін. Нәтижесінде, бұл жұмысқа тек өте қажет болған жағдайларда ғана жүгіну ұсынылады, өйткені өнімділік төмендеуі мүмкін. VIA орналастыру белгілі бір жиынтықтағы иесіне жақын жазбаны сақтауға тырысады. Әдетте жазбалар меншік иесімен бірдей физикалық бетке топтастырылады. Бұл жиынтық қатынасын орындау арқылы жазбаға қол жеткізген кезде тиімді навигацияға әкеледі. (VIA деректерді басқа IDMS аймағында сақтауға мүмкіндік береді, сондықтан оларды иесінен бөлек сақтауға болады, бірақ тиімділік үшін топталған күйде сақталады. IDMSX-те олар меншік иесінен белгілі бір беттер санымен де ығыстырылуы мүмкін). Page Direct (тек IDMSX) Тікелей режимге ұқсас, бірақ мақсатты деректер қорының бетінің нөмірі көрсетіледі және жазба сол беттің CALC тізбегіне қосылады. Random (тек IDMSX) CALC алгоритмін пайдаланып сақталған кезде жазбаның орын алуына мақсатты бет нөмірін береді (бұл жазбаның ішіндегі кілтті пайдаланады немесе кілті жоқ кездейсоқ жағдайда, CALC алгоритмі үшін тұқым ретінде сақтау күні мен уақытын пайдаланады). Жиынтар әдетте сілтемелі тізімдер ретінде сақталады, деректер қорының кілтін нұсқау ретінде пайдаланады. Әрбір жазба келесі жазбаға сілтеме береді; деректер қорының дизайнера иеленуші нұсқауларын және алдыңғы нұсқауларды қосуды таңдай алады (көрсетілмесе, бұл бағыттағы навигация баяу болады). Кейбір IDMS нұсқалары кейіннен индекстерді анықтау мүмкіндігін қосты: жазба индекстері, екінші реттік кілттің мәлімдігінен жазбаларды табуға мүмкіндік береді немесе жиын индекстері, жиынның мүшелерін кілт мәні бойынша іздеуге мүмкіндік береді. IDMSX Page Direct және Random орналасу жазбалары әдетте жоғарыда сипатталғандай Record Index-термен бірге қолданылады. Индекстердің өзінде орналасу ережесі қолданылады, Тікелей (әдетте "индекс ID кілті ретінде пайдаланылатын CALC") немесе CALC.
IDMS organizes its databases as a series of files. These files are mapped and pre formatted into so called areas. The areas are subdivided into pages which correspond to physical blocks on the disk. The database records are stored within these blocks. The DBA allocates a fixed number of pages in a file for each area. The DBA then defines which records are to be stored in each area, and details of how they are to be stored. IDMS intersperses special space allocation pages throughout the database. These pages are used to keep track of the free space available in each page in the database. To reduce I/O requirements, the free space is only tracked for all pages when the free space for the area falls below 30%. Four methods are available for storing records in an IDMS database: Direct, Sequential, CALC, and VIA. The Fujitsu/ICL IDMSX version extends this with two more methods, Page Direct, and Random. In direct mode the target database key is specified by the user and is stored as close as possible to that DB key, with the actual DB key on which the record is stored being returned to the application program. Sequential placement (not to be confused with indexed sequential), simply places each new record at the end of the area. This option is rarely used. CALC uses a hashing algorithm to decide where to place the record; the hash key then provides efficient retrieval of the record. The entire CALC area is preformatted each with a header consisting of a special CALC "owner" record. The hashing algorithm determines a page number (from which the physical disk address can be determined), and the record is then stored on this page, or as near as possible to it, and is linked to the header record on that page using the CALC set. The CALC records are linked to the page's CALC Owner record using a single link list (pointers). The CALC Owner located in the page header thus owns the set of all records which target to its particular page (whether the records are stored on that page or, in the case of an overflow, on another page ). CALC provides extremely efficient storage and retrieval: IDMS can retrieve a CALC record in 1.1 I/O operations. However, the method does not cope well with changes to the value of the primary key, and expensive reorganization is needed if the number of pages needs to be expanded. A work around is to expand the area, and then run an application program which scans the area sequentially for each CALC record, and then uses the MODIFY verb to update each record. This results in each CALC record being connected to the CALC Set for the correct target page as calculated for the Area's new page range. The downside to this method is that vanishingly few CALC records will now be on their target pages, and navigating each page's CALC set is likely to involve many IO operations. As a result, it is recommended only to use this work around in extreme circumstances as performance will suffer. VIA placement attempts to store a record near its owner in a particular set. Usually the records are clustered on the same physical page as the owner. This leads to efficient navigation when the record is accessed by following that set relationship. (VIA allows records to be stored in a different IDMS area so that they can be stored separately from the owner, yet remain clustered together for efficiency. Within IDMSX they may also be offset from the owner by a set number of pages). Page Direct (IDMSX only) is similar to Direct mode, however a target Database page number is specified and the record is connected to the CALC chain for that page. Random (IDMSX only) allocates a target page number to the record occurrence when it is stored using the CALC algorithm (this either uses a Key within the record or in the case of un keyed random, uses the date & time of storage as a seed for the CALC algorithm). Sets are generally maintained as linked lists, using the database key as a pointer. Every record includes a forward link to the next record; the database designer can choose whether to include owner pointers and prior pointers (if not provided, navigation in those directions will be slower). Some versions of IDMS subsequently included the ability to define indexes: either record indexes, allowing records to be located from knowledge of a secondary key, or set indexes, allowing the members of a set to be retrieved by key value. The IDMSX Page Direct and Random placement records are typically used in conjunction with Record Indexes as described above. The Indexes themselves are subject to placement rules, either Direct (which really means "CALC using the Index ID as the key") or CALC.