- •1. Факторы, способствующие использованию мэйнфреймов
- •1.1. Надежность, доступность и удобство обслуживания
- •1.2. Безопасность
- •1.3. Масштабируемость
- •1.4. Последовательная совместимость
- •1.5. Эволюционирующая архитектура
- •2.1 Пакетная обработка
- •2.2. Обработка оперативных транзакций
- •3. Роли в мире мэйнфреймов
- •3.1. Системный программист
- •3.2. Системный администратор.
- •3.3. Проектировщики и программисты приложений.
- •3.4. Системный оператор.
- •3.5 Аналитик производственного контроля.
- •3.6. Роль изготовителей
- •4. Архитектура мэйнфрейма.
- •4.1. Базовая архитектура zSeries и основные направления ее развития.
- •4.2.Архитектура центральных процессоров. Регистры и система команд процессоров.
- •4.2. Регистры и система команд процессоров
- •4.3. Организация адресных пространств внутренней памяти. Уровни внутренней памяти. Типы адресных пространств основной памяти.
- •4.3 Типы адресных пространств основной памяти.
- •4.4 Слово состояния программы.
- •5. Операционные системы мэйнфреймов
- •5.2 Z/Virtual Machine (z/vm)
- •5.4. Linux для zSeries
- •6.1 Общие сведения аппаратных систем мэйнфрейма
- •6.2. Устройство ранних систем s/360, современных z/series и их различия
- •6.3. Устройства ввода-вывода : логические разделы, каналы, коммутаторы - escon и ficon, блок управления устройством ucb.
- •6.4 Средства управления системой и разделы
- •6.5 Свойства логических разделов
- •6.6 Консолидация мэйнфреймов
- •6.7 Процессорные устройства cp, sap, ifl.
- •6.8 Процессорные устройства zAap, zIip, icf.
- •6.9. Мультипроцессоры
- •6.10. Дисковые устройства 3390 и 2105 , устройство управления 3990
- •6.11 Кластеризация, простой общий dasd, основные его характеристики и области применения. Сравнительный анализ уровней кластеризации dasd и ctc.
- •6.12. Кластеризация, ctc кольца, основные его характеристики и области применения. Сравнительный анализ уровней кластеризации ctc и dasd
- •6.13. Parallel Sysplex
- •6.14 Устройство сопряжения
- •6.15. Малые системы м-ф
- •6.16. Средние одиночные системы
- •6.17 Более крупные системы
- •6.18. Непрерывная доступность мэйнфреймов
- •7.1. Введение в z/os. Физическая память, используема в z/os
- •7.2. Аппаратные ресурсы, используемые в z/os.
- •7.3. Мультипрограммирование и мультипроцессирование.
- •7.4. Модули макросы. Управляющие блоки.
- •7.5. Основные средства z/os.
- •7.6. Виртуальная память, адресное пространство мэйфрейма.
- •7.7. Использование адресных пространств: изоляция, связь. Динамическая трансляция адреса.
- •7.8. Виртуальная память. Формат виртуального адреса.
- •7.9. Организация адресации виртуальной памяти в z/os. Фреймы, страницы и слоты.
- •7.10. Страничный обмен в z/os. Изъятие страницы.
- •7.11. Счетчик интервалов отсутствия обращений. Свопинг.
- •7.12. Защита памяти. Ключи защиты.
- •7.13. Менеджеры памяти: реальной, вспомогательной и виртуальной.
- •7.14. История виртуальной памяти и адресуемости семейства мэйфреймов.
- •Системные адресные пространства и главный планировщик.
- •7.16. Управление рабочей нагрузкой. Основные операции выполняемые wlm.
- •7.17. Ввод-вывод данных, средства мониторинга в системе.
- •7.18. Назначение обработки прерывания.
- •7.19. Слово состояния программы psw, регистры
- •7.20. Диспетчеризуемые единицы работы z/os: tcb, srb. Вытесняемые и не вытесняемые единицы работы.
- •7.21. Назначение компонента диспетчер в z/os.
- •7.22. Синхронизация использования ресурсов. Организация очередей. Блокировка ресурсов.
- •Определяющие свойства z/os
- •7.24. Дополнительные и промежуточные по для z/os.
- •8.Интерактивные средства z/os
- •8.1 Предназначение tso. Основные функции.
- •8.2 Выполнение команд tso в собственном режиме. Использование clist и rexx в tso.
- •8.4. Интерактивные интерфейсы Интерактивные средства z/os unix
- •9.Наборы данных
- •9.1Наборы данных. Типы набора данных в z/os.
- •9.2. Устройства хранения набора данных и методы доступа
- •9.3.Распределение набора данных. Логические записи и блоки. Экстентты набора данных.
- •9.4. Форматы записи наборов данных.
- •9.5. Последовательный, секционированный набор данных.
- •9.6. Метод доступа vsam.
- •9.7 Файловые системы z/os unix. Сравнение наборов данных z/os и файлов файловой системы
- •9.7 Сравнение наборов данных z/os и файлов файловой системы
- •10.3. Журналы транзакций и их назначения.
- •10.4. Типы резервного копирования sql Server 2008.
- •Одноранговые сети типа рабочая группа на базе ос Windows и варианты лицензирования.
- •11.3. Отказоустойчивый кластер на базе oc Windows Server 2008 Ent.
6.5 Свойства логических разделов
Логические разделы на практике равнозначны отдельным мэйнфреймам. На каждом LPAR выполняется отдельная операционная система. Это может быть любая операционная система для мэйнфреймов; другими словами, необязательно запускать z/OS на каждом LPAR. Специалисты по планированию установки могут решить установить совместное использование устройств ввода-вывода несколькими LPAR, однако такие решения принимаются на месте.
Системный администратор может выделить один или несколько процессоров системы для эксклюзивного использования одним LPAR. С другой стороны, администратор может разрешить использование всех процессоров некоторыми или всеми LPAR. В данном случае функции управления системой (часто называемые микрокодом или микропрограммным обеспечением) содержат диспетчер, осуществляющий совместное использование процессоров выбранными логическими разделами. Администратор может задать максимальное количество процессоров, одновременно задействованных в каждом логическом разделе. Администратор может также задать весовые коэффициенты для разных логических разделов, например определить для LPAR1 в два раза больше процессорного времени, чем для LPAR2.
Операционная система в каждом логическом разделе загружается отдельно, при этом используется отдельная копия операционной системы, используется отдельная консоль оператора (если требуется) и т. д. Если происходит отказ системы на одном LPAR, это не влияет на другие LPAR.
Консоли операционной системы для двух логических разделов z/OS могут располагаться в совершенно разных местах.
На практике в большинстве случаев нет разницы между, например, тремя отдельными мэйнфреймами с запущенной z/OS (и с совместным использованием большей части конфигурации ввода-вывода) и тремя LPAR на одном мэйнфрейме, настроенных таким же образом. За редким исключением z/OS, операторы и приложения не могут обнаружить разницу.
Ко второстепенным отличиям относятся способность z/OS (если разрешено при определении LPAR) получить информацию о производительности и использовании по всей мэйнфрейм-системе и динамически перераспределять использование ресурсов (процессоров и каналов) между разными LPAR для улучшения производительности.
6.6 Консолидация мэйнфреймов
В настоящее время используется меньше мэйнфреймов, чем 15 или 20 лет назад В некоторых случаях все приложения были перенесены на системы других типов. Однако в большинстве случаев меньшее число вызвано консолидацией.
Консолидация - несколько небольших мэйнфреймов заменяются на меньшее число более крупных систем.
Существует убедительный аргумент в пользу консолидации. Программное обеспечение мэйнфреймов может быть дорогостоящим и обычно стоит больше, чем оборудование мэйнфрейма. Часто бывает выгоднее заменить несколько лицензий на программное обеспечение для небольших машин на одну-две лицензии для больших машин. Стоимость лицензии на программное обеспечение часто привязана к мощности системы, однако кривые цен говорят в пользу небольшого количества крупных машин. Стоимость лицензий на программное обеспечение для мэйнфреймов стала основным фактором в росте и направлении развития отрасли мэйнфреймов.
Существует несколько нелинейных факторов, которые значительно затрудняют формирование цен на программное обеспечение. Необходимо помнить о том, что рынок программного обеспечения для мэйнфреймов не является таким массовым, как рынок программ для персональных компьютеров. Рост вычислительной мощности мэйнфреймов в последние годы происходил нелинейно.
Относительная мощность, необходимая для выполнения традиционного приложения для мэйнфреймов (например, пакетного задания на языке COBOL), не имеет линейной связи с мощностью, необходимой для нового приложения (имеющего графический интерфейс и написанного на C или Java). Эффект консолидации привел к появлению сверхмощных мэйнфреймов. Для выполнения приложения может быть достаточно 1% их мощности, однако изготовители приложений часто назначают цену, исходя из общей мощности машины. В результате возникла необычная ситуация, где клиенты хотят приобрести самый новый мэйнфрейм (чтобы использовать новые функции или снизить стоимость об- служивания, связанную со старыми машинами), но при этом они ищут самый медленный мэйнфрейм для выполнения своих приложений (чтобы снизить затраты на программное обеспечение, цена на которое привязывается к суммарной мощности системного процессора).