Воровали на предприятиях, если они там были. Или покупали краденое. Недаром тогда бытовала поговорка: "Не каждый вор -- радиолюбитель, но каждый радиолюбитель -- вор".
Что-либо из микропроцессорных микросхем и т.п. более-менее законным образом стало возможным купить лишь под самый занавес Союза, да и то, скажем культурно, далеко не везде; впрочем, и элементарнейшую К155ЛА3 тоже отнюдь не в каждом магазине радиодеталей можно было купить.
Вообще-то ЕС ЭВМ исчезли в связи с известными политическими событиями, а не по техническим причинам; пойди история другим путём -- и они до сих пор бы работали, занимая свою нишу, как это имеет место для их забугорной родни.
В классической OS/360 уровень поддержки таймера задавался при генерации системы -- вплоть до полного его отсутствия (на, как минимум, System 360/30 таймера физически могло не быть -- хотя почти на всех моделях он имелся в обязательном порядке). Если он поддерживался, то, по меньшей мере, обеспечивал ход времени (программно реализованные часы -- часы реального времени в современном виде появились только в Системе 370, а з/Арч к ним ещё индекс эпохи добавили). Если в систему включалась SMF, тогда ОС точно контролировала время выполнения пунктов задания и прибивала их по исчерпании времени (если только в задании явным образом не указывалось, что время для данного пункта выделяется без ограничений; с помощью своих подпрограмм выходов, присобаченных к SMF, можно было выделить заданию дополнительное время, даже если оно истекло). Вот если SMF не было, но таймер был, там я не помню, был ли такой функционал в системе.
Интервальный таймер, как и интерфейс прямого управления, выпилили в 80-е -- в 370-XA и последовавшей за ней ESA/370 их уже не было. Но устаревшими они были объявлены одновременно с появлением Системы 370; если память не изменяет, VM/370 ими никогда не пользовалась (ну а OS/360 продолжала пользоваться не только в MFT и MVT, но и в SVS, насчёт ранних MVS я уже не знаю -- вживую не встречал; но, поскольку она уже была существенно переработана, резонно предположить, что в ней полностью перешли на часы с компаратором и таймером процессора, а от интервального таймера отказались).
Интервальный таймер, как я понимаю, не генерирует прерывания и его значение надо проверять
Не путайте системные сервисы (макрокоманды супервизора) и интервальный таймер как железяку в составе процессора. Он генерирует внешнее прерывание, когда перекидывается из положительного в отрицательный, если память не изменяет. Но он существовал лишь в Системе 360 и Системе 370, причём в последней был объявлен устаревшим (вместе с интерфейсом прямого управления). В 370-XA и его, и интерфейс прямого управления (на котором держались первые многопроцессорные системы) выпилили, поэтому, естественно, их нет и в з/Арч.
Кроме SVC Type-1 другие в MVS можно добавлять безз генерации ОС
В MVS -- вполне может быть, я с ней дела не имел. Но в классическую OS/360 (а всё обсуждение шло вокруг её дыр, а не того, что творится в современных системах) -- нет; для SVC-программ типов 1 и 2 нужна генерация (поскольку они являются неотъемлемой частью ядра), а для типов 3 и 4 генерация не нужна лишь в случае, если при генерации ранее для них были зарезервированы номера -- поскольку для всех SVC-программ в процессе генерации строится таблица, и новые записи в неё добавлены быть не могут.
Это в z, а дискуссия шла исключительно о классических мэйнфреймах -- дыры ж в защите системы касались хоть модесета, хоть аппендиксов в ОС/360, а не з/ОС. А в те годы с ключами было всё просто, никаких тебе специальных использований для полупривилегированных команд и т.д. и т.п.
Добавлю только что не к любым областям, а только областям одного адресного пространства
Опять-таки, возвращаемся к предыдущему: дискуссия шла о классических системах, а адресные пространства (первичное и вторичное) впервые появились в поздней Системе 370 (не факт, что это расширение у нас успели скопировать, но и не исключено; к ЕС-1130 -- де-факто последней нашей серийной машине -- доки с точки зрения программиста не прилагалось, поэтому полный список реализованных там расширений мне не известен; точно знаю, что была команда TPROT, логику работы которой я восстанавливал по схемам процессора и по микропрограммам, но к адресным пространствам она не относится).
Как мне помнится для некоторых обработчиков допускаются прерывания. Вообще говоря как может быть замаскировано новое PSW от тех же машинных прерываний? Смысл работать если может быть уже пора тушить свет?
Ещё раз: прерывания от схем контроля маскируются только в новом PSW прерываний от схем контроля. Если новая критическая ошибка произойдёт при запрещённых этих прерываниях, процессор перейдёт в состояние "стоп при сбое".
Обработчики любых других прерываний не запрещают прерывания от схем контроля -- но запрещают все остальные прерывания.
Технически можно было бы запрещать лишь прерывания того вида, которые данный обработчик обрабатывает (т.е. запретить прерывания ввода-вывода в новом PSW прерываний ввода-вывода, но не внешних прерываний; в новом PSW внешних прерываний запретить прерывания внешние, но не ввода-вывода; в новых PSW программных прерываний и прерываний по вызову супервизора вообще ничего не запрещать -- они ни с того ни с сего не происходят). Однако в OS/360 все прерывания (кроме, повторюсь, от схем контроля -- но на них можно вообще не обращать внимание, поскольку при нормальной работе машины они никогда не возникают) запрещаются во всех новых PSW. Моя ОС в этом смысле была намного лучше и запрещала лишь то, что действительно необходимо, и на минимальный срок -- но идеи для неё (за исключением ввода-вывода) я черпал не из ОС ЕС, а из ОС-РВ, которая в девичестве RSX-11M (самая развитая ОС для PDP-11 и, по совместительству, бабка Винды -- через VAX/VMS; впрочем, в те годы я об этом ещё не знал).
Но в общем я готов согласится (пока не найду, или Вы мне не покажите, формальное описание для конкретной системы на МФ. Пока я нашел что решает девелопер системы какие прерывания маскировать в новых PSW) что хотя бы на время сохранения данных прерванного процесса хорошо бы быть замаскированным, но только все таки не от Machine Check
Ну, скачайте исходники OS/360 да посмотрите. Нижняя область памяти, включая области старых и новых PSW, а также начала обработчиков прерываний определяется макрокомандой IEAAIH из библиотеки SYS1.MODGEN. Метки новых PSW -- TENPSW, SVCNPSW, PINPSW для внешних, SVC и программных; MCNPSW у одного варианта от схем контроля, у другого метки нет, как нет и у нового PSW прерываний ввода-вывода, но отыскать их проблемы не составит, я думаю. И там отлично видно, что старшие 32 разряда во всех этих PSW, кроме как от схем контроля, содержат X'00040000' -- т.е. полный запрет всех прерываний, кроме от схем контроля; а прерывание от схем контроля содержит либо нуль (если обработчик есть -- его имя IGFN0000), либо X'00020000' -- т.е. ожидание со всеми запрещёнными прерываниями (если обработчика нет). Хотя, кажется, это PSW может меняться в NIP, но не уверен, а смотреть лениво.
Проблема была решена выполнением этой ОС в области V=R. И насколько я понимаю это было не связано со скоростью реакции, или времени реакции, а с тем что CP переписывает канальную программу в свою память и соответствено динамическая модификация канальной программы обламывается. V=R эту проблему решала
И со скоростью тоже: по очевидным причинам прерывание ввода-вывода до ОС, работающей на виртуальной машине, дойдёт не так быстро, как на реальной машине. Но про V=R я забыл упомянуть, это да: без этого на виртуальной машине канальные программы на лету модифицировать бессмысленно, ибо они будут указывать "не туда" (гипервизор может разобрать канальную программу "по косточкам" и сформировать правильные адреса только в момент, когда он эмулирует SIO, но не после запуска канальной программы).
Как я писал выше мне не удалось найти следов "аппендиксов" канальных программ, но и Вы говорили про модификацию их. Возможно это может означать раширение/дописка ранее запущенной программы, но все равно продолжение ее выполнения может возобнавится, как я понимаю, только через SIO после изменения CSW. А значит система (супер- или гипервизор имеет возможность проверить программу канала снова, после модификации.
Хотите вспомнить/разобраться -- перечитайте документацию на OS/360 (именно на неё, не на z/OS; что там в z/OS творится, я понятия не имею). Там упоминаются, в том числе, и имена модулей, являющихся стандартными аппендиксами, используемыми стандартными методами доступов.
И ещё и ещё раз: PCI предназначен для модификации выполняющихся канальных программ. Эти канальные программы не завершены, канал продолжает их выполнять! А PCI уведомляют супервизор ввода-вывода о том, какая часть канальной программы уже исполнена -- поскольку запрос этого прерывания возникает в момент, когда канал прочитал очередное CCW и приступил к его исполнению -- что означает, что все предшествующие CCW уже были им исполнены. Никакой проверки внесённых изменений ОС сделать просто не успеет: канал её не ждёт, он непрерывно работает, поэтому и нужен "мгновенный" вызов аппендикса PCI, чтобы он успел изменить будущие CCW до того, как канал закончит выполнение текущего, вызвавшего PCI.
Речь идет о канальной программе. Никто, ни какой обработчик прерываний ввода-вывода (т.е. программа CPU) не может выполнять канальную программу. Он только может изменить CSW и снова запустить канал.
На этих вот основах я настаиваю.
Перечитайте ещё раз, что я написал. Обработчик прерываний, а точней, выполняющийся в его рамках аппендикс PCI, модифицирует выполняющуюся в данный момент канальную программу, а не сам выполняет её. Что здесь может быть непонятного?
Мне бы еще хотелось узнать зачем Вам вдруг понадобилось писать свою ОС. Почему нельзя было использовать имеющиеся ОС и если были какие-то идеи для улучшения то внедрить их через некие расширения стандартных. Вы же не собирались свою ОС продавать или предлогать другим.
А почему одни люди коллекционируют марки, другие собирают модели танчиков и самолётиков и т.д.? Потому что им это интересно. Мне вот интересно разрабатывать ОС и ковыряться в нутре древних процессоров -- хотя бы виртуально, по сохранившимся книгам.
Вот чем бы я занялся так это попыткой написать ОС на х86-64 но имея прототипом MVS, например. Не эмулятор, а нативную ОС х86-64, но с такой же функциональностью как MVS. И пройти путь от OS/360 до MVS. Понимаю выглядит дико. Нет полного, прямого соответствия возможностей МФ и серверов х86-64. По тому же вводу-выводу и не только. Но это можно было бы попробавать эмулировать.
Ну, во-первых, нормально не получится, особенно на 64-разрядной архитектуре, где выпилили сегментацию: на сегментации можно было бы реализовать некий аналог адресных пространств и механизма вызова программ (команды PC, PT и прочая в z/Arch), а без неё подобное можно делать только системными вызовами.
Во-вторых, ввод-вывод мэйнфреймов хорош для задачи обработки больших массивов данных, но абсолютно не годится для задач реального времени: он жутко тормозной и негибкий в плане реакции на внешние события и т.д. и т.п. Поэтому он -- вещь очень нишевая (гигантские базы данных крутить -- да, всё остальное -- нет). Возможно, поэтому в предпоследней версии "принципов работы з/арч" появилось упоминание о PCI Express и отображённом на память вводе-выводе -- но только упоминание, без каких-либо деталей.
А в-третьих, архитектуры абсолютно всех процессоров Интел у меня вызывают, как минимум, неприязнь, если не чуть ли не физиологическое отвращение, но AMD, добавляя к ней 64 бита, смогла ещё более ухудшить и без того отвратительную архитектуру. По-хорошему, ей место на свалке истории, но имеем что имеем -- рыночек порешал, а он решает не по техническому совершенству. Что-либо под неё делать у меня лично желания нет.
CSW -- слово состояния канала, оно записывается каналом при прерывании ввода-вывода или при выполнении команд ввода-вывода вроде SIO и TIO, если у канала к тому времени есть информация для сохранения, относящаяся к адресуемому устройству, при этом будет установлен код условия 1 (а запуск операции ввода-вывода, если это была SIO, не произойдёт).
При запуске же ввода-вывода по SIO адрес канальной программы помещается в адресное слово канала -- CAW. Туда же помещается ключ, с которым канал будет осуществлять обращения к основной памяти. Адрес канала и устройства, к которым относится команда SIO, задаётся в ней самой.
Ну, у нас дисков тоже было больше, чем устройств. Реально у нас было две ЕС-1035, у каждой по 8 ЕС-5061, просто их контроллеры были подключены к обеим машинам (те, которые имели адреса 130-137 на одной ЭВМ, имели адреса 330-337 на другой, и наоборот). Ну а поскольку одна из машин была очень капризной (с "оловянными", а не золотыми разъёмами, из-за чего там регулярно возникали неконтакты, лечившиеся пинками и кувалдами по рамам процессора), почти всегда работали только на второй -- отсюда и 16 доступных приводов. Ну а ЕС-5052/5056 остались "в наследство" от двух ЕС-1022, которых я не застал, от них постепенно отказывались.
Переносимость дисков между 5052/5056 была практически 100%; вообще, эти дисководы требовали куда меньше заботы. 5061 требовали частой профилактики/юстировки, но совместимость была тоже очень хорошей, т.е. почти всегда диск, записанный на одном приводе, нормально читался на другом (хотя иногда возникали сбои -- но система же в такой ситуации даёт возможность переставить диски, а не сразу фиксировать сие как настоящую ошибку). На практике обычно стояло одновременно 8-10 больших дисков (в том числе два системных и два чисто под рабочие наборы).
А вот 200-мегабайтные ЕС-5080 (4 штуки), пришедшие с ЕС-1130, были очень капризными и ненадёжными. Но от них довольно быстро (года через 3 после их появления) отказались, поставив в качестве дисков персоналку :) Сама же машина была исключительно надёжной; в процессоре за несколько лет эксплуатации сдохла ровно одна микросхема -- К1800ВС1; ещё пару раз дохли блоки питания. Насчёт памяти, честно говоря, не помню, но такого, чтоб по микросхеме в месяц, как на ЕС-1035, точно не было (всё ж выпуск, кажется, 1991-го года, у нас её поставили в 1992-м).
Канальная программа -- это цепочка CCW, которая выполняется каналом ввода-вывода, почему, собственно, она и называется канальной программой. Процессор её формирует в основной памяти, заносит адрес первого CCW в CAW, а затем запускает канал на выполнение этой канальной программы с помощью команды SIO. Далее выполнение канальной программы осуществляется каналом без участия процессора, но последний может "на лету" модифицировать канальную программу.
Программа в режиме "супервизор" действительно может поменять собственный ключ, загрузив новое PSW. Но, пока она работает с ненулевым ключом, на неё распространяется та же защита памяти, что и на программу в режиме "пользователь".
При периодически выполняемом обслуживании ошибки возникали отнюдь не постоянно; и сам привод, и пакет работали без проблем достаточно долго, поэтому в постоянную, ежедневную борьбу я не верю -- ну либо на конкретном ВЦ обслуживание было поставлено из рук вон плохо, квалифицированные специалисты отсутствовали и т.д. и т.п.
У нас на моей памяти (за примерно 4 года) был только один случай, когда работа встала на полдня. На одном из дисков ЕС-5061 на ходу оторвалась головка, что, естественно, вывело из строя привод и убило стоящий на нём пакет. Диск вывели в ремонт, а операторам ЭВМ пришлось выполнить следующую процедуру:
поставить новый пакет на другой привод (в их распоряжении в сумме было 16 ЕС-5061 и 16 ЕС-5052/5056);
инициализировать этот новый диск;
восстановить с магнитной ленты копию погибшего диска на этот пакет;
выполнить задания, которые уже были выполнены, но результаты работы которых были потеряны на убитом диске.
Вот на всё это порядка полудня у девочек и ушло. Неисправный привод ввели в строй через несколько дней (заменили головку, достаточно долго настраивали-юстировали и всё такое), но на работе ВЦ, за исключением описанного выше, это не сказалось никак. И, повторюсь, это было единственное крупное происшествие за несколько лет. Мелкие поломки случались, конечно, чаще, но могли привести к потере пары-тройки часов работы за месяц, а не так чтоб стоять и чиниться неделями, как тут пишут. (Самой типичной поломкой на ЕС-1035 был выход из строя очередной микросхемы основной памяти -- К565РУ1; они дохли со скоростью микросхема в месяц, но выход из строя одной микросхемы на текущую работу не влиял: спасал код Хэмминга; увидев сообщение об ошибке, девочки позволяли доработать до конца текущим заданиям, после чего отдавали машину электронщикам, те быстро находили дохлую микросхему -- спасибо тесту памяти -- и меняли её, и через час, максимум два, машина возвращалась в работу; если же работа была срочная, то ремонт вообще откладывали на 2 или 3-ю смену).
Но, замечу, у нас был приличный штат электронищков, и диски обслуживали постоянно, каждый день -- просто диск за диском, а не все диски сразу, поэтому перерывов в работе не было. Возможно, поэтому крупные неприятности и возникали редко. (Да, обычные сбои при чтении с диска -- вещь куда более частая, но к длительным задержкам она не приводила: ОС помечала дорожку как сбойную, и приходилось, разве что, пересоздать набор данных, что отнюдь не недель требовало. Причём, замечу, не каждый сбой при чтении был фатальным, зачастую данные считывались корректно благодаря CRC и автоматически переносились системой на резервную дорожку).
когда что-то прикладное зацикливается, я бы сказал что на МФ есть службы времени, которые не позволяют никаким процессам монополизировать процессор. Т.н. компаратор, который выставляется перед каждым предоставлением доступа к CPU гостю и который (не зависимо ни от чего) вызывает прерывание через определенный промежуток времени (квант) и управление передается управляющей программе, которая выполнит много что прежде чем снова передаст управление зацикленной программе.
Даже в Системе 360, где компаратора ещё не было и был только интервальный таймер, зацикливание прикладной программы никак не могло завесить систему в целом:
никто не отменял прерывания ввода-вывода, а они при работе прикладных программ всегда разрешены. Соответственно, если оператор вводит что-то с консольного терминала, происходит прерывание ввода-вывода, в результате которого, в итоге, из ожидания выводится задача связи с оператором;
а задача связи с оператором, как и другие системные задачи, всегда имеют более высокий приоритет, чем любые задачи пользователя. Соответственно, даже если зациклилась задача пользователя с высшим приоритетом, задача связи с оператором всё равно начнёт выполнение и обработает команду, введённую оператором -- а этой командой может быть, например, CANCEL, убивающая зациклившуюся программу.
В общем, описанная товарищем ситуация попросту невозможна без вмешательства в работу супервизора, что обычный программист в рамках обычной программы сделать не может.
SVC-программы, да, возможность заложена была, но добавлять их (по крайней мере, указывать системе, что есть пользовательские SVC-программы), нужно было при генерации ОС. Соответственно, добавить что-то своё уже в процессе нормальной эксплуатации, если это не было заложено при генерации, невозможно.
Ранняя MODESET, насколько помню, никакой защиты не имела, но голову на отсечение не дам. Было б время -- попробовал бы понять по исходникам OS/360 21.8 (последняя MFT/MVT классическая, дальше уже идут с виртуальной памятью).
Все канальные программы, включая аппендиксы, запускаются "с нулевым ключом защиты", а точнее в состоянии супервизор. И вовсе не с запрещенными прерываниями. С запрещенными прерываниями выполняются как правило программы восстановления от машинных ошибок.
Извините, но лажа таки у Вас :)
1) Канальные программы и программы процессора (просто программы, будь то хоть код пользователя, хоть код супервизора, т.е. ядра системы) -- это абсолютно разные вещи. Состояния "супервизор" у канальных программ не бывает в принципе, хотя ключ у них есть (указывается при запуске). Этот ключ канальные программы используют при своих обращениях к памяти, и он обычно не равен нулю (чтобы канальная программа, относящаяся к одной задаче пользователя, не смогла залезть в память ядра или в память раздела другой задачи).
2) При выполнении программ процессора ключи защиты и состояния "пользователь/супервизор" между собой вообще никак не связаны. Программа может работать с нулевым ключом, но в режиме "пользователь" (тогда она сможет обращаться к любым областям памяти, но не сможет использовать привилегированные команды), а может, наоборот, работать в режиме "супервизор", но с ненулевым ключом (тогда она сможет использовать привилегированные команды, но не сможет обращаться к любым областям памяти).
3) С запрещёнными прерываниями начинают выполнения все без исключения обработчики прерываний, достаточно ознакомиться с исходными текстами OS/360 или даже просто включить здравый смысл: стека у машины нет, и вся информация, сохраняемая при прерывании, записывается в фиксированные ячейки памяти, т.е. затирает ранее находившуюся там информации. Соответственно, нельзя допускать, чтобы, по меньшей мере, в начальной стадии обработки, скажем, прерывания ввода-вывода произошло новое прерывание ввода-вывода (от другого устройства) -- оно тогда затрёт старое PSW прерываний ввода-вывода, CSW и другую информацию, сохраняемую аппаратно при этом прерывании. Единственная разница между прерываниями от схем контроля и всеми другими прерываниями заключается в том, что новое PSW прерываний от схем контроля запрещает вообще все прерывания, а новые PSW других классов прерываний -- все прерывания, кроме прерываний от схем контроля.
4) Хотя, сохранив информацию, записанную при прерывании, эти прерывания можно разрешать, OS/360 очень многие вещи делает при полностью запрещённых прерываниях, что длится иногда весьма продолжительное время. В частности, SVC-программы типа 1 (к ним относятся, например, GETMAIN и FREEMAIN) работают от начала до конца при запрещённых прерываниях, не считая прерываний от схем контроля. SVC-программы других типов (2, 3, 4) работают при разрешённых прерываниях, но перед этим обработчик прерываний по вызову супервизора, выполняющийся при запрещённых прерываниях, определяет тип прерывания, для типов 2, 3, 4 создаёт SVRB, заполняет его необходимой информацией и добавляет к цепочке блоков запросов текущей задачи (т.е. задачи, выдавшей SVC), если это SVC-программа типа 3 или 4, проверяет, находится ли её загрузочный модуль в памяти (если нет, инициирует его загрузку, а пока она не выполнена, позволяет выполняться другой задаче; SVC-программы типа 2 являются резидентными, поэтому проверка не нужна); наконец, если загрузочный модуль находится в памяти, разрешает прерывания (только сейчас!) и передаёт ему управление.
5) Назначение аппендикса PCI -- модифицировать канальную программу во время её выполнения, поэтому никакие задержки с его выполнением недопустимы. По этой причине обработчик прерываний ввода-вывода, являющийся частью супервизора ввода-вывода, обнаружив по информации, сохранённой в CSW, что это PCI, сразу же вызывает аппендикс, и последний, таким образом, выполняется в рамках обработчика прерываний ввода-вывода. Это, кстати, является причиной, почему программы, использующие ввод-вывод с PCI, могут оказаться неработоспособными при выполнении на виртуальной машине, хотя нормально работают на реальном железе: корректно написанная программа (и аппендикс PCI, и всё другое, относящееся к обслуживанию ввода-вывода) не может полагаться на то, что модификация канальной программы будет выполнена вовремя, а соответственно, при завершении канальной программы должна проверить, всё ли было выполнено в полном объёме, и если нет, запустить её повторно с необходимой точки. Но это делается не всегда -- и тогда на виртуальной машине возникают проблемы, так как там уже никакой гарантии "мгновенной" передачи управления аппендиксу PCI нет.
Все что представляет прикладная программа с EXCP проверяется супервизором ввода-вывода прежде чем выполнение прерваной канальной прграммы продоолжится (или начнется выполнение другой программы канала (аппендискса)
Ага, проверяет. Например, проверяет положение буферов ввода-вывода в памяти (а в системе с виртуальной памятью ещё и фиксирует нужные страницы и корректирует адреса -- заменяет виртуальные на абсолютные, причём при наличии специфических требований на этот процесс можно влиять с помощью специально предназначенного для этого аппендикса). Но система не может проверить смысл предоставляемых пользователем аппендиксов -- она может проверить лишь формальные вещи типа их физического наличия и доступности; проверить допустимость их поведения она не в состоянии.
Чувствуется мне что и у Вас есть дефицит опыта в области программирования ввода-вывода на МФ, которую мы обсуждаем. Где-то. что-то слышали и как-то поняли. Если я не прав, попробуйте меня переубедить.
Переубеждать Вас я не собираюсь -- что хотите, то и думайте хоть обо мне, хоть об обсуждаемых вопросах.
Что же касается ввода-вывода в классической Системе 370 (в лице наших ЕС-1035 и ЕС-1130), я с ним работал и как программист, и как электронщик. У меня даже своя собственная ОС была -- уже с виртуальной памятью, но ещё без обработки ошибок и без поддержки дисплеев (в качестве терминала -- только пишмашка в силу её простоты, из-за чего на ЕС-1130, когда она у нас появилась, гонять мою систему можно было только под СВМ; поддерживались, естественно, диски, ленты, АЦПУ и перфокарты, но не было обработки ошибок ввода-вывода как таковых -- только простых условий вроде конца колоды перфокарт или отсутствия бумаги в АЦПУ; всё остальное планировалось, но сделано не было -- 90-е годы не очень способствовали работе на одном месте). Так что, как работает ввод-вывод на мэйнфреймах, я знаю очень неплохо и на уровне программиста, и на уровне внутренностей процессоров и каналов, и на уровне сигналов интерфейса ввода-вывода, хотя некоторые детали, вероятно, подзабылись. Вот в устройства управления (контроллеры) тех же дисков я никогда не лез, т.е. с их работой знаком лишь со стороны программиста, но не электронищка.
2) На размер влияет не очень сильно, конечно, но если у тебя на всё про всё, скажем, 4 Кбайта памяти, то обычно считаешь каждый байт.
3) Сейчас считают не байты в ОЗУ и тем более на дисках, а байты в строках кэшей и байты, которые процессор способен прочитать из кэша и обработать за один такт -- а там счёт по-прежнему идёт на единицы и десятки байтов.
4) А иногда, наоборот, для производительности выгодней раздувать программу. Скажем, если у тебя на ПК четыре команды вместились в 15 байт, причём первая из них начинается по адресу, кратному 16, то для запуска в работу пяти команд процессору потребуется два или три такта: в первом такте он выберет эти 16 байт, обнаружит, начиная с их начала, четыре полные команды и запустит их, а во втором такте он вынужден будет выбрать те же 16 байт (они ещё не закончились), но обнаружит там лишь одну команду или вообще её начало (в последнем байте этой группы) и запустит только её. А если она многобайтовая, ему придётся прочитать (в третьем такте) следующие 16 байт, чтобы эту команду запустить.
А вот если эти четыре команды искусственно раздуть (добавив, например, ничего не значащий префикс к одной из них) до 16 байтов, то процессор в первом такте выберет те же 16 байт и запустит эти четыре команды, но в следующем будет считывать уже следующие 16 байт -- в которых, если повезёт, тоже будет четыре команды, которые он сможет запустить. В результате получится 8 команд за два такта, а не 5 команд за два или три такта.
Аппендиксы -- это подпрограммы, вызываемые супервизором в определённые моменты прохождения запроса ввода-вывода через супервизор. В частности, если это аппендикс PCI, он вызывается каждый раз, когда выполняющаяся в данный момент канальная программа, для которой он указан, вызывает программно-управляемое прерывание (PCI). Обработчик прерываний ввода-вывода, увидев, что причиной прерывания послужило PCI и что для данной канальной программы указан аппендикс PCI, немедленно вызывает этот аппендикс. Таким образом, сей аппендикс вызывается и работает в режиме супервизора с нулевым ключом защиты и с запрещёнными прерываниями -- фактически, он выполняется как часть супервизора ввода-вывода, но при этом его предоставляет системе прикладная программа, выдавшая EXCP.
Насчёт других аппендиксов я не помню, выполняются ли они в состоянии "супервизор" с нулевым ключом или в состоянии "задача" и с её ключом.
Это в современной z/OS она может быть документирована, а в обычной документации на ОС ЕС (и, надо полагать, на OS/360, с которой переводы были сделаны -- я оригиналы не читал) про неё ни слова.
С какой стати потеряны-ты? Профилактика/юстировка проводятся одновременно с работой машины -- просто конкретный накопитель выводится на эту самую профилактику, а остальные продолжают использоваться. Заканчивают с одним -- передают его в эксплуатацию, выводят из неё другой, и так по кругу. Конечно, ЧП временам случаются, но при нормально организованном техобслуживании они именно ЧП, а отнюдь не ежедневное событие.
Уж не знаю, что у Вас за ЕСки такие были. В начале 70-х первые машины действительно были очень ненадёжны из-за ненадёжной элементной базы; когда отладили выпуск микросхем, надёжность резко поднялась. Так что раз в месяц сдохнуть ещё что-то могло, а чтоб цирк был постоянно -- не верю. Вот ежедневное обслуживание дисков и несколько реже другой периферии -- да, но работе оно не мешало, просто диски по одному выводились на обслуживание, но их-то достаточно много на всех крупных конфигурациях, да и на средних тоже.
Воровали на предприятиях, если они там были. Или покупали краденое. Недаром тогда бытовала поговорка: "Не каждый вор -- радиолюбитель, но каждый радиолюбитель -- вор".
Что-либо из микропроцессорных микросхем и т.п. более-менее законным образом стало возможным купить лишь под самый занавес Союза, да и то, скажем культурно, далеко не везде; впрочем, и элементарнейшую К155ЛА3 тоже отнюдь не в каждом магазине радиодеталей можно было купить.
Вообще-то ЕС ЭВМ исчезли в связи с известными политическими событиями, а не по техническим причинам; пойди история другим путём -- и они до сих пор бы работали, занимая свою нишу, как это имеет место для их забугорной родни.
Агат (во всяком случае, Агат-7) прилично отличается от Эпла-2 и не очень-то с ним совместим. И куча микросхем, ага.
В классической OS/360 уровень поддержки таймера задавался при генерации системы -- вплоть до полного его отсутствия (на, как минимум, System 360/30 таймера физически могло не быть -- хотя почти на всех моделях он имелся в обязательном порядке). Если он поддерживался, то, по меньшей мере, обеспечивал ход времени (программно реализованные часы -- часы реального времени в современном виде появились только в Системе 370, а з/Арч к ним ещё индекс эпохи добавили). Если в систему включалась SMF, тогда ОС точно контролировала время выполнения пунктов задания и прибивала их по исчерпании времени (если только в задании явным образом не указывалось, что время для данного пункта выделяется без ограничений; с помощью своих подпрограмм выходов, присобаченных к SMF, можно было выделить заданию дополнительное время, даже если оно истекло). Вот если SMF не было, но таймер был, там я не помню, был ли такой функционал в системе.
Интервальный таймер, как и интерфейс прямого управления, выпилили в 80-е -- в 370-XA и последовавшей за ней ESA/370 их уже не было. Но устаревшими они были объявлены одновременно с появлением Системы 370; если память не изменяет, VM/370 ими никогда не пользовалась (ну а OS/360 продолжала пользоваться не только в MFT и MVT, но и в SVS, насчёт ранних MVS я уже не знаю -- вживую не встречал; но, поскольку она уже была существенно переработана, резонно предположить, что в ней полностью перешли на часы с компаратором и таймером процессора, а от интервального таймера отказались).
Не путайте системные сервисы (макрокоманды супервизора) и интервальный таймер как железяку в составе процессора. Он генерирует внешнее прерывание, когда перекидывается из положительного в отрицательный, если память не изменяет. Но он существовал лишь в Системе 360 и Системе 370, причём в последней был объявлен устаревшим (вместе с интерфейсом прямого управления). В 370-XA и его, и интерфейс прямого управления (на котором держались первые многопроцессорные системы) выпилили, поэтому, естественно, их нет и в з/Арч.
В MVS -- вполне может быть, я с ней дела не имел. Но в классическую OS/360 (а всё обсуждение шло вокруг её дыр, а не того, что творится в современных системах) -- нет; для SVC-программ типов 1 и 2 нужна генерация (поскольку они являются неотъемлемой частью ядра), а для типов 3 и 4 генерация не нужна лишь в случае, если при генерации ранее для них были зарезервированы номера -- поскольку для всех SVC-программ в процессе генерации строится таблица, и новые записи в неё добавлены быть не могут.
Это в z, а дискуссия шла исключительно о классических мэйнфреймах -- дыры ж в защите системы касались хоть модесета, хоть аппендиксов в ОС/360, а не з/ОС. А в те годы с ключами было всё просто, никаких тебе специальных использований для полупривилегированных команд и т.д. и т.п.
Опять-таки, возвращаемся к предыдущему: дискуссия шла о классических системах, а адресные пространства (первичное и вторичное) впервые появились в поздней Системе 370 (не факт, что это расширение у нас успели скопировать, но и не исключено; к ЕС-1130 -- де-факто последней нашей серийной машине -- доки с точки зрения программиста не прилагалось, поэтому полный список реализованных там расширений мне не известен; точно знаю, что была команда TPROT, логику работы которой я восстанавливал по схемам процессора и по микропрограммам, но к адресным пространствам она не относится).
Ещё раз: прерывания от схем контроля маскируются только в новом PSW прерываний от схем контроля. Если новая критическая ошибка произойдёт при запрещённых этих прерываниях, процессор перейдёт в состояние "стоп при сбое".
Обработчики любых других прерываний не запрещают прерывания от схем контроля -- но запрещают все остальные прерывания.
Технически можно было бы запрещать лишь прерывания того вида, которые данный обработчик обрабатывает (т.е. запретить прерывания ввода-вывода в новом PSW прерываний ввода-вывода, но не внешних прерываний; в новом PSW внешних прерываний запретить прерывания внешние, но не ввода-вывода; в новых PSW программных прерываний и прерываний по вызову супервизора вообще ничего не запрещать -- они ни с того ни с сего не происходят). Однако в OS/360 все прерывания (кроме, повторюсь, от схем контроля -- но на них можно вообще не обращать внимание, поскольку при нормальной работе машины они никогда не возникают) запрещаются во всех новых PSW. Моя ОС в этом смысле была намного лучше и запрещала лишь то, что действительно необходимо, и на минимальный срок -- но идеи для неё (за исключением ввода-вывода) я черпал не из ОС ЕС, а из ОС-РВ, которая в девичестве RSX-11M (самая развитая ОС для PDP-11 и, по совместительству, бабка Винды -- через VAX/VMS; впрочем, в те годы я об этом ещё не знал).
Ну, скачайте исходники OS/360 да посмотрите. Нижняя область памяти, включая области старых и новых PSW, а также начала обработчиков прерываний определяется макрокомандой IEAAIH из библиотеки SYS1.MODGEN. Метки новых PSW -- TENPSW, SVCNPSW, PINPSW для внешних, SVC и программных; MCNPSW у одного варианта от схем контроля, у другого метки нет, как нет и у нового PSW прерываний ввода-вывода, но отыскать их проблемы не составит, я думаю. И там отлично видно, что старшие 32 разряда во всех этих PSW, кроме как от схем контроля, содержат X'00040000' -- т.е. полный запрет всех прерываний, кроме от схем контроля; а прерывание от схем контроля содержит либо нуль (если обработчик есть -- его имя IGFN0000), либо X'00020000' -- т.е. ожидание со всеми запрещёнными прерываниями (если обработчика нет). Хотя, кажется, это PSW может меняться в NIP, но не уверен, а смотреть лениво.
И со скоростью тоже: по очевидным причинам прерывание ввода-вывода до ОС, работающей на виртуальной машине, дойдёт не так быстро, как на реальной машине. Но про V=R я забыл упомянуть, это да: без этого на виртуальной машине канальные программы на лету модифицировать бессмысленно, ибо они будут указывать "не туда" (гипервизор может разобрать канальную программу "по косточкам" и сформировать правильные адреса только в момент, когда он эмулирует SIO, но не после запуска канальной программы).
Хотите вспомнить/разобраться -- перечитайте документацию на OS/360 (именно на неё, не на z/OS; что там в z/OS творится, я понятия не имею). Там упоминаются, в том числе, и имена модулей, являющихся стандартными аппендиксами, используемыми стандартными методами доступов.
И ещё и ещё раз: PCI предназначен для модификации выполняющихся канальных программ. Эти канальные программы не завершены, канал продолжает их выполнять! А PCI уведомляют супервизор ввода-вывода о том, какая часть канальной программы уже исполнена -- поскольку запрос этого прерывания возникает в момент, когда канал прочитал очередное CCW и приступил к его исполнению -- что означает, что все предшествующие CCW уже были им исполнены. Никакой проверки внесённых изменений ОС сделать просто не успеет: канал её не ждёт, он непрерывно работает, поэтому и нужен "мгновенный" вызов аппендикса PCI, чтобы он успел изменить будущие CCW до того, как канал закончит выполнение текущего, вызвавшего PCI.
Перечитайте ещё раз, что я написал. Обработчик прерываний, а точней, выполняющийся в его рамках аппендикс PCI, модифицирует выполняющуюся в данный момент канальную программу, а не сам выполняет её. Что здесь может быть непонятного?
А почему одни люди коллекционируют марки, другие собирают модели танчиков и самолётиков и т.д.? Потому что им это интересно. Мне вот интересно разрабатывать ОС и ковыряться в нутре древних процессоров -- хотя бы виртуально, по сохранившимся книгам.
Ну, во-первых, нормально не получится, особенно на 64-разрядной архитектуре, где выпилили сегментацию: на сегментации можно было бы реализовать некий аналог адресных пространств и механизма вызова программ (команды PC, PT и прочая в z/Arch), а без неё подобное можно делать только системными вызовами.
Во-вторых, ввод-вывод мэйнфреймов хорош для задачи обработки больших массивов данных, но абсолютно не годится для задач реального времени: он жутко тормозной и негибкий в плане реакции на внешние события и т.д. и т.п. Поэтому он -- вещь очень нишевая (гигантские базы данных крутить -- да, всё остальное -- нет). Возможно, поэтому в предпоследней версии "принципов работы з/арч" появилось упоминание о PCI Express и отображённом на память вводе-выводе -- но только упоминание, без каких-либо деталей.
А в-третьих, архитектуры абсолютно всех процессоров Интел у меня вызывают, как минимум, неприязнь, если не чуть ли не физиологическое отвращение, но AMD, добавляя к ней 64 бита, смогла ещё более ухудшить и без того отвратительную архитектуру. По-хорошему, ей место на свалке истории, но имеем что имеем -- рыночек порешал, а он решает не по техническому совершенству. Что-либо под неё делать у меня лично желания нет.
CSW -- слово состояния канала, оно записывается каналом при прерывании ввода-вывода или при выполнении команд ввода-вывода вроде SIO и TIO, если у канала к тому времени есть информация для сохранения, относящаяся к адресуемому устройству, при этом будет установлен код условия 1 (а запуск операции ввода-вывода, если это была SIO, не произойдёт).
При запуске же ввода-вывода по SIO адрес канальной программы помещается в адресное слово канала -- CAW. Туда же помещается ключ, с которым канал будет осуществлять обращения к основной памяти. Адрес канала и устройства, к которым относится команда SIO, задаётся в ней самой.
Насколько помню, загрузить 64-разрядную константу можно только в RAX, в другие регистры нельзя.
Ну, у нас дисков тоже было больше, чем устройств. Реально у нас было две ЕС-1035, у каждой по 8 ЕС-5061, просто их контроллеры были подключены к обеим машинам (те, которые имели адреса 130-137 на одной ЭВМ, имели адреса 330-337 на другой, и наоборот). Ну а поскольку одна из машин была очень капризной (с "оловянными", а не золотыми разъёмами, из-за чего там регулярно возникали неконтакты, лечившиеся пинками и кувалдами по рамам процессора), почти всегда работали только на второй -- отсюда и 16 доступных приводов. Ну а ЕС-5052/5056 остались "в наследство" от двух ЕС-1022, которых я не застал, от них постепенно отказывались.
Переносимость дисков между 5052/5056 была практически 100%; вообще, эти дисководы требовали куда меньше заботы. 5061 требовали частой профилактики/юстировки, но совместимость была тоже очень хорошей, т.е. почти всегда диск, записанный на одном приводе, нормально читался на другом (хотя иногда возникали сбои -- но система же в такой ситуации даёт возможность переставить диски, а не сразу фиксировать сие как настоящую ошибку). На практике обычно стояло одновременно 8-10 больших дисков (в том числе два системных и два чисто под рабочие наборы).
А вот 200-мегабайтные ЕС-5080 (4 штуки), пришедшие с ЕС-1130, были очень капризными и ненадёжными. Но от них довольно быстро (года через 3 после их появления) отказались, поставив в качестве дисков персоналку :) Сама же машина была исключительно надёжной; в процессоре за несколько лет эксплуатации сдохла ровно одна микросхема -- К1800ВС1; ещё пару раз дохли блоки питания. Насчёт памяти, честно говоря, не помню, но такого, чтоб по микросхеме в месяц, как на ЕС-1035, точно не было (всё ж выпуск, кажется, 1991-го года, у нас её поставили в 1992-м).
Канальная программа -- это цепочка CCW, которая выполняется каналом ввода-вывода, почему, собственно, она и называется канальной программой. Процессор её формирует в основной памяти, заносит адрес первого CCW в CAW, а затем запускает канал на выполнение этой канальной программы с помощью команды SIO. Далее выполнение канальной программы осуществляется каналом без участия процессора, но последний может "на лету" модифицировать канальную программу.
Программа в режиме "супервизор" действительно может поменять собственный ключ, загрузив новое PSW. Но, пока она работает с ненулевым ключом, на неё распространяется та же защита памяти, что и на программу в режиме "пользователь".
При периодически выполняемом обслуживании ошибки возникали отнюдь не постоянно; и сам привод, и пакет работали без проблем достаточно долго, поэтому в постоянную, ежедневную борьбу я не верю -- ну либо на конкретном ВЦ обслуживание было поставлено из рук вон плохо, квалифицированные специалисты отсутствовали и т.д. и т.п.
У нас на моей памяти (за примерно 4 года) был только один случай, когда работа встала на полдня. На одном из дисков ЕС-5061 на ходу оторвалась головка, что, естественно, вывело из строя привод и убило стоящий на нём пакет. Диск вывели в ремонт, а операторам ЭВМ пришлось выполнить следующую процедуру:
поставить новый пакет на другой привод (в их распоряжении в сумме было 16 ЕС-5061 и 16 ЕС-5052/5056);
инициализировать этот новый диск;
восстановить с магнитной ленты копию погибшего диска на этот пакет;
выполнить задания, которые уже были выполнены, но результаты работы которых были потеряны на убитом диске.
Вот на всё это порядка полудня у девочек и ушло. Неисправный привод ввели в строй через несколько дней (заменили головку, достаточно долго настраивали-юстировали и всё такое), но на работе ВЦ, за исключением описанного выше, это не сказалось никак. И, повторюсь, это было единственное крупное происшествие за несколько лет. Мелкие поломки случались, конечно, чаще, но могли привести к потере пары-тройки часов работы за месяц, а не так чтоб стоять и чиниться неделями, как тут пишут. (Самой типичной поломкой на ЕС-1035 был выход из строя очередной микросхемы основной памяти -- К565РУ1; они дохли со скоростью микросхема в месяц, но выход из строя одной микросхемы на текущую работу не влиял: спасал код Хэмминга; увидев сообщение об ошибке, девочки позволяли доработать до конца текущим заданиям, после чего отдавали машину электронщикам, те быстро находили дохлую микросхему -- спасибо тесту памяти -- и меняли её, и через час, максимум два, машина возвращалась в работу; если же работа была срочная, то ремонт вообще откладывали на 2 или 3-ю смену).
Но, замечу, у нас был приличный штат электронищков, и диски обслуживали постоянно, каждый день -- просто диск за диском, а не все диски сразу, поэтому перерывов в работе не было. Возможно, поэтому крупные неприятности и возникали редко. (Да, обычные сбои при чтении с диска -- вещь куда более частая, но к длительным задержкам она не приводила: ОС помечала дорожку как сбойную, и приходилось, разве что, пересоздать набор данных, что отнюдь не недель требовало. Причём, замечу, не каждый сбой при чтении был фатальным, зачастую данные считывались корректно благодаря CRC и автоматически переносились системой на резервную дорожку).
Даже в Системе 360, где компаратора ещё не было и был только интервальный таймер, зацикливание прикладной программы никак не могло завесить систему в целом:
никто не отменял прерывания ввода-вывода, а они при работе прикладных программ всегда разрешены. Соответственно, если оператор вводит что-то с консольного терминала, происходит прерывание ввода-вывода, в результате которого, в итоге, из ожидания выводится задача связи с оператором;
а задача связи с оператором, как и другие системные задачи, всегда имеют более высокий приоритет, чем любые задачи пользователя. Соответственно, даже если зациклилась задача пользователя с высшим приоритетом, задача связи с оператором всё равно начнёт выполнение и обработает команду, введённую оператором -- а этой командой может быть, например, CANCEL, убивающая зациклившуюся программу.
В общем, описанная товарищем ситуация попросту невозможна без вмешательства в работу супервизора, что обычный программист в рамках обычной программы сделать не может.
SVC-программы, да, возможность заложена была, но добавлять их (по крайней мере, указывать системе, что есть пользовательские SVC-программы), нужно было при генерации ОС. Соответственно, добавить что-то своё уже в процессе нормальной эксплуатации, если это не было заложено при генерации, невозможно.
Ранняя MODESET, насколько помню, никакой защиты не имела, но голову на отсечение не дам. Было б время -- попробовал бы понять по исходникам OS/360 21.8 (последняя MFT/MVT классическая, дальше уже идут с виртуальной памятью).
Извините, но лажа таки у Вас :)
1) Канальные программы и программы процессора (просто программы, будь то хоть код пользователя, хоть код супервизора, т.е. ядра системы) -- это абсолютно разные вещи. Состояния "супервизор" у канальных программ не бывает в принципе, хотя ключ у них есть (указывается при запуске). Этот ключ канальные программы используют при своих обращениях к памяти, и он обычно не равен нулю (чтобы канальная программа, относящаяся к одной задаче пользователя, не смогла залезть в память ядра или в память раздела другой задачи).
2) При выполнении программ процессора ключи защиты и состояния "пользователь/супервизор" между собой вообще никак не связаны. Программа может работать с нулевым ключом, но в режиме "пользователь" (тогда она сможет обращаться к любым областям памяти, но не сможет использовать привилегированные команды), а может, наоборот, работать в режиме "супервизор", но с ненулевым ключом (тогда она сможет использовать привилегированные команды, но не сможет обращаться к любым областям памяти).
3) С запрещёнными прерываниями начинают выполнения все без исключения обработчики прерываний, достаточно ознакомиться с исходными текстами OS/360 или даже просто включить здравый смысл: стека у машины нет, и вся информация, сохраняемая при прерывании, записывается в фиксированные ячейки памяти, т.е. затирает ранее находившуюся там информации. Соответственно, нельзя допускать, чтобы, по меньшей мере, в начальной стадии обработки, скажем, прерывания ввода-вывода произошло новое прерывание ввода-вывода (от другого устройства) -- оно тогда затрёт старое PSW прерываний ввода-вывода, CSW и другую информацию, сохраняемую аппаратно при этом прерывании. Единственная разница между прерываниями от схем контроля и всеми другими прерываниями заключается в том, что новое PSW прерываний от схем контроля запрещает вообще все прерывания, а новые PSW других классов прерываний -- все прерывания, кроме прерываний от схем контроля.
4) Хотя, сохранив информацию, записанную при прерывании, эти прерывания можно разрешать, OS/360 очень многие вещи делает при полностью запрещённых прерываниях, что длится иногда весьма продолжительное время. В частности, SVC-программы типа 1 (к ним относятся, например, GETMAIN и FREEMAIN) работают от начала до конца при запрещённых прерываниях, не считая прерываний от схем контроля. SVC-программы других типов (2, 3, 4) работают при разрешённых прерываниях, но перед этим обработчик прерываний по вызову супервизора, выполняющийся при запрещённых прерываниях, определяет тип прерывания, для типов 2, 3, 4 создаёт SVRB, заполняет его необходимой информацией и добавляет к цепочке блоков запросов текущей задачи (т.е. задачи, выдавшей SVC), если это SVC-программа типа 3 или 4, проверяет, находится ли её загрузочный модуль в памяти (если нет, инициирует его загрузку, а пока она не выполнена, позволяет выполняться другой задаче; SVC-программы типа 2 являются резидентными, поэтому проверка не нужна); наконец, если загрузочный модуль находится в памяти, разрешает прерывания (только сейчас!) и передаёт ему управление.
5) Назначение аппендикса PCI -- модифицировать канальную программу во время её выполнения, поэтому никакие задержки с его выполнением недопустимы. По этой причине обработчик прерываний ввода-вывода, являющийся частью супервизора ввода-вывода, обнаружив по информации, сохранённой в CSW, что это PCI, сразу же вызывает аппендикс, и последний, таким образом, выполняется в рамках обработчика прерываний ввода-вывода. Это, кстати, является причиной, почему программы, использующие ввод-вывод с PCI, могут оказаться неработоспособными при выполнении на виртуальной машине, хотя нормально работают на реальном железе: корректно написанная программа (и аппендикс PCI, и всё другое, относящееся к обслуживанию ввода-вывода) не может полагаться на то, что модификация канальной программы будет выполнена вовремя, а соответственно, при завершении канальной программы должна проверить, всё ли было выполнено в полном объёме, и если нет, запустить её повторно с необходимой точки. Но это делается не всегда -- и тогда на виртуальной машине возникают проблемы, так как там уже никакой гарантии "мгновенной" передачи управления аппендиксу PCI нет.
Ага, проверяет. Например, проверяет положение буферов ввода-вывода в памяти (а в системе с виртуальной памятью ещё и фиксирует нужные страницы и корректирует адреса -- заменяет виртуальные на абсолютные, причём при наличии специфических требований на этот процесс можно влиять с помощью специально предназначенного для этого аппендикса). Но система не может проверить смысл предоставляемых пользователем аппендиксов -- она может проверить лишь формальные вещи типа их физического наличия и доступности; проверить допустимость их поведения она не в состоянии.
Переубеждать Вас я не собираюсь -- что хотите, то и думайте хоть обо мне, хоть об обсуждаемых вопросах.
Что же касается ввода-вывода в классической Системе 370 (в лице наших ЕС-1035 и ЕС-1130), я с ним работал и как программист, и как электронщик. У меня даже своя собственная ОС была -- уже с виртуальной памятью, но ещё без обработки ошибок и без поддержки дисплеев (в качестве терминала -- только пишмашка в силу её простоты, из-за чего на ЕС-1130, когда она у нас появилась, гонять мою систему можно было только под СВМ; поддерживались, естественно, диски, ленты, АЦПУ и перфокарты, но не было обработки ошибок ввода-вывода как таковых -- только простых условий вроде конца колоды перфокарт или отсутствия бумаги в АЦПУ; всё остальное планировалось, но сделано не было -- 90-е годы не очень способствовали работе на одном месте). Так что, как работает ввод-вывод на мэйнфреймах, я знаю очень неплохо и на уровне программиста, и на уровне внутренностей процессоров и каналов, и на уровне сигналов интерфейса ввода-вывода, хотя некоторые детали, вероятно, подзабылись. Вот в устройства управления (контроллеры) тех же дисков я никогда не лез, т.е. с их работой знаком лишь со стороны программиста, но не электронищка.
1) Не так редко, как иногда кажется.
2) На размер влияет не очень сильно, конечно, но если у тебя на всё про всё, скажем, 4 Кбайта памяти, то обычно считаешь каждый байт.
3) Сейчас считают не байты в ОЗУ и тем более на дисках, а байты в строках кэшей и байты, которые процессор способен прочитать из кэша и обработать за один такт -- а там счёт по-прежнему идёт на единицы и десятки байтов.
4) А иногда, наоборот, для производительности выгодней раздувать программу. Скажем, если у тебя на ПК четыре команды вместились в 15 байт, причём первая из них начинается по адресу, кратному 16, то для запуска в работу пяти команд процессору потребуется два или три такта: в первом такте он выберет эти 16 байт, обнаружит, начиная с их начала, четыре полные команды и запустит их, а во втором такте он вынужден будет выбрать те же 16 байт (они ещё не закончились), но обнаружит там лишь одну команду или вообще её начало (в последнем байте этой группы) и запустит только её. А если она многобайтовая, ему придётся прочитать (в третьем такте) следующие 16 байт, чтобы эту команду запустить.
А вот если эти четыре команды искусственно раздуть (добавив, например, ничего не значащий префикс к одной из них) до 16 байтов, то процессор в первом такте выберет те же 16 байт и запустит эти четыре команды, но в следующем будет считывать уже следующие 16 байт -- в которых, если повезёт, тоже будет четыре команды, которые он сможет запустить. В результате получится 8 команд за два такта, а не 5 команд за два или три такта.
Аппендиксы -- это подпрограммы, вызываемые супервизором в определённые моменты прохождения запроса ввода-вывода через супервизор. В частности, если это аппендикс PCI, он вызывается каждый раз, когда выполняющаяся в данный момент канальная программа, для которой он указан, вызывает программно-управляемое прерывание (PCI). Обработчик прерываний ввода-вывода, увидев, что причиной прерывания послужило PCI и что для данной канальной программы указан аппендикс PCI, немедленно вызывает этот аппендикс. Таким образом, сей аппендикс вызывается и работает в режиме супервизора с нулевым ключом защиты и с запрещёнными прерываниями -- фактически, он выполняется как часть супервизора ввода-вывода, но при этом его предоставляет системе прикладная программа, выдавшая EXCP.
Насчёт других аппендиксов я не помню, выполняются ли они в состоянии "супервизор" с нулевым ключом или в состоянии "задача" и с её ключом.
Это в современной z/OS она может быть документирована, а в обычной документации на ОС ЕС (и, надо полагать, на OS/360, с которой переводы были сделаны -- я оригиналы не читал) про неё ни слова.
С какой стати потеряны-ты? Профилактика/юстировка проводятся одновременно с работой машины -- просто конкретный накопитель выводится на эту самую профилактику, а остальные продолжают использоваться. Заканчивают с одним -- передают его в эксплуатацию, выводят из неё другой, и так по кругу. Конечно, ЧП временам случаются, но при нормально организованном техобслуживании они именно ЧП, а отнюдь не ежедневное событие.
Уж не знаю, что у Вас за ЕСки такие были. В начале 70-х первые машины действительно были очень ненадёжны из-за ненадёжной элементной базы; когда отладили выпуск микросхем, надёжность резко поднялась. Так что раз в месяц сдохнуть ещё что-то могло, а чтоб цирк был постоянно -- не верю. Вот ежедневное обслуживание дисков и несколько реже другой периферии -- да, но работе оно не мешало, просто диски по одному выводились на обслуживание, но их-то достаточно много на всех крупных конфигурациях, да и на средних тоже.