Подсистема Ввода Заданий JES в z/OS: Архитектура и Эволюция

Введение

Компонент операционной системы z/OS

Подсистема ввода заданий (JES) является компонентом операционных систем IBM MVS, отвечающим за управление пакетными рабочими нагрузками. В настоящее время существует две различные реализации системы ввода заданий – 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

HASP был разработан подрядчиками IBM Federal Systems Division в Космическом центре имени Джонсона в Хьюстоне. Подключив 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. Изначально JCL для подсистемы Master находился в загрузочных модулях, предоставляемых IBM, но в текущих версиях MVS через z/OS он может быть предоставлен как член библиотеки системных параметров (PARMLIB).

HASP was developed by IBM Federal Systems Division contractors at the Johnson Space Center in Houston. By attaching an IBM 7040 as a peripheral, processor throughput was more than doubled. In a typical ASP configuration, a small mainframe such as a 360/40 called the support system controlled one or more 360/65 or larger processors called main systems. The computers were connected through selector channels on each host attached to channel to channel adapters in an early form of short distance, point to point computer networking. ASP required the purchase of an additional computer to manage input and output of the hosts running the job workload, which was economically justified by the high cost of standalone byte multiplexor channels needed to drive printers and punched card reader devices; the 360/50 and smaller systems had a built in byte multiplexor channel, whereas the faster 360/65 and larger systems required a relatively expensive standalone unit. Using ASP made it possible to avoid the cost of the byte multiplexor channel, and offloading the job scheduling, print, and card handling also offloaded those functions from the larger machines. Increased reliability was another advantage to offset the added hardware cost. One or more main systems could fail or be taken offline for maintenance without taking down the whole complex. ASP was primarily targeted at large government agencies and defense contractors that might have as many as six 360/65s all being scheduled and managed by a separate ASP machine. An uncommon variant, local ASP (LASP), was a single large machine with the ASP functions running on the same machine. In the 1970s, a notable installation of ASP was at Princeton University controlling an IBM 360/91 mainframe. In 1973, IBM rewrote ASP and renamed it JES3, supporting MVS only. Originally the JCL for the Master subsystem was in an IBM provided load modules, but in current versions of MVS through z/OS, it can be provided as a member of the system parameter library (PARMLIB).

Настройка

Исходный код был предоставлен клиентам IBM как для ASP, так и для HASP, и многие клиенты внесли значительные улучшения в эти программы, часть которых была включена в официальную версию продукта. HASP использовался значительно больше, чем ASP, и в современных z/OS системах количество установок JES2 намного превышает количество установок JES3. В силу их уникальной истории, IBM продолжает поставлять исходный код JES2 и JES3 вместо объектного кода, в отличие от большинства компонентов операционной системы. Для повышения удобства сопровождения и обслуживания пользовательских улучшений, JES предоставляет набор точек выхода, которые передают управление от JES пользовательским программам в ключевых точках обработки. Эти расширения могут обеспечивать пользовательскую функциональность, такую как специальные команды, пользовательские заголовки страниц печати и нестандартную обработку заданий.

Современное развитие

В 2017 году IBM опубликовала заявление о стратегическом направлении развития JES2, обозначив его как "стратегический" JES, что означает, что все будущие разработки будут сосредоточены на JES2, а не на JES3. В октябре 2019 года компания Phoenix Software International объявила о получении лицензии на исходный код JES3 от IBM и о принятии на себя его поддержки и дальнейшего развития.