Читать онлайн «Основы AS/400». Страница 33

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