Съёмные диски давали постоянную ошибку или банально задирались. Юстировочный диск - не мой (или моих коллег) диск, за короткое время на это устройство ставилась куча разных дисков.
В состоянии супервизора. Долго гуглил по 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.
Мы это уже обсуждали с Вами в другой ветке, когда Вы предложили gtf, etc. Попробуем ещё раз:
Trace отрабатывает не всегда (это известный bug/feature).
Если у вас задача взаимодействует асинхронно с другой задачей, то после перехода в CP у Вас всё остановится, и нет гарантии, что другая задача отработала.
А теперь вопрос на засыпку, как Вы находите адрес останова для trace? Трассируем модуль zOS и имеем его листинг, модуль не в LPA, AS в wait.
EXCP -> аппендикс получал управление в режиме супервизора (ЕМНИП). Это были дела давно минувших дней времён MVT. P.S. Я с EXCP не очень, только на уровне понимания/правки цепочек канальных команд.
Встречаешь в коридоре дисковика с красными глазами и понимаешь, что была профилактика и юстировали диски -> день/неделя потеряны. А где-то (в Прибалтике) диски работали без проблем во время ремонта машзала.
ЕМНИП: MODESET (SVC107) не было; когда появилась, требовался AC=1 для редактора связей. Была лазейка (которую активно эксплуатировали) в аппендиксе канальных программ.
Когда была (редкая) проблема остановки по адресу в госте VM, я просто правил в памяти одну машинную команду с переходом на саму себя. И никаких проблем для 100500 остальных гостей. И никаких проблем в госте (если маски прерываний не закрыты). Есть timeslice, а холостой ход нафиг не нужен, если есть wait бит в psw :-)
Слепок памяти содержал ОС ЕС на определённый момент времени и грузился своим загрузчиком на голой машине (крутые были ребята).
Именно OS/VS1. Я был единственным пользователем, так как она имела версию метода доступа, которой не было в других OS. При исполнении вешался канал ( и СВМ естественно), так как неверно исполнялась специфическая цепочка канальных команд. Потом канал поправили.
"Я по незнанию как-то полностью завесил машину своей простой программой на FORTRAN-е." Не верю (C) Этого не может быть, потому что этого не может быть никогда (C)
Перезагрузка СВМ на ЕС 1060 занимала меньше минуты и выполнялась оператором. Это время - "о малое" от времени, пока оператор добредёт до машинного зала и нажмёт на кнопку, и "о малое" от времени загрузки какой-нибудь OS/VS1 в виртуальной машине. На производстве (система Экспресс на спарке ЕС 1045) система (слепок памяти) грузилась 'мгновенно'.
Двоякое впечатление от статьи. Не понравилось: Галлюцинации ИИ, написавшего статью. Понравилось (по ссылке на гитхаб): Closed issue #7 Problem The ./doctor.sh run script always converted COBOL to Java, even when the user selected C# as the target language. Root Cause (based on my observation) The TARGET_LANGUAGE environment variable set by the bash script was being overwritten by configuration files loaded in Program.cs. The LoadEnvFile() method unconditionally overwrote environment variables with values from config files, ignoring variables already set by the shell.
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.
Съёмные диски давали постоянную ошибку или банально задирались. Юстировочный диск - не мой (или моих коллег) диск, за короткое время на это устройство ставилась куча разных дисков.
В состоянии супервизора. Долго гуглил по 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.
Мы это уже обсуждали с Вами в другой ветке, когда Вы предложили gtf, etc.
Попробуем ещё раз:
Trace отрабатывает не всегда (это известный bug/feature).
Если у вас задача взаимодействует асинхронно с другой задачей, то после перехода в CP у Вас всё остановится, и нет гарантии, что другая задача отработала.
А теперь вопрос на засыпку, как Вы находите адрес останова для trace? Трассируем модуль zOS и имеем его листинг, модуль не в LPA, AS в wait.
Да, APF и AC(1)
EXCP -> аппендикс получал управление в режиме супервизора (ЕМНИП). Это были дела давно минувших дней времён MVT. P.S. Я с EXCP не очень, только на уровне понимания/правки цепочек канальных команд.
Встречаешь в коридоре дисковика с красными глазами и понимаешь, что была профилактика и юстировали диски -> день/неделя потеряны. А где-то (в Прибалтике) диски работали без проблем во время ремонта машзала.
Можно в обе стороны.
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 для редактора связей. Была лазейка (которую активно эксплуатировали) в аппендиксе канальных программ.
Когда была (редкая) проблема остановки по адресу в госте VM, я просто правил в памяти одну машинную команду с переходом на саму себя. И никаких проблем для 100500 остальных гостей. И никаких проблем в госте (если маски прерываний не закрыты).
Есть timeslice, а холостой ход нафиг не нужен, если есть wait бит в psw :-)
Слепок памяти содержал ОС ЕС на определённый момент времени и грузился своим загрузчиком на голой машине (крутые были ребята).
Именно OS/VS1. Я был единственным пользователем, так как она имела версию метода доступа, которой не было в других OS. При исполнении вешался канал ( и СВМ естественно), так как неверно исполнялась специфическая цепочка канальных команд. Потом канал поправили.
"Я по незнанию как-то полностью завесил машину своей простой программой на FORTRAN-е."
Не верю (C)
Этого не может быть, потому что этого не может быть никогда (C)
Перезагрузка СВМ на ЕС 1060 занимала меньше минуты и выполнялась оператором. Это время - "о малое" от времени, пока оператор добредёт до машинного зала и нажмёт на кнопку, и "о малое" от времени загрузки какой-нибудь OS/VS1 в виртуальной машине. На производстве (система Экспресс на спарке ЕС 1045) система (слепок памяти) грузилась 'мгновенно'.
Указал е-мейл
Пришёл код
Указал код
Ждите смс
Нет смс
Ждите звонка
Нет звонка
Поддержка е-мейл
Молчание
Двоякое впечатление от статьи.
Не понравилось:
Галлюцинации ИИ, написавшего статью.
Понравилось (по ссылке на гитхаб):
Closed issue #7
Problem
The ./doctor.sh run script always converted COBOL to Java, even when the user selected C# as the target language.
Root Cause (based on my observation)
The TARGET_LANGUAGE environment variable set by the bash script was being overwritten by configuration files loaded in Program.cs. The LoadEnvFile() method unconditionally overwrote environment variables with values from config files, ignoring variables already set by the shell.
Я ещё не смотрел код, а разве нельзя отсчитывать месяц от даты последнего сертификата (а не от даты перезапуска).
Пора писать предложения/etc. на гитхабе и там обсуждать. Это поможет поднять проект.
Стоит прислушаться к совету выше и параметризовать. Проект актуален не только для наших старших.
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.