В 1974 году Тед Нельсон явил миру литературного кентавра — книгу, столь же эксцентричную, как и ее создатель. Чтобы оплачивать счета, Нельсон вынужденно читал лекции по социологии в Иллинойсском университете — хотя в душе был технологическим Че Геварой. Еще в свингующие шестидесятые он родил идею «гипертекста» — системы, связывающей документы невидимыми нитями, и окрестил ее «Проектом Ксанаду». Проект, правда, походил на линию горизонта — прекрасен, грандиозен, но вечно в стадии «почти готово».
Нельсона терзала одна несправедливость. Его коллеги-радикалы смотрели на компьютеры с суеверным ужасом — как средневековые крестьяне на алхимиков. Для бунтующей контркультуры тогдашние ЭВМ казались железными церберами. Нельсон не спорил: да, сейчас эти машины используют жестоко. Но в них он видел не кандалы, а ключ от темницы.
Содержание
→ На крючке
→ Мини-компьютеры для самостоятельной сборки
→ Любовь через time-sharing
→ Культура игр
Его манифест — библиографический перевертыш: два тома, сшитые «спина к спине», каждый со своей обложкой. С одной стороны, открывалась «Компьютерная библиотека» — ликбез, объясняющий, что такое ЭВМ и почему их стыдно бояться. С другой — «Машины снов», визионерский трактат о том, чем компьютер станет, когда его вырвут из цепких лап «технических жрецов».
Автор честно предупреждал:
«Моя цель проста: компьютеры должны служить людям, и немедленно. Без искусственных сложностей и без того, чтобы человек превращался в раба машины…
Эта книга — манифест личной свободы, объявление войны любым ограничениям и принуждению.
Вот вам лозунг, с которым не стыдно выйти на улицы: всю компьютерную власть — народу! Долой кибер-заумь!»
Если у кого‑то и оставались сомнения, что сердце автора бьется в унисон с ритмами шестидесятых, Нельсон развеял их, предъявив свои «верительные грамоты».
Список его «контркультурных достижений» выглядел как звонкая пощечина скучному миру. Рядом с вполне понятными «писателем» и «шоуменом» гордо значился титул «ветерана Великого Вудстока» и совершенно обезоруживающая строчка — «бывший ученик седьмого класса».
Вишенкой на торте стал, разумеется, его знак зодиака. В конце концов, какая может быть революция без гороскопа?
Манифест Нельсона — по сути, неопровержимая улика. Он доказывает популярную теорию: персональный компьютер — не просто железка, а наследие буйной контркультуры 60‑х.
Вряд ли можно списать на географическую случайность тот факт, что колыбель Apple качалась на тех же берегах залива, где еще вчера радикалы Беркли штурмовали баррикады, а в Хейт-Эшбери фанаты Grateful Dead ловили психоделические волны. У них была общая ДНК — жажда личного освобождения.
Нельсон не был единственным пророком, желавшим вручить народу огонь Прометея. Взять хотя бы Ли Фельзенштейна, который однажды бросил инженерный факультет Беркли, чтобы позже закончить его с триумфом. У него куда более солидное политическое досье, чем у Нельсона. В 70‑х он тратил время на такие проекты, как Community Memory — по сути, цифровую доску объявлений. Терминалы стояли в общественных местах, доказывая, что соцсети возможны и в доинтернетную эпоху.
В Менло-Парке действовал Боб Альбрехт со своей «Народной компьютерной компанией» (дословно People's Computer Company). Название не врало: любой прохожий мог зайти с улицы и прикоснуться к священной машине.
И Фельзенштейн, и Альбрехт не были городскими сумасшедшими — они стали отцами-основателями индустрии: первый как блестящий «железячник», второй — как издатель и проповедник.
Два главных летописца той эпохи — Стивен Леви с его «Хакерами» и дуэт Фрайбергера и Суэйна с книгой «Пожар в долине» — сходятся в одном: персональный компьютер родился не в стерильных лабораториях корпораций, а в головах длинноволосых бунтарей.
По их мнению, мы обязаны появлением ПК таким персонажам, как Фельзенштейн и Альбрехт — тем самым «аппаратным хакерам» с Западного побережья, для которых технологии были не бизнесом, а инструментом личного освобождения.
Позже Джон Маркофф развернул эту мысль в полноценный исторический трактат с психоделическим названием «Что сказала Соня: как контркультура шестидесятых сформировала индустрию ПК». Стюарт Бранд в 1995 году подвел черту под спорами одной фразой в журнале Time: «Мы всем обязаны хиппи».
Эта история невероятно привлекательна. В ней только один крошечный изъян: она не совсем верна.
Теория о том, что компьютерную революцию совершили исключительно длинноволосые бунтари, разбивается о суровую логику. Влияние контркультуры не было ни необходимым, ни достаточным условием для взрыва интереса к ПК.
Не было необходимым, потому что искра, из которой разгорелось пламя — легендарный Altair, — была добыта людьми, бесконечно далекими от идеалов Вудстока и левого радикализма. Эд Робертс был ветераном ВВС из Альбукерке, а Лес Соломон — прагматичным нью-йоркским редактором. Нужна уж очень богатая фантазия, чтобы записать их дуэт в ряды хиппи-идеалистов.
Не было достаточным, потому что теория объясняет лишь предложение, но игнорирует спрос. Допустим, бунтари из Залива хотели продавать «цифровую свободу». Но почему тысячи людей вдруг решили эту свободу купить? Большинство заказчиков Altair не носили фенечек и не жили в коммунах.
Если смотреть на мир через очки Сан-Франциско, «контркультурный миф» выглядит правдоподобно. Но компьютерная лихорадка была феноменом национального масштаба. Чеки и заказы летели в Альбукерке со всех уголков Америки. Откуда же взялась эта армия любителей, если не из палаточных лагерей хиппи?
Исполняем желания на Новый год ?
Напишите письмо Тирексу и получите инфраструктурную поддержку для проекта.
На крючке
В 1950‑х годах в стенах лаборатории Массачусетского технологического института (MIT) случилась классическая история из серии «искали Индию, а открыли Америку». Исследователи синтезировали электронную сущность, которой в последующие десятилетия предстояло перевернуть мир вверх дном.
Ирония ситуации в том, что этот технологический прорыв родился как случайный «побочный эффект» суровой работы над системой противовоздушной обороны. Но результат оказался неожиданно притягательным — если не сказать аддиктивным. Правда, «подсаживались» на него люди весьма специфического склада: те, в ком детское любопытство и творческая искра парадоксальным образом уживались с фанатичной любовью к сухой логике и математике.
Электронный компьютер образца 1940‑х годов задумывался не как «искусственный интеллект», а как неутомимая замена комнаты, набитой живыми людьми-вычислителями. Схема работы напоминала сдачу белья в прачечную: вы вручали машине набор инструкций — будь то моделирование ядерного гриба или расчет траектории для гаубицы — и смиренно ждали, когда заказ будет готов.
Вокруг этой модели вырос целый культ «пакетной обработки». Прямой доступ к «телу» электронного идола простым смертным был заказан. Программист приносил стопку перфокарт и передавал их в руки специально обученных жрецов — операторов. Те скармливали картонную колоду машине, а затем возвращали результат на новой порции распечаток.
Чаще всего ритуал заканчивался разочарованием: пользователь забирал длинные листы с прыгающими строками, обнаруживал ошибку (баг) и, тихо бормоча ругательства, уходил переписывать код, чтобы запустить карусель заново. К началу 1960‑х годов главным распорядителем этого бала стала корпорация IBM. Гигант ловко использовал свой опыт в создании механических счетных машин, чтобы установить тотальную монополию и в мире электроники.
Однако военным нужна оперативность. Проблемы могут возникать внезапно, и решать их нужно сразу же, а не в порядке живой очереди с колодой перфокарт. Генералам требовался «компьютер реального времени», способный выстреливать ответы с интервалом в секунды.
Первый шаг в этом направлении сделали в MIT. Проект начинался вполне мирно — как авиасимулятор под руководством инженера-электрика Джея Форрестера. Но история любит иронию: подули ледяные ветры холодной войны, и безобидный тренажер мутировал в грандиозную систему противовоздушной обороны SAGE (Semi-Automated Ground Environment).
Этот гигант обосновался в Линкольнской лаборатории — правительственном объекте в тридцати милях от студенческих кампусов MIT. И, как это часто бывает с великими открытиями, SAGE совершил революцию случайно. Созданный, чтобы следить за вражескими самолетами в небе, он попутно породил на земле совершенно новую форму вычислительной техники.
Система SAGE требовала не просто вычислителей, а настоящих электронных атлантов, создание которых доверили, конечно же, IBM. В каждом центре ПВО, разбросанном по карте Северной Америки, планировали ставить по два таких гиганта. Дублирование было обязательным, чтобы в случае «обморока» одной машины вторая тут же подставила свое цифровое плечо.
Вместо стопок перфокарт операторы смотрели в завораживающее зеленое свечение электронно-лучевых трубок. На этих экранах плясали радарные метки, и человек мог одним движением запросить досье на любую подозрительную точку или, если дело пахло керосином, поднять по тревоге истребители.
Поначалу «мозги» системы хотели строить на вакуумных лампах — стандартном, но горячем и капризном решении 50‑х. Однако изобретение транзистора спутало карты, открыв дорогу к компактности и надежности. Чтобы доказать, что твердотельная электроника способна тянуть лямку оборонзаказа, Уэсли Кларк и Кен Олсен в 1955–56 годах собрали экспериментальный транзисторный компьютер TX‑0. Этот «малыш» блестяще подтвердил концепцию, а уже к 1958‑му на свет появился его более мощный и внушительный наследник — TX‑2.
Самая изящная ирония истории в том, что главной фишкой этих компьютеров стала их… полная бесполезность. Едва доказав, что транзисторная магия работает, прототипы стали для проекта SAGE чем‑то вроде архитектурного макета после окончания стройки. В итоге новосозданные баснословно дорогие игрушки перешли в практически единоличное пользование Уэсли Кларка.
В те годы балом правила «пакетная обработка» — священная корова эффективности, призванная выжимать из драгоценного железа каждую секунду простоя. Но Кларка эти бухгалтерские страдания волновали мало. В ДНК компьютеров Lincoln Lab, ведущих родословную от авиасимуляторов, был зашит принцип живого диалога с пилотом. Кларк решил не ломать традиции. Он сделал ставку на то, что «компьютерный помощник», отвечающий здесь и сейчас, даст науке куда больше, чем бездушный молотильщик перфокарт, заставляющий ждать ответа часами.
Благодаря этому карт-бланшу сотрудники MIT и лаборатории Линкольна получили то, о чем остальные могли только мечтать: право на приватную аудиенцию с электронными гигантами TX‑0 и TX‑2. Прямой диалог с машиной вызывал моментальное привыкание.
Вместо томительного ожидания результатов пакетной обработки, инженеры получили мгновенную обратную связь. Цикл «написал — проверил — исправил» сжался до секунд, превратив рутинную отладку кода в захватывающий квест или решение сложной головоломки.
Контраст с общепринятыми стандартами конца 50‑х был разительным. Теперь единственным «узким местом» системы стала не очередь к оператору, а скорость мысли и беглость пальцев самого пользователя. Стоило человеку поймать такой ритм, как он проваливался во временну́ю дыру: часы за терминалом пролетали так же незаметно, как минуты.
Дж. К. Р. Ликлидер был человеком, которого в машинном зале ожидали увидеть меньше всего — профессиональным психологом. Его наняли как специалиста по «человеческому фактору», чтобы помирить операторов SAGE с их электронными подопечными и наладить между ними хоть какое‑то подобие диалога.
Но стоило Ликлидеру самому сесть за консоль экспериментального TX‑0 в лаборатории Линкольна, как профессиональный интерес сменился почти религиозным экстазом. Это был не просто тест, а озарение, сравнимое с ударом молнии.
С этого момента скромный психолог превратился в пламенного проповедника. Он начал нести в массы идею «симбиоза человека и компьютера», утверждая, что интерактивная машина — это не просто калькулятор-переросток, а интеллектуальный допинг, способный разогнать возможности человеческого мозга до невиданных скоростей:
«Конечно, привилегия ставить цели и искать мотивацию останется за людьми... ну, по крайней мере, в первые годы. Нам достанется роль архитекторов: мы будем выдвигать гипотезы, задавать вопросы и придумывать модели.
Железу же уготована участь идеального клерка. Оборудование будет отвечать, оживлять наши схемы, проводить симуляции и превращать массивы данных в понятные графики. По сути, компьютер возьмет на себя всю „канцелярскую“ рутину, заполняя паузы между озарениями своего создателя».
В ряды неофитов вступил и Иван Сазерленд. Для докторской диссертации в MIT он превратил суровый вычислитель TX‑2 в лаборатории Линкольна в первый в мире цифровой кульман, написав программу Sketchpad.
Позже Сазерленд сменил прописку на Университет Юты, где окончательно застолбил за собой статус одного из отцов-основателей компьютерной графики. Пока другие натаскивали машины считать, он научил их рисовать.
Лаборатория Линкольна без сантиментов списала старичка TX‑0 в утиль, как только на горизонте замаячил новенький TX-2. Компьютер отправили в почетную ссылку в Исследовательскую лабораторию электроники (RLE) при MIT, где он неожиданно обрел вторую жизнь, став идолом, алтарем и единственной любовью для новой субкультуры — хакеров. Эти «цифровые наркоманы» были готовы караулить в коридорах далеко за полночь, лишь бы выкроить лишнюю минуту наедине с машиной.
Ощущение тотального контроля над электронным мозгом они описывали в выражениях, от которых покраснел бы и поэт. Одним приходило на ум пилотирование истребителя, другим — игра на музыкальном инструменте. Третьи шли еще дальше, сравнивая кодинг и первую любовь. Конечно, это были гиперболы — вроде знаменитого признания Арнольда Шварценеггера, который с тем же томным придыханием говорил об экстазе во время пампинга.
В этом закрытом мужском клубе дамам места не нашлось. В хакерской библии Стивена Леви женские имена отсутствуют как класс. Впрочем, удивляться нечему: в те годы MIT открывал двери для студенток с явным скрипом — формально учиться им не запрещали, но смотрели на них примерно так же, как на досадную ошибку в коде.
Парадокс в том, что в 1960‑м году профессия программиста вовсе не была сугубо мужской вотчиной. Женщины занимали добрую треть рабочих мест в индустрии. Но здесь пролегал глубокий водораздел. Женщины царили в «скучном» мире корпораций и госучреждений — это были аккуратные сотрудницы, обрабатывающие данные строго с девяти до пяти.
А вот ряды «хакеров» — растрепанных фанатиков, стучащих по клавишам до рассвета не ради зарплаты, а ради чистого дофаминового восторга, — состояли исключительно из мужчин. Похоже, именно сильный пол оказался фатально предрасположен к тому, чтобы без остатка растворяться в стерильных лабиринтах цифровой логики. Вероятно, именно эта странная страсть к «искусству ради искусства» и превратила информатику в то «мужское общежитие», которым она стала впоследствии. Но это тема для отдельной социологической драмы, а мы вернемся к нашим баранам умникам.
Мини-компьютеры для самостоятельной сборки
Пока Кларк видел в TX‑0 идеальный научный инструмент, его партнер Кен Олсен разглядел в нем нечто куда более прозаичное — товар.
Плотное сотрудничество с IBM в рамках проекта SAGE оставило у Олсена стойкую аллергию на неповоротливую бюрократию «Голубого гиганта». Решив, что сможет работать эффективнее, он взял в напарники еще одного выпускника Линкольна, Харлана Андерсона, привлек финансирование от одного из первых венчурных фондов и открыл свое дело.
Правда, на старте пришлось пойти на лингвистическую хитрость. Глава фонда дал Олсену совет, который сегодня звучит как анекдот: «Только не используй слово „компьютер“». В глазах инвесторов этот термин был синонимом «дорогостоящей войны с IBM», а значит — гарантированного самоубийства.
Олсен намек понял и назвал свою компанию, которая собиралась производить компьютеры, максимально невинно — Digital Equipment Corporation, или просто DEC.
В 1957 году Олсен обосновался в декорациях, достойных промышленной готики — в старой текстильной фабрике на реке Ассабет, всего в получасе езды от своей альма-матер, лаборатории Линкольна. Эти краснокирпичные стены служили домом для DEC вплоть до 90‑х, став безмолвными свидетелями как зенита славы Олсена, так и начала заката его империи.
Сам Кен Олсен был человеком, которого проще представить на воскресной проповеди, чем на баррикадах революции. Трезвый, набожный скандинав, он прожил жизнь образцового обывателя в пригородах Массачусетса, а старость встретил в тихой Индиане. Найти фигуру, менее похожую на героя бунтарских шестидесятых, было бы непростой задачей даже для детектива.
И вот вам главный поворот истории: именно этот консервативный джентльмен стал Че Геварой компьютерного мира. Именно его компания подняла «Веселого Роджера» над рынком, объявив войну тоталитарному режиму «IBM‑изма». DEC вынесла «священный огонь» интерактивных вычислений из закрытых лабораторий MIT, щедро «осыпав» этой магией техно-энтузиастов по всей стране.
В 1959 году DEC вывела на рынок своего первенца — PDP‑1. За скучной аббревиатурой (Programmed Data Processor — программируемый обработчик данных) скрывался прямой идейный наследник легендарного TX‑0. Когда в 1961 году один такой экземпляр подарили MIT, то местные хакеры, истосковавшиеся по «железу», приняли его как родного.
Но настоящая революция грянула в 1965‑ом с выходом PDP‑8. Этот аппарат рвал шаблоны: размером с синий уличный почтовый ящик и ценой всего в 18 000 долларов — сущие копейки по меркам той эпохи.
Вскоре кто‑то остроумный (и, разумеется, это был не чопорный пуританин Олсен) окрестил подобный класс машин «мини-компьютерами» — явный реверанс в сторону мини-юбок, которые тогда как раз сводили мир с ума. Маркетологи DEC подхватили волну, описывая PDP‑8 как «доступные, покладистые и персональные машины», намекая, что теперь компьютер — это не идол за стеклом, а вполне земной приятель.
![Рекламный ролик 1966 года, изображающий различные модели PDP-8 в окружении милых плюшевых мишек [ Datamation, октябрь 1966].](https://habrastorage.org/r/w780/getpro/habr/upload_files/8d8/44a/b19/8d844ab19bece01551f8fc8370407d66.jpeg "Рекламный ролик 1966 года, изображающий различные модели PDP-8 в окружении милых плюшевых мишек [ Datamation, октябрь 1966].")
До этого момента у «бюджетных» компьютеров была одна постыдная тайна: их кратковременная память полагалась на вращающиеся магнитные барабаны. Это накладывало на скорость вычислений жесткий механический потолок — машина просто не могла думать быстрее, чем крутился вал.
PDP‑8 сбросил эти оковы, перейдя на молниеносную память на магнитных сердечниках. Высокоскоростные вычисления, ранее доступные лишь избранным, внезапно стали по карману небольшим научным фирмам и скромным лабораториям.
Универсальность машины поражала воображение. PDP‑8 трудились не только в стерильных кабинетах, но и в пыли заводских цехов, и даже — представьте себе сюрреализм картины — монтировались прямо на тракторы.
За пятнадцать лет DEC продала 50 000 этих неутомимых трудяг. Успех не просто породил армию конкурентов и новую индустрию мини-компьютеров, но и эхом отозвался в будущем, вдохновив инженеров на создание первого микропроцессора Intel 4004.
В начале 1960‑х IBM под скипетром Томаса Уотсона-младшего не просто заняла рынок мейнфреймов США (читай: всего мира), а забетонировала его под себя. Армия продавцов, чье дружелюбие прямо зависело от процента с продаж, выстраивала с клиентами отношения такой крепости, что разорвать их было сложнее, чем сицилийские узы.
Это была игра вдолгую: IBM не продавала машины, а сдавала их в аренду. В комплекте с ежемесячным счетом клиент получал уютную «золотую клетку»: круглосуточный сервис, гору периферии (наследство эры перфокарт), системный софт и даже прикладные программы для расчета зарплат и складского учета.
Вместе с «железом» IBM навязывала и новую корпоративную иерархию. Предполагалось, что между компьютером и реальным потребителем информации должна стоять специальная прослойка — жрецы отдела обработки данных. Именно эти люди управляли машиной и вели бесконечные переговоры с поставщиком, пока обычные сотрудники, которым вычисления были нужны на самом деле, терпеливо ждали своих распечаток за дверью.
Культура DEC строилась на принципе «от противного»: все, что считалось священным в IBM, предавалось анафеме. Это была настоящая контркультура в деловых костюмах.
Олсен упразднил институт корпоративных нянек. Он полагал, что если человек достаточно умен, чтобы быть инженером или ученым, то как‑нибудь разберется с компьютером без помощи жрецов из техподдержки. В мире DEC пользователь был настоящем королем: сам настраивал систему, сам писал софт и сам же его администрировал. Полная свобода — и полная ответственность.
Справедливости ради заметим, что и в недрах IBM водились светлые головы, способные оценить прелесть интерактива. Например, Энди Кинслоу в середине 60‑х пытался пробить проект по разделению времени (об этой технологии мы еще поговорим). Он мечтал дать своим коллегам тот же наркотический восторг от работы с консолью, на котором плотно сидели хакеры из MIT.
Но корпоративный иммунитет «Голубого гиганта» отторг чужеродный орган. Итоговый продукт — система TSS/360, выпущенная в 1967 году, — оказалась настолько технически беспомощной, что IBM предпочла сделать вид, будто это недоразумение никогда не появлялось.
Все упиралось в несовместимость культурных кодов. Маркетинговая машина IBM была смазана и настроена под нужды корпоративных бюрократов — тех, кто заведовал процессингом данных. Этим людям требовались мощные системы пакетной обработки, вылизанный софт и круглосуточная опека техподдержки.
А вот настоящих технарей — инженеров и ученых, которые мечтали сами жать на кнопки и не боялись, фигурально выражаясь, испачкать руки в машинном масле, — «Голубой гигант» упорно игнорировал.
Неудивительно, что эта аудитория проголосовала кошельком за DEC и других дерзких новичков вроде Scientific Data Systems. Как язвительно заметил один из сотрудников этого успешного стартапа 60‑х:
«Конечно, в те годы наука купалась в деньгах, но исследователи — это совсем не то же самое, что бизнесмены, сидящие на окладе. Им был нужен компьютер, но относились они к нему не как к калькулятору, а как к объекту страсти.
Они были очарованы нашими машинами и любили их так, как любят Ferrari или женщину. И эта любовь была слепа: если компьютер начинал капризничать, ему прощали все — точно так же, как прощают маленькие слабости сногсшибательной красотке».
Клиентура DEC напоминала список гостей на закрытой вечеринке для интеллектуальной элиты: федеральные лаборатории с казенными бюджетами, частные инженерные бюро, «гиковские» департаменты промышленных конгломератов и, разумеется, университеты — вечные инкубаторы прогресса.
Всех их объединяла аллергия на ожидание. Работа шла исключительно в режиме реального времени, где компьютер выступал не далеким идолом, а расторопным напарником. Он напрямую общался с оператором или, засучив свои цифровые рукава, управлял сложным «железом».
Спектр задач был пестрым, как ярмарочный балаган: здесь машина «на лету» щелкала инженерные расчеты для химических магнатов, там — управляла трассировкой, выуживая данные из физических экспериментов, а в соседней лаборатории — помогала психологам копаться в лабиринтах человеческого сознания.
Для обмена опытом и софтом адепты DEC сколотили собственное братство — DECUS (Digital Equipment Computer Users Society — общество пользователей цифрового оборудования и компьютеров).
У клиентов IBM тоже был свой клуб по интересам — организация с демократичным названием SHARE («делиться»), основанная еще в 1955 году. Но если в DECUS царила анархия свободного обмена, то SHARE больше напоминала закрытую масонскую ложу, живущую по строгому корпоративному уставу.
В мире IBM аксиомой считалось наличие «вычислительного центра» — этакого храма, отделенного от грешной земли. Членами клуба могли стать только верховные жрецы — начальники этих центров. Именно они собирались, чтобы с важным видом обсуждать операционные системы и ассемблеры.
Простым смертным — конечным пользователям, которые сидели где‑то снаружи и ждали свои перфокарты, — вход в это элитное заведение был заказан. В мире DEC такой классовой сегрегации не существовало по простой причине: здесь пользователь и оператор чаще всего были одним и тем же человеком.
![Мой отец, исследователь, специализирующийся на компьютеризированных медицинских картах, был частью культуры DEC и соавтором как минимум одной статьи для DECUS, «Информационные системы амбулаторной помощи, написанные на BASIC‑Plus», опубликованной в сборнике трудов DECUS (осень 1973 г.). На фотографии вверху слева, 1973 год, он изображен в терминальной комнате своего исследовательского института рядом с PDP‑11 [Институт Регенстрифа].](https://habrastorage.org/r/w780/getpro/habr/upload_files/2ea/059/61c/2ea05961cc6b64624fb4d32f583592c3.jpeg "Мой отец, исследователь, специализирующийся на компьютеризированных медицинских картах, был частью культуры DEC и соавтором как минимум одной статьи для DECUS, «Информационные системы амбулаторной помощи, написанные на BASIC‑Plus», опубликованной в сборнике трудов DECUS (осень 1973 г.). На фотографии вверху слева, 1973 год, он изображен в терминальной комнате своего исследовательского института рядом с PDP‑11 [Институт Регенстрифа].")
Как и их коллеги из стана «врага» (то есть SHARE), сообщество DECUS поддерживало обширную библиотеку софта. В их закромах хранилось все, что нужно для цифрового счастья: драйверы для общения с периферией, ассемблеры и компиляторы, превращающие человеческие каракули в понятный машине код, а также отладчики для охоты на «жучков». Отдельной полкой лежали математические функции — своего рода программные костыли для железа, которое в те годы еще не знало, с какой стороны подступиться к тригонометрии, логарифмам и возведению в степень.
Не стоит думать, что это была стихийная свалка кода. Поддержание порядка требовало бюрократии, пусть и с человеческим лицом. В 1963 году, например, пользователи пожертвовали в общий котел пятьдесят программ. Большинство из них прошли через чистилище двойной проверки коллегами, а семнадцать избранных даже получили официальный знак качества от Комитета по программированию DECUS — органа, звучащего почти так же важно, как Сенат, только без тог.
Опьяненные магией интерактивных вычислений, фанаты DEC уверовали, что вот‑вот перевернут мир — от школьных классов до больничных палат. Однако в революционном угаре они порой теряли связь с реальностью, приписывая машине свойства волшебной палочки.
Отрезвляющий душ пролился на одном из собраний DECUS. Врач ВВС Джозеф Мунди, наблюдая за этим парадом техно-оптимизма, с мягкой, почти отеческой иронией осадил «компьютерных энтузиастов». Он деликатно напомнил собравшимся, что даже у великого PDP есть, скажем так, некоторые нюансы, когда дело доходит до постановки медицинских диагнозов живым людям.
Хотя сбросить DEC с рыночного Олимпа так никому и не удалось, успех PDP‑8 в конце 60‑х спровоцировал настоящий бум подражателей. Рынок мини-компьютеров расцвел пышным цветом.
В гонку включились все: от дерзких стартапов до промышленных гигантов. Самым ярким примером первых стала Data General — компания, основанная перебежчиками из той же DEC. Бунтовщики не стали далеко бегать и окопались по соседству — чуть выше по течению той же реки Ассабет, в городке Хадсон. Вслед за ними подтянулась и тяжелая артиллерия в лице мастодонтов электроники: Honeywell, Hewlett-Packard и Texas Instruments.
Счет проданных устройств пошел на тысячи. Это означало, что тысячи инженеров и ученых наконец‑то испытали то пьянящее, почти запретное чувство: когда компьютер — это не абстрактный идол за толстой стеной, а личный инструмент, жужжащий прямо на рабочем столе.
Даже в цитадели прогресса, Массачусетском технологическом институте, администрация смотрела на любовные игры хакеров с TX‑0 и PDP‑1 как на святотатство. В глазах бухгалтерии эти «шалости» были гротескным разбазариванием драгоценного машинного времени.
Однако ситуация в корне изменилась, когда компьютеры подешевели до «смешных» 10−20 тысяч долларов. Руководители отделов, купившие себе такие игрушки, перестали трястись над каждой секундой простоя. Да и кому было следить за дисциплиной? Штатных надзирателей-операторов к этим малюткам не приставляли.
Оставшись без присмотра, пользователи тут же выбрали путь наименьшего сопротивления, то есть — комфорт. Ручное управление, интерактивность, живое общение с терминалом — все то, что раньше считалось непозволительной роскошью.
И пока тысячи инженеров и ученых наслаждались пьянящим чувством обладания собственным «электронным мозгом», на горизонте уже маячила новая технология. Ей предстояло взять этот элитарный опыт и растиражировать его для куда более широкой публики.
Любовь через time-sharing
Как мы уже убедились, обитатели MIT и его окрестностей «подсели» на интерактивные вычисления еще к 1960 году — задолго до того, как PDP‑8 сделал это удовольствие доступным.
Но здесь возник конфликт скоростей, достойный пера драматурга. Электронный мозг был готов щелкать миллионы операций в секунду, но в режиме диалога этот титан вынужден был смиренно ждать, пока его белковый оператор соизволит сформулировать мысль и нажать на клавишу. В эти паузы колоссальная мощь уходила в небытие.
Для администраторов — тех самых хранителей бюджета, у которых при виде лишних трат начинался нервный тик — зрелище было невыносимым. Позволить машине с шести‑ или семизначным ценником «курить бамбук», пока ученый чешет в затылке? С их точки зрения, использовать драгоценные вычислительные ресурсы только ради комфорта инженеров было не просто расточительством, а преступлением против бухгалтерии.
А что, если превратить этот простой в преимущество? Решение оказалось изящным, как карточный фокус.
Идея заключалась в том, чтобы подключить к одному электронному мозгу четыре, сорок или даже четыреста терминалов. Пока один пользователь задумчиво смотрит в экран, процессор мгновенно переключается на запрос соседа или в фоновом режиме «грызет» пакетные задачи. Для человека за клавиатурой создавалась полная, сладкая иллюзия обладания: ему казалось, что машина принадлежит только ему. Если система не захлебывалась от нагрузки, никто и не подозревал, что цифровой слуга работает на несколько фронтов одновременно.
Главным проповедником этой концепции — разделения времени — стал Джон Маккарти. Математик и пионер искусственного интеллекта перебрался из Дартмутского колледжа в MIT не от хорошей жизни, а по любви: в родном Дартмуте компьютеров попросту не было, а Маккарти не мог без них жить.
Медлительность пакетной обработки доводила его до белого каления, мешая экспериментам. Поэтому он предложил соломоново решение, призванное примирить всех: дать ученым желанный интерактив, а администраторам — стопроцентную загрузку их драгоценных мощностей.
Крестовый поход Маккарти увенчался успехом. В Массачусетском технологическом институте группа под командованием Фернандо «Корби» Корбато создала CTSS — cовместимую систему разделения времени.
Слово «совместимая» здесь было ключевым дипломатическим маневром. Оно означало, что новой системе не нужно свергать старую власть: CTSS мирно уживалась на одном IBM-мэйнфрейме с традиционной пакетной обработкой, действуя параллельно, как соседи на кухне в коммуналке.
Маккарти на этом не остановился. В консалтинговой фирме Bolt, Beranek and Newman (BBN), которая была связана с MIT группой общих интересов, он провернул еще один трюк: запустил примитивное разделение времени на скромном PDP‑1. Это доказало революционный тезис: чтобы делить время, не обязательно владеть гигантским мэйнфреймом.
Вскоре эта идея пошла в народ. Даже малютка PDP‑8, при наличии достаточного объема памяти, умудрялась жонглировать запросами от двадцати четырех терминалов одновременно. Размер, как выяснилось, не имел решающего значения.
Однако самые решительные шаги по внедрению интерактивных вычислений и технологии разделения времени были сделаны в Дартмутском колледже — бывшей вотчине Джона Маккарти.
Революцию возглавил дуэт, который трудно было назвать типичным. Джон Кемени (заведующий кафедрой математики) подбил своего коллегу Томаса Курца (служившего связным с вычислительным центром MIT) на грандиозную авантюру: создать собственный компьютерный центр. Но сделать это не «как у людей», а по‑своему.
Кемени был настоящим феноменом. Блестящий венгерский еврей, бежавший от нацистов в США, он принадлежал к тому же золотому поколению гениев, что и фон Нейман или Эдвард Теллер, хотя и был значительно моложе. Его талант был настолько очевиден, что в 1943 году, будучи еще «зеленым» студентом Принстона, он уже работал над Манхэттенским проектом.
Его партнер, Томас Курц, имел менее драматичную биографию — уроженец пригорода Чикаго и аспирант элитного принстонского матфака. Однако его страсть лежала не в плоскости высоких абстракций. Сразу после колледжа, в начале 50‑х, Курц с головой ушел в численный анализ. По сути, он занимался информатикой задолго до того, как мир вообще договорился, что это такое, предпочитая «железо» и алгоритмы традиционной математике.
Эта парочка энтузиастов стартовала в начале 60‑х, вооружившись скромным Librascope LGP‑30 — компьютером с памятью на магнитном барабане, который, тем не менее, умел работать в интерактивном режиме.
К тому моменту оба профессора уверовали в нехитрую истину: компьютеры — это не просто калькуляторы-переростки, а явление цивилизационного масштаба. Наблюдая, как студенты укрощают LGP‑30, продираясь через дебри Ассемблера, Кемени и Курц пришли к революционному выводу: программирование должно стать обязательной частью гуманитарного образования. Код, по их мнению, следовало преподавать наравне с философией и историей.
Впрочем, упражнения с хрустальным шаром были тогда в моде. Ученые мужи наперебой строчили трактаты о том, как электронный мозг перекроит юриспруденцию, библиотеки и само понятие частной жизни. Неутомимый же Джон Маккарти еще в 1961 году выступал в роли Нострадамуса, предрекая появление «компьютерной коммуналки»: он описывал мир, где вычислительная мощь будет течь в дома и офисы по телефонным проводам, словно вода из крана или электричество из розетки.
Курц предложил идею, звучавшую для той эпохи как научная фантастика: привезти в Дартмут мощный компьютер с разделением времени и дать к нему прямой доступ всем студентам. Это должен был быть цифровой аналог публичной библиотеки — никаких закрытых дверей.
Чтобы воплотить мечту в жизнь, потребовался слаженный дуэт. Кемени пустил в ход свои политические таланты (которые позже вознесут его в кресло президента университета), уламывая руководство. Курц тем временем выбивал деньги, добившись грантов от Национального научного фонда (NSF).
Нашлись и союзники в бизнесе. General Electric, отчаянно пытавшаяся потеснить IBM, расщедрилась на 60‑процентную скидку. В итоге Дартмут получил сразу две машины: мэйнфрейм GE‑225 для вычислений и коммуникационный процессор Datanet‑30, который жонглировал данными между «мозгом» и терминалами пользователей.
Эту связку назвали DTSS (Dartmouth Time-Sharing System — Дартмутская система разделения времени).
Выгода вышла далеко за пределы кампуса. Университет превратился в региональный хаб: к DTSS по телефонным линиям подключались колледжи Новой Англии и даже обычные средние школы. К 1971 году сеть охватила пятьдесят учебных заведений, открыв доступ к «цифровому оракулу» для 13 000 пользователей.
Но амбиции DTSS не ограничились ролью «первого парня на деревне». Эта система сделала два царских подарка, которые навсегда изменили ДНК персональных компьютеров.
Первый — язык программирования BASIC.
Конечно, среди студентов встречались уникумы, способные думать на Ассемблере, но для большинства нормальных людей тот был чем‑то вроде древнешумерского. Кемени и Курц понимали: чтобы пустить за терминалы всех, нужен язык высокого уровня, абстрактный и дружелюбный.
Даже FORTRAN, тогдашний король науки и техники, грешил излишней загадочностью. Курц любил приводить в пример тамошний цикл:
DO 100, I = 1, 10, 2Поди разбери: порядок цифр — это 1, 10, 2 или все‑таки 1, 2, 10? И нужна ли там запятая, или компилятор просто обидится и уйдет в себя?
Профессора́ решили упростить правила игры. Руками своих самых талантливых студентов они создали язык, который не требовал дешифратора. Взгляните на тот же цикл в их исполнении:
FOR I = 1 TO 10 STEP 2Вместо математических ребусов — понятные английские слова. Синтаксис BASIC читался не как заклинание, а как обычное, человеческое предложение.
Вторым вкладом Дартмута стал сам «архитектурный чертеж» системы, который General Electric, повинуясь здоровому капиталистическому инстинкту, позаимствовала для своих нужд. Причем дважды.
Связка из GE‑235 и Datanet‑30 превратилась в коммерческий сервис GE Mark I, а более поздняя версия DTSS на базе GE‑635 легла в основу Mark II. К 1968 году торговля «цифровыми секундами» превратилась в бойкий рынок объемом в 70 млн долларов. Схема была проста: терминал подключался через телефонную сеть, а тарифицировался по времени — как за такси.
Львиную долю этого пирога — более 40% и десятки тысяч абонентов — держала GE, паразитируя (в хорошем смысле) на дартмутских идеях.
И здесь история делает поворот, достойный лучшей новеллы. Одним из платных подписчиков стала школа Lakeside в Сиэтле. Местный «Клуб матерей», вероятно, продав немало домашней выпечки, собрал средства на покупку терминала для доступа к системе GE.
Дамы просто хотели, чтобы у детей было все лучшее. Они и не подозревали, что, оплачивая счета за доступ к BASIC, по сути, финансируют рождение империи Microsoft. Ведь среди школьников, прилипших к этому терминалу, были восьмиклассник Билл Гейтс и десятиклассник Пол Аллен.
Маркетинговая машина General Electric, разогнавшая BASIC по своим сетям разделения времени, сработала эффективнее любого вирусного ролика. Популярность языка росла с такой скоростью, что игнорировать ее стало невозможно. Вскоре даже конкуренты — от либеральной DEC до застегнутой на все пуговицы IBM — были вынуждены сдаться и выпустить свои версии BASIC.
К 1970‑м годам, во многом стараниями GE, BASIC стал настоящим lingua franca — языком межнационального общения в мире интерактивных вычислений.
И тут вскрылась ироничная правда о человеческой природе. Итак, получен доступ к передовым вычислительным мощностям и универсальному языку программирования. О чем же больше всего мечтали пользователи? О сложных расчетах? О научных прорывах?
Как бы не так. Они жаждали игр.
Бесплатная миграция в Selectel
Начислим до 1 000 000 бонусов на два месяца. А наши инженеры подготовят план и поддержат на всех этапах миграции.
Культура игр
Куда бы ни проникал вирус интерактивности, следом за ним неизменно тянулся шлейф игромании.
Это касалось не только появления собственно компьютерных игр — первых робких пиксельных развлечений. Изменился сам дух общения с «железом». Пользователи вдруг обнаружили, что этот многотонный шкаф с мигающими лампочками — превосходная, хоть и безумно дорогая игрушка.
Процесс написания кода и диалога с машиной превратился из суровой производственной необходимости в чистое искусство, в самоцель. Решение «серьезных задач» отошло на второй план, уступив место главному — удовольствию от процесса.
Самым громким манифестом новой игровой культуры в раннем MIT стала битва рефлексов и силы воли под названием «Spacewar!»
PDP‑1 казался настоящим пришельцем из будущего. В то время как его собратья оставались слепыми ящиками, он щеголял двухмерным графическим дисплеем — круглым, завораживающим экраном на электронно-лучевой трубке.
Чтобы оценить масштаб чуда, нужно понимать: вплоть до середины 70‑х основным языком общения с машиной был сухой треск телетайпа. Такие устройства, рожденные для телеграфа, работали как дистанционные пишущие машинки: запрос отбивался — улетал по проводам — а ответ компьютера механически отстукивался обратно на бумагу.
PDP‑1, конечно, повезло с наследственностью. Благодаря своим корням в системе ПВО SAGE, он получил тот самый экран. Изначально задуманный для отслеживания суровых радарных меток, в руках хакеров он превратился в окно в открытый космос.
Хакеры из MIT уже успели «размять пальцы», создав несколько ранних игр и графических демок на старичке TX‑0. Но настоящий прорыв совершил человек, которого даже не было в штатном расписании университета.
Стивен «Слаг» Рассел, энтузиаст, просто ошивавшийся при лаборатории (то, что называется hanger‑on), создал первую версию «Spacewar!». Вдохновение он черпал в космических операх Э. Э. «Дока» Смита.
К февралю 1962 года игра обрела форму: два пилота управляли ракетами на экране, пытаясь превратить корабль соперника в облако космической пыли с помощью торпед.
Однако хакерское братство не умело останавливаться на достигнутом. Коллеги Рассела тут же набросились на код с улучшениями. Они добавили звездный фон — причем астрономически достоверный, соответствующий реальному небу! — поместили в центр экрана Солнце с работающей гравитацией, внедрили прыжки в гиперпространство для экстренного спасения и прикрутили счетчик очков.
Результат превзошел все ожидания. Вышла уже не примитивная поделка, а визуально завораживающая, напряженная дуэль, требующая отточенных рефлексов. Хакеры MIT были обречены: теперь их ночи проходили в бесконечных космических баталиях.
Зависимость «Spacewar!» от дорогого графического дисплея, конечно, сужала круг избранных. Но игра нашла новый дом в Стэнфорде, куда в 1962 году перебрался неугомонный Джон Маккарти, превратив университет в настоящий центр космических баталий. Свидетельства о бессонных ночах за игрой задокументированы даже в Университете Миннесоты.
В 1970 году Нолан Бушнелл, вдохновленный этой идеей, основал компанию по разработке видеоигр (сначала под мудреным именем Syzygy, а позже — легендарную Atari). Его целью было перенести университетскую забаву в народ, создав аркадную версию под названием Computer Space.
Эхо того первого взрыва звучало еще долго. Влияние «Spacewar!» ощущалось вплоть до 90‑х годов, когда Star Control и ее эпическое продолжение The Ur‑Quan Masters познакомили уже мое поколение геймеров с классикой жанра — бессмертной дуэлью двух кораблей на орбите смертоносной звезды.
Впрочем, подавляющее большинство пользователей мини-компьютеров, лишенных роскоши графического экрана, вовсе не чувствовали себя обделенными.
Игры на телетайпах, ограниченные сухим вводом и выводом текста, затягивали ничуть не меньше. Ассортимент развлечений простирался от примитивных «угадаек» до сложнейших стратегических баталий вроде шахмат.
Энтузиасты обменивались рулонами перфорированных по краю лент из рук в руки, но главным «дилером» развлечений выступало сообщество DECUS. Уже в первом выпуске их бюллетеня DECUSCOPE за 1962 год прозвучали дифирамбы «SpaceWar!», а в 1964‑ом в общедоступной библиотеке появилась простенькая игра в кости.
К ноябрю 1969 года игровой раздел каталога DECUS разросся до тридцати семи наименований. Там соседствовали простецкие «Виселица» и «Блэкджек» с такими серьезными вещами, как «SpaceWar!» и «The Sumer Game» — экономическим симулятором управления ресурсами в условиях бронзового века.
Зацените: каталог научных и инженерных приложений — то есть та самая «серьезная» причина, ради которой люди вообще покупали эти дорогие машины, — насчитывал всего пятьдесят восемь позиций. Разрыв был минимальным.
Игривое настроение выплескивалось не только в создание видеоигр. Хакеры из MIT писали тонны кода просто ради чистого удовольствия.
В их арсенале были генератор дребезжащей музыки и конвертер арабских цифр в римские. Вершиной самоиронии стали программы с говорящими названиями: «Дорогой настольный калькулятор» (чтобы считать простую арифметику на машине за 120 000 долларов!) и «Дорогая пишущая машинка» (для набора эссе).
Мысль о том, чтобы применять компьютер для какой‑то практической пользы или реального результата, посещала их далеко не всегда. Многие самозабвенно создавали инструменты для написания и отладки кода, даже не задумываясь, зачем они нужны, кроме как для самого процесса. Как гласила народная хакерская мудрость: «Процесс отладки зачастую куда интереснее, чем использование уже отлаженной программы».
По мере того как интерактивные вычисления мигрировали с элитарных мини-компьютеров в демократичные системы с разделением времени, менялся и портрет пользователя.
Среди новой волны энтузиастов становилось все меньше тех «технических гурманов», обладающих изысканным вкусом и навыками, чтобы получать эстетическое наслаждение от написания компиляторов или копания в отладчиках.
Зато порог вхождения упал: многие из этих новичков вполне могли набросать игрушку на BASIC. А уж играть в результат мог вообще кто угодно.
К 1970 году игры на BASIC стали доминирующей силой, главным культурным пластом цифровых развлечений. Хотя и не единственным: где‑то в параллельной вселенной Университета Иллинойса и Control Data Corporation процветала своя, особая субкультура вокруг системы PLATO.
И, как и в эпоху первых мини-компьютеров, балом здесь правил текст. Графические дисплеи все еще оставались экзотикой для избранных, поэтому почти все игры на BASIC полагались исключительно на силу слова и воображения.
Дейв Ахл, занимавший в DEC пост менеджера по образовательному маркетингу, придумал отличный ход. Он начал публиковать листинги игр на BASIC прямо в корпоративном рекламном бюллетене EDU.
Репертуар был пестрым. Кое‑что Ахл писал сам — например, знаменитую Hamurabi, свою версию той самой «Шумерской игры». Но многое присылали сами пользователи — школьники и студенты, добравшиеся до систем DEC в своих учебных классах.
Успех был настолько оглушительным, что в 1973 году DEC выпустила отдельный сборник — «101 компьютерная игра на BASIC» (101 BASIC Computer Games). Книга разлеталась как горячие пирожки, выдержав три переиздания.
Уходя из компании, Ахл совершил стратегически гениальный поступок: он мудро сохранил права на эту книгу за собой. В 80‑х, когда грянул бум домашних ПК, он продал более миллиона экземпляров новому поколению пользователей.
Хотя многие из этих игр были всего лишь цифровыми клонами привычных настолок или карточных колод, другие — вслед за «SpaceWar!» — прокладывали путь к совершенно новым, уникально компьютерным форматам развлечений.
Было и одно важное отличие: если «SpaceWar!» создавалась для дуэли, то большинство новых хитов предлагали соло-приключения. Компьютер здесь выступал в роли хранителя тайн: он прятал информацию, открывая пользователю новый мир по кусочкам, шаг за шагом, по мере исследования.
Взять, к примеру, «Прятки» (Hide and Seek) — простенькую забаву, написанную старшеклассниками, где нужно было искать людей на координатной сетке. Со временем эта идея мутировала в культовую «Охоту на Вампуса» (Hunt the Wumpus) — сложную игру на выживание в лабиринте, породившую бесчисленное количество подражателей.
Кроме того, диаграмма Венна, объединяющая компьютерных гиков и фанатов «Звездного пути», представляла собой практически идеальный круг. Неудивительно, что вскоре расцвел целый жанр стратегий по мотивам Star Trek.
Самую популярную версию — охоту на клингонов в случайно генерируемых секторах галактики — создал инженер Майк Мэйфилд. Изначально он написал ее для мини-компьютера Hewlett-Packard (HP) — предположительно, того самого, что стоял у него на работе.
Ведь DECUS были не единственными, кто практиковал шеринг кода. Star Trek Мэйфилда попал в библиотеку пользователей HP, оттуда добрался до Дейва Ахла, а тот уже перевел его на народный BASIC. Вслед посыпались новые версии, включая хит 1974 года — Super Star Trek от Боба Лидома.
Традиции сообщества BASIC невероятно ускорили эволюцию игровых серий по одной простой причине: каждая игра распространялась в открытом текстовом виде. Счастливчикам доставался физический носитель — бумажная перфолента или магнитная кассета, с которой код залетал в память компьютера по тем меркам молниеносно.
В противном случае — например, при покупке той самой книги Ахла, — предстояли часы утомительного ручного набора, чреватого опечатками и нервным тиком.
Но у этой медали была и золотая сторона: каким бы путем игра ни попадала к пользователю, он получал полный доступ к исходному коду. Его можно было читать, разбирать на винтики и — главное! — менять по своему усмотрению.
Хочется немного облегчить себе жизнь в Star Trek от Ахла? Нужно просто найти подпрограмму в строке 3790 и подкрутить урон на максимум.
Чувствуется прилив амбиций? В строке 1270 можно вписать в главное меню совершенно новую команду — например, «Произнести вдохновляющую речь перед экипажем».
![Фрагмент кода игры Civil War, симулятора, созданного старшеклассниками в Лексингтоне, штат Массачусетс, в 1968 году и включенного в книгу Ахла «101 компьютерная игра на языке BASIC». Набрать что‑то подобное на собственном компьютере требовало большого терпения [Ахл, «101 компьютерная игра на языке BASIC», с. 81].](https://habrastorage.org/r/w780/getpro/habr/upload_files/471/f5a/7db/471f5a7db28b1201c2b420bc63e7b4cf.jpeg "Фрагмент кода игры Civil War, симулятора, созданного старшеклассниками в Лексингтоне, штат Массачусетс, в 1968 году и включенного в книгу Ахла «101 компьютерная игра на языке BASIC». Набрать что‑то подобное на собственном компьютере требовало большого терпения [Ахл, «101 компьютерная игра на языке BASIC», с. 81].")
Примечание переводчика
Не все молодые читатели Хабра сразу поймут, почему так пляшут буквы на распечатке выше.
Мы видим фирменный почерк барабанного принтера. Процесс печати напоминал стрельбу по движущимся мишеням: массивный цилиндр с буквами быстро вращался, а молоточки ударяли по нему через ленту по бумаге, пытаясь «поймать» нужный символ на лету. Каждый электромагнит срабатывал с крошечной разницей в скорости — этим и объясняется некоторый разброс знаков по высоте.
Я застал такие. Только не помню, ходил уже тогда в школу или еще нет.:)
Пожалуй, самым плодовитым автором игр той эпохи стал Дон Даглоу. В 1971 году он «заболел» компьютером DEC PDP‑10, обнаружив терминал с разделением времени прямо в своем общежитии в колледже Помона, к востоку от Лос‑Анджелеса.
В последующие годы он выдал на‑гора впечатляющий список хитов: собственную версию Star Trek, бейсбольный симулятор, игру-исследование подземелий по мотивам Dungeons & Dragons и многое другое.
Такой марафон длиной в карьеру стал возможен благодаря тому, что Даглоу надолго пустил корни в Помоне, обеспечив себе бесперебойный доступ к машине. В общей сложности он провел там девять лет, последовательно меняя статусы: студент, аспирант и, наконец, преподаватель.
К началу 1970‑х тысячи энтузиастов, подобных Даглоу, открыли для себя удивительно податливый цифровой мир. Стоило лишь освоить правила игры, и компьютер превращался в бесконечный конструктор. Из этого цифрового «пластилина» можно было вылепить что угодно: хоть скрупулезную реконструкцию давно исчезнувшей древней цивилизации, хоть целую галактику, кишащую враждебными клингонами.
Однако большинству влюбленных в новые технологии повезло куда меньше, чем Дону Даглоу. Их держали на расстоянии вытянутой руки от объекта их страсти.
Студент, еще мог тайком пробираться к университетскому мейнфрейму по ночам. Но стоило получить диплом — и доступ закрывался навсегда. Оставались лишь компромиссы:
кто-то, скрипя сердцем, платил за аренду пары часов в неделю через сервисы разделения времени;
кто-то посещал общественные компьютерные центры — вроде того, что открыл Боб Альбрехт в Менло-Парке;
а кто-то, подобно Майку Мэйфилду, вынужден был выпрашивать у начальства разрешение задержаться после работы, чтобы поиграть на офисной машине.
Но все это были полумеры. Настоящей мечтой, идеей «фикс», стала мысль о собственном компьютере дома. Чтобы включать его не по расписанию, а по велению души. Именно из этой неутоленной жажды и родилась потребность в персональном компьютере.
Комментарии (112)
liutas4x4
13.12.2025 12:41Вот погрело, так погрело! Аж проглотил как доберман сырую печень.
Уж и не знаю сколько ночей в 80-тых просидел за Star Trek, Empire и Dungeons. На PDP-11/70, в RSX-11M.
А днем -- НИОКР, той же машиной крутил через крейт CAMAC микроподвижки юстировки лазеров накачки оптоволокна. По работе в НИИ. И на кафедру был свободный доступ к такой же машине -- я ее оживил и имел ключи и право на любое время суток.
А таким вот барабанным принтером (АЦПУ-128?) по ночам печатал самиздат с лент для народа. И "редактировал" task images, -- подменял сообщения программ и утилит на русский, для коллег, которые "не волокли" English. Некоторые ключи BRU> и TED>, основные команды MCR> помню по сей день.
Как было обидно, когда DEC умер... Пойду чайку заварю, надо выдохнуть.
CatAssa
13.12.2025 12:41У нас один энтузиаст перелопатил исходники RSX-11M с единственной целью перевести сообщения на русский, в итоге узнал, что внутри ОС использовали кодировку RADIX50, которая не предусматривала букв, отличных от A-Z... :)
SIISII
13.12.2025 12:41Интересно, как этого можно было не знать, если ты программист, писавший под RSX-11?.. Имена файлов -- тоже RADIX-50, например.
CatAssa
13.12.2025 12:41Они "внутри" в RADIX50, а если пишешь на Фортране, то вполне себе ASCII. И - вот в т.ч. такие у нас программисты были в советской армии.
checkpoint
13.12.2025 12:41Фортране, то вполне себе ASCII
А не в EBCDIC ли ?
SIISII
13.12.2025 12:41EBCDIC -- только на ЕС ЭВМ (Системе 360), на ПДП-11 -- RADIX-50 и ASCII (разные вариации КОИ-7/8). В частности, если из Фортрана дёргать системные сервисы с именами файлов и задач, там надо, есно, в RADIX-50 было кодировать; это, насколько помню, СМовская (ДЕКовская т.е.) версия Фортрана предусматривала.
checkpoint
13.12.2025 12:41Я помню что EBCDIC только на IBM/ЕС. Я не помню чтобы для СМ/PDP писали на фортране. :)
SIISII
13.12.2025 12:41Фортран -- основной язык разработки для PDP-11 (под RSX-11, во всяком случае). Для него даже сделали подпрограммы, чтобы можно было дёргать системные сервисы (которые, есно, были рассчитаны на вызов только на ассемблере). На Фортране под неё у нас было написано дофига всего, причём нередко ещё на СМ-4 с использованием команд FIS -- из-за чего на СМ-1420 и СМ-1600 приходилось использовать их эмулятор (эти машины имеют полноценный FPU, а значит, FIS у них отсутствует).
CatAssa
13.12.2025 12:41О, на Фортране для СМ-4 столько было написано! На Fortran-4 из RSX-11M, помню, летели исключения при попытке работать с float числами (не нашей СМ-4 не было сопроцессора), так написали программку, которая обрабатывала такие исключения, эмулируя нужное оборудование, медленно , да. А Фортран из ОС-РВ-СМ такое умел из коробки, но сам по себе имел худшие возможности по сравнению с Fortran-4 из RSX-11M. Ещё, был пакет RATFIV, который обрабатывал исходники т.н. структурированного Фортрана, на выходе генерировал F4 исходники.
liutas4x4
13.12.2025 12:41Хе. Там все просто как... В радиксе использовалить прописные и строчные буквы. Очумельцы из СКБ ВМ Сигма, Вильнюс, пропатчили до прописных онли на двух языках. Для серии СМ, что было практически копией PDP-11.
Когда система нарывалась на кириллицу, то получались перлы типа "NАЖАЛ АТТАШЕ" или "IНЖАЛИД ОПЕРАТИОН."
CatAssa
13.12.2025 12:41В радиксе использовалить прописные и строчные буквы.
Только прописные в RADIX50.
И, некоторые сообщения кодировались в RADIX50, некоторые в ASCII. Потому что-то получилось русифицировать, а что-то не получилось.
SIISII
13.12.2025 12:41Ошибаетесь, как уже написали. Инжалид дежице и прочая -- это замена строчных английских на большие русские в ASCII и т.п. манипуляции. В RADIX-50 -- всего 40 символов, 50 в его названии -- это их число в восьмеричной системе.
liutas4x4
13.12.2025 12:41Давайте так: radix там был или ascii я не уверен что знал. До русификации сигмовцами она печатала английским в двух регистрах. После русификации я перебивал тексты прямо в задачах, в .task и только капслоком. И тем же занимался Костя Рождественский, через дорогу от нашего НИИ. Тот вообще гений Кремниевой Долины, и давно. Найти бы....
checkpoint
13.12.2025 12:41Большинство заказчиков Altair не носили фенечек и не жили в коммунах.
Автор пытается категоризировать людей по внешнему виду и в этом его ошибка. В Bell Labs, Томпсон, Риччи и прочие тоже не носили фенечек. Да чего там, обыденная для них форма - пиждаки и галстуки. Тем не менее, ОС Unix которую они создали (и попутно язык программирования "Си") - что это как не бунтарство и взрыв свободы ? И технари из Беркли, которые сделали Unix опенсорсным и распространили по всему миру, тоже фенечек не носили, а имели вполне цивильный по тем временам прикид. Дело не в одежде, не во внешнем виде и не в месте работы, а в мышлении и разделяемых ценностях и идеалах. А они были повсеместно такими, что пора освободить компьютер, вычисления и программирование от оков жадных капиталистов. К сожалению, их идеалы мы благополучно слили в соцсетях.
PS: В молодости я предпочитал ходить в белой наглаженной рубашке, в черном пиджаке и в галстуке. Тем не менее, среди моих друзей было полно хайрастых рокенрольщиков, толкиенистов обвешенных феничками, и прочих лиц "очень странной наружности" (таких кстати сейчас на улицах и не встретишь больше). И на рок концерты я тоже в таком прикиде ходил - такой вот у меня был свой стиль протеста. А занимался я продвижением свободы электронного общения - содержал узел сети Fidonet и BBS, разматывал Интернет по городу, через BBS давал бесплатный доступк к Интернет тем, кто этого себе не мог позволить (dialup доступ в 90-х был по карману далеко не всем), продвигал опенсорс.
zVlad909
13.12.2025 12:41Тем не менее, ОС Unix которую они создали (и попутно язык программирования "Си") - что это как не бунтарство и взрыв свободы ?
Против чего бунтарство? Против ИБМ? Чем им мещала ИБМ делать то что они делали? Ничем. А распростронение Unix вовсе не заслуга Ричи и Томпсона, а простое стечение обстоятельств. Их было много и ни одного объективного.
ИБМ поддерживал и поддерживает Юникс и TCP/IP во всех своих своих ОС. Хотите Линукс на МФ - пожалуйста.
В молодости я предпочитал ходить в белой наглаженной рубашке, в черном пиджаке и в галстуке.
И это Вы подписываете под моим сообщением "Вот и пиджаки подтянулись?". Я никогда пиджаков не любил, а галстуков тем более. Если и носил пиджаки то без галстуков и то как куртку.
В Вашем профиле написано:
Юниксоид с 1996 года ....
С 2006 года я системный программист z/OS (До этого был фанатом виртуальных машин на МФ, до чего Юниксы (HP-UX, Sun Solaris) доросли только в начале нулевых. Юникс (USS) в z/OS это неотъемлемая часть наряду с MVS и работатьь мне приходилось на равных с той и другой. Кроме того zLinux. Юникс в z/OS существенно облагорожен и снарежен мэйнфрэймовскими возможностями, отсутствующими в нативном Unix. Это касается секьюрити и управления рабочей нагрузкой (workload). А всё что есть в нативном Юниксе есть и в USS (Unix System Services). Так что можно быть Юниксоидом и на ИБМ МФ, в z/OS.
Работать с Unix и Linux не велика проблема, но с MVS, как ОС, гораздо приятнее. А z/OS поднимает эту парочку до недостижимых высот в области ОС, недоступных просто Unix и Linux.
checkpoint
13.12.2025 12:41Против чего бунтарство? Против ИБМ? Чем им мещала ИБМ делать то что они делали? Ничем. А распростронение Unix вовсе не заслуга Ричи и Томпсона, а простое стечение обстоятельств. Их было много и ни одного объективного.
История создания ОС Unix хорошо описана в мемуарах Кернигана. Ей предшестововало вполне определенное событие и общая усталость программистов того времени от монстроидальных "пакетных" систем.
SIISII
13.12.2025 12:41Интересно, что можно сказать о современных монстроидальных гуёвых системах типа Линуха и Винды? :)
zVlad909
13.12.2025 12:41История создания ОС Unix ...
Мне известна история создания Unix. Кто устал от монстроидальной "пакетной" системы и от какой? Поведайте сами чтобы не было причины в чем то обвинять меня.
Flammmable
13.12.2025 12:41Автор пытается категоризировать людей по внешнему виду и в этом его ошибка.
Я полагаю, что автор оригинального текста полемизирует с теми, кто продвигает мысль, что ПК создали хиппи-социологи с фенечками и прочие популяризаторы, да евангелисты.
Поэтому он акцентирует внимание, что нет - настоящие создатели были не недоученные гуманитарии с Вудстока, а немного иные типажи.
checkpoint
13.12.2025 12:41Дочитал до конца. Статья хороша, спасибо за перевод.
Уж не знаю, автор ли, или переводчик, но слог сильно похож на Стивена Леви. :)
victor_1212
13.12.2025 12:41действительно Levy "Hackers" есть среди ссылок оригинала, большинство недостатков этого перевода недостатки оригинала, его автор Chris McDonald стремится к читабельности , а не точности, типа излагает как сам понимает, его популярные книги "The Switch", "The Backbone" это уровень газеты или журнала
zVlad909
13.12.2025 12:41Статья (перевод) яркий пример бессилия и комплекса неполности из разряда "назло мамке отморожу уши" и "мимо тещеного дома я без шуток не хожу"..
Многократное и многославное порицание "пакетной обработки", используемой на всех более менее мощных машинах 50-х, начале 60-х в виду отсутствия устройств диалогового общения и доступное только на малых машинах в монопольном их испльзовании, разбивается об нытье в середине статьи про то что даже на подросших малых машинах монопольное их использование оказалось нонсенсом и привело с коллетивному использованию, которое на ИМБ МФ к тому времени уже стало нормой с появлением терминалов для МФ (IBM 3270) и SNA.
И вот абзац из статьи:
Слово «совместимая» здесь было ключевым дипломатическим маневром. Оно означало, что новой системе не нужно свергать старую власть: CTSS мирно уживалась на одном IBM-мэйнфрейме с традиционной пакетной обработкой, действуя параллельно, как соседи на кухне в коммуналке.
Кстати TSS/360 в отличии от заявленого в статье изничтожении вовсе не была уничтожена, а нашла свое продолжение в других продуктах в том числе того же DEC:
The IBM Time Sharing System TSS/360 is a discontinued early time-sharing operating system designed exclusively for a special model of the System/360 line of mainframes, the Model 67. Made available on a trial basis to a limited set of customers in 1967, it was never officially released as a supported product by IBM. TSS pioneered a number of novel features, some of which later appeared in more popular systems such as MVS. TSS was migrated to System/370 and 303x systems, but despite its many advances and novel capabilities, TSS failed to meet expectations and was eventually canceled. The Resident Supervisor of TSS/370 was used as the basis for a port of UNIX to the IBM mainframe.[1] TSS/360 also inspired the development of the TSS/8 (TSS/8 is a discontinued time-sharing operating system co-written by Don Witcraft and John Everett at Digital Equipment Corporation in 1967. DEC also referred to it as Timeshared-8 and later the EduSystem) operating system.[2]
Короче это всё "Бунт против ИБМ", "Голубой гигант", "Застегнутые на все пуговицы бюрократы" не более чем нытье пигмеев-неудачников, пытающихся такими пасквильными статьями оправдывать убогость своих достижений. DEC "сдулась" в 1998 (Compaq, HP). VAX, MicroVAX, VMS все это ушло в небытие.
А ИБМ мэйнфрэйм, их флагманская ОС - z/OS, в компании с z/VM, zLinux и всеми другими "современными" (в ковычках потому что это все чисто коммерческие исхищрения, пользующиеся, правда, популярностью) технологиями продолжает существовать и развиваться.
Вот вам и бунт, буря в стакане.
Да, про пакетную обработку. Пакетная обработка тоже жива и используется на "современных" платформах повсеместно (batch processing). В самом деле, а как еще может быть огранизована производственная система обработки данных по правилам и графикам бизнесов. Не сидеть же оператору за экраном и вручную запускать программы по графику.
Терминал IBM 2260 появился в 1964 году. С этого года ИБМ мэйнфрэйм перестал быть (собственно и ИБМ мэйнфрэйм был аннонсировал в том же году) чисто машиной пакетной обработки и стал машиной для смешанной работы. TSS/360 и виртуальные машины появились в 1967 году. О чем тогда вообще идет речь в этой статье? О своем дилетантизме и отсутствии кругозора, зацикленности?
Стоило было заниматься переводом этого бреда? Думаю что нет. Ставлю минус, хотя и превержен историческим статьям про ИТ. Но это явно тенденциозная статья, необъективная.
Переводчику респект. И совет лучше подбирать тексты для переводов. Например, есть очень подробная книга о том как создавалась VM/370.
checkpoint
13.12.2025 12:41А вот и пиджаки подтянулись... ;)
SIISII
13.12.2025 12:41Не обязательно пиджаки. Я вот тоже не согласен с таким ярким восхвалением DEC и порицанием IBM. Да, их машины очень разные -- но они попросту не пересекаются в реальном мире и решают совершенно разные задачи. Даже топовые VAXы и близко не подошли к возможностям мэйнфреймов по обработке крупных баз данных и тому подобным задачам, на которых держится крупный и особо крупный бизнес (и не только бизнес). Но таки да, в области диалоговой работы мэйнфреймы, скажем так, весьма неудобны -- но это просто другая область, и человек разумный и не страдающий фанатизмом будет выбирать то, что нужно под конкретную задачу -- и нередко это будет комбинацией нескольких разных технических средств, где каждая машина играет свою роль.
zVlad909
13.12.2025 12:41Но таки да, в области диалоговой работы мэйнфреймы, скажем так, весьма неудобны -- но это просто другая область,
Привет, коллега.
Поставил тебе плюсик, но хочу не согласиться в том что МФ хоть на йоту уступает каким либо другим диалоговым системам с терминалами.
Наоборот IBM 3270 это не терминал в понимании терминалов Юникс ориентированных систем. SSH - ха-ха-ха - эмуляция пишущей машинки. А были и графические терминалы. Вообщем то и есть.
Зорошая система ни в чем не может уступать системам так себе.
Недавно менял шины в Costco. Приемщик заказов как водится работает с компьютером и на экране привычный GUI. Но в какой момент картинка поменялась и я узнал родной 3279. Конечно он мог бы быть тенминалом i Series, впрочем почему мог бы, так оно и есть:
Costco famously runs its core retail and logistics on powerful, reliable IBM i (AS/400) systems ....
The IBM 3270 "i Series" likely refers to the modern evolution of the classic IBM 3270 Information Display System, a family of "green screen" terminals for mainframes, now integrated into the IBM i Series .
Картинки с экранов DEC VXT2000, которые я смог найти, удручающе просто.
На сегодня есть масса софта для ОС мэйнфрэйм в конфигурации клиент-сервер использующих GUI. Новых специалистов обучают использовать этот софт в работе с МФ, а не 3270. Только такие как я еще используют 3270 и никогда не будут полагаться на GUI варианты.
SIISII
13.12.2025 12:41Хотя диалоговые системы на мэйнфреймах были, но они менее удобны и гибки по сравнению с тем, что можно было сделать (и делалось), скажем, на PDP-11. Но причина здесь в разной "идеологии" железа и ориентации на разные классы задач.
Вы, надо полагать, в курсе, но многие читатели вряд ли представляют специфику IBMовских терминалов по сравнению с более привычными DECовскими и прочими, поэтому ниже кратко поясню.
В "обычных" терминалах -- скажем, VT52 и VT100, которые были основными для PDP-11 и поддержка которых тянется до сих пор (скажем, в PuTTY есть эмуляция VT100) -- каждое нажатие кнопки на клавиатуре вызывало отправку байта данных на машину. Та его принимала, программно обрабатывала и выдавала терминалу ту или иную команду -- в частности, могла просто вернуть этот байт, и тогда терминал печатал эту буковку на экране и сдвигал курсор. Естественно, были и команды для управления положением курсора и выполнения ряда других операций (ESC-последовательности всякие разные).
Терминалы же IBM работали в известной степени подобно заполнению формочек в современных браузерах. Машина изначально отправляла терминалу полное изображение экрана, которое включало как видимые символы, так и коды, управляющие разделением экрана на поля. Пользователь вводил, что ему нужно, в определённых полях, при этом вводимые символы попадали напрямую в видеопамять, но в машину не передавались -- т.е. ввод и редактирование текста выполнялось терминалом полностью автономно. И лишь при нажатии некоторых клавиш (ВВОД и функциональные) терминал дёргал машину. Та считывала код нажатой клавиши плюс, если нужно, полное или частичное содержимое видеобуфера, после чего обрабатывала всё это и отравляла на терминал результат.
Таким образом, ДЕКовские терминалы отвлекали машину при каждом действии пользователя, а ИБМовские -- только в редких случаях, благодаря чему ПДП-11 начинала тупить, если одновременно был активен десяток терминалов, и даже с одним-единственным, если параллельно выполнялось что-то, занимающее много времени процессора (компиляция, например). А вот мэйнфрейм, даже слабый, на "обычном" редактировании не тормозил по той причине, что терминал вообще его не отвлекал и делал всё автономно -- из-за чего к нему можно было подключить намного больше терминалов. Конечно, отправив ему запрос, приходилось ждать ответа, причём время ответа зависело от того, сколько пользователей одновременно отправили свои запросы, но вот ситуации с тяжёлыми тормозами при правильно выставленных приоритетах возникали реже -- и особенно на слабых машинах (там, где ПДПшка просто тонула в потоке запросов прерываний от терминалов, мэйнфрейм имел этих прерываний буквально в 100-1000 раз меньше, а соответственно, мог намного эффективнее их обрабатывать). Но недостаток тоже очевиден: очень большая часть функционала определялась железом терминала и не могла быть переопределена, в то время как на ДЕКовском терминале -- полная гибкость, ведь за всё отвечает программа, выполняемая на самой ПДПшке.
checkpoint
13.12.2025 12:41Главное отличие DEC-овской техники от IBM-овской было не в техническом плане, и не в том как были устроен терминальный ввод. Мэйнфрэймы IBM и прочих подобных производителей стоили страшных денег, более того, они даже не продавались, а сдавались в долгосрочную аренду с сопровождением и т.д. При таком подходе любые действия с отоклонением от инструкции могли рассматриваться производителем как нарушение "гарантии" и сятие системы с обслуживания. Поэтому всякого рода эксперименты на таких машинах категорически не приветствовались руководством эксплуатирующей организации. Техника DEC, напротив, была во много раз дешевле, а эксплуатант был собственником системы - мог делать с ней всё что заблагорассудиться. Именно это и привело к появлению ОС Unix. У Кернигана это четко указано.
В СССР ситуация была иная. Отечественная линейка ЕС ЭВМ которая являлась клоном IBM S/360 и S/370, не накладывала подобных ограничений. В каждом ИВЦ, как правило, были люди которые могли разобрать машину "по косточкам" и собрать вновь из того "что бог послал" (дефицит компонентов был даже на ИВЦ), эксперименты с машиной в целом не возбранялись, если это не мешало основному процессу. И тем не менее, я хорошо помню, что инженеры на ВЦ, в котором я работал, любили СМ-1420 (советский клон PDP-11) и терпеть не могли ЕС-ки. СМ-ку можно было быстро загрузить в нужную ОС чтобы поэкспериментировать - хочешь в однозадачную/однопользовательскую RT-11 (РАФОС), хочешь в многопользовательскую RSX-11 (ОСРВ) или даже Unix (ОС ДЕМОС). На загрузку СМ-ки уходило 5-10 минут. В то время как перезагрузка ЕС-ки это целый ритуал и локальная трагедия. Очевидно, что СМ (PDP) была более пригодна для исследований и равлечений пытливых умов.
SIISII
13.12.2025 12:41Вообще-то, RSX-11 на СМ-1420 грузилась несколько секунд, а не 5-10 минут -- по сути, скорость загрузки лимитировать скоростью дисков (нужно было прочесть в ОЗУ образ системы весом около 248 Кбайт; дальнейшая инициализация была почти мгновенной).
ОС ЕС на ЕС-1035, т.е. на очень медленной машине, грузилась пару минут, если оператор не тупил с ответами на тупые вопросы системы. Правда, потом ещё надо было запустить, например, Примус -- ещё порядка минуты-двух. В общем, за пять минут загрузить и начать работать было возможно.
Но что экспериментировать на ПДПшках было легче, это точно. Впрочем, мне это не мешало вовсю развлекаться на ЕС-1035, особенно в третью смену, когда никого не было, кроме дежурного инженера (спящего) и меня.
checkpoint
13.12.2025 12:41Я помню, что ЕС-ку чтобы загрузить требовалось несколько человек и всегда это сопровождалось каким-то шаманством на час, а то и на весь день (то диски сбойные, то контроллер канала какую-то неизвестную ошибку выдаст). СМ-ка загружалась в одинокого, с диска или с ленты, за считанные минуты. Если не ошибаюсь, там надо было еще код загрузчика руками вбить, чтобы он считал boot sector в память и передал ему управления, на это больше всего времени и уходило.
Впрочем, мне это не мешало вовсю развлекаться на ЕС-1035, особенно в третью смену, когда никого не было, кроме дежурного инженера (спящего) и меня.
Я же говорю, на советских ВЦ с машиной можно было экспериментировать. На западе был совсем другой подход. И вся статья, собссно, об этом IBM-овском
ГУЛАГеvendor lock-е.
duselguy
13.12.2025 12:41Перезагрузка СВМ на ЕС 1060 занимала меньше минуты и выполнялась оператором. Это время - "о малое" от времени, пока оператор добредёт до машинного зала и нажмёт на кнопку, и "о малое" от времени загрузки какой-нибудь OS/VS1 в виртуальной машине. На производстве (система Экспресс на спарке ЕС 1045) система (слепок памяти) грузилась 'мгновенно'.
checkpoint
13.12.2025 12:41На том ВЦ где я работал эксплуатировалась ЕС-1066 и её перезапуск был целым ритуальным действием. Возможно, в теории, она и могла бы загрузиться "мгновенно", если бы не куча периферии и частых проблем с ней. Для работников ВЦ перезапуск машины всегда был локальной трагедией. На этой машине, кстати, работала система продажи авиабилетов "Сирена", коммуникационным контроллером для которой выступала СМ-ка с кучей модемов.
Я понезнанию как-то полностью завесил машину своей простой программой на FORTRAN-е. Сейчас уже не скажу как это случилось (помоему это было что-то вроде
10 GO TO 10), я тогда был юн и неопытен, но машину пришлось запускать с холодного старта, кипежу создал прилично. :)duselguy
13.12.2025 12:41"Я по незнанию как-то полностью завесил машину своей простой программой на FORTRAN-е."
Не верю (C)
Этого не может быть, потому что этого не может быть никогда (C)checkpoint
13.12.2025 12:41Ну да, ну да. ;) Проблема с холостым вечным циклом по сей день не имеет решения в современных ОС (Linux, Win). Запустите такую же программу на одноядерной системе - и конец. Но я не утверждаю что это было именно так, может быть прога записала чего лишнего куда не надо (в канал I/O), но машина стала сильно тупить, отзыв на консоле оператора был с минуту. Пришел начальник ВЦ и приказал машину ребутить.
SIISII
13.12.2025 12:41Бред полный. Никакого конца не будет, многозадачная ОС всегда сохраняет свою работоспособность, так что для оператора нет никакой проблемы прибить такую программу.
Записать "в канал" Ваша программа тоже ничего не могла -- для этого она должна работать в режиме супервизора, а в него просто так не переключишься (собственно, официально вообще нельзя, неофициально -- можно с помощью недокументированной макрокоманды MODESET, но и эту лазейку в поздних версиях прикрыли, хотя я и не помню, была она закрыта в наших клонах ОС/360 или нет). Ну и, опять-таки, и "запись в канал", и МОДЕСЕТ доступны только на ассемблере, никаких языков высокого уровня.
duselguy
13.12.2025 12:41ЕМНИП: MODESET (SVC107) не было; когда появилась, требовался AC=1 для редактора связей. Была лазейка (которую активно эксплуатировали) в аппендиксе канальных программ.
SIISII
13.12.2025 12:41Была такая, да -- но это, опять-таки, только на ассемблере можно использовать, из Фортранов-Алголов-Коболов и даже ПЛ/1 на столь низкий уровень выхода не было (прямого выхода; понятно, что можно написать ассемблерную обёртку, которая вызовет подпрограмму, написанную на языке высокого уровня).
duselguy
13.12.2025 12:41Можно в обе стороны.
Applications with COBOL and assembler
Last Updated: 2025-06-12
https://www.ibm.com/docs/en/cobol-zos/6.5.0?topic=appendixes-applications-cobol-assembler
zVlad909
13.12.2025 12:41ЕМНИП: MODESET (SVC107) не было; когда появилась, требовался AC=1 для редактора связей.
А также APF авторизацию библиотеки в которую программа с SVC 107 будет положено. А это означает что в дело должен быть включен системщик.
Была лазейка (которую активно эксплуатировали) в аппендиксе канальных программ.
Что за лазейка?
duselguy
13.12.2025 12:41Да, APF и AC(1)
EXCP -> аппендикс получал управление в режиме супервизора (ЕМНИП). Это были дела давно минувших дней времён MVT. P.S. Я с EXCP не очень, только на уровне понимания/правки цепочек канальных команд.
zVlad909
13.12.2025 12:41Насколько я понимаю EXCP (Execute Channel Program) не требует каких специальных авторизаций. Канальная программа все равно проверяется супервизором ввода-вывода и никакую херню не пропустит, а также проверит права запустившего программу пользователя на те ресурсы которые будут вовлечены в такой процесс ввода-вывода.
Выполнение EXCP предполагает создание и заполнение всех пологающихся (DCB, etc...) и требуемых системой управляющих блоков, а также шаг открытия - .OPEN. Т.е. фактически EXCP это то что в методах доступа тоже происходит и чем завершается выполнение обращения к любому другому методу доступа, которые не требуют больших уровней чем есть.
Ну и конечно поскольку EXCP это макро, программа должна быть написана на Ассемблер. Или это будет подпрограмма вызываемая из языка высокого уровня. PL/I, Fortran, Cobol. etc...
И на ВМ можно подготовить, даже в ручную, канальную программу, CCW и выполнить команду SIO (Start I/O). Результат будет зависить от того как это воспримет менеджер виртуальных машин - CP (Control Program).
Про аппендикс к канальной программе я не понял. Нет я писал канальные програмы, но без аппендиксов и без лазеек (куда? зачем?).
SIISII
13.12.2025 12:41Аппендиксы -- это подпрограммы, вызываемые супервизором в определённые моменты прохождения запроса ввода-вывода через супервизор. В частности, если это аппендикс PCI, он вызывается каждый раз, когда выполняющаяся в данный момент канальная программа, для которой он указан, вызывает программно-управляемое прерывание (PCI). Обработчик прерываний ввода-вывода, увидев, что причиной прерывания послужило PCI и что для данной канальной программы указан аппендикс PCI, немедленно вызывает этот аппендикс. Таким образом, сей аппендикс вызывается и работает в режиме супервизора с нулевым ключом защиты и с запрещёнными прерываниями -- фактически, он выполняется как часть супервизора ввода-вывода, но при этом его предоставляет системе прикладная программа, выдавшая EXCP.
Насчёт других аппендиксов я не помню, выполняются ли они в состоянии "супервизор" с нулевым ключом или в состоянии "задача" и с её ключом.
duselguy
13.12.2025 12:41В состоянии супервизора. Долго гуглил по appendix, а надо было по appendage :-)
Задал вопрос одному из гуру I/O, так как в описании IBM для аппендикса дыры (ака лазейки) не видно.
От ИИ Гугла:
Supervisor Mode: The appendage ran in Supervisor Mode because it manipulated critical system structures and interacted directly with hardware channels.
zVlad909
13.12.2025 12:41Ок. Спасибо. Напомнили. Вспомнил про эту возможность канальных команд CCW. Это достаточно высокий уровень программирования ввода-вывода до которого у меня не было нужды доходить.
На Виртуальных Машинах это было некоторого рода проблемой. Оттуда я об этом и знал. Вот нашел на Гугл некоторое блеяние подобрав правильные слова:
The IBM mainframe concept of Program Controlled Interruption (PCI) relates to how I/O devices signal completion or issues (interrupts) to the CPU, managed by Channel Programs (sets of commands for I/O channels), often within z/VM (a hypervisor) where guest OSes (like Linux or z/OS VMs) handle these device interactions, using specific commands to control channels and manage virtual hardware, but it's a low-level hardware/software interface for device management
zVlad909
13.12.2025 12:41Таким образом, сей аппендикс вызывается и работает в режиме супервизора с нулевым ключом защиты и с запрещёнными прерываниями -- фактически, он выполняется как часть супервизора ввода-вывода, но при этом его предоставляет системе прикладная программа, выдавшая EXCP.
А вот тут Вы, извините, написали какую то лажу.
Все канальные программы, включая аппендиксы, запускаются "с нулевым ключом защиты", а точнее в состоянии супервизор. И вовсе не с запрещенными прерываниями. С запрещенными прерываниями выполняются как правило программы восстановления от машинных ошибок.
И вообще. Канальные программы выполняются каналами, запрещенные прерывания и состояние супервизор это про центральный процессор. Конечно канал сожет быть запущен только из состояния супервизор командой SIO. Но выполнение канальной программы вовсе не супервизором ввода-вывода делается, а каналом - компьютером ввода-вывода. Автономно и независимо, до того момента пока канальная программа не завершилась или не появилась в канальной программе CСW с битом PCI, бит 36, которой вызывает прерывание ввода-вывода для CPU.
Все что представляет прикладная программа с EXCP проверяется супервизором ввода-вывода прежде чем выполнение прерваной канальной прграммы продоолжится (или начнется выполнение другой программы канала (аппендискса). Тут мои знания о вводе-выводе заканчиваются потому что не было опыта).
Чувствуется мне что и у Вас есть дефицит опыта в области программирования ввода-вывода на МФ, которую мы обсуждаем. Где-то. что-то слышали и как-то поняли. Если я не прав, попробуйте меня переубедить.
SIISII
13.12.2025 12:41Все канальные программы, включая аппендиксы, запускаются "с нулевым ключом защиты", а точнее в состоянии супервизор. И вовсе не с запрещенными прерываниями. С запрещенными прерываниями выполняются как правило программы восстановления от машинных ошибок.
Извините, но лажа таки у Вас :)
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-е годы не очень способствовали работе на одном месте). Так что, как работает ввод-вывод на мэйнфреймах, я знаю очень неплохо и на уровне программиста, и на уровне внутренностей процессоров и каналов, и на уровне сигналов интерфейса ввода-вывода, хотя некоторые детали, вероятно, подзабылись. Вот в устройства управления (контроллеры) тех же дисков я никогда не лез, т.е. с их работой знаком лишь со стороны программиста, но не электронищка.
duselguy
13.12.2025 12:41По терминологии и не только:
Канальная программа - это цепочка команд CCW, которая исполняется процессором. Она часть программы (может быть в её теле или построена в динамический памяти на лету). Что делает канал - другая история.
Если программа выполняется в режиме супервизор, то она может получить нулевой ключ одной машинной привелигерованной командой (и поиметь доступ к любой памяти) .
SIISII
13.12.2025 12:41Канальная программа -- это цепочка CCW, которая выполняется каналом ввода-вывода, почему, собственно, она и называется канальной программой. Процессор её формирует в основной памяти, заносит адрес первого CCW в CAW, а затем запускает канал на выполнение этой канальной программы с помощью команды SIO. Далее выполнение канальной программы осуществляется каналом без участия процессора, но последний может "на лету" модифицировать канальную программу.
Программа в режиме "супервизор" действительно может поменять собственный ключ, загрузив новое PSW. Но, пока она работает с ненулевым ключом, на неё распространяется та же защита памяти, что и на программу в режиме "пользователь".
zVlad909
13.12.2025 12:41Маленькая поправка. Не CAW, а CSW. Я работаю над Вашим большим сообщением. Это возьмет время. Во многом Вы правы (может даже во всем. У нас не должно быть разногласий). Но подробности позже.
SIISII
13.12.2025 12:41CSW -- слово состояния канала, оно записывается каналом при прерывании ввода-вывода или при выполнении команд ввода-вывода вроде SIO и TIO, если у канала к тому времени есть информация для сохранения, относящаяся к адресуемому устройству, при этом будет установлен код условия 1 (а запуск операции ввода-вывода, если это была SIO, не произойдёт).
При запуске же ввода-вывода по SIO адрес канальной программы помещается в адресное слово канала -- CAW. Туда же помещается ключ, с которым канал будет осуществлять обращения к основной памяти. Адрес канала и устройства, к которым относится команда SIO, задаётся в ней самой.
zVlad909
13.12.2025 12:41Вы правы. Я по помяти тоже так и думал, но решил проверить у ИИ и вот что он ответил на запрос "CAW mainframe IBM":
"CAW" on an IBM mainframe likely refers to either the Common Work Area (CWA) in CICS environments
Конечно CAW - Channel Address Work. Как я мог так опозориться. Давно этим занимался, в конце 80-х последний раз.
Кстати на запрос "caw mainframe ibm input output" ИИ дает:
The term "CAW" in the context of IBM mainframes likely refers to the Channel Address Word (CAW), a critical component of the input/output (I/O) architecture.
zVlad909
13.12.2025 12:41Извините, но лажа таки у Вас :)
Согласен в отношении вот этой моей фразы: "Все канальные программы, включая аппендиксы, запускаются "с нулевым ключом защиты", а точнее в состоянии супервизор." Прочитал утром в Вашем сообщении и подумал: кто ж это написал. Оказалдось я.
Этот ключ канальные программы используют при своих обращениях к памяти, и он обычно не равен нулю (чтобы канальная программа, относящаяся к одной задаче пользователя, не смогла залезть в память ядра или в память раздела другой задачи).
С ключами в архитектуре Z не все так просто. Ключей защиты ысего 15 плюс нулевой. При том что ключи 1-7 используются управляющей программой (BCP, ядро) и подсистемами типа CICS, DB2. Процессов конечно же много больше. Иными словами ключи (всего семь) используются для защиты в пределах одного адресного пространства.
Не хотелось бы сильно залезать в дебри, но вот что ИИ дает по поводу защиты памяти от канальных програм:
Key-Controlled Protection: Memory keys prevent unauthorized access to storage, but older methods didn't stop channel corruption. Modern features (like EDAT-1 (Enhanced DAT)) provide better protection, but the channel subsystem still interacts with memory at a fundamental level.
Конечно в CSW есть ключ защиты и он используется как обычно. Но это в рамках одного адресного пространства. Другие пространства защищены EDAT-1.
Кстати есть два формата CCW:
Format-0 CCWs: Use a 24-bit data address and require the CCWs themselves and the associated I/O buffers to be in storage below 16 MB.
Format-1 CCWs: Use a 31-bit data address, allowing access to storage above the 16 MB line (up to 2 GB).
Я полагаю Вы понимаете что я имею в виду.
При выполнении программ процессора ключи защиты и состояния "пользователь/супервизор" между собой вообще никак не связаны. Программа может работать с нулевым ключом, но в режиме "пользователь" (тогда она сможет обращаться к любым областям памяти, но не сможет использовать привилегированные команды), а может, наоборот, работать в режиме "супервизор", но с ненулевым ключом (тогда она сможет использовать привилегированные команды, но не сможет обращаться к любым областям памяти).
Добавлю только что не к любым областям, а только областям одного адресного пространства.
3) С запрещёнными прерываниями начинают выполнения все без исключения обработчики прерываний, ....
А если при выполнении обработчика случится Machine Check? Впрочем и Вы об этом тоже говорите.
Как мне помнится для некоторых обработчиков допускаются прерывания. Вообще говоря как может быть замаскировано новое PSW от тех же машинных прерываний? Смысл работать если может быть уже пора тушить свет?
Но в общем я готов согласится (пока не найду, или Вы мне не покажите, формальное описание для конкретной системы на МФ. Пока я нашел что решает девелопер системы какие прерывания маскировать в новых PSW) что хотя бы на время сохранения данных прерванного процесса хорошо бы быть замаскированным, но только все таки не от Machine Check.
У был трэйниг по этой теме в ИБМ. Но это было очень давно и моя память может меня подвести. Тем не менее.
Cогласитесь это уже дебри и мало кому это интересно читать кроме нас. Но если у Вас есть материал под рукой welcome and appreciate. .
оно тогда затрёт старое PSW прерываний ввода-вывода, ...
Это конечно да, поэтому при прерывании I/O и до сохранения информации о прерваном процессе от новых прерываний I/O надо маскироваться. Но от других может быть и нет. Старое PSW сохранится и старое PSW обработчика I/O тоже сохранится в сторм PSW нового прерывания.
Как я понял из того что смог найти с утра, не глубоко копая, вопрос что маскировать новыми PSW оставлено нв усмотрение разработчитка той или иной системы.
Конечно S/360 это основа основ, но в современных МФ есть PR/SM и логические партиции в каждой из которых своя система, а CPU и каналы используются совместно.
Конечно я принимаю в серьез Ваши замечания и благодарю. При случае попытаюсь просветить эту тему по полной ясности. Спасибо.
По SVC мне конечно же все это известно. Но пусть почитают другие если такие найдутся.
Про маскирование прерываний остановимся на том что по крайней мере от схем контроля прерывания не маскируются в обработчиках исключая обработчика прерываний от схем контроля.
Не забудем также про приоритеты прерываний. Machine Check имеет высший приоритет.
Назначение аппендикса PCI -- модифицировать канальную программу во время её выполнения, поэтому никакие задержки с его выполнением недопустимы. По этой причине обработчик прерываний ввода-вывода, являющийся частью супервизора ввода-вывода, обнаружив по информации, сохранённой в CSW, что это PCI, сразу же вызывает аппендикс, и последний, таким образом, выполняется в рамках обработчика прерываний ввода-вывода. Это, кстати, является причиной, почему программы, использующие ввод-вывод с PCI, могут оказаться неработоспособными при выполнении на виртуальной машине, хотя нормально работают на реальном железе: корректно написанная программа (и аппендикс PCI, и всё другое, относящееся к обслуживанию ввода-вывода) не может полагаться на то, что модификация канальной программы будет выполнена вовремя, а соответственно, при завершении канальной программы должна проверить, всё ли было выполнено в полном объёме, и если нет, запустить её повторно с необходимой точки. Но это делается не всегда -- и тогда на виртуальной машине возникают проблемы, так как там уже никакой гарантии "мгновенной" передачи управления аппендиксу PCI нет.
Это тоже конечно интересная и тема. Но мы уже очень далеко вышли за рамки комментариев на статью совсем другой направленности.
Отмечу лишь что в терминологии ИБМ документации нет такого термина как "апендикс канальной программы", но есть динамическая модификация канальной программы. С этим мне приходилось сталкиваться именно в связи с выполнение гостевой ОС (Это было ОС ЕС из ИВЦ МПС.). Проблема была решена выполнением этой ОС в области V=R. И насколько я понимаю это было не связано со скоростью реакции, или времени реакции, а с тем что CP переписывает канальную программу в свою память и соответствено динамическая модификация канальной программы обламывается. V=R эту проблему решала.
In IBM Mainframe VM, a Program Controlled Interruption (PCI) in a channel program (CCWs) signals the Control Program (CP) to regain control, often via DIAGNOSE X'08' (TIC - Transfer In Channel) or a specific DIAGNOSE X'19' (Write)/X'49' with PCI flag set`, allowing the virtual machine to handle I/O events like terminal attention (ATTN) or spool file management, enabling interactive applications (like ISPF/TSO) to manage virtual devices within the hypervisor environment.
Переубеждать Вас я не собираюсь -- что хотите, то и думайте хоть обо мне, хоть об обсуждаемых вопросах.
Беру свои слова обратно. Все досканально можно знать если плотно этим занимаешься. Конечно если Вы писали свою систему вам довелось ближе с матчастью знакомится. Я готов признать что Вы больше моего имели дело с программированием I/O. Но некоторые Ваши высказывания меня настораживают и это не ньюансе ввов-вывода, а основы. Например:
Но система не может проверить смысл предоставляемых пользователем аппендиксов -- она может проверить лишь формальные вещи типа их физического наличия и доступности; проверить допустимость их поведения она не в состоянии.
Как я писал выше мне не удалось найти следов "аппендиксов" канальных программ, но и Вы говорили про модификацию их. Возможно это может означать раширение/дописка ранее запущенной программы, но все равно продолжение ее выполнения может возобнавится, как я понимаю, только через SIO после изменения CSW. А значит система (супер- или гипервизор имеет возможность проверить программу канала снова, после модификации.
Другой пример настораживающий меня:
По этой причине обработчик прерываний ввода-вывода, являющийся частью супервизора ввода-вывода, обнаружив по информации, сохранённой в CSW, что это PCI, сразу же вызывает аппендикс, и последний, таким образом, выполняется в рамках обработчика прерываний ввода-вывода. Это, кстати, является причиной, почему программы, использующие ввод-вывод с PCI, могут оказаться неработоспособными при выполнении на виртуальной машине, хотя нормально работают на реальном железе:
Речь идет о канальной программе. Никто, ни какой обработчик прерываний ввода-вывода (т.е. программа CPU) не может выполнять канальную программу. Он только может изменить CSW и снова запустить канал.
На этих вот основах я настаиваю.
Может Вы это и имели в виду, но не достаточно четко разграничили кто что делает. Не знаю.
В общем и целом мне очень нравится наша с Вами беседа. Мне бы еще хотелось узнать зачем Вам вдруг понадобилось писать свою ОС. Почему нельзя было использовать имеющиеся ОС и если были какие-то идеи для улучшения то внедрить их через некие расширения стандартных. Вы же не собирались свою ОС продавать или предлогать другим.
Вот чем бы я занялся так это попыткой написать ОС на х86-64 но имея прототипом MVS, например. Не эмулятор, а нативную ОС х86-64, но с такой же функциональностью как MVS. И пройти путь от OS/360 до MVS. Понимаю выглядит дико. Нет полного, прямого соответствия возможностей МФ и серверов х86-64. По тому же вводу-выводу и не только. Но это можно было бы попробавать эмулировать.
SIISII
13.12.2025 12:41С ключами в архитектуре Z не все так просто
Это в 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 бита, смогла ещё более ухудшить и без того отвратительную архитектуру. По-хорошему, ей место на свалке истории, но имеем что имеем -- рыночек порешал, а он решает не по техническому совершенству. Что-либо под неё делать у меня лично желания нет.
zVlad909
13.12.2025 12:41Нижняя область памяти, включая области старых и новых PSW, а также начала обработчиков прерываний определяется макрокомандой IEAAIH из библиотеки SYS1.MODGEN.
В z/OS это макро IHAPSA и она в SYS1.MACLIB. Также по ссылке:
https://www.ibm.com/docs/en/zos/2.5.0?topic=rqe-psa-information
Я посмотрел, там не все так однозначно, но копаться не захотелось. Все сложнее чем в OS/360.
Хотите вспомнить/разобраться -- перечитайте документацию на OS/360 (именно на неё, не на z/OS; что там в z/OS творится, я понятия не имею).
В z/OS есть все что было в OS/360 и добавлены все промежуточные архитектуры как то ESA/390. 6 форматов PSW. И т.п.
И ещё и ещё раз: PCI предназначен для модификации выполняющихся канальных программ. Эти канальные программы не завершены, канал продолжает их выполнять!
Вот это совпадает с моим пониманием и не вызывает противоречий. Но дальнейшие Ваши объяснения воспринимаются с сомнением. Я нашел описание PCI в принципах работы Z, но это надо читать внимательно и думать. Все походу не так просто как Вы пишите. Возможно я вернусь к этому позже.
А в-третьих, архитектуры абсолютно всех процессоров Интел у меня вызывают, как минимум, неприязнь, если не чуть ли не физиологическое отвращение, но AMD, добавляя к ней 64 бита, смогла ещё более ухудшить и без того отвратительную архитектуру. По-хорошему, ей место на свалке истории, но имеем что имеем -- рыночек порешал, а он решает не по техническому совершенству. Что-либо под неё делать у меня лично желания нет.
Я полагаю Интел был задуман и создан совсем не для серверов и не для смеси разных нагрузок. Поэтому распределенная обработка на этих сервер является навязчивой идеей.
МФ изначально задуман для централизованной обработки больших смесей различных нагрузок и в этом весьма преуспел (вместе с z/OS конечно). Одним из эффектов этого я сам наблюдал когда мы к загруженому на 100% МФ добавили хороший дополнительный объем работы и он ее "проглатил" без проблем. Причем эти работы были диалоговые и в них измерителем качества было время выполнения транзакций. Индикаторные транзакции требовалось выполнять за меньше чем 1 сек. Приэтом выполнение других транзакций занимало минуты. И одновременно в этой же системе выполнялись пакетные задания. Я уж не говорю о том что и база данных и бизнес логика все там же, а в смежной партиции выполнялись все девелепорские и другие работы этого приложения.
zVlad909
13.12.2025 12:41Почему недокументированая? Очень даже документированая:
https://www.ibm.com/docs/en/zos/2.5.0?topic=status-description
SIISII
13.12.2025 12:41Это в современной z/OS она может быть документирована, а в обычной документации на ОС ЕС (и, надо полагать, на OS/360, с которой переводы были сделаны -- я оригиналы не читал) про неё ни слова.
zVlad909
13.12.2025 12:41Это все ерунда. С самого начала ОС МФ была возможность (документированная) вставлять свой код в систему, в ядро. Я имею в виду SVC программы.
Кроме того существововало и существует множество точек выхода из программ системных компонент через которые можно добавлять/изменять алгоритмы этих компонент или добавлять чем то другим.
MODESET обложено защитами по ее использованию. Т.е. для обычного программиста абсолютно не доступно. Есть MODESET или ее нет - одинаково. А системщику рулящему системой на уровне RACF SPECIAL доступно много больше возможностей.
Разве это достойно траты времени на обсуждение что документировано (было), а что нет. При наличии сопровождения от ИБМ можно было бы получить исходные коды интересующих системных программ, а еще проще предложить хорошую идею и ее внедрят в очередной версии профессионально и для всех. У меня был такой опыт.
SIISII
13.12.2025 12:41SVC-программы, да, возможность заложена была, но добавлять их (по крайней мере, указывать системе, что есть пользовательские SVC-программы), нужно было при генерации ОС. Соответственно, добавить что-то своё уже в процессе нормальной эксплуатации, если это не было заложено при генерации, невозможно.
Ранняя MODESET, насколько помню, никакой защиты не имела, но голову на отсечение не дам. Было б время -- попробовал бы понять по исходникам OS/360 21.8 (последняя MFT/MVT классическая, дальше уже идут с виртуальной памятью).
zVlad909
13.12.2025 12:41Кроме SVC Type-1 другие в MVS можно добавлять безз генерации ОС.
Вообще SVC, т.е. код выполняемый на уровне супервизора, далеко не всегда вообще нужны и как правило предназначены для весьма простых в смысле алгоритмов целей. Кроме того в MVS есть т.н. SubSystems^
A subsystem is a service provider that performs one function or many functions, but does nothing until it is requested. Although the term subsystem is used in other ways, in this section a subsystem must either be the master subsystem or be defined to MVS in one of the following ways:
• By processing the IEFSSNxx parmlib member during IPL You can use either the keyword format or positional format of the IEFSSNxx parmlib member. IBM recommends that you use the keyword format, which allows you to define and dynamically manage your subsystems.
• By issuing the IEFSSI macro
• By issuing the SETSSI system command The master subsystem (MSTR) is a part of MVS and is not defined in any of these ways.
The following IBM subsystems use the SSI:
• JES2 • JES3 • IMS • Tivoli® NetView® for z/OS
Это некие расширения основной ОС, имеющие более высокие права и которые могут обслуживать запросы прикладных программ.
Ранняя MODESET, насколько помню, никакой защиты не имела, но голову на отсечение не дам.
Скорее всего так это и было. Поэтому ее не документировали. Но облажив MODESET защитами от дураков сделали обще доступной.
Вообще это по смыслу макро для системных программ и прикладному программированию не нужно в принципе.
SIISII
13.12.2025 12:41Кроме SVC Type-1 другие в MVS можно добавлять безз генерации ОС
В MVS -- вполне может быть, я с ней дела не имел. Но в классическую OS/360 (а всё обсуждение шло вокруг её дыр, а не того, что творится в современных системах) -- нет; для SVC-программ типов 1 и 2 нужна генерация (поскольку они являются неотъемлемой частью ядра), а для типов 3 и 4 генерация не нужна лишь в случае, если при генерации ранее для них были зарезервированы номера -- поскольку для всех SVC-программ в процессе генерации строится таблица, и новые записи в неё добавлены быть не могут.
duselguy
13.12.2025 12:41Когда была (редкая) проблема остановки по адресу в госте VM, я просто правил в памяти одну машинную команду с переходом на саму себя. И никаких проблем для 100500 остальных гостей. И никаких проблем в госте (если маски прерываний не закрыты).
Есть timeslice, а холостой ход нафиг не нужен, если есть wait бит в psw :-)zVlad909
13.12.2025 12:41Это было не нужно. Была и есть команда TRACE^
Use the TRACE command to monitor events that occur in your virtual machine. z/VM lets you trace a number of events, including:
Instruction execution
Storage alteration
Register alteration
I/O activity.
Each traced event results in a trace entry, a command response that you can have sent to your virtual console, to a virtual printer, or to both. The trace entry is made up of significant information about the event. You can use trace entries to analyze the operation of your virtual machine and to debug problems.
Причем в оригинальной VM/SP эта команда была хуже (при схожей функциональности) чем в минской СВМ ЕС. В годы хороших отношений ИБМ позаимствовал эту команду. Подробностей я не знаю, но минской TRACE пользовался много.
В вашем случае не надо было курочить Вашу прграмму, а просто выполнить TRACE с указанием алреса остановки и запустить программу. Она была бы остановлена и перевела бы ВМ в среду CP. Остальное Вы знаете сами.
duselguy
13.12.2025 12:41Мы это уже обсуждали с Вами в другой ветке, когда Вы предложили gtf, etc.
Попробуем ещё раз:Trace отрабатывает не всегда (это известный bug/feature).
Если у вас задача взаимодействует асинхронно с другой задачей, то после перехода в CP у Вас всё остановится, и нет гарантии, что другая задача отработала.
А теперь вопрос на засыпку, как Вы находите адрес останова для trace? Трассируем модуль zOS и имеем его листинг, модуль не в LPA, AS в wait.
zVlad909
13.12.2025 12:41Мы это уже обсуждали с Вами в другой ветке, когда Вы предложили gtf, etc.
Да что-то такое обсуждали. Но GTF это z/OS. А Вы говорили про "проблема остановки по адресу в госте VM, ".
Вот именно для гостей VM и существует команда CP TRACE.
Про timeslice Вы тоже как-то по простетски написали что даже мне не легко Вас понять что Вы имели в виду.
По существе же обсуждаемой проблемы, когда что-то прикладное зацикливается, я бы сказал что на МФ есть службы времени, которые не позволяют никаким процессам монополизировать процессор. Т.н. компаратор, который выставляется перед каждым предоставлением доступа к CPU гостю и который (не зависимо ни от чего) вызывает прерывание через определенный промежуток времени (квант) и управление передается управляющей программе, которая выполнит много что прежде чем снова передаст управление зацикленной программе.
Этот механизм позволяет легко убить, или остановить гостя, или убить любую программу (или TSO сессию, или USS клиента etc...) в MVS (z/OS).
SIISII
13.12.2025 12:41когда что-то прикладное зацикливается, я бы сказал что на МФ есть службы времени, которые не позволяют никаким процессам монополизировать процессор. Т.н. компаратор, который выставляется перед каждым предоставлением доступа к CPU гостю и который (не зависимо ни от чего) вызывает прерывание через определенный промежуток времени (квант) и управление передается управляющей программе, которая выполнит много что прежде чем снова передаст управление зацикленной программе.
Даже в Системе 360, где компаратора ещё не было и был только интервальный таймер, зацикливание прикладной программы никак не могло завесить систему в целом:
никто не отменял прерывания ввода-вывода, а они при работе прикладных программ всегда разрешены. Соответственно, если оператор вводит что-то с консольного терминала, происходит прерывание ввода-вывода, в результате которого, в итоге, из ожидания выводится задача связи с оператором;
а задача связи с оператором, как и другие системные задачи, всегда имеют более высокий приоритет, чем любые задачи пользователя. Соответственно, даже если зациклилась задача пользователя с высшим приоритетом, задача связи с оператором всё равно начнёт выполнение и обработает команду, введённую оператором -- а этой командой может быть, например, CANCEL, убивающая зациклившуюся программу.
В общем, описанная товарищем ситуация попросту невозможна без вмешательства в работу супервизора, что обычный программист в рамках обычной программы сделать не может.
zVlad909
13.12.2025 12:41С интервальным таймером это было не так очевидно и в случае зацикливания программы без I/O это действительно проблематично связаться с системой.
С компоратором это стало более надежно:
The comparator continuously compares its internal value against the ongoing TOD clock value. When the TOD clock value reaches the value set in the comparator, an interrupt is generated.
TOD тикает независимо от ничего и компаратор сравнивает тоже автономно. Так что при истечении кванта времени зацикленная программа прервется. В CВМ, насколько я помню был монитор, который иог указать на ВМ с возможным зацикливанием. В z/OS тоже такое дол;о быть, в Omegamon.
Интервальный таймер, как я понимаю, не генерирует прерывания и его значение надо проверять:
Programming and Automation
STIMERand$STIMERMacros: Programmers use theSTIMERor$STIMERmacro instructions in assembly language to set a timer for a specific time period. When the allocated time elapses, the application task is notified.$TTIMERMacro: Used in conjunction with$STIMER, the$TTIMERmacro is used to query the remaining time in an interval or to cancel an active timer.
Честно скажу я не готов спорить до мелочей, но четко помню что в ОС ЕС с этим были проблема, а в СВМ ЕС их не стало именно потому что в СВМ ЕС появились кванты времени и их контроль с компоратором. В ОС ЕС квантов не было. Возможно просто не было такого механизма в системе и может быть и с интервальным таймером можно было это организовать. Но сдается мне что все таки интервальный таймер надо проверять программно. Вот события вызывающие внешнее прерывание:
External interrupts are triggered by events independent of the currently executing program. Specific sources in IBM z/Architecture systems include:
Timer events: Signals from the CPU timer, Time-of-Day (TOD) clock comparator, or the Sysplex Timer/Server Time Protocol (STP).
Тут нет интервального таймера.
SIISII
13.12.2025 12:41Интервальный таймер, как я понимаю, не генерирует прерывания и его значение надо проверять
Не путайте системные сервисы (макрокоманды супервизора) и интервальный таймер как железяку в составе процессора. Он генерирует внешнее прерывание, когда перекидывается из положительного в отрицательный, если память не изменяет. Но он существовал лишь в Системе 360 и Системе 370, причём в последней был объявлен устаревшим (вместе с интерфейсом прямого управления). В 370-XA и его, и интерфейс прямого управления (на котором держались первые многопроцессорные системы) выпилили, поэтому, естественно, их нет и в з/Арч.
duselguy
13.12.2025 12:41zVM guest это известное и понятное словосочетание.
timeslice (если забанили в Гугл): A "timeslice" (or time slice) refers to a brief, fixed interval of CPU time given to a process in multitasking operating systems, making many tasks seem to run simultaneously.
И, да, как Вы находите адрес останова для trace? Трассируем модуль zOS и имеем его листинг, модуль не в LPA, AS в wait.
zVlad909
13.12.2025 12:41И, да, как Вы находите адрес останова для trace? Трассируем модуль zOS и имеем его листинг, модуль не в LPA, AS в wait.
Начнем ч того что это не мой случай когда человеку надо было "остановиться/зациклится" на определенном месте его программы.
Лично мне приходилось это делать с программами выполняемыми в ПДО где адрес загрузки программы известен и постоянен, а листинг самой программы под рукой и можно вычислить нужный адрес.
Кроме адреса можно использовать и другие виды остановки, например, по коду инструкции, если кконечно это редкая инструкция, как то запись в память серийного номера процессора.
Если говорить о z/OS в ней есть шикарные средства отладки причем для языков свои и в целом системные. Никто не разрешит останавливать z/OS в котором идет работа многих пользователей. В случае же гостевой z/OS для индивидуальной отладки это тоже не составит труда и создаст проблему. z/OS, ее разработчики, отлаживают в том числе и на виртуалках. Не думаю что они зацикливают отлаживаемые модули.
zVlad909
13.12.2025 12:41Если бы Вы поподробнее рассказывали что Вы имеете в виду, то тогда было бы проще Вам отвечать.
TRACE это команда CP. Почему вдруг она может " отрабатывает не всегда "? Какой такой bug/feature вы знаете по этому поводу? Почему бы не поделиться ссылкой.
Если кому то понадобился останов и при этом естественно останавливается все, то причем здесь "другая задача"?
Как видите у меня Ваше сообщение вызвало больше вопросов чем ответов. Это из-за недостатка информации с Вашей стороны.
SIISII
13.12.2025 12:41Извините, но это уже бред какой-то. Одно дело технические неполадки -- тогда да, может твориться всё, что угодно. Но когда само железо исправно (а обычно оно таки исправно было -- даже диски, если за ними следить и выполнять все положенные регламентные работы в положенные сроки и с потреблением спирта после того, а не до того), завесить систему прикладным кодом невозможно в принципе, а её загрузка занимает максимум несколько минут, и для этого ничего вбивать не надо: на пульте управления набирается адрес устройства загрузки, нажимается кнопка "Загрузка" -- и всё, дальше уже идёт работа с системой через консольный терминал (дисплей или пишмашку в зависимости от машины).
checkpoint
13.12.2025 12:41На сколько я помню, технические неполадки с ЕС-кой были всегда. Так, чтобы все железо было на 100% рабочим такого вообще не было никогда. Постоянно что-то ремонитировали, ТЭЗы меняли и перепаивали, что-то подключали и отключали. Я паять то научился на том ВЦ помогая электронщикам заменять логику в ТЭЗах. :-)
SIISII
13.12.2025 12:41Уж не знаю, что у Вас за ЕСки такие были. В начале 70-х первые машины действительно были очень ненадёжны из-за ненадёжной элементной базы; когда отладили выпуск микросхем, надёжность резко поднялась. Так что раз в месяц сдохнуть ещё что-то могло, а чтоб цирк был постоянно -- не верю. Вот ежедневное обслуживание дисков и несколько реже другой периферии -- да, но работе оно не мешало, просто диски по одному выводились на обслуживание, но их-то достаточно много на всех крупных конфигурациях, да и на средних тоже.
duselguy
13.12.2025 12:41Встречаешь в коридоре дисковика с красными глазами и понимаешь, что была профилактика и юстировали диски -> день/неделя потеряны. А где-то (в Прибалтике) диски работали без проблем во время ремонта машзала.
SIISII
13.12.2025 12:41С какой стати потеряны-ты? Профилактика/юстировка проводятся одновременно с работой машины -- просто конкретный накопитель выводится на эту самую профилактику, а остальные продолжают использоваться. Заканчивают с одним -- передают его в эксплуатацию, выводят из неё другой, и так по кругу. Конечно, ЧП временам случаются, но при нормально организованном техобслуживании они именно ЧП, а отнюдь не ежедневное событие.
duselguy
13.12.2025 12:41Съёмные диски давали постоянную ошибку или банально задирались. Юстировочный диск - не мой (или моих коллег) диск, за короткое время на это устройство ставилась куча разных дисков.
SIISII
13.12.2025 12:41При периодически выполняемом обслуживании ошибки возникали отнюдь не постоянно; и сам привод, и пакет работали без проблем достаточно долго, поэтому в постоянную, ежедневную борьбу я не верю -- ну либо на конкретном ВЦ обслуживание было поставлено из рук вон плохо, квалифицированные специалисты отсутствовали и т.д. и т.п.
У нас на моей памяти (за примерно 4 года) был только один случай, когда работа встала на полдня. На одном из дисков ЕС-5061 на ходу оторвалась головка, что, естественно, вывело из строя привод и убило стоящий на нём пакет. Диск вывели в ремонт, а операторам ЭВМ пришлось выполнить следующую процедуру:
поставить новый пакет на другой привод (в их распоряжении в сумме было 16 ЕС-5061 и 16 ЕС-5052/5056);
инициализировать этот новый диск;
восстановить с магнитной ленты копию погибшего диска на этот пакет;
выполнить задания, которые уже были выполнены, но результаты работы которых были потеряны на убитом диске.
Вот на всё это порядка полудня у девочек и ушло. Неисправный привод ввели в строй через несколько дней (заменили головку, достаточно долго настраивали-юстировали и всё такое), но на работе ВЦ, за исключением описанного выше, это не сказалось никак. И, повторюсь, это было единственное крупное происшествие за несколько лет. Мелкие поломки случались, конечно, чаще, но могли привести к потере пары-тройки часов работы за месяц, а не так чтоб стоять и чиниться неделями, как тут пишут. (Самой типичной поломкой на ЕС-1035 был выход из строя очередной микросхемы основной памяти -- К565РУ1; они дохли со скоростью микросхема в месяц, но выход из строя одной микросхемы на текущую работу не влиял: спасал код Хэмминга; увидев сообщение об ошибке, девочки позволяли доработать до конца текущим заданиям, после чего отдавали машину электронщикам, те быстро находили дохлую микросхему -- спасибо тесту памяти -- и меняли её, и через час, максимум два, машина возвращалась в работу; если же работа была срочная, то ремонт вообще откладывали на 2 или 3-ю смену).
Но, замечу, у нас был приличный штат электронищков, и диски обслуживали постоянно, каждый день -- просто диск за диском, а не все диски сразу, поэтому перерывов в работе не было. Возможно, поэтому крупные неприятности и возникали редко. (Да, обычные сбои при чтении с диска -- вещь куда более частая, но к длительным задержкам она не приводила: ОС помечала дорожку как сбойную, и приходилось, разве что, пересоздать набор данных, что отнюдь не недель требовало. Причём, замечу, не каждый сбой при чтении был фатальным, зачастую данные считывались корректно благодаря CRC и автоматически переносились системой на резервную дорожку).
duselguy
13.12.2025 12:41У нас было так:
M дисков, N устройств, M>>N
Переставляя диск, выясняешь, на каком устройстве он работает.
Профилактика, диск перестаёт работать на этом устройстве.
В цикле 2) и 3).
SIISII
13.12.2025 12:41Ну, у нас дисков тоже было больше, чем устройств. Реально у нас было две ЕС-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-м).
SIISII
13.12.2025 12:41СВМ сама по себе грузилась намного быстрей -- она маленькая и компактная, в отличие от ОС ЕС. Загрузка слепка памяти -- ну, это не загрузка в том смысле, что загрузка ОС ЕС на голой машине, это сильно быстрей.
А уверены, кстати, что OS/VS1? Потому что это -- MFT с виртуальной памятью; SVS -- это OS/VS2 ранних выпусков (более поздние -- это уже MVS).
duselguy
13.12.2025 12:41Слепок памяти содержал ОС ЕС на определённый момент времени и грузился своим загрузчиком на голой машине (крутые были ребята).
Именно OS/VS1. Я был единственным пользователем, так как она имела версию метода доступа, которой не было в других OS. При исполнении вешался канал ( и СВМ естественно), так как неверно исполнялась специфическая цепочка канальных команд. Потом канал поправили.
zVlad909
13.12.2025 12:41Мэйнфрэймы IBM и прочих подобных производителей ...
Можете назвать "прочих"?
стоили страшных денег, более того, они даже не продавались, а сдавались в долгосрочную аренду с сопровождением и т.д.
Что плохого в аренде? Как можно вообще надежно эксплуатировать такие системы без сопровождения? Тем более что сопровождение ИБМ всегда славилось высоким, непревзойдённым, уровнем.
Я проработал 25 лет в кампании с МФ которые сначала были арендоваными, а под конец, не понятно почему, были приобретены в собственность (сейчас не знают как от них избавится).
Как это работало? Каждые два-три года ИБМ предлагал заменить МФ на новый, новой генерации. При этом стоимость аренды снижалась, а мощность МФ росла. Переход на новый МФ это элементарная продедура выполняемая за пару часов outage. И ОС мы обновляли с каждым новым релизом и редакцией. Текущие патчи я имплементировал дважды в год.
Я работаю в тесном контакте с нашими Юниксоидами, в одной команде мы. Много раз слышал как они говорили что не гарантируют переход на новый сервер для Sun Solaris, HP-UX. Даже перезагрузок системы они боялись и говорили что не гарантируют что система загрузится без танцев с бубнами. В результате у нас есть такие древние юникс сервера что просто диву даешься.
При таком подходе любые действия с отоклонением от инструкции могли рассматриваться производителем как нарушение "гарантии" и сятие системы с обслуживания.
Каких инструкций? Документации на ОС и саму машину? А как от них можно было бы вообще "отклониться". Не надо тень на плетень наводить. Не красиво это.
Поэтому всякого рода эксперименты на таких машинах категорически не приветствовались руководством эксплуатирующей организации.
Продолжение благоглупостей. Какие эксперименты не приветствовались? Каким "руководством эксплуатирующей организации"? Опчть тень на плетень.
Все что мне приходило в голову внедрить и изменить (в рамках документации по ОС и машины) я делал без какого-либо давления с какой угодно "организации".
Переход на новый МФ делался так. ИБМ доставлял стойку нового МФ. Технарь ИБМ-вский прогонял электронные тесты (по инструкции конечно) и отдавал МФ мне. Технарь уходил и все дальнейшее делалось мною Конфигурирование как было надо нам, первод имиджей ОС.
Как то мне понадобилось зарядить Linux на МФ. Скачал SuSe, создал новую партицию на продакшн МФ (а они всегда продакшн), проинсталировал и загрузил zLinux. No problem.
эксплуатант был собственником системы - мог делать с ней всё что заблагорассудиться. Именно это и привело к появлению ОС Unix. У Кернигана это четко указано.
Я был собственником системы на МФ. Делал, конечно не все что заблагорассудится я не был идиотом, но то что имело смысл делать (много чего) делал и докладывал руководству. ИБМ никогда и ни как в это не вмешивалась и не диктовала.
Я могу объяснить Ваше не понимание этих процессов и обстоятельств известных Вам от какого то Кернигана. Это точка зрения программистов, работающих под диктатом местного администратора систем. Да, поначалу в ранних версиях ОС, особенно в продакшн ручки программистов надо была ограничивать, порой отрубать. И это было везде, на любых платформах. В Bell была никем не используемая PDP-11 и поэтому появилась Unix. А на ИБМ МФ весьма рано, уже в конце 60-х, появились виртуальные машины. И те кому надо могли на одном МФ иметь несколько ВМ и делать в них все что заблагорассудится. Хоть свою ОС пиши, и отлаживай. Ничего подобного Unix не допускал. И root не всем программистам давался.
Так что Карниган Ваш тоже тень на плетень наводил. Их таких много было.
В СССР ситуация была иная. Отечественная линейка ЕС ЭВМ которая являлась клоном IBM S/360 и S/370, не накладывала подобных ограничений.
Ограничения конечно же были. Такие же как и в случае с ИБМ. Ломом в стойку бить не разрешалось.
И тем не менее, я хорошо помню, что инженеры на ВЦ, в котором я работал, любили СМ-1420 (советский клон PDP-11) и терпеть не могли ЕС-ки.
Представил как инженеры ВЦ где были только ЕС-ки мучались и плакали. Я прошел порядка ста ВЦ когда работал в СоюзЭВМкомплексе. Как правило инженеры на ЕС и СМ это были разные люди. В нашей сервисной организации ЕС и СМ были сначала сообще в разных министествах, а с созданием Госкомитета по ВТ все объдинили, но это все равно были разные подразделения.
можно было быстро загрузить в нужную ОС чтобы поэкспериментировать - хочешь в однозадачную/однопользовательскую RT-11 (РАФОС), хочешь в многопользовательскую RSX-11 (ОСРВ) или даже Unix (ОС ДЕМОС). На загрузку СМ-ки уходило 5-10 минут. В то время как перезагрузка ЕС-ки это целый ритуал и локальная трагедия. Очевидно, что СМ (PDP) была более пригодна для исследований и равлечений пытливых умов.
Хорошо поешь как говорится. С появлением Виртуальных Машин на ЕС на одной ЕС-ке сожно было создать за пару минут виртуальную машину и загрузить в нее что угодно, в том числе МОС - Мобильная ОС - сиречь Unix.
Когда у Вами горячо любимой PDP-11 появились Виртуальные Машины? Правильно - никогда.
Загрузка ОС на ЕС никогда не была ни ритуалом ни трагедией. Вы просто знаете это с чьи-то слов. А я это делал тысячи раз, возможно десятки тысяч. Один только случай помню, на УралАЗ-е, после генерации новой системы она не загрузилась. Один раз из десятком тысяч. И я не мог понять почему. Были неудачные загрузки, но тут же понималось почему и загружалось На УразАЗ-е конечно в итоге тоже загрузили.
victor_1212
13.12.2025 12:41известных Вам от какого-то Кернигана ...
однако, первыми над UNIX начали работать - Thompson, Ritchie, Rudd Canaday, Doug McIIroy, Joe Ossanna, позже Kernighan, хотя название UNIX предложил именно он
zVlad909
13.12.2025 12:41Кем бы они не были, но говорить ерунду про ИБМ им бы не следовало. Не седовало чтобы не терять лицо профессионалов. Никто из ИБМ себе это не позволял, хотя возможностей резонно покритиковать Unix была и остается.
У ИБМ есть два Unix-a: AIX и USS в z/OS. А с zCX еще и Linux в z/OS, не считая многих вариантов независимых Linux для МФ: SuSe, RedHat, Ubuntu, KVM.
victor_1212
13.12.2025 12:41не знаю какую ерунду Вы имеете в виду, но можно заметить, что профессионал определяется главным образом делами, а не словами, сильные и слабые стороны IBM хорошо известны, несколько десятков лет назад пришлось видеть внутрений документ DEC страниц на 50 специально по этой теме, возможно в сети где-то есть, если попадется посмотрите
zVlad909
13.12.2025 12:41Мне не попадется. А если и попадется то не думаю что я бы из этого документа нашел бы для себя кое-либо откровение.
Не понял связи между тем как определяется профессионал и 50 страничным документом DEC.
Если Вам хорошо известны "сильные и слабые стороны" ИБМ возьмите и напишите статью. Та статья, которую мы здесь комментируют, на такое знание не годится ни каким образом.
DEC со всеми своими продуктами сгинул, а ИБМ нет. Этим всё сказано.
victor_1212
13.12.2025 12:41вероятно полагаете, что IBM будет вечной, рано или поздно все кончается, но память остается, и бывает разной
zVlad909
13.12.2025 12:41Нет я не считаю что ИБМ будет вечно. Ничто не вечно под Луной. Но те многочисленные похоронные процессы ИБМ мэйнфрэйм, которые начались с 1995 года до сих пор время от времени проходят и это уже начинает походить на помешательство. А ИБМ МФ жив и развивается. Конечно пока, но все же.
А про то что действительно сгинуло что можно говорить? Можно только вспоминать. Мы тоже вспоминаем ранние этапы ИБМ МФ, которых уже нет, и тоже по разному. Но есть новые поколения. В этом разница.
Flammmable
13.12.2025 12:41Терминал IBM 2260 появился в 1964 году. С этого года ИБМ мэйнфрэйм перестал быть (собственно и ИБМ мэйнфрэйм был аннонсировал в том же году) чисто машиной пакетной обработки и стал машиной для смешанной работы.
Истину глаголите! Всё ждал, когда автор упомянет IBM-овские терминалы, но не дождался :)
А ИБМ мэйнфрэйм, их флагманская ОС - z/OS, в компании с z/VM, zLinux и всеми другими "современными" (в ковычках потому что это все чисто коммерческие исхищрения, пользующиеся, правда, популярностью) технологиями продолжает существовать и развиваться.
Да и что уж там, настоящая революция ПК началась именно с IBM PC :)
Стоило было заниматься переводом этого бреда? Думаю что нет. Ставлю минус, хотя и превержен историческим статьям про ИТ. Но это явно тенденциозная статья, необъективная.
Как по мне, несмотря на однобокость аргументов, две ключевые вещи подмечены очень верно: восторг от интерактивного общения с машиной настолько первобытный (испытано на себе), как будто эволюция пару миллионов лет готовила людей именно к появлению ПК; и жажда игр - вот причины бума ПК.
Жаль, что автор оригинала не углубляется в рассмотрение данных причин. Впрочем, я не видил, чтобы хоть кто-то в них. Ограничиваются обычно прометеианскими лозунгами "<username> освободил нас всех, принеся свет и тепло ПК".
Flammmable
13.12.2025 12:41А. Ну и ещё у автора оригинала типичная для подобных статей фишка: "наш Прометей видел, что компьютеры того периода большие, медленные и дорогие и решил: а что если сделать маленький быстрый и дешёвый компьютер?" :)))
leon_shtuet
13.12.2025 12:41Выражаю свое возмущение неуместным и нелепым использованием в этом тексте слова "хакер". Целых 17 раз используется этот термин совершенно не в тему. Они были такие же хакеры, как я Иван Грозный, царь всея Руси. Прямо выбесило. Уж не знаю, кто виноват, автор или переводчик. Поубивав бы. :( Минусов не ставил, по причине невозможности(бодливой корове, бог рогов не дал), но "виртуально" заминусил рассказ в плинтус.
checkpoint
13.12.2025 12:41В статье использован термин "хакер" в том смысле в каком он был у С. Леви в его "Хакерах", у П. Грэма в "Хакеры и Художники" и у Э. Рэймонда в "Jargon File". Так скажем, в его оригинальном значении. А Вы про что ?
leon_shtuet
13.12.2025 12:41А Вы про что ?
А я про общеупотребительное значение слова "хакер". Из тех времен и более/менее известных персонажей, хакером можно было бы лишь назвать Кевина Митника и то с натяжкой. Он скорее был спецом по социальной инженерии. А все те, кого Вы в переводе назвали/перевели "хакерами", просто юзеры. Гики, да, но никак не хакеры.
В статье использован термин "хакер" в том смысле в каком он был у С. Леви в его "Хакерах", у П. Грэма в "Хакеры и Художники" и у Э. Рэймонда в "Jargon File". Так скажем, в его оригинальном значении.
Вот именно, что в "оригинальном значении". Но оно никакое не оригинальное. Искусство переводчика и заключается в умении передать смысл, а не формальная, механическая подстановка переведенных слов.
checkpoint
13.12.2025 12:41Слово "Hacker" весьма четко определено в JargonFile-е. Прошу ознакомиться.
polar_yogi
13.12.2025 12:41Ну вот и Джобс с Гейтсом стали борцами за свободу с властью бездушных корпораций. А Ксерокс с их гуи и мышкой даже не упоминаются. Знатная сова на глобус.
По-моему у Лайонса в Опционах кто-то из персонажей говорит - из хиппи выросли самые хищные акулы капитализма.checkpoint
13.12.2025 12:41из хиппи выросли самые хищные акулы капитализма
Что-то в этом есть. Если посмотреть на современный американских "эстеблишмент", то там каждый второй в прошлом хиппарь и укурок. И вот эти люди учат нас не ковыряться в носу. ;)
victor_1212
13.12.2025 12:41настоящие хиппи это обычно наркотики и печальная история с быстрым концом, исключений мало, что касается вида и поведения, дурака в свободное время валяли большинство, у меня в свое время типа волосы до плеч были, про "'эстеблишмент" вопрос сложный, при близком рассмотрении общего мало между людьми, главный вопрос это про "ruling class" который существует конечно, но очень малочисленен и практически незаметен для внешнего наблюдателя
oneastok Автор
13.12.2025 12:41Вы или как‑то совсем уж невнимательно прочитали статью или перепутали ее с чьей‑то другой публикацией. Про Билла Гейтса говорится, что он учился в восьмом классе — вот и всё! Никакой борьбы восьмиклассник ни с кем не вел.
Все технологии, включая копировальные аппараты и графический интерфейс, в одном материале не уместятся.
Тема про GUI бесконечно глубокая, меня равнодушным не оставляет. Перепробовал я их немало. Последние годы работаю в Linux Mint Cinnamon, но все чаще задумываюсь переползти обратно на KDE. Может когда‑нибудь напишу об этом. Если любопытно, можете прочитать о GUI мою старую статью 2018 года.
Flammmable
13.12.2025 12:41А Ксерокс с их гуи и мышкой даже не упоминаются.
IBM PC 5150 не имел мыши, и предусматривал лишь текстовый режим гуи.
Altair не имел мыши, а в качестве гуи использовал лампочки.
Наработки Ксерокс конечно со временем оказались весьма полезны, но бум ПК начался независимо от данных наработок.
Flammmable
13.12.2025 12:41Большое спасибо за перевод. Интересны параллели с выводами, которые я для себя сделал при написании вот этой статьи при совершенно различной аргументации. Также неожиданным являются многие новые факты, например про установку PDP на агротехнику.
oneastok Автор
13.12.2025 12:41Статью вашу глянул мельком и сразу понял, что мимо не пройду. Настоящий исследовательский шедевр! Сегодня уже не успею, но на следующих выходных прочитаю обязательно.
victor_1212
13.12.2025 12:41Культура DEC строилась на принципе "от противного" ...
ничего подобного, это типа "отсебятина" автора оригинала,
на самом деле культура DEC была на 80-90% культура MIT и Lincoln Lab, т.к. с самого начала DEC по стилю работы и уровню сотрудников была типа продолжением MIT в промышленности, как работает IBM представление было, но это мало кого вообще интересовало,
чопорный пуританин Олсен ...
видел его достаточно, вполне доступный человек был, прекрасный инженер, сам ездил на старом Volvo, из сотен машин на парковке его типа самая убитая, менеджерам не разрешал отдельные кабинеты, все сидели в обычных cubicles до уровня директоров, вообще ушел из DEC т.к. отказался менять политику "из DEC инженеров не увольняют"
ErshoffPeter
Статья шикарная! Хоть и немного сумбурная.
Нуии опечатки есть немного: "аллергия".
oneastok Автор
У меня тоже аллергия на опечатки. :) Вычитывал утром еще раз и сейчас бегло пробежал — в упор не вижу. Не подскажете, где именно? Можно в личку, чтобы не засорять чат.. Я оперативно поправлю.
eledev
"Фотоаппарат TX‑0 в Массачусетском технологическом институте, предположительно сделанное в конце 1950‑х годов." под фотографией.
oneastok Автор
Благодарю! Прошелся по подписям к иллюстрациям, исправил.