Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
z/OS операциялық жүйесінің компоненті
Component of the z/OS operating system
Job Entry Subsystem (JES) – IBM-нің MVS операциялық жүйелерінің бір бөлігі болып табылады және топтық жұмыс жүктемесін басқаруға жауапты. Қазіргі кезде JES2 және JES3 деп аталатын Жұмыс кіргізу жүйесінің екі бөлек түрі бар. Олар топтық жұмыстарды тиімді орындау үшін құрастырылған. Жұмысты өңдеу параллелизмді құбыр арқылы қамтамасыз ету үшін бірнеше кезеңге бөлінеді. Бұл кезеңдерге жұмыстарды оқу және түсіндіру, орындалу кезеңі (жұмыстар орындалатын кезең) және шығыс өңдеу (жұмыс нәтижелерін DASD-ге басып шығару немесе сақтау) кіреді. Орындалудың бір кезеңіндегі жұмыстар әдетте белгілі бір кезекте орналасады; мысалы, қазіргі уақытта орындалып жатқан жұмыстар орындалу кезегінде болады. I/O тиімділігін арттыру үшін JES spooling-ті қолданады, бұл бірнеше жұмыстың ортақ сақтау көлеміне бір уақытта қол жеткізуін қамтамасыз етеді. JES аталған бақылау нүктесі (checkpoint) құрылымын қолданады, ол қазіргі орындалып жатқан жұмыстар мен оларға байланысты шығыстар туралы ақпаратты сақтайды. Бақылау нүктесі күтпеген аппараттық немесе бағдарламалық қателер болған жағдайда жұмыстарды және шығыстарды қалпына келтіру үшін пайдаланылуы мүмкін. JES2 және JES3 бірдей негізгі функционалдықты ұсынса да, біреуінде болса, екіншісінде жоқ кейбір мүмкіндіктер бар. Осы айырмашылықтарға байланысты, кейбір клиенттік орналымдарда біздің ЖЭС екіншісіне қарағанда артықшылыққа ие болуы мүмкін. JCL екі JES2 және JES3 үшін жұмыстарды анықтау үшін қолданылады, бірақ бір JES үшін жазылған жұмысты екіншісінде орындау үшін JCL-ге көбінесе шағын өзгерістер енгізу қажет. Жиі кездесетін мәселе – JES3 JCL-де тізімделген барлық деректер жиынтығының орындалу алдында бар екенін немесе деректер жиынтығын NEW,CATLG ретінде анықтаған бұрынғы қадамның бар екенін тексерді. JES2 мұндай талапқа бағынбады, тіпті оны пайдаланатын қадам оны таба алмаса да, жұмысты орындауға рұқсат берді.
The Job Entry Subsystem (JES) is a component of IBM's MVS mainframe operating systems that is responsible for managing batch workloads. In modern times, there are two distinct implementations of the Job Entry System called JES2 and JES3. They are designed to provide efficient execution of batch jobs. Job processing is divided into several phases to provide parallelism through pipelining. These phases include input processing where jobs are read and interpreted, the execution phase where jobs run, and output processing where job output is printed or stored on DASD. Jobs that are in the same phase of execution are usually said to reside on a particular queue; for example, jobs that are currently executing are on the execution queue. To improve I/O efficiency, JES performs spooling, which provides multiple jobs with simultaneous access to a common storage volume. JES uses a structure called a checkpoint to backup information about currently executing jobs and their associated output. The checkpoint can be used to restore jobs and output in the event of unexpected hardware or software failures. Although JES2 and JES3 provide the same core functionality, there are certain features that may be present in one JES but not the other. Because of these differences, one JES may be favored over the other in certain customer installations. JCL is used to define jobs to both JES2 and JES3, but small changes usually need to be made to the JCL to get a job written for one JES to run on the other. A common issue was that JES3 checked that all datasets listed in the JCL existed before execution or that there was a prior step where the dataset was defined as NEW,CATLG. JES2 did not insist on this, allowing the job to run even though it would fail when the step using it failed to find it.
Алдын ала өнімдер
OS/360-тың пакеттік тапсырмаларды өңдеуінің операциялық икемділігі мен өнімділігі шектеулі болды, бұл Хьюстон автоматты түрде шығару басымдығы (HASP) және Қосылған қолдау процессоры (ASP) деп аталатын екі далалық әзірленген бағдарламалық пакеттер арқылы шешілді.
OS/360's batch job processing had limited operational flexibility and performance, which was addressed by two field developed packages called the Houston Automatic Spooling Priority (HASP) and the Attached Support Processor (ASP).
HASP
HASP Хьюстондағы Джонсон ғарыш орталығында IBM Federal Systems бөлімінің мердігерлерімен жасалды. 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-ті қолдады. Алғашқыда Master қосалқы жүйесіне арналған JCL 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 жүйелерінде JES3-ге қарағанда JES2 орнатылымдары көп. Олардың ерекше тарихына байланысты, IBM операциялық жүйенің көптеген компоненттерінен айырмашылығы, объектілік кодтың орнына JES2 және JES3 бастапқы кодын жеткізуді жалғастыруда. Пайдаланушылар жасаған жақсартулардың техникалық қолдау және қызмет көрсетуін жақсарту үшін JES, негізгі өңдеу кезеңдерінде JES-тен пайдаланушы бағдарламаларына басқаруды жүзеге асыратын шығу нүктелері жиынтығын ұсынады. Бұл кеңейтулер арнайы командалар, басу беттерінің тақырыптары және стандартты емес жұмыс процестері сияқты қосымша мүмкіндіктерді қамтамасыз ете алады.
Source code was provided to IBM customers for both ASP and HASP, and many customers made substantial enhancements to these programs, some of which were incorporated into the official product. Far more installations made use of HASP than ASP, and in contemporary z/OS systems, there are many more JES2 installations than JES3. Because of their unique history, IBM continues to ship JES2 and JES3 source code instead of object code, unlike most components of the operating system. To improve maintainability and serviceability of user written enhancements, JES provides a set of exit points that pass control from the JES to user programs at key points of processing. These extensions can provide custom functionality such as special commands, custom print page headings, and non standard job processing.
Қазіргі дамуы
2017 жылы IBM JES2-ні «стратегиялық» JES деп белгіледі, яғни болашақ даму жұмыстарының барлығы JES3-ке емес, JES2-ге шоғырланады. 2019 жылдың қазан айында Phoenix Software International компаниясы IBM-ден JES3 бастапқы кодын лицензия алғанын және оның техникалық қолдауын және жаңартуларын өз міндетіне алатынын хабарлады.
In 2017, IBM released a statement of direction for JES2 to be the "strategic" JES, meaning that all future development efforts will be focused on JES2 rather than JES3. In October 2019, Phoenix Software International announced that it had licensed the JES3 source code from IBM and would be taking over its maintenance and enhancement.