Подсистема ввода заданий (JES) — это компонент операционных систем мэйнфреймов MVS от IBM , отвечающий за управление пакетными рабочими нагрузками. В настоящее время существуют две различные реализации системы ввода заданий, называемые JES2 и JES3 . Они предназначены для обеспечения эффективного выполнения пакетных заданий.
Обработка заданий делится на несколько фаз для обеспечения параллелизма посредством конвейеризации . Эти фазы включают обработку ввода, где задания считываются и интерпретируются, фазу выполнения, где задания запускаются, и обработку вывода, где вывод задания печатается или сохраняется на DASD . Задания, которые находятся в одной и той же фазе выполнения, обычно называются находящимися в определенной очереди; например, задания, которые в данный момент выполняются, находятся в очереди выполнения.
Для повышения эффективности ввода-вывода JES выполняет спулинг , который обеспечивает нескольким заданиям одновременный доступ к общему объему хранилища. JES использует структуру, называемую контрольной точкой, для резервного копирования информации о текущих выполняемых заданиях и их связанных выходных данных. Контрольную точку можно использовать для восстановления заданий и выходных данных в случае непредвиденных сбоев оборудования или программного обеспечения.
Хотя JES2 и JES3 предоставляют одинаковую базовую функциональность, есть определенные функции, которые могут присутствовать в одном JES, но не в другом. Из-за этих различий один JES может быть предпочтительнее другого в некоторых клиентских установках. JCL используется для определения заданий как для JES2, так и для JES3, но обычно необходимо внести небольшие изменения в JCL, чтобы задание, написанное для одного JES, запускалось на другом. Распространенной проблемой было то, что JES3 проверял, что все наборы данных, перечисленные в JCL, существуют до выполнения или что был предыдущий шаг, на котором набор данных был определен как NEW,CATLG. JES2 не настаивал на этом, позволяя заданию выполняться, даже если оно даст сбой, если шаг, использующий его, не сможет его найти.
Пакетная обработка заданий OS/360 имела ограниченную операционную гибкость и производительность, для решения этой проблемы были разработаны два пакета, которые назывались Houston Automatic Spooling Priority ( HASP ) и Attached Support Processor ( ASP ).
HASP был разработан подрядчиками IBM Federal Systems Division в Космическом центре имени Джонсона в Хьюстоне . [1] [2] Первоначально он управлял планированием заданий, а также выводом печати и перфорации для одного компьютера OS/360. Была добавлена возможность Multi Access Spool , чтобы позволить одноранговым компьютерам совместно использовать общую очередь заданий и очереди вывода печати/перфорации. [ необходима ссылка ]
С появлением System/370 в 1972 году IBM переписала HASP, чтобы он стал стандартной частью системы, и переименовала его в Job Entry Subsystem 2. JES2 был представлен в OS/VS2 в Release 2, также известном как MVS , в 1973 году. [3] Прошло много лет, прежде чем метки HASP были удалены из исходного кода, и сообщения, выдаваемые JES2, по-прежнему имеют префикс $HASP
. Несколько команд JES2 продолжают поддерживать спецификацию либо JES2
, либо HASP
для сохранения обратной совместимости . [4]
ASP изначально обозначал Attached Support Processor , [a] [5] и был разработан для обеспечения эффективного использования нескольких систем с общей рабочей нагрузкой. Он позволял одной центральной системе распределять задания по нескольким подключенным системам; ASP мог запускать смесь эмуляции OS/360 , SVS и 7090 на главном процессоре 360/65, но только [b] OS/360 и SVS на других моделях S/360 и S/370. ASP был анонсирован в марте 1967 года, [6] : стр.710 , и в том году сообщалось, что он «работает очень стабильно». [7]
ASP развился из конструкции системы прямого сопряжения 7094/7040 , использующей канал передачи данных для связи между каналами передачи данных. [8] При подключении IBM 7040 в качестве периферийного устройства пропускная способность процессора увеличилась более чем вдвое. [ необходима цитата ]
В типичной конфигурации ASP небольшой мэйнфрейм, такой как 360/40, называемый системой поддержки , управлял одним или несколькими процессорами 360/65 или более крупными, называемыми основными системами. Компьютеры были подключены через селекторные каналы на каждом хосте, подключенные к адаптерам канал-канал в ранней форме короткой, двухточечной компьютерной сети.
ASP требовала покупки дополнительного компьютера для управления вводом и выводом хостов, выполняющих рабочую нагрузку задания, что было экономически оправдано высокой стоимостью автономных каналов байт-мультиплексора, необходимых для управления принтерами и устройствами чтения перфокарт; [ требуется цитата ] системы 360/50 и меньшие имели встроенный канал байт-мультиплексора, тогда как более быстрые системы 360/65 и более крупные требовали относительно дорогого автономного устройства. Использование ASP позволило избежать стоимости канала байт-мультиплексора, а разгрузка планирования заданий, печати и обработки карт также разгрузила эти функции с более крупных машин. [ требуется цитата ]
Еще одним преимуществом, компенсирующим дополнительные затраты на оборудование, стала повышенная надежность. [ необходима цитата ] Одна или несколько основных систем могли выйти из строя или быть отключены для обслуживания без остановки всего комплекса.
ASP в первую очередь предназначался для крупных правительственных учреждений и оборонных подрядчиков, у которых могло быть до шести 360/65, все из которых планировались и управлялись отдельной машиной ASP. [ необходима ссылка ] Необычный вариант, локальный ASP ( LASP ), представлял собой одну большую машину с функциями ASP, работающими на той же машине.
В 1970-х годах известная инсталляция ASP была осуществлена в Принстонском университете для управления мэйнфреймом IBM 360/91. [ необходима цитата ]
В 1973 году IBM переписала ASP и переименовала его в JES3, поддерживая только MVS. [3]
В OS/VS1 также был JES , который часто назывался JES1 . [9] [10] Кроме того, главная подсистема ( MSTR ), встроенная в MVS, может запускать задания, которые выполняются вне контроля основной JES, включая главный планировщик и саму основную JES. [11] Первоначально JCL для главной подсистемы находился в загрузочных модулях, предоставленных IBM, но в текущих версиях MVS через z/OS он может быть предоставлен как член библиотеки системных параметров (PARMLIB).
Исходный код был предоставлен клиентам IBM как для ASP, так и для HASP, и многие клиенты внесли существенные улучшения в эти программы, некоторые из которых были включены в официальный продукт. [ требуется цитата ] Гораздо больше установок использовали HASP, чем ASP, и в современных системах z/OS существует гораздо больше установок JES2, чем JES3. [ требуется цитата ] Из-за своей уникальной истории IBM продолжает поставлять исходный код JES2 и JES3 вместо объектного кода , в отличие от большинства компонентов операционной системы. [ требуется цитата ]
Для улучшения удобства обслуживания и эксплуатации пользовательских улучшений JES предоставляет набор точек выхода, которые передают управление от JES к пользовательским программам в ключевых точках обработки. [ необходима ссылка ] Эти расширения могут предоставлять настраиваемые функции, такие как специальные команды, настраиваемые заголовки страниц печати и нестандартную обработку заданий.
В 2017 году IBM опубликовала заявление о направлении JES2 как «стратегического» JES, что означает, что все будущие усилия по разработке будут сосредоточены на JES2, а не на JES3. [12] IBM заверила клиентов, что JES3 будет продолжать поддерживаться до тех пор, пока не будет объявлена дата окончания поддержки. [13] [14] В феврале 2019 года IBM объявила, что z/OS 2.5 (ожидается, что будет выпущен в 2021 году) станет последней версией z/OS, включающей JES3. [15] В октябре 2019 года Phoenix Software International объявила, что она лицензировала исходный код JES3 у IBM и возьмет на себя его обслуживание и улучшение. [16]
IBM подтверждает, что JES2 является стратегической подсистемой ввода заданий для z/OS.