Comments 42
какой практический смысл читать про детали реализации технологий 50-летней давности? На кого рассчитана статья?
Во-первых, есть любители истории вычислительной техники -- в первую очередь расчёт на них. Во-вторых, в технологиях 50-летней давности тоже встречаются интересные решения, особенно с учётом того, что решать приходилось сложные задачи, а ресурсы были куда более ограниченными, чем сейчас (грубо говоря, чтоб заставить мигать лампочку, нужно было делать мультивибратор на двух транзисторах, а не ставить какую-нибудь Raspberry Pi с несколькими 64-битными ядрами и десятками миллионов транзисторов).
Знание истории всегда поучительно. Всегда нужно знать контекст. Для общего развития. Что и из чего вырастает. Что могло быть забыто, хотя, и было удачным (например). И срок давности здесь значения не имеет. Никакого.
Как говорится в одном эпиграфе:
Кусочек подлинной истории — это такая редкая вещь, что им надо очень дорожить.
А практика всегда вырастает из богатого окружения. Так зачем же себя обеднять историческими познаниями?!?
Потому что эти технологии все еще используются. Где-то в измененном виде (IBM), где-то — в первородном. Не удивлюсь, если в каких-нибудь условных РЖД билетная система живет на той самой ЕС ЭВМ. Или на эмуляторе ЕС ЭВМ, запущенном на первопне...
Как-то раз ребята из Я.Расписания наткнулись на такой артефакт из времён ЕС – некоторые русские буквы оказались английскими. Я про их замешательство узнал из Твиттера, где обсуждали пост на баше про дичь в сообщениях из билетной системы РЖД – и написал тут статью https://habr.com/ru/articles/547820/.
Так что да, используются в полный рост много где и знать про всю эту экзотику точно имеет смысл, хотя-бы по поверхности.
Да, было такое -- экономили место, но не в кодовых таблицах (пустого места в EBCDIC было предостаточно), а на барабанах принтеров, в первую очередь. Из-за этого сортировка в ОС ЕС была доработана: при запуске можно было указать, сортировать по-русски или по-английски.
До сих пор такой способ используется для прсевдоруссификации символьных дисплеев, там есть память для нескольких произвольных символов - туда записывается часть кирилицы, а всё остальное латиница.
Наследие эпохи, когда пишущие машинки «Консул» заменяли принтеры, клавиатуры и мониторы...
Ну почему заменяли... Были на ЕСках и принтеры, и мониторы с клавиатурами. Но в качестве консольного терминала пишмашка часто была удобнее: протокол сохранялся. А что она печатала максимум 10 символов в секунду, то какая нужда-то для консоли печатать быстро? (Ну а принтеры в зависимости от модели -- от 500 до 1200 строк по 128-132 символа в минуту; из-за высокой скорости и низких эксплуатационных расходов их потом к ПК присобачивали).
У нас наследие ЕС ЭВМ почти не сохранилось. А вот на западе дор сих пор, особенно в банковской сфере крутится куча программ либо Z платформе, либо на эмуляторах. До сих пор актуальны специ по COBOL. А все потому, что отход от принципа "работает - не трогай" в финансовой сфере стоит очень дорого. Перенос ПО на современные системы идёт, но это очень дорого и долго - перекодировать то просто, а вот гарантировать безошибочную работу куда сложнее. Сам столкнулся с таким при переносе математической библиотеке с Fortran на С
Довольно сложно понять, зачем в сверхцентрализованном СССР распыляли силы на решение разными организациями одних и тех же задач, но что было, то было.
Централизация была не такой уж "сверх": были, к примеру, и ведомственные поликлиники, и ведомственные детсады, и ведомственное жильё, и ведомственные дома отдыха. В данном случае, очевидно, получилась ведомственная система вычислительной техники - вся серия АСВТ, а затем сменившая её СМ, предназначалась для нужд автоматизации производства.
И авиаконструкторских бюро и даже ракетчиков было больше чем один коллектив на всю страну.
Ну, для чего АСВТ нужна была, понятно. Непонятно, почему в её рамках разрабатывали машину верхнего уровня в виде той же самой ЕСки, вид сбоку -- вместо того, чтоб делать всё ИБМ-совместимое в рамках одного проекта, PDP-совместимое -- в другом, HP-совместимое -- в третьем (а два последних в итоге смешали в одну кучу). Ничто ведь не мешало использовать ЕСки вместе с машинами из АСВТ и СМками -- как, собственно, и бывало на практике; да и в качестве управляющих в строгом смысле слова они никогда не годились -- слишком большие, дорогие, сложные и недостаточно надёжные. Обработка экономической информации, всякая там статистика и т.д. -- да, это их область, но не прямое управление оборудованием или участие в техпроцессах.
Ну а централизация как позволяла эффективней использовать ресурсы, не распыляя их -- но на практике получилось, что у нас ни конкуренции нормальной не было, как у капиталистов, ни эффективного использования возможностей централизации.
Моё предложение такое: внутри ведомственных "владений" правили бал люди с производства, которым важнее был результат "здесь и сейчас".
Сдается мне, что Вы правы в своем предложении. Но альтернативой «здесь и сейчас» в условиях тогдашней плановой экономики вполне могло быть и «никогда».
В 1986 году на практике в одном КБ удивился увидев схему серийного микропроцессорного прибора где стояло 2 микросхемы ПЗУ К573РФ1 (каждая 1Кx8 с тремя питаниями +5, -5 и +12 В), спросил почему бы не поставить одну К573РФ2 (2Кx8 одно питание +5 В), кроме экономии места на плате там существенно упрощался БП. Ответ конструктора поразил: наше министерство эти микросхемы не делает, нужно заказывать в МЭП, такой заказ идёт через Госплан (серийное производство) и поэтому занимает 3 года — год на консолидацию потребности в нашем министерстве, год на верстку в госплане и год на планирование производства в целевом министерстве. Но заказывать нужно не К573РФ2, а конкретный артикул под которым микросхема производится (одна и та же логически микросхема постоянно совершенствуется, меняется технология, топология — каждое изменение сопровождается изменением артикула). Они заказывали К573РФ2, но через 3 года, когда пришел момент получения первой партии — получили ответ, что заказанный артикул больше не производится. РФ1 — микросхема устаревшая, технология больше не меняется, артикул тоже неизменен.
Та же самая ситуация с планированием определяла и желание каждого министерства иметь свою собственную линейку ЭВМ, желательно из компонент которые либо производятся своими силами либо крупносерийные проверенные временем.
при всей централизации - уверенности что все получится не было ни у кого, и гарантии никто давал. Это сейчас легко говорить "будет успешной", а тогда - когда вокруг полно архитектур с прекрасными обещаниями и реальной реализацией с теми или иными проблемами, приходилось держать "запасной вариант" (как пилоты у самолета - они даже едят разную еду на всякий случай)
Перед политическим решением о копировании, был эпичный срач институтов и коллективов, в котором все топили всех.
Тут политики просто устали ждать, и сделали ход конём, разрубив узел обещаний и сказок о светлом будущем.
Сейчас ситуация в один один с ГосУслугами: сказок о светлом будущем много-много лет, а по факту весь этот вилограблепед едва ползёт, в неизвестном направлении (москвичам проще, у них спектр работающих сервисов намного больше).
В некоторых случаях УВУ и ВУ технически являются одним целым и для пользователя неразличимы; к таким устройствам относятся, например, принтеры, устройства ввода и вывода перфокарт и т. д.
Не ради придирки, а для уточнения: были модели УВУ, которые технически исполнялись отдельными устройствами и объединяли в себе управление принтерами и перфокарточным вводом-выводом, оставляя за самими ВУ исключительно механические функции. К таким относилась, к примеру, IBM 2821 - название ЕС-овского аналога я привести не могу, но сам видел такие УВУ "в железе" на ЕС-1022. Программно такие УВУ, похоже, были неразличимы, но при генерации ядра ОС их требовалось указывать - очевидно, чтобы учитывать специфику загрузки ввода-вывода при одновременной работе.
Таким образом, благодаря своей унифицированной организации ввода-вывода Система 360 способна выполнить загрузку с любого ВУ, реализующего команду «основное чтение»
В курилках даже вели дискуссии на тему возможности начальной загрузки с устройства системной консоли или с некоторых моделей дисплеев. Формально, в них тоже была реализована эта команда.
Угу. Но диапазон значений байтов, которые можно было передать машине, был ограничен, поэтому вряд ли бы удалось практически.
Совершенно верно, поэтому обсуждение продолжилось таким образом: мы не требуем работоспособности от загруженной таким образом программы. То есть достаточно, чтобы успешно завершилась аппаратная часть процедуры IPL (в реальности она микропрограммная). Иными словами, требуется, чтобы погасла индикация начальной загрузки на пульте управления ЭВМ.
По поводу параллельной работы ЦП и каналов, ради эксперимента запустили одновременно форматирование 4 дисководов на ЕС 1045. Нагрузка на процессор была в пределах 8%, на канал нагрузка доходила до 80%. При этом программисты работающие параллельно никакой задержки не наблюдали.
Ну а что здесь удивительного? Процессор формировал канальные программы и запускал их, всё остальное делалось без его участия: контроллер дисков сам управлял накопителями, позиционируя головки и затем записывая разметку на дорожки. Естественно, время от времени процессор и канал конфликтовали при доступе к ОП, что слегка подтормаживало работу процессора, но не более того.
Спасибо, очень интересно! Жду следующих статей про ЕС ЭВМ
Помню, можно было с помощью команды modeset (это такая svc команда со своим кодом) получить привилегированный режим и делать всякие интересные вещи.
Ага, в обычной официальной документации вроде б не упоминается, но без проблем отыскивается в системной макробиблиотеке. Правда, её использование, в принципе, можно запретить беспарольным заданиям, но обычно с этим не заморачивались.
MODESET -- это для тех, кто не в курсе. В ОС ЕС 4.1 и 6.1 была дырка в SVC вызове FREEDBUF, доставшаяся "по наследству" от MVT. Никакого пароля она не требовала в принципе, и ещё ходила удобная "обертка" для неё в виде процедуры NEWPSW. Я не так давно изучил, как они обе работают, по исходникам MVT и дампу процедуры, могу здесь рассказать.
А что, есть полные исходники MVT?
Почти полные, я не нашел только кое-какие из модулей QSAM. А так -- начальный загрузчик, модули ядра, утилиты, ASM F, редактор связей, загрузчик, компиляторы. Ищите "ОS/360 CD" и "os360mvt.tar.gz" Я когда-то скачивал здесь, но сейчас у меня эта ссылка не открывается. В крайнем случае, поделюсь своей копией.
Да, точно. Была такая дыра.
Расскажите
Для начала, постараюсь ввести в контекст, насколько возможно кратко.
Основная структура, с помощью которой в OS/360 выполняются операции с набором данных (НД), -- это блок DCB (Data Control Block), который располагается в области памяти программы. После открытия НД создаётся блок DEB (Data Extent Block) в системной области памяти, в который записывается информация, требующая защиты от посторонних изменений, например, границы областей диска, в которых расположен НД (extents, отсюда и название этого блока). Эта область памяти защищена нулевым ключём, т.е. изменять её содержимое может только ОС.
Небольшое отступление: если говорить про защиту системных данных применительно к OS/360, имеется в виду защита именно от несанкционированного изменения этих данных. Защита от чтения отсутствует; более того, в ряде случаев, чтобы программа получила ту или иную нужную ей информацию, требуется пройти по цепочке указателей на системные блоки, найти требуемый блок и извлечь данные из него.
Так вот, помимо всего прочего в DEB содержатся адреса т.наз. программ-аппендиксов. Это, по сути, callbacks, которые ОС вызывает в определенных ситуациях в процессе ввода-вывода. Состав и функции аппендиксов варьируются в зависимости от метода доступа. Понятно, почему требуется защищать их адреса: если программа сумеет заменить один из них, последует передача управления по этому адресу в состоянии процессора "супервизор" и с нулевым ключём защиты памяти (иными словами, в системном контексте).
Для базисного индексно-последовательного метода доступа (BISAM) и базисного прямого метода доступа (BDAM), которые работают только с дисками, была реализована дополнительно функция динамической буферизации. Что это такое: обычно требуется, чтобы область памяти для чтения данных из ВУ была выделена заранее. В случае, когда НД может содержать блоки данных разного размера, при этом приходится заранее выделять область максимальной длины, даже если она вся не потребуется. При динамический буферизации заранее ничего выделять не требуется: в ходе операции ввода ОС прочитает размер блока данных из области счёта на диске, выделит для него область памяти необходимого размера и прочитает туда блок данных.
После успешного завершения операции чтения программа может работать с прочитанным блоком данных, изменить там что-нибудь, не меняя длины, и записать его обратно на диск. После успешного завершения операции записи ОС освободит выделенную область памяти. Также можно просто освободить эту область при помощи системного вызова FREEDBUF.
Здесь я не очень понимаю, почему для такого освобождения памяти понадобился отдельный системный вызов (SVC). Например, при обычной буферизации буфер возвращается в свой пул при помощи вызова модуля из программы, не требуя для этого ни состояния супервизора, ни нулевого ключа защиты. Возможно, дело в том, что первоначально этот вызов и не планировался, но затем выяснилось, что при освобождении потребуется что-то поменять в других системных блоках. Так или иначе, это самый короткий из системных вызовов по объему кода и, на мой взгляд, носит явные следы спешки при реализации, что и повлекло за собой появление дырки в защите.
Что делает обработчик SVC FREEDBUF: он получает указатель на DCB, определяет метод доступа BISAM либо BDAM, читает адрес DEB из DCB, [здесь я отпускаю небольшое блуждание по системным структурам], читает адрес требуемого аппендикса, в зависимости от метода доступа, передаёт по управление по этому адресу и после возврата управления заканчивает обработку системного вызова.
Видите, в чём подвох? Управление в системном контексте передается "куда-то туда", не проверив предварительно подлинность переданных в системный вызов параметров! А проверить-то было очень просто: пройти по цепочке блоков DEB для данной задачи (процесса в современных ОС), сравнивать обратные адреса DCB в этих DEB с параметром и, если не совпадает ни один, непонятно ругаться, уж что-что, а это OS/360 умела.
Теперь воспользуемся этой дыркой. Пишем блок данных, который якобы DCB, но заполняем только те поля, к которым обращается SVC и подставляем адрес якобы блока DEB. Дальше поступаем аналогичным образом, пока не доберемся до адреса аппендикса, куда подставляем, разумеется, указатель на свою процедуру. Профит! ;)
Скажу ещё пару слов про NEWPSW. Прежде всего, она определяла версию ОС. Для MFT/MVT/SVS использовалась указанная дырка, а для MVS какая-то другая (с ней я не стал разбираться по причине недостаточной документации и опыта работы с MVS). Затем она вызывала FREEDBUF с указателем на фальшивый DCB. (Так совпало, что свой proof-of-concept я написал для одного метода доступа, а NEWPSW эксплуатирует другой.) Получив управление с нулевым ключём защиты, процедура находила сохранённый PSW для переключения обратно после системного вызова и заменяла в нем флаг состояния и ключ защиты памяти, сохранив старые значения. Таким образом, с помощью NEWPSW можно было, например, установить нулевой ключ защиты, что-нибудь поменять в системных блоках и вернуть ключ защиты программы. Либо установить состояние супервизора, запретить прерывания, произвести какие-то атомарные операции, снова разрешить прерывания и вернуть состояние программы.
Если коротко, то можно было получить привилегированный режим работы, а затем и нулевой ключ.
Напоследок замечу, что совместимыми с Системой 360 в нашей стране были
не только ЕС ЭВМ. Например, в те же годы в рамках «Агрегатной системы
средств вычислительной техники» (АСВТ) была разработана ЭВМ М-4000 и её
модификации М-4030 и М-4030-1
Еще раньше, и даже до выпуска первых ЕС-машин, с архитектурой а-ля IBM-360 выпускались ЭВМ в семействе АСВТ: М-2000 и М-3000. Это были машины еще на дискретных транзисторах. Разработка - г.Северодонецк, "Импульс". М-3000 использовалась в первой версии системы бронирвпния билетов Сирена.
Борис Фельдман в своей книге мемуаров писал, что М-4000 вышла неудачной и фактически была полностью переделана на киевском Электронмаше силами СКБ, так появилась М-4030. Политически удобно было, однако, считать ее модификацией М-4000.
------
Ваш текст, наверное, первый современный в интернете, где акцентируется и притом с указанием деталей, что внутренне советские машины ряда ЕС отличались от IBM и прямых сопоставлений между конкретыми моделями сделать не получается. Спасибо!
Ну, обычно ж пишут либо не очень грамотные технически люди, либо откровенно ангажированные, вот и превращается заимствование архитектуры (чем занимались в те годы все кому не лень) в слепое копирование всего вообще. Грамотному человеку понятно, что копирования быть не могло именно технически: ЕСки делались на микросхемах-аналогах (вот уж не знаю, точных копиях или созданных "по мотивам" -- в микроэлектронике некомпетентен) изделий Texas Instruments (ТТЛ) и Motorola (ЭСЛ), а IBMовские машины -- сначала на собственных IBMовских микросборках, потом на столь же собственных микросхемах, аналогов которым у нас не было. Так что, хошь не хошь, а реализацию приходилось делать самостоятельно.
Хотелось бы иметь больше деталей , какие модели ЕС ЭВМ, какой набор инструкций поддерживали (360, 370, своя), пока вся информация разрозненная.
Да мне тоже хотелось бы :) Но дело в том, что подробной информации по ряду машин нет. Даже по отечественным полная ясность не всегда присутствует. Скажем, ЕС-1066 какой "версии" Системы 370 соответствовала? Я лично понятия не имею -- а соответственно, не могу сказать, какие расширения архитектуры там были реализованы. На Вике вообще регулярно чушь пишут. Например, ЕС-1015 относят к тому же ряду, что ЕС-1010/11/12 -- но последние никакого отношения к Системе 360 не имеют, а 1015, согласно венгерскому каталогу для какой-то советской выставки 1979 года, полностью совместима со старшими моделями -- т.е. является полноценной Системой 370 (в частности, имеет виртуальную память). Ну или ЕС-1130: Вика говорит, что год начала производства -- 1994, но я на ней уже в 1993 работал, причём отнюдь не в Минске, где их делали. В общем, плохо с информацией...
Мне говорили, что ЕС-1036, ЕС-1046 и ЕС-1066 соответствуют серии IBM 303X. То есть, ЕС-1066 - это копия IBM Model 3033.
ЕС ЭВМ. Введение