GTF - мимо, если компонента в него не пишет. SLIP - на стороне заказчика (дамп по программному прерыванию, etc.). zVM (у себя) - останов по адресу, прогр. прерыванию, етс., покомандное исполнение, етс. "В z/OS каждую системную компоненту ...". 1) Не каждую. 2) А если у двух разработчиков общий модуль в LPA? 3) Туева куча других проблем ...
"Да были времена когда отладка MVS под VM была важной сферой применения VM в IBM. Но вряд ли сейчас это так важно имея LPAR и средства отладки в самом z/OS." Здесь Вы заблуждаетесь. Тестировщики имеют по несколько виртуальных машин (например, для сисплекса), разработчики - минимум по одной. И дело не только в средствах отладки в VM из коробки, если подумать и посчитать. LPAR используется при системном (нагрузочном) тестировании и тестах (проблем) производительности.
"... firmware это самостоятельный вид деятельности и совмещать его с разработкой z/VM просто нецелесообразно." Справедливости ради, был исторический этап с VM/SP и hardware assist. Но сейчас, IBM нет особого смысла вкладываться в производительность zVM, так как эра VSE под VM ушла, а 100500 Линукс под zVM не зашла, и zVM используется для разработки, отладки и тестирования zOS.
В первом абзаце Вашего ответа Вы неверно интерпретируете мой комментарий. Надеюсь, что у Вас есть (или будет) собственное понимание фразы Синявского: «У меня с советской властью были стилистические разногласия».
Вторая фраза на троечку. Значимым персонам надо быть требовательнее к своим текстам. Прочитав такое от влиятельного инженера AI, действительно забеспокоишься о будущем (обоих).
Новые команды (S360 vs S370). 1.1. ЕМНИП, весьма полезная и часто используема команда ICM появилась в S370. 1.2. Если "разработчик" (доработчик) ОС - всё, что связано с виртуализацией в новых ОС.
Программисты 80-х не были (столь) токсичны (как нынешние). Возможно, в силу отсутствия (чрезмерно) развитых (анонимных) средств коммуникации. Ну да, и трава была зеленее ...
Если рассматривать философию (и постулаты Парменида в частности) как множество логических выражений, то проблем нет. Если попытаться (не советую) развидеть в них дополнительный смысл, то возникают проблемы.
О какой Культуре может идти речь, если в Вашем МП нет формы открытия/контроля обращения по ошибкам в МП. Только чат с глупыми вопросами/рекомендациями/обещаниями от оператора. Впрочем, этот уровень (ниже плинтуса) свойственен и МП от топ ритейлеров, банков, etc.
Смешно читать о ваших "достижениях" в области решения проблем, когда в мобильном приложении X5 отсутствует форма обратной связи с разработчиком. Эрзац-система обращений не работает (и не может работать) в силу своей убогости. Пытаетесь навести порядок в здании, не имеющим фундамента. Фу, такими быть :-(
"а 1055 никогда не могли запустить дольше чем на полчаса, обычно до первого сбоя проходило минут 5" Странно, 1055 (как и 1040) немецкая машина, у нас работала без единого сбоя (но медленная).
Ссылки [1] и [2] в статье не раскрыты (или я не нашёл). Upd. Надеюсь (не флейма ради), что фраза про запутанность Big Endian (vs Little Endian) относится лишь к конкретному случаю обозначений индексов.
GTF - мимо, если компонента в него не пишет. SLIP - на стороне заказчика (дамп по программному прерыванию, etc.). zVM (у себя) - останов по адресу, прогр. прерыванию, етс., покомандное исполнение, етс.
"В z/OS каждую системную компоненту ...". 1) Не каждую. 2) А если у двух разработчиков общий модуль в LPA? 3) Туева куча других проблем ...
Я имел в виду, что разбрасываться партициями дорого, а более одного разработчика/тестировщика в партиции проблемно.
По поводу отладки (коротко): встроенный в zOS на уровне языка, zVM на уровне ассемблера.
P.S. Дела давно минувших дней, Преданья старины глубокой. (©)
P.P.S. И, да, для внутреннего отладчика нужен исходный код и компилятор с опциями. При этом вы отлаживаете только свой кусок, который пересобрали. А если вы наводите ошибку в другой компоненте? Без средств отладки zVM поймать это будет (значительно) сложнее.
"Да были времена когда отладка MVS под VM была важной сферой применения VM в IBM. Но вряд ли сейчас это так важно имея LPAR и средства отладки в самом z/OS."
Здесь Вы заблуждаетесь. Тестировщики имеют по несколько виртуальных машин (например, для сисплекса), разработчики - минимум по одной. И дело не только в средствах отладки в VM из коробки, если подумать и посчитать. LPAR используется при системном (нагрузочном) тестировании и тестах (проблем) производительности.
"... firmware это самостоятельный вид деятельности и совмещать его с разработкой z/VM просто нецелесообразно."
Справедливости ради, был исторический этап с VM/SP и hardware assist. Но сейчас, IBM нет особого смысла вкладываться в производительность zVM, так как эра VSE под VM ушла, а 100500 Линукс под zVM не зашла, и zVM используется для разработки, отладки и тестирования zOS.
В первом абзаце Вашего ответа Вы неверно интерпретируете мой комментарий. Надеюсь, что у Вас есть (или будет) собственное понимание фразы Синявского: «У меня с советской властью были стилистические разногласия».
Вторая фраза на троечку. Значимым персонам надо быть требовательнее к своим текстам. Прочитав такое от влиятельного инженера AI, действительно забеспокоишься о будущем (обоих).
Новые команды (S360 vs S370). 1.1. ЕМНИП, весьма полезная и часто используема команда ICM появилась в S370. 1.2. Если "разработчик" (доработчик) ОС - всё, что связано с виртуализацией в новых ОС.
Новые среды разработки (CMS)
etc.
Программисты 80-х не были (столь) токсичны (как нынешние). Возможно, в силу отсутствия (чрезмерно) развитых (анонимных) средств коммуникации.
Ну да, и трава была зеленее ...
Плюсую.
Точно! Поиск по фото указывает на ЕС-1021.
Если рассматривать философию (и постулаты Парменида в частности) как множество логических выражений, то проблем нет. Если попытаться (не советую) развидеть в них дополнительный смысл, то возникают проблемы.
Размышления на основе постулатов Парменида о бытии ... Которые сами не имеют основания.
О какой Культуре может идти речь, если в Вашем МП нет формы открытия/контроля обращения по ошибкам в МП. Только чат с глупыми вопросами/рекомендациями/обещаниями от оператора. Впрочем, этот уровень (ниже плинтуса) свойственен и МП от топ ритейлеров, банков, etc.
В начале статьи: "Нет, не нужен WiFi и Bluetooth".
Смешно читать о ваших "достижениях" в области решения проблем, когда в мобильном приложении X5 отсутствует форма обратной связи с разработчиком. Эрзац-система обращений не работает (и не может работать) в силу своей убогости. Пытаетесь навести порядок в здании, не имеющим фундамента. Фу, такими быть :-(
Верите ли Вы коллективные блоги на английском?(Хотелось бы более Вас услышать в комментариях)
А что с указателями?
Кроме исследования проблем программистов, Вы рассматривали похожие языки Odin, Hare, etc. ?
Неуместные пассажи в статье и некоторых комментариях :-(
"а 1055 никогда не могли запустить дольше чем на полчаса, обычно до первого сбоя проходило минут 5"
Странно, 1055 (как и 1040) немецкая машина, у нас работала без единого сбоя (но медленная).
В первые месяцы "выгорали" дребезжащие ТЭЗы, потом полёт нормальный (кроме задранных дисков).
Ссылки [1] и [2] в статье не раскрыты (или я не нашёл).
Upd. Надеюсь (не флейма ради), что фраза про запутанность Big Endian (vs Little Endian) относится лишь к конкретному случаю обозначений индексов.