Объекты

Сетевые вычисления и Интернет сделали тему объектных технологий бестселлером компьютерных новостей. Распространение таких языков программирования, как Java и С++, заставляет разработчиков приложений изменить свое отношение к традициям и признать преимущества новых объектноориентированных языков.

Подобно другим технологиям, которые мы считаем новыми, объекты используются в программировании уже более 30 лет. Впервые они появились в конце 60-х годов в языках типа Simula 67, применявшихся для программ моделирования. Современные языки программирования, такие как Java, C++ и Smalltalk — прямые потомки Simula 67. Программы моделирования имитируют поведение объектов реального мира. Аналогично, прикладные программы для бизнеса, содержащие объекты и операции над ними, моделируют реальные деловые отношения.

ОС работают с аппаратными и программными объектами, такими как устройства ввода-вывода и программы. Использование объектов в ОС выглядит совершенно естественным. О создании объектноориентированной ОС говорят многие фирмы, такие как Microsoft, Apple, Novell/USL (UNIX Systems Laboratory) и Sun Microsystems, однако, лишь немногие из них смогли реализовать свои планы. Одна из таких фирм — Next, уже поставляющая на рынок объектноориентированную ОС под названием NextStep.

Есть, конечно, и другая объектноориентированная ОС. С момента появления System/38 мы строим ОС (CPF и OS/400) по объектноориентированной моделиНекоторые из нас, создателей System/38, были очень хорошо знакомы с языками компьютерного моделирования уже в конце 60-х. Я сам использовал объектные модели в своей докторской диссертации для компьютерного моделирования различных архитектур виртуальной памяти. Решение использовать объекты в System/38 пришло после нашего участия в проекте Future Systems (подробнее об этом см. в Приложении).. Более того, мы не остановились на этом, но сделали объекты фундаментальной частью архитектуры машины. Как уже отмечалось в лекции 4, MI состоит из двух частей: команд и объектов. В этой лекции мы рассмотрим использование объектов в AS/400.

Иногда говорят, что AS/400 это не объектноориентированная система, а система на основе объектов (objectbased). Различие этих двух терминов имеет смысл при обсуждении языков программирования. Например, есть языки на основе объектов, такие как Ada, и объектноориентированные языки, такие как Smalltalk-80. Гради Буч (Grady Booch) определил различия между этими двумя типами языков. По Бучу, в языке на основе объектов отсутствует наследованиеGrady Booch. Object Oriented Design with Appliations. The Benjamin/Cummings Publishing Company, Inc. 1991.. Как уже вкратце упоминалось в лекции 3, наследование определяет иерархию классов, где подкласс заимствует структуру или поведение одного или нескольких базовых классов. Наследование позволяет создавать новые типы объектов. Так как объекты AS/400 ничего не наследуют от других объектов, и прикладные программисты, пишущие приложения для этой системы, не могут создавать новые типы объектов, то вероятно, правильнее называть AS/400 системой на основе объектов. Но какое бы имя мы не выбрали, важно то, что AS/400 не просто использует или включает объекты, — они являются фундаментальной частью ее архитектуры.

В упрощенном виде объект — это просто контейнер, внутри которого находятся пользовательские и системные структуры данных. Объект инкапсулирован, что означает (как мы условились ранее) невозможность заглянуть внутрь него. Система, построенная на основе объектной модели независима от аппаратуры. Первопричиной использования объектов в System/38 было желание инкапсулировать детали, чтобы позже их можно было изменять без влияния на прикладные программы.

Еще одно достоинство объектов — целостность. Оригинальная System/3 была байтовой машиной (то есть все в ней располагалось на границе байта), а ее команды содержали однобайтовый код операции. Они занимали несколько последовательных байтов памяти, но никакого обязательного выравнивания команд не было. Более того, все разряды кода были задействованы для задания типа операции и местоположения операндов. Практически любая комбинация разрядов в байте могла быть интерпретирована как допустимый код операции System/3.

Это вызывало проблему, если в программе непреднамеренно происходил переход в область данных: процессор мог продолжать выбирать байты данных и интерпретировать их как команды. Такая программа могла исполняться долгое время, сея хаос внутри системы. Ликвидировать последствия таких ошибок было весьма сложно.

В этом плане System/3, ничем не отличалась от большинства других вычислительных систем того времени. Например, в обычной системе цепочка байтов может быть интерпретирована, практически, как угодно. Можно взять байты из одной части программы и перемножить их с байтами из другой ее части. Процессор "не волнует", имеет ли смысл такая операция. Он работает с байтами, а не с тем, что они представляют.

Итак, мы были очень обеспокоены проблемами целостности, и сделали все, что бы таковых не возникало в AS/400. Команды в этой системе могут работать только с теми объектами, для которых предназначены. Некоторые универсальные команды, такие как "Создать объект", применимы ко всем объектам, другие — работают только с объектами определенных типов. Таким образом, в AS/400 нельзя использовать объект не по назначению, как в обычной системе. В результате целостность значительно повышается.

На эту проблему можно взглянуть и с другой стороны. В большинстве ОС, все, что находится в постоянной памяти, считается файлом (в MSDOS или MVS файлом называют набор данных). Файлы могут иметь различное назначение, но такая классификация определяется лишь по соглашению. Вы можете читать объект-программу так, как если бы это был файл. В OS/400 это невозможно (как и создать вирус, по крайней мере, в слое над MI), так как термин "файл" применим лишь к небольшому числу типов объектов, и программа определенно файлом не является. Кстати, с этим связаны некоторые неудобства, присутствовавшие в System/38, где значительная часть информации об объектах была недоступна программам. COMMON (группа пользователей AS/400) многократно просила включить во все команды отображения, такие как, например, "DSPOUTQ" ("Display Output Queue"), "DSPJOBQ" ("Display Job Queue"), опцию генерации выходного файла, чтобы информация, хранящаяся внутри объектов, могла быть считана программно. В конце концов, мы добавили такую возможность в некоторые команды, которые первоначально ей не обладали (а в "DSPOUTQ" и "DSPJOBQ" ее нет и сейчас). Но исчерпывающим ответом на эти запросы было создание API, позволяющих поместить информацию об объектах и системе в объект, известный как пользовательское пространство. Этот объект программы могут читать быстрее, чем файлы базы данных.

Имена объектов

В System/38 объекты были как в ОС, так и в MI. Определением этих объектов и выбором имен для них занимались две разные группы. Одна разрабатывала объекты CPF, (которая в AS/400 была переименована в OS/400До AS/400 в системах Рочестера не использовалось название "операционная система". Считалось, что для большинства заказчиков ОС — это нечто слишком сложное и страшное, а такие названия, как Control Program Facility и System Support Program, казались более близкими. К нашему большому изумлению, при объявлении DOS (Disk Operating System) для IBM PC никто не испугался. Поэтому мы решились на название OS/400. ), другая — разрабатывала набор команд и системные объекты MI.

Хорошо, что иногда между объектом OS/400 и объектом MI соотношение один к одному, тогда это тот же самый объект. Все усложняется, когда это разные объекты. Все объекты OS/400 состоят из одного или нескольких системных объектов MI. Другими словами, типы объектов OS/400 и типы системных объектов MI соотносятся как один к одному или как один ко многим, но никогда как многие к одному или многие ко многим.

Пример, иллюстрирующий это положение, мы рассмотрим в следующем разделе. А теперь, прежде чем идти дальше, я должен внести ясность еще в одну область.

Иногда, объекты OS/400 и системные объекты MI, даже при соотношении между ними один к одному, могут называться поразному. Например, в OS/400 есть объект "библиотека", в MI эквивалентный объект называется "контекст". Как это могло получиться? Ответ восходит ко времени создания System/38 двумя разными группами проектировщиков с разными подходами к выбору названий.

Объекты OS/400 и системные объекты MI

Несколько типов объектов имеются и в OS/400, и в MI. Типы объектов OS/400 перечислены в таблице 5.1. Для сравнения, в таблице 5.2 приведены системные объекты MI. Помните, что в каждой новой версии AS/400 добавляются новые функции и даже новые объекты. Списки объектов таблицах 5.1 и 5.2 достаточно полны для нашего обсуждения в этой и следующей лекции, но включить в них все типы объектов невозможно.

Некоторые объекты OS/400 из таблицы 5.1 полностью соответствуют системным объектам MI из таблицы 5.2, при этом имена объекта в двух разных наборах могут совпадать, а могут и не совпадать. Пример совпадения имен — "программа", несовпадения — "библиотека" и "контекст".

Другие объекты OS/400 относятся к системным объектам MI как один ко многим. Посмотрите на пример на рисунке 5.1: здесь файл базы данных OS/400 состоит из пяти системных объектов MI, и ему соответствуют четыре разных типа системных объектов MI (в нашем примере два объектапространства). Фактически, файл могут составлять намного больше объектов. Для каждого из них существует курсор, и даже однокомпонентный файл объединения (join file) может владеть или ссылаться на 32 индекса области данных. База данных, а также связи между разными системными объектами MI будут рассмотрены в следующей лекции.

На рисунке можно видеть набор отдельных компонентов. Один из системных объектов MI — область данных. Она используется базой данных для хранения физических данных вместе с определением полей записей. Еще один системный объект — индекс области данных — содержит описание того, как осуществлять доступ к этим данным. В следующей лекции мы увидим, как индекс области данных обеспечивает логическое представление физических данных. Третий объект — курсор, осуществляющий фактический доступ к записям в области данных и использующий индекс области данных для формирования логического представления. Курсор предоставляет управляющие структуры для доступа к данным в области данных, а также содержит пользовательские буферы. Четвертый объект — пространство, в которое помещается результат операции над базой данных (по сути дела, это буфер вводавывода). Последний, показанный в примере объект, который также является пространством, содержит описание файла. Единственная его функция — поиск других объектов.

Поиск объектов

Найти объект в базе данных оригинальной System/38 было очень легко, так как все они были поименованы: Вы просто отыскивали нужное имя в библиотеке. Библиотека давала возможность организации объектов в группы и обеспечивала их поименный поиск. Эта структура была перенесена и в AS/400.

Библиотеки

В OS/400 библиотека — объект, который используется для поиска других объектов в базе данных. В отличие от многоуровневой иерархии каталогов в ОС ПК и Unix, библиотека OS/400 имеет одноуровневую иерархию. Для иллюстрации рассмотрим структуру имен объектов OS/400.

Чтобы найти объект OS/400 требуется знать имена библиотеки и объекта (то есть, путь "Библиотека/Объект"), а также его тип (одно и то же имя могут иметь несколько объектов, но все они — объекты разного типа). Другими словами, в библиотеке может содержаться программа SAM и пространство данных SAM, но двух программ с именами SAM быть не может. Кроме того, каждый объект находится в одной и только в одной библиотеке.

Библиотека не может ссылаться на другие библиотеки, иначе была бы нарушена одноуровневая иерархия "Библиотека/Объект". Из этого правила есть лишь одно исключение — специальная библиотека с именем QSYS, в которой, и только в кото рой, находятся некоторые специальные объекты OS/400 например, профили пользо вателей, определяющие права последних, и объекты конфигурации вводавывода, используемые для выполнения соответствующих операций. Подробно эти объекты рассматриваются в последующих лекциях.

Структура библиотеки OS/400 показана на рисунке 5.2. В данном примере QSYS содержит профиль пользователя (JOHN), библиотеку (LIB1) и описание устройства (DEVD1). Библиотека LIB1 содержит файл базы данных (DB), очередь данных (DQ) и выходную очередь (OQ).

Позже мы увидим, что с каждым заданием в системе связан список библиотек. Этот список указывает системе, где следует искать объект, а также задает порядок поиска в библиотеках.

Разделяемые папки

Разделяемые папки были введены в AS/400, главным образом, для поддержки функций OfficeИмеется в виду Office Vision/400 — программный пакет для автоматизации офисной деятельности. — Прим. консультанта.. Эту идею мы позаимствовали из System/36, которая была отличной офисной системой. Для поддержки функций Office в AS/400 были добавлены объекты папки. Интегрированная поддержка обеспечивает систему хранения всех объектов Office, содержащих необходимые данные. Среди традиционных элементов, которые могут храниться там — почта, документы, программы и файлы.

Библиотечный способ хранения документов дает пользователям возможность рассматривать эту систему как электронную картотеку, содержащую папки. Средства управления позволяют организовывать объекты, помещая их в папки. Папки могут содержать другие папки и поддерживают интерактивный поиск.

Разделяемые папки и в PC SupportПрограммный пакет для подключения персональных компьютеров к System/36, а позже и к AS/ 400. — Прим. консультанта. на System/36, и в AS/400 помогают обеспечить эффективность офисного использования ПК. В дополнение к упомянутым традиционным элементам Office, в разделяемых папках могут храниться электронные таблицы, диаграммы, рисунки, а также программы и файлы ПК.

Доступ к файлам ПК, хранящимся на AS/400, осуществляется так же, как если бы они хранились локально на ПК. Файлы могут пересылаться с ПК и назад, при этом автоматически выполняются преобразования данных. Если ПК поддерживает не сколько сессий, то он может взаимодействовать с несколькими системами AS/400, с несколькими заданиями на одной AS/400 или с любой комбинацией этих вариантов.

IBM несколько раз модифицировала PC Support, но он быстро "старел" и не соответствовал потребностям новых клиент/серверных приложений. Кроме того, PC Support поддерживал не все ОС ПК, нужные заказчикам. Хотя он и позволял использовать DOS, DOS с расширенной памятью и OS/2, но (что важно!) не мог поддерживать Microsoft Windows.

PC Support требовал радикальной замены, и IBM предложила своим заказчикам совершенно новый продукт. Client Access for OS/400 обеспечивает мощную платформу для распределенных клиент/серверных вычислений. Для привлечения новых заказчиков потребовалось также внести изменения и в файловую систему AS/400. Библиотеки для обслуживания базы данных и папки для Office и файлов ПК в целом справлялись с задачей, но им не помешали бы дополнительные возможности. В результате, была создана новая файловая система.

Интегрированная файловая система

Что если объединить в одну структуру файловую систему ПК, файловую систему Unix, а также библиотечную систему и разделяемые папки OS/400? Тогда приложение, написанное для использования файловой системы ПК или Unix, могло бы напрямую обращаться к данным, хранящимся на AS/400.

Такая интегрированная файловая система появилась в V3R1 и была названа интегрированной файловой системой IFS (integrated file system). Она объединяет все файловые системы на AS/400 общим интерфейсом и общим набором правил. Более того, любой пользователь Client Access, предпочитающий новейшие версии Windows или OS/2, может на своей рабочей станции в графическом режиме работать с библиотеками, папками и всеми новыми файловыми системами.

Первой и основной проблемой было — определить конструкцию такой файловой системы. Ведь ее отдельные части не предназначались для функционирования в единой структуре. Решение оказалось проще, чем опасались сначала.

Посмотрите еще раз на рисунок 5.2 и обратите внимание на то, что структура библиотеки OS/400 — это, по сути, подмножество структуры, используемой в ОС ПК, таких как DOS и OS/2. Пусть в мире ПК используются другие названия, но структура-то та же! ОС ПК имеют дело с файлами, а не с объектами. Библиотека там называется каталогом, внутри которого хранятся файлы. В отличие от библиотечной структуры OS/400, в каталогах ПК могут находиться другие каталоги, обычно называемые подкаталогами. Таким образом, имена файлов ПК имеют многоуровневую иерархию, в противоположность одноуровневой структуре библиотек OS/400. Имя файла ПК может иметь вид КАТ1\КАТ2\...\КАТn\ИМЯФАЙЛА. За исключением обратной косой черты (\), это — надмножество структуры имен библиотеки OS/400.

Файловая структура Unix — также надмножество библиотечной структуры OS/400. Вспомните, что объект OS/400 может находиться только в одной библиотеке, иначе говоря, к любому объекту OS/400 имеется единственный путь. Файловая система Unix поддерживает наличие множественных путей к одному и тому же объекту.

Для объединения всех этих файловых систем мы решили взять единый корень из ПК-подобной файловой системы и поместить в него все остальные. На рисунке 5.3 показано, как видится вся AS/400 и ее файловые системы клиенту Windows. AS/400 представлена как один диск, на котором находятся каталоги в стиле ПК, каталоги в стиле Unix, библиотеки OS/400 (QSYS.LIB), разделяемые папки OS/400 (QDLS) и еще несколько файловых систем поддержки новых приложений. В число последних входят: система, полностью совместимая с POSIX (QOpenSys); файловая система для пользователей LANServer (QLANSrv); файловая система для Novell Netware (QNETWARE); Network File System (QNFS) фирмы Sun Microsystems. Поддержива ются и другие файловые системы, а в будущем, по мере того как все больше приложений и их файловых систем будут использовать AS/400, добавятся новые.

Соглашение об именах в IFS основано на стандарте ПК. Имя имеет вид КАТ1\КАТ2\...\КАТn\ИМЯФАЙЛА. К радости тех, кто не может запомнить, когда использовать прямую (/), а когда обратную (\) косую черту, новое соглашение допускает обе. Вы даже можете использовать разные разделители в одном и том же имени.

В соответствии со стандартом POSIX, длина имен файлов и каталогов увеличена. На AS/400 имена в каталогах IFS хранятся в формате Unicode, который, будучи международным стандартом, поддерживает использование разных языков, включая двух-байтовые наборы символов, используемые в ряде стран. Все RISC-системы теперь позволяют хранить информацию в базе данных в формате Unicode.

IFS дает возможность пользователю рассматривать файл, хранящийся на AS/400, как расширение его собственной файловой системы. Пользователи Unix считают, что они имеют дело с файловой системой Unix, а пользователи ПК (см. рисунок 5.3) — что это файлы ПК. К тому же, если оба пользователя могут работать с одними и теми же данными, отпадает необходимость копирования этих данных. Те, кто привык к ПК или к AS/400 продолжают использовать QDLS и QSYS.LIB соответственно, а новые пользователи могут работать со своими приложениями с помощью любой из поддерживаемых файловых систем. Пользователям ПК и Unix даже не требуется изучать CL — язык команд AS/400. Они могут применять любые команды и утилиты для DOS, Windows или Unix.

Нельзя забывать, что главная задача IFS — обеспечение доступа к данным. Поэтому либо формат данных должен быть изначально совместим с приложением, которое их запрашивает, либо данные должны быть преобразованы соответствующим образом. OS/400 поддерживает большинство таких преобразований, например, между кодировкой EBCDIC, (Extended Binary Coded Decimal Interchange Code) используемой "родными" приложениями AS/400, и ASCII (American Standard Code for Information Interchange), используемой ПК.

Поддержка Unicode в базе данных RISCсистем дает возможность разработчикам приложений использовать универсальный формат данных на разных платформах. При этом отпадает необходимость специальных версий программ для стран, где языки требуют двухбайтового представления. Приложение может быть использоваться по всему миру.

Доступ к объектам

Недостаточно просто найти объект. Чтобы получить к нему доступ или модифицировать объект, пользовательской или системной программе необходимы некоторые средства доступа. Для системных объектов эти средства находятся на уровне MI.

OS/400 отвечает за управление своими объектами, каждый из которых состоит из системных объектов, отслеживая последние. Компонент управления объектами в SLIC работает с системными объектами и ничего не "знает" об объектах OS/400. И в этом случае разработчики AS/400 старались поддержать независимость между двумя частями ОС, выше и ниже MI. Единственной плоскостью соприкосновения между ними является MI, и именно здесь обеспечиваться доступ к объектам.

Доступ к системному объекту осуществляется посредством системного указателя, который, занимая 16 байтов памяти, содержит адрес системного объекта, а также информацию о его типе. Более подробно формат системного указателя рассматри вается в лекции 8.

Адресация на базе возможностей

Системный указатель может также содержать сведения о типе операций, которые выполнимы над объектом. Обычно, такая информация называется полномочиями (authority). Указатель, содержащий адрес объекта и полномочия, называется возможностью (capability). System/38 использует адресацию на базе возможностей, все системные указатели содержат как адрес, так и полномочия. В AS/400 способ предоставления пользователям полномочий по работе с объектами был изменен.

Причина изменений — забота о защищенности системы. Если полномочия хранятся в указателе, то пользователь, обладающий указателем, обладает и полномочиями. Мало того, он даже может передать указатель или его копии другому пользователю.

Предположим, мы хотим дать пользователю право выполнения одиночной операции над объектом, то есть предоставить программе пользователя однократный доступ или возможность модификации данных объекта, но не на постоянной основе. Однако после того, как доступ к системному указателю открыт, "закрыть" его невозможно.

Для ограничения полномочий пользователя и повышения степени защищенности IBM добавила в AS/400 методы предоставления временных полномочий. Одновременно, мы удалили полномочия из указателей всех пользовательских программ, оставив их только для указателей, используемых ОС в системном состоянии (подробности — в лекции 7).

Так что говорить об AS/400 как о системе с адресацией на базе возможностей неправильно. За исключением только что указанного случая, такой способ адресации в AS/400 не используется.

Разрешение системных указателей

Системный указатель считается разрешенным, если содержит прямой адрес системного объекта. Указатель, содержащий символический адрес, называется неразрешенным. Символический адрес используется для поиска объекта в библиотеке и состоит из имени, типа и подтипа объекта, причем последний для поиска не требуется. Его значение определяется пользователем, и служит лишь для дальнейшей классификации объектов OS/400.

На рисунке 5.4 показан процесс разрешения системного указателя по команде "RESOLVE". Команда использует имя и тип системного объекта из неразрешенного указателя, а также запрашиваемые полномочия. Выполняется поочередный просмотр библиотек из списка библиотек, связанного с заданием, выдавшим данную команду. Просмотр длится, пока не будет найден заданный объект.

Затем выполняется тройная проверка. Прежде всего, проверяется тип объекта, чтобы гарантировать корректный возврат объекта; затем, есть ли у пользователя права, указанные в команде "RESOLVE" (эта информация хранится в профиле пользователя); и, наконец, выясняется, возможен ли доступ к объекту (не был ли он заблокирован другим пользователем).

Если результаты тройной проверки удовлетворительны, то в неразрешенный системный указатель записывается адрес системного объекта. Как отмечалось выше, полномочия могут быть помещены только в указатель, возвращаемый системной программе. После того как указатель разрешен, программа может использовать его при последующих обращениях к объекту; повторять процедуру разрешения при этом не требуется.

Другие типы указателей

Системный указатель обеспечивает доступ к системному объекту, но при выполнении некоторых операций нужно работать с данными, содержащимися внутри таких объектов. Для этого используются другие типы указателей. Но прежде чем рассказать о них, я хочу остановиться на внутренней структуре системного объекта.

Итак, системный объект состоит из двух основных частей: функциональной и пространственной. Содержимое функциональной части зависит от типа системного объекта, например, для программы — это последовательность команд. Пространственная часть системного объекта (часто называемая ассоциированным пространством) - просто байтовое пространство, используемое в качестве рабочего. Такая структура характерна для всех системных объектов, за единственным исключением: системный объект "пространство" не имеет функциональной части.

Необходимость отдельной пространственной части в объекте объясняется способом представления памяти в MI. Вспомните, что для поддержания независимости от нижележащей технологии, в MI нет понятия памяти в традиционном смысле; только объекты и ничего кроме них. Между тем, указатели и данные пользователей должны где-то храниться. Место для этого - пространственная часть системных объектов.

На рисунке 5.5. Вы можете видеть два системных объекта, каждый из которых имеет функциональную и пространственную части. Пространственная часть может содержать как указатели, так и данные. На рисунке пространственная часть второго объекта содержит системный указатель на первый системный объект. Системные указатели всегда указывают на системные объекты, но лишь на начало, так что с их помощью не много можно сделать. Это и понятно, ведь основное назначение указателя - обеспечить доступ к объектам. Но как быть, если надо проникнуть внутрь объекта и поработать с байтами?

Так как все системные объекты инкапсулированы, манипуляции с байтами внутри функциональной части невозможны ѕ нельзя даже заглянуть внутрь ее. Очевидно, нужен некий способ доступа к информации, находящейся в пространственной части (рабочем пространстве). Этот способ предоставляет нам пространственный указатель.

Пространственный указатель очень похож на системный. Он имеет длину 16 байтов и содержит адрес. Отличие в том, что адрес из пространственного указателя указывает на некоторый байт гдето в пространственной части системного объекта. Таким образом, пространственные указатели можно использовать для доступа и манипуляции содержащимися там байтами.

Другое важное различие между двумя типами указателей состоит в операциях с адресом, которые каждый из них может выполнять. Адрес в пространственном указателе может быть изменен программой MI так, чтобы указывать на другой байт в том же пространстве. Адрес в системном указателе лишь указывает на начало объекта и изменить его нельзя. Пользователь, имеющий соответствующие права, может с помощью системного указателя получить пространственный указатель на объект. Второй объект, показанный на рисунке 5.5, также содержит пространственный указатель. Рисунок иллюстрирует, как указатель такого типа предоставляет доступ к байтовому пространству первого объекта.

В дополнение к системным и пространственным, в MI есть еще четыре типа указателей. Указатель данных аналогичен пространственному, но содержит описание типа данных, что позволяет рассматривать цепочку байтов внутри пространства как данные любого типа. В качестве аналогии можно привести указатель языка С. Указатель команд служит для определения места команды в последовательности и используется для выполнения переходов.

Четыре рассмотренных типа указателя (системный, пространственный, данных и команд) присутствовали в первом варианте System/38. Позднее для обеспечения доступа к внутренней памяти была добавлена специальная версия пространственного указателя - машинный пространственный указатель. В AS/400 с появлением ILE был добавлен новый процедурный указатель. Процедурные указатели используются в операциях вызова/возврата, рассмотренных в лекции 4.

Характеристики системных объектов

Теперь можем, наконец, перечислить основные характеристики всех системных объектов (некоторые из них мы рассмотрим сейчас, а некоторые — в следующих лекциях).

Постоянство объекта (часть характеристики 8) требует некоторых дополнительных пояснений. Итак, постоянный объект продолжает существовать в системе, пока не будет специально уничтожен. Присутствуя в памяти, он может легко использоваться совместно разными пользователями. Именно этим AS/400 сильно отличается от других систем, которые требуют располагать разделяемую или предназначенную для длительного хранения информацию в отдельной файловой системе. Позже мы рассмотрим, как одноуровневая память AS/400 поддерживает постоянство объектов.

В будущем постоянство объектов очень пригодится для поддержки объектно-ориентированных баз данных. Необходимо, чтобы объекты продолжали существовать, и после того, как их создатель ушел со сцены. И здесь уникальные возможности постоянства объектов AS/400 дают ей существенные преимущества перед другими ОС, вынужденными прибегать к хранению постоянных объектов в отдельной файловой системе.

Не каждый объект должен быть постоянным, этот параметр задается при его создании. Постоянные объекты требуют дополнительных расходов, так на всем протяжении своего существования используют системные ресурсы. Пример объекта, который имеет смысл создавать как постоянный — область хранения записей базы данных.

Как уже упоминалось, временные объекты исчезают при каждой загрузке системы. В обычной системе области временной памяти связаны с создавшими их заданиями, не могут разделяться пользователями и исчезают, когда задание завершено. В AS/400 вся память, содержит ли она постоянные или временные объекты, может разделяться пользователями и объекты остаются в системе даже после завершения задания. При разработке AS/400 в качестве некоторого, отличного от завершения задания, момента удаления временных объектов была выбрана загрузка системы. Это оказалось удобным, так как снижает накладные расходы. Например, если бы мы разрушали временную библиотеку задания по завершении последнего, то производительность при исполнении остальных заданий несколько снижалась бы. И мы решили перенести накладные расходы на время выполнения загрузки.

Примером временного объекта может служить индекс области данных, обеспечивающий проекцию базы данных: если он создается для выполнения единственного запроса к базе данных, то нет смысла делать его постоянным. Обратите внимание, что постоянный объект может пережить крах системы, иногда объекты и создаются постоянными только для того, чтобы не потерять их в случае сбоя системы. Напротив, если для восстановления системы ее потребуется перезагрузить, то все временные объекты будут потеряны. Внутренние детали обработки системой временных и постоянных объектов будут объяснены далее.

Программные объекты

До сих пор мы рассматривали только системные объекты и их характеристики. Однако в MI есть другие элементы данных, также называемые объектами, но имеющие очень малое сходство с обычными, что создает еще одну терминологическую проблему.

В лекции 4 мы рассмотрели содержимое оригинального шаблона программы MI — последовательность команд и таблицу определения объектов ODT. ODT описывает операнды, используемые программой. В результате неудачного выбора имен проектировщики MI для System/38 называли эти операнды объектами, а точнее программными объектами. Таким образом, двухбайтовое двоичное число считается объектом.

Программные объекты не имеют с системными объектами MI ничего общего, кроме названия. Но так как программный объект очень легко спутать с системным объектом типа "программа", то мы, для простоты, будем с этого момента использовать слово "объект" только для обозначения системных объектов MI.

Внутри системного объекта

Хотя в MI нет концепции памяти, все процессоры AS/400 используют физическую память, включая основную память и диск. Системные объекты, расположенные ниже MI, реализованы как строго определенные структуры, хранящиеся в этой памяти. За создание и управление этими структурами данных отвечает компонент управления объектами в SLIC. Давайте рассмотрим формат этих структур данных и их использование для представления системных объектов MI.

Сегментированная память

Понятия памяти и дискового пространства верны только ниже MI. В отличие от OS/400, SLIC "знает" о наличии этой памяти и работает с нею. Вся основная память и дисковое пространство в AS/400 находятся внутри большого единого адресного пространства, обычно, называемого одноуровневой памятью. Объем этой памяти равен общему числу байтов, на которое может ссылаться 64-разрядный адресЧисло байтов, адресуемых 64-разрядным числом, настолько велико, что большинство людей не могут соотнести его с чем-либо, что можно "пощупать руками". Когда в AS/400 был 48-разрядный адрес, мы, бывало, говорили, что число адресуемых байтов равно расстоянию от Земли до Солнца и обратно в миллиметрах. Для 64-разрядного адреса нужна какаято новая аналогия..

Одноуровневая память — это используемая в AS/400 разновидность виртуальной памяти, обеспечивающая логическое представление памяти, которое не обязательно соответствует ее физической структуре. Достаточно представлять себе одноуровневую память как очень большое адресное пространство, внутри которого все и хранится. Различия между обычными системами виртуальной памяти одноуровневой памятью AS/400 описаны в лекции 8.

Адресное пространство AS/400 логически разделено на блок последовательных байтов, называемых сегментами. В System/38 и первых AS/400 использовалось два размера сегмента: 64К и 16М. 16-мегабайтный сегмент состоял из 256 сегментов по 64К и иногда назывался сегментной группой. При переходе на 64-разрядную адресацию сегменты меньшего размера были исключены, остался только сегмент размером в 16М.

Сегменты не перекрываются и всегда начинаются с границы. Это означает, что 24 младших (самых правых) бита адреса первого байта каждого сегмента размером 16М всегда равны 0. Каждый 16-мегабайтный сегмент уникально задается 40 старшими (самыми левыми) битами 64-разрядного адреса.

Отображение адресного пространства AS/400 на физическую основную память и диски осуществляется компонентом управления памятью SLIC с помощью блоков памяти по 4К, называемых страницамиSystem/38 и первые модели AS/400 использовали размер страницы в 512 байтов. Размер страницы был увеличен до 4К при переходе на 64-разрядную RISC-аппаратуру.. Сегмент состоит из целого числа таких страниц, которые не обязательно расположены в физической памяти последовательно.

Структура системного объекта

На рисунке 5.6 изображен формат системного объекта в одноуровневой памяти. Первые 32 байта содержат заголовок, предоставляющий информацию о самом сегменте. Далее следует заголовок EPA (Encapsulated Program Architecture). ЕРА была создана для спецификации внутренней структуры инкапсулированных объектов System/38, а затем та же внутренняя структура была перенесена в AS/400. Заголовок ЕРА содержит атрибуты (свойства) общие для всех системных объектов, независимо от типа. Заголовок сегмента и заголовок ЕРА вместе занимают первые 256 байтов всякого системного объекта.

Каждый тип объекта содержит свойства, присущие только ему: свойства программы уникальны по сравнению с областью данных, и наоборот. Эти индивидуальные свойства содержатся в специфическом заголовке (customized header) объекта, следующем после заголовка ЕРА.

После трех заголовков следуют компоненты, составляющие данный объект: например, за специфическим заголовком программы размещается последовательность команд. Так как все системные объекты имеют пространственную часть, пространственный компонент присутствует всегда. В MI он называется ассоциированным пространством. Конкретный набор компонентов и порядок их следования зависят от типа объекта.

Типов системных объектов слишком много, для того чтобы подробно описывать специфические заголовки и компоненты объектов. Однако некоторые примеры мы рассмотрим.

Многосегментные объекты

Как мы уже говорили, системные объекты занимают один или несколько сегментов и всегда начинаются с границы сегмента. Первый сегмент называется базовым — его имеет каждый объект, и на него всегда ссылается системный указатель. В зависимости от типа объекта, он может занимать один или несколько вторичных сегментов, большинство объектов занимают их ассоциированным пространством. Ни один сегмент не может быть частью более чем одного системного объекта.

На рисунке 5.7 показан системный объект, занимающий два сегмента, при этом системный указатель ссылается на базовый сегмент. Обратите внимание, что у каждого сегмента — свой заголовок. Заголовок сегмента содержит информацию о сегменте, а не о содержащемся в нем объекте. В заголовке сегмента также содержатся адреса, связывающие сегменты друг с другом. Заголовок ЕРА содержится только в базовом сегменте. За заголовком ЕРА, также только в базовом сегменте, следует специфический заголовок объекта.

Выделение сегментов происходит при создании системного объекта посредством команды "Create xxx", где "xxx" — тип создаваемого объекта. На рисунке 5.8 показаны исходные параметры и результаты команды "Create" на уровне MI. Эта команда использует пространственный указатель для доступа к шаблону объекта, содержащегося в пространственном объекте. Читателю следует иметь в виду, что команды "Create xxx" MI — это не то же самое, что и команды "CRTxxx" OS/400. Например, команда OS/400 "CRTRPGPGM" должна выполнить ряд предварительных шагов, прежде чем дело дойдет до заключительного прохода компиляции программы — вызова "Create" в MI. Исполнение этой команды на уровне MI приводит к созданию в одноуровневой памяти базового и вторичных сегментов.

Для отражения наличия нового объекта обновляются различные справочники, поддерживаемые SLIC. Компоненту управления памятью нужен доступ к сегменту, поэтому выполняется обновление одного из справочников компонента. Если объект создается в библиотеке (аналогичный термин ниже MI — контекст), то туда также нужно внести его имя и местоположение. Если библиотека не задана, то объект помещается в текущую библиотеку задания, вызвавшего команду "Create" (одна библиотека из списка для каждого задания всегда обозначается как текущая). Аналогично, следует обновить профиль пользователя или группы, чтобы обозначить владельца нового объекта. Заключительный этап — создание системного указателя на объект и возвращение его пользователю, запросившему о создании.