Комментарии 119
Статья шикарная! Хоть и немного сумбурная.
Нуии опечатки есть немного: "аллергия".
У нас один энтузиаст перелопатил исходники RSX-11M с единственной целью перевести сообщения на русский, в итоге узнал, что внутри ОС использовали кодировку RADIX50, которая не предусматривала букв, отличных от A-Z... :)
Интересно, как этого можно было не знать, если ты программист, писавший под RSX-11?.. Имена файлов -- тоже RADIX-50, например.
Они "внутри" в RADIX50, а если пишешь на Фортране, то вполне себе ASCII. И - вот в т.ч. такие у нас программисты были в советской армии.
Фортране, то вполне себе ASCII
А не в EBCDIC ли ?
EBCDIC -- только на ЕС ЭВМ (Системе 360), на ПДП-11 -- RADIX-50 и ASCII (разные вариации КОИ-7/8). В частности, если из Фортрана дёргать системные сервисы с именами файлов и задач, там надо, есно, в RADIX-50 было кодировать; это, насколько помню, СМовская (ДЕКовская т.е.) версия Фортрана предусматривала.
Я помню что EBCDIC только на IBM/ЕС. Я не помню чтобы для СМ/PDP писали на фортране. :)
Фортран -- основной язык разработки для PDP-11 (под RSX-11, во всяком случае). Для него даже сделали подпрограммы, чтобы можно было дёргать системные сервисы (которые, есно, были рассчитаны на вызов только на ассемблере). На Фортране под неё у нас было написано дофига всего, причём нередко ещё на СМ-4 с использованием команд FIS -- из-за чего на СМ-1420 и СМ-1600 приходилось использовать их эмулятор (эти машины имеют полноценный FPU, а значит, FIS у них отсутствует).
О, на Фортране для СМ-4 столько было написано! На Fortran-4 из RSX-11M, помню, летели исключения при попытке работать с float числами (не нашей СМ-4 не было сопроцессора), так написали программку, которая обрабатывала такие исключения, эмулируя нужное оборудование, медленно , да. А Фортран из ОС-РВ-СМ такое умел из коробки, но сам по себе имел худшие возможности по сравнению с Fortran-4 из RSX-11M. Ещё, был пакет RATFIV, который обрабатывал исходники т.н. структурированного Фортрана, на выходе генерировал F4 исходники.
В радиксе использовалить прописные и строчные буквы.
Только прописные в RADIX50.
И, некоторые сообщения кодировались в RADIX50, некоторые в ASCII. Потому что-то получилось русифицировать, а что-то не получилось.
Ошибаетесь, как уже написали. Инжалид дежице и прочая -- это замена строчных английских на большие русские в ASCII и т.п. манипуляции. В RADIX-50 -- всего 40 символов, 50 в его названии -- это их число в восьмеричной системе.
Ух, хорошо!
Мне кажется эта или подобная статья уже была на хабре, точно помню текст и фото.
Большинство заказчиков Altair не носили фенечек и не жили в коммунах.
Автор пытается категоризировать людей по внешнему виду и в этом его ошибка. В Bell Labs, Томпсон, Риччи и прочие тоже не носили фенечек. Да чего там, обыденная для них форма - пиждаки и галстуки. Тем не менее, ОС Unix которую они создали (и попутно язык программирования "Си") - что это как не бунтарство и взрыв свободы ? И технари из Беркли, которые сделали Unix опенсорсным и распространили по всему миру, тоже фенечек не носили, а имели вполне цивильный по тем временам прикид. Дело не в одежде, не во внешнем виде и не в месте работы, а в мышлении и разделяемых ценностях и идеалах. А они были повсеместно такими, что пора освободить компьютер, вычисления и программирование от оков жадных капиталистов. К сожалению, их идеалы мы благополучно слили в соцсетях.
PS: В молодости я предпочитал ходить в белой наглаженной рубашке, в черном пиджаке и в галстуке. Тем не менее, среди моих друзей было полно хайрастых рокенрольщиков, толкиенистов обвешенных феничками, и прочих лиц "очень странной наружности" (таких кстати сейчас на улицах и не встретишь больше). И на рок концерты я тоже в таком прикиде ходил - такой вот у меня был свой стиль протеста. А занимался я продвижением свободы электронного общения - содержал узел сети Fidonet и BBS, разматывал Интернет по городу, через BBS давал бесплатный доступк к Интернет тем, кто этого себе не мог позволить (dialup доступ в 90-х был по карману далеко не всем), продвигал опенсорс.
Тем не менее, ОС 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.
Против чего бунтарство? Против ИБМ? Чем им мещала ИБМ делать то что они делали? Ничем. А распростронение Unix вовсе не заслуга Ричи и Томпсона, а простое стечение обстоятельств. Их было много и ни одного объективного.
История создания ОС Unix хорошо описана в мемуарах Кернигана. Ей предшестововало вполне определенное событие и общая усталость программистов того времени от монстроидальных "пакетных" систем.
Автор пытается категоризировать людей по внешнему виду и в этом его ошибка.
Я полагаю, что автор оригинального текста полемизирует с теми, кто продвигает мысль, что ПК создали хиппи-социологи с фенечками и прочие популяризаторы, да евангелисты.
Поэтому он акцентирует внимание, что нет - настоящие создатели были не недоученные гуманитарии с Вудстока, а немного иные типажи.
Дочитал до конца. Статья хороша, спасибо за перевод.
Уж не знаю, автор ли, или переводчик, но слог сильно похож на Стивена Леви. :)
Статья (перевод) яркий пример бессилия и комплекса неполности из разряда "назло мамке отморожу уши" и "мимо тещеного дома я без шуток не хожу"..
Многократное и многославное порицание "пакетной обработки", используемой на всех более менее мощных машинах 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.
А вот и пиджаки подтянулись... ;)
Не обязательно пиджаки. Я вот тоже не согласен с таким ярким восхвалением DEC и порицанием IBM. Да, их машины очень разные -- но они попросту не пересекаются в реальном мире и решают совершенно разные задачи. Даже топовые VAXы и близко не подошли к возможностям мэйнфреймов по обработке крупных баз данных и тому подобным задачам, на которых держится крупный и особо крупный бизнес (и не только бизнес). Но таки да, в области диалоговой работы мэйнфреймы, скажем так, весьма неудобны -- но это просто другая область, и человек разумный и не страдающий фанатизмом будет выбирать то, что нужно под конкретную задачу -- и нередко это будет комбинацией нескольких разных технических средств, где каждая машина играет свою роль.
Но таки да, в области диалоговой работы мэйнфреймы, скажем так, весьма неудобны -- но это просто другая область,
Привет, коллега.
Поставил тебе плюсик, но хочу не согласиться в том что МФ хоть на йоту уступает каким либо другим диалоговым системам с терминалами.
Наоборот 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 варианты.
Хотя диалоговые системы на мэйнфреймах были, но они менее удобны и гибки по сравнению с тем, что можно было сделать (и делалось), скажем, на PDP-11. Но причина здесь в разной "идеологии" железа и ориентации на разные классы задач.
Вы, надо полагать, в курсе, но многие читатели вряд ли представляют специфику IBMовских терминалов по сравнению с более привычными DECовскими и прочими, поэтому ниже кратко поясню.
В "обычных" терминалах -- скажем, VT52 и VT100, которые были основными для PDP-11 и поддержка которых тянется до сих пор (скажем, в PuTTY есть эмуляция VT100) -- каждое нажатие кнопки на клавиатуре вызывало отправку байта данных на машину. Та его принимала, программно обрабатывала и выдавала терминалу ту или иную команду -- в частности, могла просто вернуть этот байт, и тогда терминал печатал эту буковку на экране и сдвигал курсор. Естественно, были и команды для управления положением курсора и выполнения ряда других операций (ESC-последовательности всякие разные).
Терминалы же IBM работали в известной степени подобно заполнению формочек в современных браузерах. Машина изначально отправляла терминалу полное изображение экрана, которое включало как видимые символы, так и коды, управляющие разделением экрана на поля. Пользователь вводил, что ему нужно, в определённых полях, при этом вводимые символы попадали напрямую в видеопамять, но в машину не передавались -- т.е. ввод и редактирование текста выполнялось терминалом полностью автономно. И лишь при нажатии некоторых клавиш (ВВОД и функциональные) терминал дёргал машину. Та считывала код нажатой клавиши плюс, если нужно, полное или частичное содержимое видеобуфера, после чего обрабатывала всё это и отравляла на терминал результат.
Таким образом, ДЕКовские терминалы отвлекали машину при каждом действии пользователя, а ИБМовские -- только в редких случаях, благодаря чему ПДП-11 начинала тупить, если одновременно был активен десяток терминалов, и даже с одним-единственным, если параллельно выполнялось что-то, занимающее много времени процессора (компиляция, например). А вот мэйнфрейм, даже слабый, на "обычном" редактировании не тормозил по той причине, что терминал вообще его не отвлекал и делал всё автономно -- из-за чего к нему можно было подключить намного больше терминалов. Конечно, отправив ему запрос, приходилось ждать ответа, причём время ответа зависело от того, сколько пользователей одновременно отправили свои запросы, но вот ситуации с тяжёлыми тормозами при правильно выставленных приоритетах возникали реже -- и особенно на слабых машинах (там, где ПДПшка просто тонула в потоке запросов прерываний от терминалов, мэйнфрейм имел этих прерываний буквально в 100-1000 раз меньше, а соответственно, мог намного эффективнее их обрабатывать). Но недостаток тоже очевиден: очень большая часть функционала определялась железом терминала и не могла быть переопределена, в то время как на ДЕКовском терминале -- полная гибкость, ведь за всё отвечает программа, выполняемая на самой ПДПшке.
Главное отличие DEC-овской техники от IBM-овской было не в техническом плане, и не в том как были устроен терминальный ввод. Мэйнфрэймы IBM и прочих подобных производителей стоили страшных денег, более того, они даже не продавались, а сдавались в долгосрочную аренду с сопровождением и т.д. При таком подходе любые действия с отоклонением от инструкции могли рассматриваться производителем как нарушение "гарантии" и сятие системы с обслуживания. Поэтому всякого рода эксперименты на таких машинах категорически не приветствовались руководством эксплуатирующей организации. Техника DEC, напротив, была во много раз дешевле, а эксплуатант был собственником системы - мог делать с ней всё что заблагорассудиться. Именно это и привело к появлению ОС Unix. У Кернигана это четко указано.
В СССР ситуация была иная. Отечественная линейка ЕС ЭВМ которая являлась клоном IBM S/360 и S/370, не накладывала подобных ограничений. В каждом ИВЦ, как правило, были люди которые могли разобрать машину "по косточкам" и собрать вновь из того "что бог послал" (дефицит компонентов был даже на ИВЦ), эксперименты с машиной в целом не возбранялись, если это не мешало основному процессу. И тем не менее, я хорошо помню, что инженеры на ВЦ, в котором я работал, любили СМ-1420 (советский клон PDP-11) и терпеть не могли ЕС-ки. СМ-ку можно было быстро загрузить в нужную ОС чтобы поэкспериментировать - хочешь в однозадачную/однопользовательскую RT-11 (РАФОС), хочешь в многопользовательскую RSX-11 (ОСРВ) или даже Unix (ОС ДЕМОС). На загрузку СМ-ки уходило 5-10 минут. В то время как перезагрузка ЕС-ки это целый ритуал и локальная трагедия. Очевидно, что СМ (PDP) была более пригодна для исследований и равлечений пытливых умов.
Вообще-то, RSX-11 на СМ-1420 грузилась несколько секунд, а не 5-10 минут -- по сути, скорость загрузки лимитировать скоростью дисков (нужно было прочесть в ОЗУ образ системы весом около 248 Кбайт; дальнейшая инициализация была почти мгновенной).
ОС ЕС на ЕС-1035, т.е. на очень медленной машине, грузилась пару минут, если оператор не тупил с ответами на тупые вопросы системы. Правда, потом ещё надо было запустить, например, Примус -- ещё порядка минуты-двух. В общем, за пять минут загрузить и начать работать было возможно.
Но что экспериментировать на ПДПшках было легче, это точно. Впрочем, мне это не мешало вовсю развлекаться на ЕС-1035, особенно в третью смену, когда никого не было, кроме дежурного инженера (спящего) и меня.
Я помню, что ЕС-ку чтобы загрузить требовалось несколько человек и всегда это сопровождалось каким-то шаманством на час, а то и на весь день (то диски сбойные, то контроллер канала какую-то неизвестную ошибку выдаст). СМ-ка загружалась в одинокого, с диска или с ленты, за считанные минуты. Если не ошибаюсь, там надо было еще код загрузчика руками вбить, чтобы он считал boot sector в память и передал ему управления, на это больше всего времени и уходило.
Впрочем, мне это не мешало вовсю развлекаться на ЕС-1035, особенно в третью смену, когда никого не было, кроме дежурного инженера (спящего) и меня.
Я же говорю, на советских ВЦ с машиной можно было экспериментировать. На западе был совсем другой подход. И вся статья, собссно, об этом IBM-овском ГУЛАГе vendor lock-е.
Перезагрузка СВМ на ЕС 1060 занимала меньше минуты и выполнялась оператором. Это время - "о малое" от времени, пока оператор добредёт до машинного зала и нажмёт на кнопку, и "о малое" от времени загрузки какой-нибудь OS/VS1 в виртуальной машине. На производстве (система Экспресс на спарке ЕС 1045) система (слепок памяти) грузилась 'мгновенно'.
На том ВЦ где я работал эксплуатировалась ЕС-1066 и её перезапуск был целым ритуальным действием. Возможно, в теории, она и могла бы загрузиться "мгновенно", если бы не куча периферии и частых проблем с ней. Для работников ВЦ перезапуск машины всегда был локальной трагедией. На этой машине, кстати, работала система продажи авиабилетов "Сирена", коммуникационным контроллером для которой выступала СМ-ка с кучей модемов.
Я понезнанию как-то полностью завесил машину своей простой программой на FORTRAN-е. Сейчас уже не скажу как это случилось (помоему это было что-то вроде 10 GO TO 10), я тогда был юн и неопытен, но машину пришлось запускать с холодного старта, кипежу создал прилично. :)
"Я по незнанию как-то полностью завесил машину своей простой программой на FORTRAN-е."
Не верю (C)
Этого не может быть, потому что этого не может быть никогда (C)
Ну да, ну да. ;) Проблема с холостым вечным циклом по сей день не имеет решения в современных ОС (Linux, Win). Запустите такую же программу на одноядерной системе - и конец. Но я не утверждаю что это было именно так, может быть прога записала чего лишнего куда не надо (в канал I/O), но машина стала сильно тупить, отзыв на консоле оператора был с минуту. Пришел начальник ВЦ и приказал машину ребутить.
Бред полный. Никакого конца не будет, многозадачная ОС всегда сохраняет свою работоспособность, так что для оператора нет никакой проблемы прибить такую программу.
Записать "в канал" Ваша программа тоже ничего не могла -- для этого она должна работать в режиме супервизора, а в него просто так не переключишься (собственно, официально вообще нельзя, неофициально -- можно с помощью недокументированной макрокоманды MODESET, но и эту лазейку в поздних версиях прикрыли, хотя я и не помню, была она закрыта в наших клонах ОС/360 или нет). Ну и, опять-таки, и "запись в канал", и МОДЕСЕТ доступны только на ассемблере, никаких языков высокого уровня.
ЕМНИП: MODESET (SVC107) не было; когда появилась, требовался AC=1 для редактора связей. Была лазейка (которую активно эксплуатировали) в аппендиксе канальных программ.
Была такая, да -- но это, опять-таки, только на ассемблере можно использовать, из Фортранов-Алголов-Коболов и даже ПЛ/1 на столь низкий уровень выхода не было (прямого выхода; понятно, что можно написать ассемблерную обёртку, которая вызовет подпрограмму, написанную на языке высокого уровня).
Можно в обе стороны.
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
ЕМНИП: MODESET (SVC107) не было; когда появилась, требовался AC=1 для редактора связей.
А также APF авторизацию библиотеки в которую программа с SVC 107 будет положено. А это означает что в дело должен быть включен системщик.
Была лазейка (которую активно эксплуатировали) в аппендиксе канальных программ.
Что за лазейка?
Да, APF и AC(1)
EXCP -> аппендикс получал управление в режиме супервизора (ЕМНИП). Это были дела давно минувших дней времён MVT. P.S. Я с EXCP не очень, только на уровне понимания/правки цепочек канальных команд.
Насколько я понимаю EXCP (Execute Channel Program) не требует каких специальных авторизаций. Канальная программа все равно проверяется супервизором ввода-вывода и никакую херню не пропустит, а также проверит права запустившего программу пользователя на те ресурсы которые будут вовлечены в такой процесс ввода-вывода.
Выполнение EXCP предполагает создание и заполнение всех пологающихся (DCB, etc...) и требуемых системой управляющих блоков, а также шаг открытия - .OPEN. Т.е. фактически EXCP это то что в методах доступа тоже происходит и чем завершается выполнение обращения к любому другому методу доступа, которые не требуют больших уровней чем есть.
Ну и конечно поскольку EXCP это макро, программа должна быть написана на Ассемблер. Или это будет подпрограмма вызываемая из языка высокого уровня. PL/I, Fortran, Cobol. etc...
И на ВМ можно подготовить, даже в ручную, канальную программу, CCW и выполнить команду SIO (Start I/O). Результат будет зависить от того как это воспримет менеджер виртуальных машин - CP (Control Program).
Про аппендикс к канальной программе я не понял. Нет я писал канальные програмы, но без аппендиксов и без лазеек (куда? зачем?).
Аппендиксы -- это подпрограммы, вызываемые супервизором в определённые моменты прохождения запроса ввода-вывода через супервизор. В частности, если это аппендикс PCI, он вызывается каждый раз, когда выполняющаяся в данный момент канальная программа, для которой он указан, вызывает программно-управляемое прерывание (PCI). Обработчик прерываний ввода-вывода, увидев, что причиной прерывания послужило PCI и что для данной канальной программы указан аппендикс PCI, немедленно вызывает этот аппендикс. Таким образом, сей аппендикс вызывается и работает в режиме супервизора с нулевым ключом защиты и с запрещёнными прерываниями -- фактически, он выполняется как часть супервизора ввода-вывода, но при этом его предоставляет системе прикладная программа, выдавшая EXCP.
Насчёт других аппендиксов я не помню, выполняются ли они в состоянии "супервизор" с нулевым ключом или в состоянии "задача" и с её ключом.
В состоянии супервизора. Долго гуглил по 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.
Ок. Спасибо. Напомнили. Вспомнил про эту возможность канальных команд 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
Таким образом, сей аппендикс вызывается и работает в режиме супервизора с нулевым ключом защиты и с запрещёнными прерываниями -- фактически, он выполняется как часть супервизора ввода-вывода, но при этом его предоставляет системе прикладная программа, выдавшая EXCP.
А вот тут Вы, извините, написали какую то лажу.
Все канальные программы, включая аппендиксы, запускаются "с нулевым ключом защиты", а точнее в состоянии супервизор. И вовсе не с запрещенными прерываниями. С запрещенными прерываниями выполняются как правило программы восстановления от машинных ошибок.
И вообще. Канальные программы выполняются каналами, запрещенные прерывания и состояние супервизор это про центральный процессор. Конечно канал сожет быть запущен только из состояния супервизор командой SIO. Но выполнение канальной программы вовсе не супервизором ввода-вывода делается, а каналом - компьютером ввода-вывода. Автономно и независимо, до того момента пока канальная программа не завершилась или не появилась в канальной программе CСW с битом PCI, бит 36, которой вызывает прерывание ввода-вывода для CPU.
Все что представляет прикладная программа с EXCP проверяется супервизором ввода-вывода прежде чем выполнение прерваной канальной прграммы продоолжится (или начнется выполнение другой программы канала (аппендискса). Тут мои знания о вводе-выводе заканчиваются потому что не было опыта).
Чувствуется мне что и у Вас есть дефицит опыта в области программирования ввода-вывода на МФ, которую мы обсуждаем. Где-то. что-то слышали и как-то поняли. Если я не прав, попробуйте меня переубедить.
Все канальные программы, включая аппендиксы, запускаются "с нулевым ключом защиты", а точнее в состоянии супервизор. И вовсе не с запрещенными прерываниями. С запрещенными прерываниями выполняются как правило программы восстановления от машинных ошибок.
Извините, но лажа таки у Вас :)
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-е годы не очень способствовали работе на одном месте). Так что, как работает ввод-вывод на мэйнфреймах, я знаю очень неплохо и на уровне программиста, и на уровне внутренностей процессоров и каналов, и на уровне сигналов интерфейса ввода-вывода, хотя некоторые детали, вероятно, подзабылись. Вот в устройства управления (контроллеры) тех же дисков я никогда не лез, т.е. с их работой знаком лишь со стороны программиста, но не электронищка.
По терминологии и не только:
Канальная программа - это цепочка команд CCW, которая исполняется процессором. Она часть программы (может быть в её теле или построена в динамический памяти на лету). Что делает канал - другая история.
Если программа выполняется в режиме супервизор, то она может получить нулевой ключ одной машинной привелигерованной командой (и поиметь доступ к любой памяти) .
Канальная программа -- это цепочка CCW, которая выполняется каналом ввода-вывода, почему, собственно, она и называется канальной программой. Процессор её формирует в основной памяти, заносит адрес первого CCW в CAW, а затем запускает канал на выполнение этой канальной программы с помощью команды SIO. Далее выполнение канальной программы осуществляется каналом без участия процессора, но последний может "на лету" модифицировать канальную программу.
Программа в режиме "супервизор" действительно может поменять собственный ключ, загрузив новое PSW. Но, пока она работает с ненулевым ключом, на неё распространяется та же защита памяти, что и на программу в режиме "пользователь".
Маленькая поправка. Не CAW, а CSW. Я работаю над Вашим большим сообщением. Это возьмет время. Во многом Вы правы (может даже во всем. У нас не должно быть разногласий). Но подробности позже.
CSW -- слово состояния канала, оно записывается каналом при прерывании ввода-вывода или при выполнении команд ввода-вывода вроде SIO и TIO, если у канала к тому времени есть информация для сохранения, относящаяся к адресуемому устройству, при этом будет установлен код условия 1 (а запуск операции ввода-вывода, если это была SIO, не произойдёт).
При запуске же ввода-вывода по SIO адрес канальной программы помещается в адресное слово канала -- CAW. Туда же помещается ключ, с которым канал будет осуществлять обращения к основной памяти. Адрес канала и устройства, к которым относится команда SIO, задаётся в ней самой.
Вы правы. Я по помяти тоже так и думал, но решил проверить у ИИ и вот что он ответил на запрос "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.
Извините, но лажа таки у Вас :)
Согласен в отношении вот этой моей фразы: "Все канальные программы, включая аппендиксы, запускаются "с нулевым ключом защиты", а точнее в состоянии супервизор." Прочитал утром в Вашем сообщении и подумал: кто ж это написал. Оказалдось я.
Этот ключ канальные программы используют при своих обращениях к памяти, и он обычно не равен нулю (чтобы канальная программа, относящаяся к одной задаче пользователя, не смогла залезть в память ядра или в память раздела другой задачи).
С ключами в архитектуре 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. По тому же вводу-выводу и не только. Но это можно было бы попробавать эмулировать.
С ключами в архитектуре 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 бита, смогла ещё более ухудшить и без того отвратительную архитектуру. По-хорошему, ей место на свалке истории, но имеем что имеем -- рыночек порешал, а он решает не по техническому совершенству. Что-либо под неё делать у меня лично желания нет.
Нижняя область памяти, включая области старых и новых 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 сек. Приэтом выполнение других транзакций занимало минуты. И одновременно в этой же системе выполнялись пакетные задания. Я уж не говорю о том что и база данных и бизнес логика все там же, а в смежной партиции выполнялись все девелепорские и другие работы этого приложения.
в предпоследней версии "принципов работы з/арч" появилось упоминание о PCI Express и отображённом на память вводе-выводе -- но только упоминание, без каких-либо деталей.
Уже все в работе:
Integration of PCI Express (PCIe)
In recent years, IBM mainframes (specifically the IBM Z and LinuxONE systems) have incorporated industry-standard PCIe technology to support a wider range of modern network and storage adapters.
PCIe Adapters: Mainframes now have dedicated I/O drawers and slots for PCIe adapters, which provide high-speed interfaces like FICON (for storage) and high-speed Ethernet (10 GbE, 25 GbE) for network connectivity.
Почему недокументированая? Очень даже документированая:
https://www.ibm.com/docs/en/zos/2.5.0?topic=status-description
Это в современной z/OS она может быть документирована, а в обычной документации на ОС ЕС (и, надо полагать, на OS/360, с которой переводы были сделаны -- я оригиналы не читал) про неё ни слова.
Это все ерунда. С самого начала ОС МФ была возможность (документированная) вставлять свой код в систему, в ядро. Я имею в виду SVC программы.
Кроме того существововало и существует множество точек выхода из программ системных компонент через которые можно добавлять/изменять алгоритмы этих компонент или добавлять чем то другим.
MODESET обложено защитами по ее использованию. Т.е. для обычного программиста абсолютно не доступно. Есть MODESET или ее нет - одинаково. А системщику рулящему системой на уровне RACF SPECIAL доступно много больше возможностей.
Разве это достойно траты времени на обсуждение что документировано (было), а что нет. При наличии сопровождения от ИБМ можно было бы получить исходные коды интересующих системных программ, а еще проще предложить хорошую идею и ее внедрят в очередной версии профессионально и для всех. У меня был такой опыт.
SVC-программы, да, возможность заложена была, но добавлять их (по крайней мере, указывать системе, что есть пользовательские SVC-программы), нужно было при генерации ОС. Соответственно, добавить что-то своё уже в процессе нормальной эксплуатации, если это не было заложено при генерации, невозможно.
Ранняя MODESET, насколько помню, никакой защиты не имела, но голову на отсечение не дам. Было б время -- попробовал бы понять по исходникам OS/360 21.8 (последняя MFT/MVT классическая, дальше уже идут с виртуальной памятью).
Кроме 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 защитами от дураков сделали обще доступной.
Вообще это по смыслу макро для системных программ и прикладному программированию не нужно в принципе.
Кроме SVC Type-1 другие в MVS можно добавлять безз генерации ОС
В MVS -- вполне может быть, я с ней дела не имел. Но в классическую OS/360 (а всё обсуждение шло вокруг её дыр, а не того, что творится в современных системах) -- нет; для SVC-программ типов 1 и 2 нужна генерация (поскольку они являются неотъемлемой частью ядра), а для типов 3 и 4 генерация не нужна лишь в случае, если при генерации ранее для них были зарезервированы номера -- поскольку для всех SVC-программ в процессе генерации строится таблица, и новые записи в неё добавлены быть не могут.
Я так понимаю мы здесь остались одни: Вы и я. Ну еще @duselguyиногда пишет.
Мне было забавно читать Ваши объяснения про SVC. Я эти плотно занимался в ОС ЕС в 80-е.
Да многое изменилось в новых версиях потомков OS/360. ОЧЕНЬ МНОГО. Но основа все таже и все что было сохранено, а новое добавлено. Многие вещи, которые можно было только через генерацию внести в систему (строго говоря не так уж и много их было), теперь можно изменять даже без остановки системы. Новое тоже появляется и для этого ничего останавливать чтобы это заработало.
В процентном отношении я бы дал однозначное число для того что было в OS/360 по сравнению с z/OS. Я 25 лет занимался освоением и внедрением нового к тому что где я работаю было использовано на уровне OS/390. И до конца мне еще далеко. Проблема в основном была в том что то что я внедрял как правило никому не было нужно. Даже внедрив encryption в интезфейс 3270, по заказы рукщводства, все юзеры, кроме нашей команды сопровождения, оставались до самого конца на несекьюрном порте 23.
Когда была (редкая) проблема остановки по адресу в госте VM, я просто правил в памяти одну машинную команду с переходом на саму себя. И никаких проблем для 100500 остальных гостей. И никаких проблем в госте (если маски прерываний не закрыты).
Есть timeslice, а холостой ход нафиг не нужен, если есть wait бит в psw :-)
Это было не нужно. Была и есть команда 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. Остальное Вы знаете сами.
Мы это уже обсуждали с Вами в другой ветке, когда Вы предложили gtf, etc.
Попробуем ещё раз:
Trace отрабатывает не всегда (это известный bug/feature).
Если у вас задача взаимодействует асинхронно с другой задачей, то после перехода в CP у Вас всё остановится, и нет гарантии, что другая задача отработала.
А теперь вопрос на засыпку, как Вы находите адрес останова для trace? Трассируем модуль zOS и имеем его листинг, модуль не в LPA, AS в wait.
Мы это уже обсуждали с Вами в другой ветке, когда Вы предложили gtf, etc.
Да что-то такое обсуждали. Но GTF это z/OS. А Вы говорили про "проблема остановки по адресу в госте VM, ".
Вот именно для гостей VM и существует команда CP TRACE.
Про timeslice Вы тоже как-то по простетски написали что даже мне не легко Вас понять что Вы имели в виду.
По существе же обсуждаемой проблемы, когда что-то прикладное зацикливается, я бы сказал что на МФ есть службы времени, которые не позволяют никаким процессам монополизировать процессор. Т.н. компаратор, который выставляется перед каждым предоставлением доступа к CPU гостю и который (не зависимо ни от чего) вызывает прерывание через определенный промежуток времени (квант) и управление передается управляющей программе, которая выполнит много что прежде чем снова передаст управление зацикленной программе.
Этот механизм позволяет легко убить, или остановить гостя, или убить любую программу (или TSO сессию, или USS клиента etc...) в MVS (z/OS).
когда что-то прикладное зацикливается, я бы сказал что на МФ есть службы времени, которые не позволяют никаким процессам монополизировать процессор. Т.н. компаратор, который выставляется перед каждым предоставлением доступа к CPU гостю и который (не зависимо ни от чего) вызывает прерывание через определенный промежуток времени (квант) и управление передается управляющей программе, которая выполнит много что прежде чем снова передаст управление зацикленной программе.
Даже в Системе 360, где компаратора ещё не было и был только интервальный таймер, зацикливание прикладной программы никак не могло завесить систему в целом:
никто не отменял прерывания ввода-вывода, а они при работе прикладных программ всегда разрешены. Соответственно, если оператор вводит что-то с консольного терминала, происходит прерывание ввода-вывода, в результате которого, в итоге, из ожидания выводится задача связи с оператором;
а задача связи с оператором, как и другие системные задачи, всегда имеют более высокий приоритет, чем любые задачи пользователя. Соответственно, даже если зациклилась задача пользователя с высшим приоритетом, задача связи с оператором всё равно начнёт выполнение и обработает команду, введённую оператором -- а этой командой может быть, например, CANCEL, убивающая зациклившуюся программу.
В общем, описанная товарищем ситуация попросту невозможна без вмешательства в работу супервизора, что обычный программист в рамках обычной программы сделать не может.
С интервальным таймером это было не так очевидно и в случае зацикливания программы без 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).
Тут нет интервального таймера.
Интервальный таймер, как я понимаю, не генерирует прерывания и его значение надо проверять
Не путайте системные сервисы (макрокоманды супервизора) и интервальный таймер как железяку в составе процессора. Он генерирует внешнее прерывание, когда перекидывается из положительного в отрицательный, если память не изменяет. Но он существовал лишь в Системе 360 и Системе 370, причём в последней был объявлен устаревшим (вместе с интерфейсом прямого управления). В 370-XA и его, и интерфейс прямого управления (на котором держались первые многопроцессорные системы) выпилили, поэтому, естественно, их нет и в з/Арч.
Ok. Make sense. То что интервальный таймер "выпилили" прошло мимо меня. Это видимо произошло в 90-е, начале 2000 когда я от системных дел отходил на ПК и уже в Канаде на DB2. В систему вернулся в 2006 году.
Но вот как прочитал про переход в отрицательные значени так меня и торкнуло. Конечно прерывание должно было быть. Но опять же интервальный таймер мог и быть, но система им не пользовалась для контроля за временем выполнения прикладных програм. Что про это скажите? Я как то не помню чтобы это была на слуху и только в СВМ ЕС это прозвучало громко и явно. Может в каких экзотических моментах, продуктах OS/360, это использовалось, но я ничего про это не помню.
Спасибо.
В классической OS/360 уровень поддержки таймера задавался при генерации системы -- вплоть до полного его отсутствия (на, как минимум, System 360/30 таймера физически могло не быть -- хотя почти на всех моделях он имелся в обязательном порядке). Если он поддерживался, то, по меньшей мере, обеспечивал ход времени (программно реализованные часы -- часы реального времени в современном виде появились только в Системе 370, а з/Арч к ним ещё индекс эпохи добавили). Если в систему включалась SMF, тогда ОС точно контролировала время выполнения пунктов задания и прибивала их по исчерпании времени (если только в задании явным образом не указывалось, что время для данного пункта выделяется без ограничений; с помощью своих подпрограмм выходов, присобаченных к SMF, можно было выделить заданию дополнительное время, даже если оно истекло). Вот если SMF не было, но таймер был, там я не помню, был ли такой функционал в системе.
Интервальный таймер, как и интерфейс прямого управления, выпилили в 80-е -- в 370-XA и последовавшей за ней ESA/370 их уже не было. Но устаревшими они были объявлены одновременно с появлением Системы 370; если память не изменяет, VM/370 ими никогда не пользовалась (ну а OS/360 продолжала пользоваться не только в MFT и MVT, но и в SVS, насчёт ранних MVS я уже не знаю -- вживую не встречал; но, поскольку она уже была существенно переработана, резонно предположить, что в ней полностью перешли на часы с компаратором и таймером процессора, а от интервального таймера отказались).
zVM 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.
И, да, как Вы находите адрес останова для trace? Трассируем модуль zOS и имеем его листинг, модуль не в LPA, AS в wait.
Начнем ч того что это не мой случай когда человеку надо было "остановиться/зациклится" на определенном месте его программы.
Лично мне приходилось это делать с программами выполняемыми в ПДО где адрес загрузки программы известен и постоянен, а листинг самой программы под рукой и можно вычислить нужный адрес.
Кроме адреса можно использовать и другие виды остановки, например, по коду инструкции, если кконечно это редкая инструкция, как то запись в память серийного номера процессора.
Если говорить о z/OS в ней есть шикарные средства отладки причем для языков свои и в целом системные. Никто не разрешит останавливать z/OS в котором идет работа многих пользователей. В случае же гостевой z/OS для индивидуальной отладки это тоже не составит труда и создаст проблему. z/OS, ее разработчики, отлаживают в том числе и на виртуалках. Не думаю что они зацикливают отлаживаемые модули.
Если бы Вы поподробнее рассказывали что Вы имеете в виду, то тогда было бы проще Вам отвечать.
TRACE это команда CP. Почему вдруг она может " отрабатывает не всегда "? Какой такой bug/feature вы знаете по этому поводу? Почему бы не поделиться ссылкой.
Если кому то понадобился останов и при этом естественно останавливается все, то причем здесь "другая задача"?
Как видите у меня Ваше сообщение вызвало больше вопросов чем ответов. Это из-за недостатка информации с Вашей стороны.
Извините, но это уже бред какой-то. Одно дело технические неполадки -- тогда да, может твориться всё, что угодно. Но когда само железо исправно (а обычно оно таки исправно было -- даже диски, если за ними следить и выполнять все положенные регламентные работы в положенные сроки и с потреблением спирта после того, а не до того), завесить систему прикладным кодом невозможно в принципе, а её загрузка занимает максимум несколько минут, и для этого ничего вбивать не надо: на пульте управления набирается адрес устройства загрузки, нажимается кнопка "Загрузка" -- и всё, дальше уже идёт работа с системой через консольный терминал (дисплей или пишмашку в зависимости от машины).
На сколько я помню, технические неполадки с ЕС-кой были всегда. Так, чтобы все железо было на 100% рабочим такого вообще не было никогда. Постоянно что-то ремонитировали, ТЭЗы меняли и перепаивали, что-то подключали и отключали. Я паять то научился на том ВЦ помогая электронщикам заменять логику в ТЭЗах. :-)
Уж не знаю, что у Вас за ЕСки такие были. В начале 70-х первые машины действительно были очень ненадёжны из-за ненадёжной элементной базы; когда отладили выпуск микросхем, надёжность резко поднялась. Так что раз в месяц сдохнуть ещё что-то могло, а чтоб цирк был постоянно -- не верю. Вот ежедневное обслуживание дисков и несколько реже другой периферии -- да, но работе оно не мешало, просто диски по одному выводились на обслуживание, но их-то достаточно много на всех крупных конфигурациях, да и на средних тоже.
Встречаешь в коридоре дисковика с красными глазами и понимаешь, что была профилактика и юстировали диски -> день/неделя потеряны. А где-то (в Прибалтике) диски работали без проблем во время ремонта машзала.
С какой стати потеряны-ты? Профилактика/юстировка проводятся одновременно с работой машины -- просто конкретный накопитель выводится на эту самую профилактику, а остальные продолжают использоваться. Заканчивают с одним -- передают его в эксплуатацию, выводят из неё другой, и так по кругу. Конечно, ЧП временам случаются, но при нормально организованном техобслуживании они именно ЧП, а отнюдь не ежедневное событие.
Съёмные диски давали постоянную ошибку или банально задирались. Юстировочный диск - не мой (или моих коллег) диск, за короткое время на это устройство ставилась куча разных дисков.
При периодически выполняемом обслуживании ошибки возникали отнюдь не постоянно; и сам привод, и пакет работали без проблем достаточно долго, поэтому в постоянную, ежедневную борьбу я не верю -- ну либо на конкретном ВЦ обслуживание было поставлено из рук вон плохо, квалифицированные специалисты отсутствовали и т.д. и т.п.
У нас на моей памяти (за примерно 4 года) был только один случай, когда работа встала на полдня. На одном из дисков ЕС-5061 на ходу оторвалась головка, что, естественно, вывело из строя привод и убило стоящий на нём пакет. Диск вывели в ремонт, а операторам ЭВМ пришлось выполнить следующую процедуру:
поставить новый пакет на другой привод (в их распоряжении в сумме было 16 ЕС-5061 и 16 ЕС-5052/5056);
инициализировать этот новый диск;
восстановить с магнитной ленты копию погибшего диска на этот пакет;
выполнить задания, которые уже были выполнены, но результаты работы которых были потеряны на убитом диске.
Вот на всё это порядка полудня у девочек и ушло. Неисправный привод ввели в строй через несколько дней (заменили головку, достаточно долго настраивали-юстировали и всё такое), но на работе ВЦ, за исключением описанного выше, это не сказалось никак. И, повторюсь, это было единственное крупное происшествие за несколько лет. Мелкие поломки случались, конечно, чаще, но могли привести к потере пары-тройки часов работы за месяц, а не так чтоб стоять и чиниться неделями, как тут пишут. (Самой типичной поломкой на ЕС-1035 был выход из строя очередной микросхемы основной памяти -- К565РУ1; они дохли со скоростью микросхема в месяц, но выход из строя одной микросхемы на текущую работу не влиял: спасал код Хэмминга; увидев сообщение об ошибке, девочки позволяли доработать до конца текущим заданиям, после чего отдавали машину электронщикам, те быстро находили дохлую микросхему -- спасибо тесту памяти -- и меняли её, и через час, максимум два, машина возвращалась в работу; если же работа была срочная, то ремонт вообще откладывали на 2 или 3-ю смену).
Но, замечу, у нас был приличный штат электронищков, и диски обслуживали постоянно, каждый день -- просто диск за диском, а не все диски сразу, поэтому перерывов в работе не было. Возможно, поэтому крупные неприятности и возникали редко. (Да, обычные сбои при чтении с диска -- вещь куда более частая, но к длительным задержкам она не приводила: ОС помечала дорожку как сбойную, и приходилось, разве что, пересоздать набор данных, что отнюдь не недель требовало. Причём, замечу, не каждый сбой при чтении был фатальным, зачастую данные считывались корректно благодаря CRC и автоматически переносились системой на резервную дорожку).
У нас было так:
M дисков, N устройств, M>>N
Переставляя диск, выясняешь, на каком устройстве он работает.
Профилактика, диск перестаёт работать на этом устройстве.
В цикле 2) и 3).
Ну, у нас дисков тоже было больше, чем устройств. Реально у нас было две ЕС-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-м).
СВМ сама по себе грузилась намного быстрей -- она маленькая и компактная, в отличие от ОС ЕС. Загрузка слепка памяти -- ну, это не загрузка в том смысле, что загрузка ОС ЕС на голой машине, это сильно быстрей.
А уверены, кстати, что OS/VS1? Потому что это -- MFT с виртуальной памятью; SVS -- это OS/VS2 ранних выпусков (более поздние -- это уже MVS).
Слепок памяти содержал ОС ЕС на определённый момент времени и грузился своим загрузчиком на голой машине (крутые были ребята).
Именно OS/VS1. Я был единственным пользователем, так как она имела версию метода доступа, которой не было в других OS. При исполнении вешался канал ( и СВМ естественно), так как неверно исполнялась специфическая цепочка канальных команд. Потом канал поправили.
Мэйнфрэймы 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 появились Виртуальные Машины? Правильно - никогда.
Загрузка ОС на ЕС никогда не была ни ритуалом ни трагедией. Вы просто знаете это с чьи-то слов. А я это делал тысячи раз, возможно десятки тысяч. Один только случай помню, на УралАЗ-е, после генерации новой системы она не загрузилась. Один раз из десятком тысяч. И я не мог понять почему. Были неудачные загрузки, но тут же понималось почему и загружалось На УразАЗ-е конечно в итоге тоже загрузили.
известных Вам от какого-то Кернигана ...
однако, первыми над UNIX начали работать - Thompson, Ritchie, Rudd Canaday, Doug McIIroy, Joe Ossanna, позже Kernighan, хотя название UNIX предложил именно он
Кем бы они не были, но говорить ерунду про ИБМ им бы не следовало. Не седовало чтобы не терять лицо профессионалов. Никто из ИБМ себе это не позволял, хотя возможностей резонно покритиковать Unix была и остается.
У ИБМ есть два Unix-a: AIX и USS в z/OS. А с zCX еще и Linux в z/OS, не считая многих вариантов независимых Linux для МФ: SuSe, RedHat, Ubuntu, KVM.
не знаю какую ерунду Вы имеете в виду, но можно заметить, что профессионал определяется главным образом делами, а не словами, сильные и слабые стороны IBM хорошо известны, несколько десятков лет назад пришлось видеть внутрений документ DEC страниц на 50 специально по этой теме, возможно в сети где-то есть, если попадется посмотрите
Мне не попадется. А если и попадется то не думаю что я бы из этого документа нашел бы для себя кое-либо откровение.
Не понял связи между тем как определяется профессионал и 50 страничным документом DEC.
Если Вам хорошо известны "сильные и слабые стороны" ИБМ возьмите и напишите статью. Та статья, которую мы здесь комментируют, на такое знание не годится ни каким образом.
DEC со всеми своими продуктами сгинул, а ИБМ нет. Этим всё сказано.
вероятно полагаете, что IBM будет вечной, рано или поздно все кончается, но память остается, и бывает разной
Нет я не считаю что ИБМ будет вечно. Ничто не вечно под Луной. Но те многочисленные похоронные процессы ИБМ мэйнфрэйм, которые начались с 1995 года до сих пор время от времени проходят и это уже начинает походить на помешательство. А ИБМ МФ жив и развивается. Конечно пока, но все же.
А про то что действительно сгинуло что можно говорить? Можно только вспоминать. Мы тоже вспоминаем ранние этапы ИБМ МФ, которых уже нет, и тоже по разному. Но есть новые поколения. В этом разница.
Терминал IBM 2260 появился в 1964 году. С этого года ИБМ мэйнфрэйм перестал быть (собственно и ИБМ мэйнфрэйм был аннонсировал в том же году) чисто машиной пакетной обработки и стал машиной для смешанной работы.
Истину глаголите! Всё ждал, когда автор упомянет IBM-овские терминалы, но не дождался :)
А ИБМ мэйнфрэйм, их флагманская ОС - z/OS, в компании с z/VM, zLinux и всеми другими "современными" (в ковычках потому что это все чисто коммерческие исхищрения, пользующиеся, правда, популярностью) технологиями продолжает существовать и развиваться.
Да и что уж там, настоящая революция ПК началась именно с IBM PC :)
Стоило было заниматься переводом этого бреда? Думаю что нет. Ставлю минус, хотя и превержен историческим статьям про ИТ. Но это явно тенденциозная статья, необъективная.
Как по мне, несмотря на однобокость аргументов, две ключевые вещи подмечены очень верно: восторг от интерактивного общения с машиной настолько первобытный (испытано на себе), как будто эволюция пару миллионов лет готовила людей именно к появлению ПК; и жажда игр - вот причины бума ПК.
Жаль, что автор оригинала не углубляется в рассмотрение данных причин. Впрочем, я не видил, чтобы хоть кто-то в них. Ограничиваются обычно прометеианскими лозунгами "<username> освободил нас всех, принеся свет и тепло ПК".
А. Ну и ещё у автора оригинала типичная для подобных статей фишка: "наш Прометей видел, что компьютеры того периода большие, медленные и дорогие и решил: а что если сделать маленький быстрый и дешёвый компьютер?" :)))
Выражаю свое возмущение неуместным и нелепым использованием в этом тексте слова "хакер". Целых 17 раз используется этот термин совершенно не в тему. Они были такие же хакеры, как я Иван Грозный, царь всея Руси. Прямо выбесило. Уж не знаю, кто виноват, автор или переводчик. Поубивав бы. :( Минусов не ставил, по причине невозможности(бодливой корове, бог рогов не дал), но "виртуально" заминусил рассказ в плинтус.
В статье использован термин "хакер" в том смысле в каком он был у С. Леви в его "Хакерах", у П. Грэма в "Хакеры и Художники" и у Э. Рэймонда в "Jargon File". Так скажем, в его оригинальном значении. А Вы про что ?
А Вы про что ?
А я про общеупотребительное значение слова "хакер". Из тех времен и более/менее известных персонажей, хакером можно было бы лишь назвать Кевина Митника и то с натяжкой. Он скорее был спецом по социальной инженерии. А все те, кого Вы в переводе назвали/перевели "хакерами", просто юзеры. Гики, да, но никак не хакеры.
В статье использован термин "хакер" в том смысле в каком он был у С. Леви в его "Хакерах", у П. Грэма в "Хакеры и Художники" и у Э. Рэймонда в "Jargon File". Так скажем, в его оригинальном значении.
Вот именно, что в "оригинальном значении". Но оно никакое не оригинальное. Искусство переводчика и заключается в умении передать смысл, а не формальная, механическая подстановка переведенных слов.
Слово "Hacker" весьма четко определено в JargonFile-е. Прошу ознакомиться.
Слово "Hacker" весьма четко определено в JargonFile-е. Прошу ознакомиться.
Нет нужды. Я прекрасно знаю общеупотребительное значение слова "хакер" в русском языке и какой-то там сферический файл JargonFile в вакууме, где-то на просторах интернета, для меня не указ. Так же, как и для подавляющего большинства русскоязычных пользователей интернета, которые тоже осведомлены о значении этого слова и понятия не имеющих о существовании какого-то там JargonFile-а. Не говоря уж даже о том, что герои той истории, которую Вы переводили, по смыслу повествования, в ее контексте, подразумеваются именно в значении "юзеры"/пользователи, а не "хакеры".
Ну вот и Джобс с Гейтсом стали борцами за свободу с властью бездушных корпораций. А Ксерокс с их гуи и мышкой даже не упоминаются. Знатная сова на глобус.
По-моему у Лайонса в Опционах кто-то из персонажей говорит - из хиппи выросли самые хищные акулы капитализма.
из хиппи выросли самые хищные акулы капитализма
Что-то в этом есть. Если посмотреть на современный американских "эстеблишмент", то там каждый второй в прошлом хиппарь и укурок. И вот эти люди учат нас не ковыряться в носу. ;)
настоящие хиппи это обычно наркотики и печальная история с быстрым концом, исключений мало, что касается вида и поведения, дурака в свободное время валяли большинство, у меня в свое время типа волосы до плеч были, про "'эстеблишмент" вопрос сложный, при близком рассмотрении общего мало между людьми, главный вопрос это про "ruling class" который существует конечно, но очень малочисленен и практически незаметен для внешнего наблюдателя
Вы или как‑то совсем уж невнимательно прочитали статью или перепутали ее с чьей‑то другой публикацией. Про Билла Гейтса говорится, что он учился в восьмом классе — вот и всё! Никакой борьбы восьмиклассник ни с кем не вел.
Все технологии, включая копировальные аппараты и графический интерфейс, в одном материале не уместятся.
Тема про GUI бесконечно глубокая, меня равнодушным не оставляет. Перепробовал я их немало. Последние годы работаю в Linux Mint Cinnamon, но все чаще задумываюсь переползти обратно на KDE. Может когда‑нибудь напишу об этом. Если любопытно, можете прочитать о GUI мою старую статью 2018 года.
А Ксерокс с их гуи и мышкой даже не упоминаются.
IBM PC 5150 не имел мыши, и предусматривал лишь текстовый режим гуи.
Altair не имел мыши, а в качестве гуи использовал лампочки.
Наработки Ксерокс конечно со временем оказались весьма полезны, но бум ПК начался независимо от данных наработок.
Большое спасибо за перевод. Интересны параллели с выводами, которые я для себя сделал при написании вот этой статьи при совершенно различной аргументации. Также неожиданным являются многие новые факты, например про установку PDP на агротехнику.
Культура DEC строилась на принципе "от противного" ...
ничего подобного, это типа "отсебятина" автора оригинала,
на самом деле культура DEC была на 80-90% культура MIT и Lincoln Lab, т.к. с самого начала DEC по стилю работы и уровню сотрудников была типа продолжением MIT в промышленности, как работает IBM представление было, но это мало кого вообще интересовало,
чопорный пуританин Олсен ...
видел его достаточно, вполне доступный человек был, прекрасный инженер, сам ездил на старом Volvo, из сотен машин на парковке его типа самая убитая, менеджерам не разрешал отдельные кабинеты, все сидели в обычных cubicles до уровня директоров, вообще ушел из DEC т.к. отказался менять политику "из DEC инженеров не увольняют"
Вишенкой на торте стал, разумеется, его знак зодиака. В конце концов, какая может быть революция без гороскопа?
Я конечно дико извиняюсь, но как насчёт этого? Для начала, для начала. Ибо далее начинается полнейший адище.
Эх, жаль что только сейчас достал статью из бэклога...
Издание 87 года, куплено довольно свежим. В конце 80-х чтиво было крышесносящее.
А уж воспоминаний про PDP-11 и RSX-11M/M-PLUS. Или ещё раньше, когда ночами просиживал около СМ1420 изучая тексты плюса чтоб заставить её загрузиться в 32К словах. И ощущение оргазма когда она загрузилась... Или ещё раньше, когда на СМ-4 принёс StarTrek с клингонами и ромуланами. И пока игра не была пройдена, на учёбу был забит болт воо-о-от такого размера...
Бунт против IBM, или как хакеры сломали систему и сделали компьютеры персональными