Фрэнк Солтис - Основы AS/400
- Название:Основы AS/400
- Автор:
- Жанр:
- Издательство:Русская Редакция
- Год:1998
- ISBN:5-7502-0038-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Фрэнк Солтис - Основы AS/400 краткое содержание
В данном переводе второго издания книги "Основы AS/400" описаны практически все аспекты работы этой вычислительной системы: от используемых в ней новейших аппаратных и программных технологий до истории создания. Издание состоит из предисловия, введения, 12 глав, приложения и предметного указателя; содержит иллюстрации. Автор книги Фрэнк Солтис, сделавший академическую карьеру в области информатики, начиная с замысла System/38, является одним из ведущих специалистов по идеологии и архитектуре AS/400. Книга предназначена для широкого круга читателей: бизнесменов, менеджеров, руководителей подразделений, желающих понять, чем система или сервер AS/400e могут быть выгодны их бизнесу. Тем не менее, издание будет полезно и специалистам, которые хотят разобраться в мельчайших деталях. На русском языке публикуется впервые.
Основы AS/400 - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Команда создания программы «Create Program» указывает на шаблон программы. Пока мы остановимся на двух типах указателей: системном и пространственном (позже мы увидим, что есть указатели и других типов). Первый направлен на системный объект MI, второй — на байт в пространстве. Длина каждого из этих указателей 16 байт. Через указатели в MI осуществляется адресация, так что указатель в MI можно представлять себе просто как адрес.
Команда создания программы исполняется с помощью кода, лежащего ниже MI. Сначала через пространственный указатель команды «Create Program» код находит шаблон программы, над которым выполняется синтаксический контроль. Затем транслятор преобразует последовательность команд MI-шаблона программы в последовательность внутренних команд IMPI или PowerPC, которая упаковывается в системный объект MI — программу. Наконец, инициатору запроса возвращается адрес вновь созданной программы в виде системного указателя на этот объект. Если в какой-то части данной операции возникают проблемы, соответствующая диагностическая информация возвращается в виде сообщения.
Уничтожение программы
Любой объект на уровне MI, который можно создать, можно и уничтожить. Соответственно на каждую команду создания объектов MI приходится команда уничтожения. Пользователь на уровне MI устанавливает системный указатель на программу или другой объект MI и дает команду: «Уничтожить». Конечно, сделать это просто так нельзя: у пользователя должны быть соответствующие права на доступ к разным объектам.
Тему прав пользователей по отношению к объектам мы подробно обсудим в главе 7, а сейчас только упомянем, что пользователь может иметь разные уровни прав доступа к разным объектам. Чтобы уничтожать объекты, нужен самый высокий уровень. Как правило, объект может уничтожить только его владелец; но бывают ситуации, когда такие права имеют несколько пользователей. Каждому пользователю в системе соответствует специальный объект — профиль пользователя. Вместе с другими объектами профиль пользователя определяет права данного пользователя по отношению к тем или иным объектам. Когда пользователь прибегает к команде уничтожения, система сначала обращается к его профилю и выясняет, есть ли у него такое право, и лишь в случае утвердительного ответа выполняет операцию.
Материализация и адаптируемость программы
Наблюдать характеристики программы поверх MI можно лишь через шаблон программы. Шаблон — результат работы компиляторов ЯВУ. Это самый нижний уровень, на котором возможна работа с компонентами программы поверх MI. Ниже MI программа существует в виде системного объекта, и все работающие с ним команды MI воспринимают его как единое целое.
Внутри объекта находится последовательность команд IMPI или PowerPC. Объект инкапсулирован, то есть, невидим извне. Это обеспечивает независимость от технологии, однако программа не имеет законченной формы, так как последовательность ее команд невидима.
Однако, если прикладному или системному ПО необходим доступ к характеристикам программы, команда MI, позволяет эту программу материализовать. Команда материализации указывает на инкапсулированный программный объект, по которому воссоздается шаблон программы. Материализация — операция, противоположная инкапсуляции.
Технологию материализации не всем просто понять. Честно говоря, обратная компиляция (восстановление исходного текста программы при наличии ее только в откомпилированном виде) не слишком хорошо разработана и многолетние исследования в этой области идут пока без особого успеха.
Как же решает эту задачу AS/400? Да просто жульничает: она не выполняет де-компиляции последовательности команд IMPI или PowerPC. Вместо этого копия шаблона программы сохраняется вместе с объектом. Когда выполняется команда MI материализующая программу, в ответ возвращается объект шаблона программы.
Хранение шаблона программы в качестве системного объекта MI и придает System/38 и AS/400 возможности, отсутствующие в других системах. Это позволяет изменять набор команд, не влияя на приложения заказчиков. Изменения вносятся в новую версию транслятора, а затем все программы ретранслируются из своих шаблонов. Наконец, новые последовательности команд снова инкапсулируются в объекты. Все это происходит ниже MI и без участия пользователя.
Чтобы Вы смогли лучше «почувствовать разницу», обратимся к классическому примеру внедрения System/38 Model 7. System/38 появилась как абсолютно новая система с абсолютно новым набором команд, новыми приложениями и новой ОС. Но как использовать эти команды:, никто точно не знал. Как правило, для того, чтобы достичь максимальной производительности системы, оптимизируют аппаратную реализацию наиболее часто встречающихся последовательностей команд с целью достичь их как можно более быстрого выполнения.
Первоначально набор команд IMPI имел только 8-битные коды операций, то есть команд не могло быть более 256 (28 = 25 6). Когда начали писать приложения для System/38, то обнаружилось, что нужны новые функции. В ответ мы изобретали новые команды (своего рода болезнь!) и очень скоро вышли за эти пределы.
Вполне естественно стремление сохранить набор операций небольшим, а следовательно, контролируемым и не избыточным. Но не менее законно желание упростить сложные задачи. Как увязать эти противоречия? Хорошо, если б существовал научный метод создания наборов команд, но, увы! Это скорее искусство, чем наука. Через пару лет мы пришли, как нам казалось, к оптимальному набору команд IMPI. И чтобы добавить эти новые команды, решили ввести в формат команд IMPI расширения кода операции.
К тому времени мы уже знали, как работать с существующими командами IMPI и как повысить производительность путем перевода наиболее часто используемых команд в другие, более быстрые форматы. Изменение кодов операций означает, что команда, на предыдущей версии оборудования вызывавшая, скажем, загрузку, на новой версии служит для передачи управления. В любой «нормальной» системе такая замена привела бы к хаосу, но не в System/38 — ведь она не зависит от технологии.
При модернизации оборудования системы устанавливалась и новая версия транслятора. У каждой программы в системе был свой заголовок объекта, который, кроме всего прочего, показывал, какой уровень транслятора использовался для создания программы. При первом исполнении программы система проверяла заголовок и при обнаружении старой версии обрабатывала связанный с объектом шаблон программы новым транслятором, сохраняя новый код IMPI в объекте. После этого программа выполнялась. Ретрансляция производится лишь однажды — при следующих вызовах программы используется новый код.
Читать дальшеИнтервал:
Закладка: