Текст книги "Основы AS/400"

Автор книги: Фрэнк Солтис

сообщить о нарушении

Текущая страница: 13 (всего у книги 41 страниц)

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

В System/38 объекты были как в ОС, так и в MI. Определением этих объектов и выбором имен для них занимались две разные группы. Одна разрабатывала объекты CPF, (которая в AS/400 была переименована в OS/400[ 42 ]42
  До 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 двумя разными группами проектировщиков с разными подходами к выбору названий.

Один подход таков: коль Вы создаете новую систему – то все надо переименовать, и пусть пользователи, видя новые названия вдумаются в новую структуру. По этой логике, если Вы собираетесь реализовать библиотеку и назвали ее библиотекой, то кто-нибудь обязательно скажет: «Я знаю, что такое библиотека; я уже работал с системой, где есть библиотеки». Между тем, библиотека в другой системе может полностью отличаться от Вашей. Если же дать библиотеке другое название, например «контекст», то никто не сможет априори строить о ней какие-либо предположения. Данный подход к именам защищал Гленн Хенри – менеджер программирования System/38 и, следуя подобным взглядам, группа, разрабатывавшая системные объекты MI, породила некоторые весьма странные названия.

Названия же для объектов ОС выбирала другая группа, предпочитавшая подход Томаса Эдисона (Thomas Edison): лучше даже не вполне подходящее, но уже знакомое покупателям имя. Когда Эдисон продвигал идеи использования электроэнергии, он решил выбирать названия, знакомые каждому, использующему природный газ. Он говорил, что к дому подводятся электрические магистрали (main), подобно газовым или водопроводным магистралям, хотя main – это труба или канал, а электроны, обычно, попадают в дом не по трубе. Он также называл нагревательный элемент кухонной плиты электрической горелкой, чтобы электрическая плита казалась чем-то знакомым людям, имевшим дело с газовыми горелками (скажем честно – электричество в нагревающем элементе не «горит»). Наша группа разработчиков ОС понравилась бы Эдисону.

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

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

Графический набор символов	Служебная программа
Документ	Описание сетевого интерфейса
Идеографическая таблица символов	Описание сессии
Идеографическая таблица сортировки Описание подсистемы
Идеографический словарь	Словарь правописания
Индекс поиска информации	Таблица
Класс	Библиотека
Класс описания сервиса	Описание линии
Команда	Определение меню
Область данных	Определение группы панели
Описание задания	Пользовательский индекс
Описание контроллера	Очередь сообщений
Описание редактирования	Программа
Описание устройства	Модуль
Очередь данных	Определение продукта
Очередь заданий	Пользовательский профиль
Папка	Справочная таблица трансляции кода
Словарь данных	Описание режима
Список документов	Выходная очередь
Список конфигурации	Файл сообщения
Список прав	Журнал
Таблица управления формами	Описание машины S/36
Файл	Определение запроса
Формат диаграммы	Приемник журнала

Таблица 5.1. Объекты OS/400

лок транзакции	Описатель режима
Группа доступа	Индекс
Индекс пространства данных	Очередь
Класс описания сервиса	Описание логического устройства
Контекст	Модуль
Курсор	Пространство управления процессом
Описание контроллера	Описатель сети
Пространство дампа	Профиль пользователя
Пространство данных	Программа (3 подтипа)
Пространство цепочки байтов	Пространство журнала
Словарь	Пространство
Список прав	Порт журнала

Таблица 5.2. Системные объекты MI

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

Рисунок 5.1 Объекты файла базы данных OS/400

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

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

рации над базой данных (по сути дела, это буфер ввода-вывода). Последний, показанный в примере объект, который также является пространством, содержит описание файла. Единственная его функция – поиск других объектов.

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

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

Библиотеки

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

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

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

Рисунок 5.2 Структура библиотеки OS/400

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

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

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

Разделяемые папки были введены в AS/400, главным образом, для поддержки функций Office[ 43 ]43
  Имеется в виду Office Vision/400 – программный пакет для автоматизации офисной деятельности. – Прим. консультанта.


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

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

Разделяемые папки и в PC Support[ 44 ]44
  Программный пакет для подключения персональных компьютеров к 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...КАТпИМЯФАЙЛА. За исключением обратной косой черты (), это – надмножество структуры имен библиотеки 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...КАТпИМЯФАЙЛА. К радости тех, кто не может запомнить, когда использовать прямую (/), а когда обратную () косую черту, новое соглашение допускает обе. Вы даже можете использовать разные разделители в одном и том же имени.

В соответствии со стандартом 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.

Рисунок 5.3 Интегрированная файловая система с точки зрения Windows-клиента

Нельзя забывать, что главная задача 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». Команда использует имя и тип системного объекта из неразрешенного указателя, а также запрашиваемые полномочия. Выполняется поочередный просмотр библиотек из списка библиотек, связанного с заданием, выдавшим данную команду. Просмотр длится, пока не будет найден заданный объект.

Рисунок 5.4 Разрешение системного указателя

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

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

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

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

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

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

Рисунок 5.5 Системные объекты

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

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

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

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

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

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

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