Как стать автором
Обновить

Комментарии 88

Компьютеры System/360 под брендом ЕС ЭВМ были широко распространены в Советском Союзе:
image
Это была целая эпоха.

ЕС по воспоминаниям аксакалов ( https://m.habr.com/ru/post/214377/ ) была clock-precise копией 360й.

Я работал на ЕС ЭВМ и даже программировал на ассемблере.
Значит, я тоже аксакал?
Вполне)
Ассемблер, это что. Нам ещё преподавали, как прогу на ассемблере ЕС ЭВМ (та же система команд IBM/360) вручную «компилировать» в машинные коды. Даже задание такое было на экзамене.
Даже из этого поста вполне понятно, что S/360 это далеко не одна линейка одинаковых машин, а много разных. ЕС тоже. Аппаратная база — разная, в том числе внутри линейки. Так что копией — нет. А вот программно-совместимым клоном — да.

И вовсе не единственным — клоны S/3xx делали и другие (вспоминаются японцы, чуть ли не Тошиба вроде).

Так была куплена лицензия у ИБМ на производство. Примечательно то, что для них была и операционная система типа Unix — МОС ЕС. Ее можно сегодня считать прообразом отечественных Linux.

Лицензия? Вот тут явно написано, что IBM отказалась от сотрудничества. И я ни про какую лицензию никогда не слышал, хотя много раз общался на эти темы, в частности в Минском НИИЭВМ.

Да, вы правы. Лицензии не было. Было фактически клонирование.


Руководство IBM, которое он же принимал в стенах ВЦ РАН, от подобного сотрудничества отказалось.[4]
Свою роль сыграла и презентация, сделанная в США для советской правительственной делегации во главе с премьер-министром А. Н. Косыгиным в 1971 году, демонстрировавшая успешное повсеместное использование линии System/360.
Дело в том, что IBM в те далёкие годы продавал машины вместе с программным обеспечением в исходниках, включая ОС. Скопипастить элементную базу, в СССР вполне умели.
Несомненно. VM/SP компилировалась (хотя исходники были и не все).
>По современным стандартам компьютеры System/360 не были особо впечатляющими с точки зрения производительности:
По большому счету, и S/370 тоже были не ахти какие быстрые. Однако же, от сегодняшних решений их отличали некоторые особенности архитектуры, которые вы сегодня далеко не везде найдете:
— многоканальная память (мне помнится попадались упоминания про 8 каналов, хотя это не точно)
— довольно быстрая плавающая точка, а также десятичная арифметика в системе команд
— каналы ввода-вывода, которые делали весь ввод-вывод асинхронным
— дисплеи с собственной памятью, позволявшие редактировать текст автономно, отсылая процессору только результат, а не нажатие каждой клавиши

Ну то есть, многие вещи параллелились, и многие компоненты железа были достаточно интеллектуальны и независимы от процессора.

В итоге какая-нибудь машинка вроде отечественной ЕС-1046 (S/370), по формальным признакам слабее типовой сегодняшней персоналки (или телефона), вполне могла обслуживать примерно 80 терминалов, при условии что большая часть пользователей что-то делала в текстовом редакторе.
а также десятичная арифметика в системе команд
Вот это как раз не достижение. И Z80 и 8086 имеют её. А ЭНИАК только такой вариант и поддерживал. Так что это скорее показатель старости, чем прогрессивности.

Остальное — да, это круто.
А никто не говорит, что это уникальное свойство. Просто это удобно — не переводить в двоичную систему, а фактически считать прямо в том виде, как ввели. Насколько это нужно… ну сложно сказать, я вот вообще не пользовался, ибо от бизнеса и бухгалтерий был весьма далек.

Десятичная арифметика в System/360 — это уступка бизнес-расчетам, которые берут начало ещё с табуляторов (про них на Хабре было несколько статей), и уже имели сложившуюся десятилетиями "культуру". В те времена бытовало даже мнение, что объединять их вместе с двоичными числами (научные расчеты) в одной архитектуре нецелесообразно.

Если вы под «культурой» понимаете отсутствие ошибок при конвертации из десятичной системы в двоичную — так почему в кавычках? Не вижу, почему это плохо и почему это уступка. Бизнесу естественно, чтобы 5 копеек были 5 копейками, а не какой-то периодической дробью. Бизнес — потребитель. Как показала практика — даже наверное основной потребитель.

Под "культурой" я понимаю сложившюся к тем годам практику использования перфокарт, табуляторов, сортировщиков и тому подобной техники для проведения различных расчетов по коммерческим данным. А также "багаж" алгоритмов, разработанных для этой техники (та же поразрядная сортировка, к примеру). А ещё штат специалистов, которые этим занимались, и накопленный ими опыт. Это был на самом деле огромный "культурный пласт", сейчас уже во многом забытый.


Дело тут было не столько в том, как именно представлять доллары/центы, фунты, галлоны и мили. IBM декларировала возможность переноса широко применявшихся технологий на новую систему с минимальными издержками, и десятичные числа были одним из "кирпичиков" совместимости.

А. Ну просто, культура в кавычках — это как бы НЕ культура. Я подумал, что вы это в отрицательном контексте.
Дисплеи (терминалы) имели не только собственную память, но и процессор и ввод-вывод. Мы в универе играли в игрушки (типа ping-pong), которые загружались в терминал, который отключался от ЕС-ки и работал автономно.
Ну да. ЕС-7970 например. Только это уже 80-е пожалуй.
Model 22 располагала меньшим числом рядов с светодиодами
Да откуда там светодиоды, обычные лампочки)
мне тоже бросилось в глаза, всё же лампочки наверное
Да здесь весь перевод довольно косячный.
Но гуглетранслейт довольно продвинулся.
Жаль, что не знает о чем пишет.
Хм. Консоли у отечественных ЕС ЭВМ выглядели совсем по-другому, хотя и похоже. Например, ЕС-1033
image
Хотя, это уже следующее поколение — на интегральных схемах, а не отдельных транзисторах, и на 10 лет позже
НЛО прилетело и опубликовало эту надпись здесь
Было бы очень интересно почитать что-нибудь в духе «пишем и запускаем Hello World/FizzBuzz/Фибоначчи для System/360».

Фотографии очень впечатляют, но для меня, как человека, чьё знакомство с компьютерами началось уже на клонах IBM PC с MS-DOS на стероидах, остаётся довольно туманным, как именно осуществлялась разработка/отладка ПО под такие машины (да и в целом, как происходило взаимодействие операторов с ними).
как именно осуществлялась разработка/отладка ПО под такие машины (да и в целом, как происходило взаимодействие операторов с ними).
Всё в пакетном режиме поначалу. А отладка — ручкой на бумажке. Если вы получаете машинного времени пару частов в неделю в ночь с субботы на воскресенье — то иначе не получится…

Терминалы — это уже не 60е, а конец 70х…

Вот они терминалы КС-7920:
image


Если вы получаете машинного времени пару частов в неделю в ночь с субботы на воскресенье — то иначе не получится…

Часто время давали ночью. Одну такую ночь я запомнил навсегда. Это было в 1982 году в день похорон Л.И.Брежнева. Утром после ночи мы вышли из Акадении им.Ф.Э. Дзержинского (она была в Китай-городе) и решили зайти в Армянский переулок выпить по кружке пива. Мы ничего не поняли сразу, Москва пустая, магазины без народу, и в пивной пусто. А тут еще раздался грохот и гудки редких автомобилей. И мы поняли, что происходит. Этот день запомнился. И когда его вспонимаю, говорб все было как при коммунизме: магазины без народу, бери что хочешь (я имею ввиду продукты). Вот так мне запомнилась программисткая ночь на ЕС-1022.

Кхм.

/* */
say «Hello World»

Ничего что я на REXX? ;) Фибоначчи кстати будет не сильно длиннее, и еще — у REXX арифметика потенциально бесконечной точности, так что можно много членов рассчитать.
Ничего что я на REXX? ;)
Какое это отношение к IBM/360 имеет? REXX — это 1980е (в 1979м он только появился), а IBM/360 — это 1960е и самое начала 1970х (последняя модель вроде 22я, 1971го года выпуска).

Да, наверное, кто-то где-то сохранил IBM/360 к моменту выхода REXX и, возможно, их даже для чего-то использовали… но это не было типичной ситуацией с учётом того, что IBM их не продавала, а арендовала обычно…
Я же сразу намекнул, что буду жульничать :) Ну да, вы правы, REXX это не S/360, это попозже. Однако же это не меняет основной мысли, которую хотелось донести — на уровне Hello world разработка выполнялась точно также, как и сегодня.

Т.е. пишете программу, и если это интерпретируемый язык для написания скриптов — просто запускаете, и все происходит так, как будто это условный bash, или другой современный язык аналогичного назначения.

Или берете любой из известных языков, которые были на то время, и если это будет C, то получаете ровно такой же Hello, World, как описан в любой книжке для начинающих. Код не изменится. Компилируете, линкуете, запускаете — все эти этапы были и тогда, и принципиально не сильно отличались.
Вот это «пишете программу» и есть самое непонятное. Экрана нет, клавиатура непонятно какая. Перфокарты с номерами строк.
>Вот это «пишете программу» и есть самое непонятное.
Вы разве никогда не писали программу на бумажке? Я понимаю, что этот процесс неудобный, но что в нем непонятного-то?

Если экрана нет, то клавиатура все равно обычная — только на перфораторе. Перфоратор — это примерно вот так. На выходе колода карт. Считайте что это последовательный файл, со строками фиксированной длины.

Ну да, строки по 80 символов, чтобы влезали в перфокарту. Номера строк не обязательны — но удобны, если вы соберетесь потом заменить одну из строк на исправленную. Ну или уроните свои перфокарты — чтобы потом собрать по порядку. Больше, в общем-то, ни для чего не нужны.

Если что, мне не жалко пояснить подробнее, но мне тоже нужно понимать, какие именно аспекты непонятны тем, кто никогда не видел живого перфоратора :)
Если экрана нет, то клавиатура все равно обычная — только на перфораторе. Перфоратор — это примерно вот так. На выходе колода карт. Считайте что это последовательный файл, со строками фиксированной длины.
Ого. Я не то, что не видел живого перфоратора, я даже не подозревал об их существовании. :)
Спасибо, теперь у меня в голове уложилось (1) как можно использовать клавиатуру без терминала (Вы ниже упоминали про «пишущую машинку», но для меня это оставалось туманным) и (2) как программы печатались на перфокартах (да, наверное, можно и руками, но совсем же неудобно будет).

Я правильно понимаю, что при печати на перфораторе:
1) Из визуальной обратной связи — только перфокарта перед глазами? Т. е. либо читаешь по ней, либо печатаешь вслепую?
2) Средства редактирования отсутствуют в принципе — можно только заменить отдельную перфокарту? А если перфолента?
1. В 80-х были перфораторы с надпечаткой. То есть по верхней стороне идет напечатанный текст. Но типовой перфоратор все равно бил дырки при нажатии клавиши, так что редактировать на нем — только путем замены карты целиком.
2. Да, хотя можно было резать и заклеивать дырки в перфокартах (и перфолентах тоже) :)

Ну и замена программно в общем была. Как карты/строк целиком, так и части текста. Хотя если вы патч (как это сейчас зовут обычно) набираете на картах, от уменьшения объема текста толку не очень много. Шанс на ошибку сокращается конечно, но цикл отладки все равно не сокращается.
Спасибо за разъяснения.
Лично для меня это важное напоминание о том, что относительная простота технологий не означает примитивность и отсутствие изящных и эффективных решений.
Сквозь призму полувековой давности компьютеры той эпохи воспринимаются как нечто примитивное и крайне неудобное, но даже при таком поверхностном знакомстве осознаёшь, что такое восприятие далеко от реальности и не учитывает изобретательности людей при любом уровне технологий.
Мне сложно что-то сказать про полувековую давность, так как я сам начал в 1975, и это была М-222 и Алгол-60. И 50 лет с тех пор будет только в 2025 :)

Но вот скажем VM/SP, которая началась еще в 60-х в виде CP/CMS, и с которой я много работал в 80-х, то есть лет 30 назад, была далеко не примитивная, даже по современным меркам. По сути, она обеспечивала одновременную работу на одной реальной S/370 многих виртуальных машин, каждая из которых сама была S/370. То есть, можно например было запускать эту ОС саму под собой, или выполнять на виртуальной машине какой-нибудь ДЕМОС.
Да, ниже safari2012 упомянул СВМ (которая аналог IBM VM) и я хотя я не очень вижу разницу между всеми этими системами, они и правда впечатляют уровнем возможностей.
СВМ это VM/SP с немного переписанными под отечественные устройства обработчиками ошибок, по большей части, локализацией, ну и так, по мелочи.
Да, это-то я понял.

Я о семействе IBM-овских ОС: CP/CMS, VM и т. д.
Некорректно выразился изначально, простите.
В целом, наверное, разница между этими ОС не очень принципиальна сегодня, примерное представление я составил.
Хотя, может, я ещё какие открытие чудные упускаю. :)
>CP/CMS, VM
Это все почти одно и тоже… вернее так, CP/67 и CP/CMS оно называлось в детстве, под ним создали его в Кембридже (американском), когда машины были еще S/360 (модель 67), потом стало зваться VM/370, позже VM/SP, и VM/XA. А сейчас это кажется называется z/VM. В общем, разные названия разных версий.
Ого. Я не то, что не видел живого перфоратора, я даже не подозревал об их существовании. :)
Рука-лицо. Неужели же вам не рассказывали о Жаккарде, с которого всё это началось. А, собственно, IBM началась с Холлерита — и машинки, позволявшие обрабатывать перфокарты. Вначале механические, потом — электромеханические. И они, в общем, до сих по ещё в строю кое-где.

Разумеется фирма, занимавшаяся табуляторами и перфораторами при разработке ЭВМ будет на всё это богатство опираться… было бы странно, если бы было иначе.
Жаккарда знал, перфокарты знал, а вот перфораторы упустил, честно признаю. ¯\_(ツ)_/¯
Устройства телетайпного типа вполне могли заменять дисплеи, по крайней мере в конце 60 годов. Интерактивная работа на таком телетайпе, например, с интерпретатором языка APL, была вполне подобна современной реализации этого языка. Настолько похожа, что я как-то без труда использовал скан мануала от IBM 1971 года и он подошел и к современной реализации.
> как происходило взаимодействие операторов с ними
Это зависит от… Впрочем, CP/CMS разрабатывалась начиная с 1967, TSO тоже появилась не сильно позже, так что в 70-х уже были интерактивные терминалы. У тех, у кого они были, конечно. А так перфокарты, и пакетные задания. На JCL например.
Если же вы про операторов, которые управляют системой, то показанные тут консоли по большей части не для них. Обычному оператору от этой консоли нужно две вещи — выбрать адрес устройства, где стоит системный диск, и нажать кнопку начальной загрузки (IPL).

После этого система находит готовое к работе устройство — пишущую машинку или дисплей, и вы уже работаете там.

А консоль… ну там по большей части кроме инженерных регистров имели место обычные регистры процессора, в том числе PSW (слово состояния программы), которое в том числе показывает, какую команду процессор выполняет (адрес — часть PSW). Ну и можно было при желании заниматься отладкой — ставить точки останова, смотреть и менять содержимое памяти и регистров, выполнять пошагово. В общем, даже для системных программистов — штука достаточно редко нужная, всего несколько раз пригодилась в моей практике.
Спасибо за ответ, наверное, он ближе всего к тому, что мне было интересно. Потому что DISPLAY «Hello world» на COBOL'е можно и в Википедии подсмотреть. :)

У меня ключевое непонимание именно во взаимодействии человека и машины. Для меня практический минимум интерфейса — это «голый» POSIX shell, где ты можешь создать/отредактировать файл его, а потом передать его на вход компилятору/интерпретатору. Соответственно, я плохо представляю, куда, простите, этому IBM/360 исходный код программы засовывать. :)

После этого система находит готовое к работе устройство — пишущую машинку или дисплей, и вы уже работаете там.
А можете вот тут подробнее рассказать? Вы сами (и khim) выше упоминали, что интерактивные терминалы появились уже в 70-х. А что делали до них? И что выступало интерактивной оболочкой в этих терминалах с их появлением?

Ну и можно было при желании заниматься отладкой — ставить точки останова, смотреть и менять содержимое памяти и регистров, выполнять пошагово. В общем, даже для системных программистов — штука достаточно редко нужная, всего несколько раз пригодилась в моей практике.
Вот честно, я вообще не понимаю, как с такой консоли можно поставить точку останова где-то в коде (пусть даже машинном). И почему «редко нужная»? Слишком сложный процесс отладки плюс масштаб программ, позволяющий их отлаживать «в уме»?
>Соответственно, я плохо представляю, куда, простите, этому IBM/360 исходный код программы засовывать. :)
Ну, это зависит от ОС (а их было несколько довольно разных). В общем случае это файл, который может быть просто текстовый файл, библиотека, или скажем входной поток (перфокарты). Идеология в общем довольно сильно отличалась от posix, поэтому именование файлов и их структуры — другие. Скажем, у MVT описание файла — это том (физический диск), имя библиотеки + раздел. Но суть все равно весьма похожая.

Для VM/SP, где работали в основном в CMS, файл это имя, тип и буковка диска, т.е. HELLO FORTRAN B. Буковки очень похожи на то, что есть/было в DOS, и соответствовали разделам физического диска, выделенным для виртуальной машины CMS.

До терминалов все равно были пишущие машинки. Процедуры и команды опять же зависят от ОС, но в целом оператор мог например запустить системный процесс, который начинает считывать задания с какого-то ввода (RDR), процессы вывода на печать (WTR), и управлять уровнем параллелизма, запуская несколько INIT процессов, которые собственно выполняли задачи.

А с появлением терминалов интерактивные оболочки распространились в большом количестве. По сути, кроме собственной TSO от IBM, было еще куча разного софта, который в сущности был аналогом того, что сегодня делает например FAR Manager, или IDE — т.е. менеджер файлов, редактор, возможность что-то запустить. Это длинная тема, и очень разнообразная.

А в CMS, которая по сути была однозадачная однопользовательская виртуальная машина, была весьма похожа на известную вам posix консоль. Не буквально, но в целом близко. Т.е. процесс там происходил уже практически так же — запускаете условный vim (в том случае xedit), редактируете файл, сохраняете, запускаете компилятор (или сам файл, если это скрипт). Редиректа stdin/stdout/stderr и пайпов в таком же виде не было. Вместо них был системный стек, куда программа могла положить данные, т.е. скажем можно было в скрипте попросить утилиту получить список файлов на диске, а потом достать его из стека, и обработать. Ну и была такая штука, как FLIST, которая ровно повторяла (а скорее была прообразом) семейства Norton Commander. Т.е. список файлов, с фильтрацией и сортировкой, и кусочком командной строки против каждого, где можно было запустить команду типа PRINT, с подстановкой вместо параметров /N /T /M реального имени, типа и диска. И повторить это для многих файлов.

>Вот честно, я вообще не понимаю, как с такой консоли можно поставить точку останова где-то в коде (пусть даже машинном).
Ну собственно, вы задаете адрес (путем набора переключателями с пульта), и говорите «остановиться по этому адресу». Это все. Адрес обычно один. А редко нужная — потому что речь об отладке либо ОС, либо чего-то автономного, что работает без нее. Мало кто отлаживает ОС. Еще меньше таких, кто пишет автономные утилиты.

В рамках ОС обычные процессы можно было отлаживать более привычными способами.
Большое спасибо за развёрнутый ответ.
Честно говоря, для меня несколько удивительно, что уже тогда были похожие современным ОС, достаточно развитые для того, чтобы сделать редкостью написание автономных от ОС программ.
Собственно IBM/360 явилась прорывом ровно по этой причине: это была первое семейство компьютеров. Где программы могли переноситься с более слабого компьютера на более сильный без переписывания.

Позже появились и другие семейства: PDP-11, VAX, IBM PC… но IBM/360 — была первой.
Я полагал, что переносимость обеспечивалась просто одинаковыми архитектурой и системой команд. Оказалась, что всё более интересно. :)
Ну дык эта: разные модели отличались, в первую очередь, разным объёмом памяти и периферией. Ну и процессоры были разные, да — но это скорее на скорость выполнения программ влияло, чем на переносимость. Но если у вас на одном компьютере лента, а на другом — считыватель для перфокарт, а вы хотите использовать одну и ту же программу — то должно быть что-то, что соединяло бы программу с железом, очевидно.
По большому счету, CP/CMS — это 1967, и по своей идеологии это было очень здорово. Не то чтобы сейчас это было распространено — но многие годы задавало тенденции.

Ну и, в общем-то зачем нужна автономная программа? Чтобы тестировать железо. Такие были во множестве. Чтобы скопировать скажем ленту с дистрибутивом — такие тоже были. А больше-то зачем?
В статье промелькнуло упоминание о том, что с пульта надо было задавать адрес устройства для загрузки. Как вы думаете, почему? А потому, что в IBM 360/370 не было пзу и чтобы загрузить машину эмулировалась команда канала с устройства заданного с пульта. Эх, ностальгия… Тоже что-ли пост про ЕС ЭВМ написать?
>А потому, что в IBM 360/370 не было пзу и чтобы загрузить машину эмулировалась команда канала с устройства заданного с пульта.

Ну я не уверен, что именно поэтому. Скажем, у нас была типичной ситуация, когда имеется две копии ОС (возможно, совершенно разных версий), и можно загрузиться с одного из двух дисков. Или с ленты. Или с перфокарт, если совсем делать нечего. И при чем тут отсутствие ПЗУ? В современном PC вполне себе есть BIOS (ну или как его сегодня звать), тем не менее вполне можно в его меню задать, в каком порядке и с чего грузить ОС. Чем это принципиально отличается от выбора устройства по адресу?

>Тоже что-ли пост про ЕС ЭВМ написать?
А отчего же не написать? Напишите. Я вот кстати подумал, не написать ли пост про REXX, весьма интересный для своего времени язык. Но мало известен в широких кругах.
Как вы представляете себе загрузку без пзу?
Вот вы включили компьютер, и у вас в оперативной памяти ничего нет.
Какую команду должен выполнять процессор?
Биос, про который вы говорите, он в пзу живет.
Я говорю про то, что прямой связи между отсутствием ПЗУ, и необходимостью набирать адрес устройства, в общем-то не прослеживается.

>Какую команду должен выполнять процессор?
Чтение блока данных с какого-то устройства, обычно. По фиксированному адресу. И передача туда управления.

То что выбор адреса сделан аппаратно, в виде переключателей — да, это конечно следствие того, что нет ПЗУ, и нет аналога BIOS, который может это спросить, но сама возможность сделать выбор, откуда загружаться, вполне нужна и при наличии ПЗУ.
Не видел ни одной системы с ПЗУ, где был бы выбор, извините. ARM переходит на адрес 0, 8086 на адрес 0xFFFF0 — и так далее.

Вот программа, загруженная из ПЗУ — она уже что-то там позволяет выбирать.

А вот если ПЗУ нет — нужно как-то что-то откуда загрузить с пульта, больше неоткуда.

Чтение блока данных с какого-то устройства, обычно. По фиксированному адресу. И передача туда управления.
Вы представляете сколько транзисторов подобная конструкция потребует? А мы, напомню, живём в эпоху, когда они поштучно покупаются, микросхем пока нет…
Initial Program Load (IPL)PoOps(p123) is a process for loading a program when there isn't a loader available in storage, usually because the machine was just powered on or to load an alternative operating system.[2](p123) This process is sometimes known as Booting.
As part of the IPL facility the operator has a means of specifying a 12-bit[NB 3] device address, typically with three dials as shown in the operator controls drawing. When the operator[NB 15] selects the Load function, the system performs a System Reset, sends a Read IPL[NB 16] channel command to the selected device in order to read 24 bytes into locations 0-23 and causes the channel to begin fetching CCWs at location 8; the effect is as if the channel had fetched a CCW with a length of 24, and address of 0 and the flags containing Command Chaining + Suppress Length Indication. At the completion of the operation, the system stores the I/O address in the halfword at location 2 and loads the PSW from location 0.
Initial program loading is typically done from a tape, a card reader, or a disk drive. Generally, the operating system was loaded from a disk drive; IPL from tape or cards was used only for diagnostics or for installing an operating system on a new computer.


Вот выше текст, как реально была устроена загрузка. Это именно чтение с устройства (поскольку операции управляются канальной программой — то это именно адрес программы, которая до этого сама считывается с устройства).

Тут всего два шага:
— читаем с указанного устройства канальную программу, 24 байта
— выполняем эту программу

Мне, честно говоря, наплевать, сколько для этого нужно транзисторов. И где тут пульт — я тоже в упор не вижу.
Было бы здорово что-нибудь помимо «вводной статьи» или «статьи воспоминаний». Таких уже есть (вот тут, например).

А вот взять OS/360 — и рассказать как в ней живут — было бы прикольно.
Одной OS/360 как таковой не существовало. Были PCP, DOS, MFT, MVT. Я бы мог что-то по MVT написать, PCP, DOS и MFT не застал, ибо это были системы для уж очень хилых конфигураций, а у меня никогда не было ничего хуже ЕС-1033 с 512К памяти, но в целом это довольно скушная система, я бы сказал. Ну не рассказывать же всерьез про JCL, в самом деле…
1033, на которой я будучи студентом подрабатывал оператором, иногда отказывалась загружаться после зависания. Лечилось это «очисткой памяти» с пульта. В кавычках потому что через 30 с лишним лет тяжело вспомнить что реально делала последовательность которую надо было набрать. Интересно стало что я там вводил. Может вы помните чтото подобное?
Ну, я реально не знаю, что вы делали, могу рассказать про тот реальный опыт, когда мне потребовался пульт для отладки VM/SP. В нашем случае ЕС-1061, одна из первых, периодически переставала загружаться, и циклилась. Через какое-то время процесс проходил, нужно было просто подождать сколько-то времени, периодически нажимая на IPL.

Нас это довольно быстро достало, и как-то вечером наша теплая компания системных программистов, словив очередной цикл, решила в этом деле разобраться (благо, воспроизвести ситуацию в другое время не выходило, а тут как раз пациент под руками, и одновременно четыре или больше голов для обдумывания).

Поскольку генерация ОС это по большей части ассемблер, достали листинг, чтобы посмотреть, что по какому адресу располагается. Остановили цикл с пульта, поглядели, в какой секции оно циклится. Пришли к выводу, что это обработчик прерывания от таймера (одного из двух, которые в S/370 имелись). Поставили останов уже конкретно в нем, ближе к входу. В итоге вместо одного словили два прерывания, от чего у ядра слегка поехала крыша.

Кончилось все багрепортом в НИИЭВМ, и выпуском новой микропрограммы.

Но к вашей истории с 1033 это скорее всего никакого отношения не имеет :)
НЛО прилетело и опубликовало эту надпись здесь
Я тут имел в виду исключительно консоль. Наши операторы к ней после загрузки не подходили — зачем? При нормальной работе там нечего смотреть, и есть много других дел, как в ОС, так и например смена носителей (те же диски и ленты).
НЛО прилетело и опубликовало эту надпись здесь
Не, ну весь этот пост — он же не про пишущие машинки. И я тут не про них.
НЛО прилетело и опубликовало эту надпись здесь
Я примерно 15 лет проработал системным программистом, две ЕС-1046, ЕС-1061, ЕС-1066. И это не телетайп.
НЛО прилетело и опубликовало эту надпись здесь
Ну, это споры про названия, не вижу смысла. Вон чуть выше фотка ЕС-1033, я говорю о том что по центру, а вы видимо о том, что справа? :)
НЛО прилетело и опубликовало эту надпись здесь
Возможно, на упомянутых вами моделях оно так и было, но в моих случаях такого процесса либо не существовало, либо он применялся очень редко.

Чтобы в ЕС-1061 вводить код загрузчика с пульта? Микропрограммы с ленты грузили, да. В том числе обновления.

Даже на ЕС-1033 я такого никогда не делал, хотя ОС загружал каждый день (мы работали со своим дистрибутивом). Да и работа после загрузки, когда уже появилось приветствие, для VM/SP или СВМ в общем-то сводилась к паре команд. Типа enable all — чтобы подключить все дисплеи и разрешить вход. Для MVT посложнее, но тоже не сильно.

> ЕС-ки перегружались во много раз чаще
Ну в общем да. С надежностью было не очень. В лучшем случае аптайм несколько дней, на более новых машинах. И несколько раз в день — тоже вполне типично.

Именно так.
Были у нас лабы на СМ2м (тормозная до жути — компиляция и сборка простой программки на паскале по 20 минут). Потом поставили СМ4… Быстрая но глючная… Очень скоро почти все студенты знали как работать с консолью — выбор адреса загрузки микрокода, кнопка загрузки мк, потом адрес системного диска и кнопка загрузки ос.

НЛО прилетело и опубликовало эту надпись здесь
Строго говоря, под VM/SP у меня уже был компилятор C, так что можно было и совсем классический Hello, World написать.
А можно взять эмулятор x86 и там Windows 10 запустить… вот только зачем?
Просили Hello, World на S/360. Я и отвечаю, что компиляторы в том числе были с C, то есть в этом смысле Hello, World вообще ничем не отличается от того, что известно по опыту DOS или Windows. Сборка и запуск — да, могут отличаться.
НЛО прилетело и опубликовало эту надпись здесь
Fortran не забывайте :) А под классическим я имел в виду ровно тот вариант, что пишут в книжках, а точнее в известной книжке по C, откуда само название «Hello, World», насколько я знаю, и пошло. Т.е. K&R
У нас была ОС — СВМ . Интерфейс командной строки, похожий на dos/unix. Ну и некое подобие нортон коммандера и текстовый редактор, сравнимый по удобству с nano, vi. Пишешь программу, запускаешь компилятор, результаты вывода в файл. Тут пишут про дефицит машинного времени. Если надо запустить длительный расчет (например задачи по статистике), запускаешь свою прогу в виртуальной машине, отсоединяешь терминал от СВМ и пошёл себе гулять. Примерно, как использовать screen в linux.
Удивительно (по крайней, лично для меня), что технологии полноценной виртуализации появились так давно (или, если с другого конца истории, так быстро — менее чем через 20 лет после первых ЭВМ).
Большое спасибо за статью.
С момента первой встречи с мэйнфрэймом (S390 / 2001й год) очень хотелось почитать чего то популярного на тему но не нашел в то время.
С удовольствием прочитал бы ещё инфы по переферии — коммуникационные контроллеры, терминалы/дисководы, каналы и эсконы.
Solid Logic Technology (SLT) — гибридная технология компановки микроэлектронных схем
А что, собственно, такое это самое SLT? Знаю микромодули этажерочного типа, знаю гибридные ИМС, а вот SLT, несмотря на обширную практику возни со старьём, как-то не припоминаются. Можно ли считать ситалловую плату от совецкого радиоприёмника «Микро» сделанной по этой технологии?
Огромное спасибо за статью! Добавлю и я ещё немножко.

Все, кто заинтересовался этой темой, могут попробовать запустить OS/360 на своём компьютере и почувствовать себя, что называется, «в шкуре» тогдашнего программиста и оператора ЭВМ заодно.

Эмулятор IBM System/360 под названием Hercules тут. (На самом деле, эмулирует он IBM/370 и выше, но эта разница уже «для настоящих знатоков», тем более что последние версии OS/360 умеют использовать некоторые особенности IBM/370) Там же есть много полезных ссылок.

Вся документация по системе тут в оцифрованным виде. Не хватает, правда, кое-каких мелочей, но можно взять следующие версии отсюда.

Дальше возможны различные варианты:

1. Хардкор, так сказать. Берём дистрибутив OS/360 (например, отсюда), долго читаем мануалы и сами делаем генерацию системы. У меня получилось не с первой попытки, при том что есть бонус в виде личного опыта работы на ЕС-ках (но без собственно генерации системы) и куча литературы, собранной ещё в те времена. Книжками поделиться не могу, а на вопросы отвечу, по возможности.

2. Можно скачать уже готовую систему (ссылки есть на сайте Hercules'а) с кучей полезных «фишек», чтобы не тратить время и сразу начать писать программы.

3. Промежуточный вариант: повторить самому действия для получения п.2 (там все очень подробно описано), при этом избежать неудачных попыток и получить некоторый опыт.

Желаю успехов всем, кто попробует «погрузиться» в атмосферу той эпохи!
Тут только одна поправка: все ссылки, которые ссылаются на готовую систему уже давным давно протухли, так что незабываемый опыт генерации всего этого с нуля вас ждёт…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий