Лорин Г., Дейтел Х.М. Операционные системы. Главы 1-3

Подождите немного. Документ загружается.

по управлению ходом выполнения необходимых работ, а также по указанию

требуемых для этого ресурсов. Входной поток обычно состоит из программ и

соответствующих им данных. Операндная структура JCL реализуется

совокупностью ключевых параметров, взаимное расположение которых

произвольно. Язык предусматривает набор ключевых слов, например РGМ

(программа), DSNAME (имя набора данных), DISP (диспозиция — используется для

указания действий, производимых с наборами данных по завершении задания),

DEVICE (устройство — позволяет определить устройство или тип устройства для

размещения некоторого набора данных). Каждому предложению языка

соответствует свое множество ключевых слов, записываемых в виде КЛЮЧЕВОЕ

СЛОВО = список значений параметров. Этот список может быть достаточно

сложным. Некоторые параметры также обозначаются ключевыми словами,

имеющими для системы особый смысл. Ряд параметров (имена программ или

наборов данных) представляют собой ссылки на объекты, связанные с выполнением

конкретного задания.

Возможности ЕХЕС-предложения становятся ясными, если рассмотреть

соответствующий ему список ключевых слов. Так, ТIМЕ означает максимальное

время, отведенное для выполнения программы, REGION задает необходимый объем

памяти, а DPRTY указывает приоритет, который данная программа будет иметь в

условиях мультипрограммного режима выполнения.

С помощью DD-предложений определяются входные и выходные наборы

данных для программы, указанной в предложении ЕХЕС. Параметры DD-

предложений позволяют: 1) приписывать набор данных конкретному физическому

устройству или устройству какого-либо типа, 2) описывать действия, которые

необходимо выполнить с набором данных по завершении выполнения задания, 3)

описывать необходимые размеры дисковой памяти, 4) устанавливать соглашения

об использовании меток, 5) задавать параметры буферизации и размеры блоков, 6)

учитывать, требуется ли парольная защита набора данных.

Богатство, сложность и необычность JСL приводит к тому, что зачастую

составление управляющих предложений оказывается трудной задачей. Для

упрощения пользования этим языком во многих системах предусмотрены

механизмы, заранее устанавливающие значения многих параметров. Такими

механизмами являются умолчание, каталогизированные процедуры и замещение.

Умолчание представляет собой способ задания значений параметров

предложения в некоторый предшествующий момент времени, обычно при

генерации системы. Генерация системы (SYSGEN — SYStem GENeration) возможна

или до поставки ее пользователю, или на его установке. Если система сгенерирована

до поставки, то вычислительный центр получает «готовую к работе» систему с

заданными значениями большого числа параметров. Если же пользователю нужно

задать свои, особые значения параметров, соответствующую генерацию ему

придется выполнить самому.

При генерации системы всегда устанавливаются стандартные значения

большинства параметров JCL. Поэтому в дальнейшем, когда будут составляться

управляющие предложения, эти параметры могут быть опущены. К сожалению, при

таком порядке работы становится невозможным свободный перенос JCL-программ с

одной системы на другую. Необходимо всегда помнить о том, что значения,

получаемые параметрами по умолчанию в одной системе, должны совпадать со

значениями, получаемыми этими же параметрами по умолчанию в другой системе.

В противном случае наборы .JCL-предложений в разных системах могут приводить

к выполнению различных действий.

Еще один способ, позволяющий упростить составление управляющих

предложений JCL, — применение каталогизированных процедур.

Каталогизированная процедура представляет собой заранее подготовленную часть

входного потока, содержащую ЕХЕС- и DD-предложения. В потоке заданий на

каталогизированную процедуру можно ссылаться по ее имени. Каждая

каталогизированная процедура, как правило, имеет собственный набор

символических параметров. При вызове этой процедуры программисту достаточно

указать ее имя и задать значения этих параметров. Например, в результате

выполнения оператора //ЕХЕС РLIFCLС вызывается каталогизированная процедура,

которая осуществляет обращение к некоторой версии компилятора языка РL/1, а

также обеспечивает загрузку и выполнение скомпилированной программы.

Многие стандартные запросы реализуются каталогизированными

процедурами в чистом виде. Возможности каталогизированных процедур можно

расширить с помощью механизма замещения. Иногда вызов каталогизированной

процедуры дополняется управляющими предложениями, задающими новые

значения некоторых JCL-параметров. В этом случае при вызове процедуры значения

параметров предложений с теми же именами, что и у вновь заданных, изменяются в

ее теле на новые. Однако существуют соглашения, для соблюдения которых

программисту, использующему замещение, приходится подробно знакомиться с

порядком операндов в предложениях каталогизированной процедуры.

В качестве примера языка управления для пакетного режима можно привести

язык JCL. операционной системы OS фирмы IВМ. Любая операционная система,

поддерживающая пакетный режим, имеет подобный язык управления,

отличающийся от указанного, быть может, составом параметров, соотношением

обязательных параметров и параметров по выбору, а также синтаксисом. Язык JCL

системы OS фирмы IВМ—горизонтальный.

В языках управления систем DOS фирмы IВМ (Disk Operating System) и

ЕХЕС VIII для машин UNIVAC свойство горизонтальности выражено значительно

слабее. Эти языки содержат больше различных типов предложений, но их

операндная структура проще, чем в JCL. Они обладают многими процедурными

свойствами и в этом смысле напоминают обычные языки программирования.

2.3.3. Командный язык

В системах, ориентированных на режим диалога, трудно провести четкую

грань между программированием и составлением запросов. Программисту,

работающему за терминалом, в течение сеанса приходится и запускать программы,

и требовать от операционной системы выполнения некоторых услуг. Все это

удобнее было бы делать в рамках единых синтаксиса и семантики. В таком случае

язык управления, с одной стороны, синтаксически приблизился бы к языку

программирования, но с другой — частично утратил бы свою выразительность.

Однако, что касается командных языков, то они теряют свои выразительные

свойства далеко не всегда.

Командный язык иногда приобретает многие процедурные атрибуты языков

программирования, включая возможность организации циклов, наличие условных

операторов и вычислительные средства. А это значит, что вызов программ

операционной системы для выполнения размещения набора данных и обращение к

прикладной программе становятся весьма похожими. Может оказаться

осуществимым достаточно произвольное чередование предложений командного

языка и языка программирования.

Естественно, внутренняя структура системы каким-то образом отражает

отношения между командным языком и языком программирования. Транслятор

расширенной машины может или быть шаговым, т. е. выполнять построчную

компиляцию, или работать в режиме интерпретации.

Общим свойством командных языков является их недостаточная

выразительность. Пользователю, как правило, не разрешается самому указывать

необходимые для выполнения его программ ресурсы. Вместо этого определяется

набор правил и соглашений по использованию фактически фиксированной среды.

Такая среда обычно включают рабочее поле заданных размеров, набор доступных

функций и библиотеку, которая может служить для хранения функций,

определяемых пользователем в процессе работы. Находясь за терминалом,

программист производит всевозможные манипуляции в своем рабочем поле и,

кроме того, записывает программы и данные в библиотеку либо считывает их

оттуда. Подобная среда представляется удобной и простой. В качестве примера

можно привести программирование в системе APL. В отличие от JCL-программ

АПЛ-программы не предполагают задания собственной рабочей среды. Такие

команды, как СОРY (СКОПИРОВАТЬ), LOAD (ЗАГРУЗИТЬ) и START (НАЧАТЬ),

относятся непосредственно к программам и функциям, с которыми работает

пользователь. Вследствие упрощения командного языка и особенностей синтаксиса

АПЛ языки управления и программирования с точки зрения пользователя

практически сливаются.

Другие системы, предназначенные скорее не для пользователей, а для

профессиональных программистов, также допускают работу в режиме разделения

времени со стандартизованным и упрощенным интерфейсом, но, кроме того,

открывает широкие возможности манипулирования ресурсами системы и

программами, реализующиеся операторами ALLOCATE (РАЗМЕСТИТЬ),

ASSOCIATE (СВЯЗАТЬ), COMBINE (ОБЪЕДИНИТЬ) и т. д. Примерами таких

систем могут служить ТSO и СМS фирмы IВМ. Система UNIX также предоставляет

в распоряжение пользователя за терминалом богатый выбор функций. В этих

системах облегчение процессов составления и выполнения программ происходит

без потери выразительных средств соответствующих командных языков.

Вероятно, одним из лучших образцов командных систем, работающих в

диалоговом режиме, можно назвать систему Multics. Эта система разрабатывалась

как система общего назначения, т. е. для одновременного обслуживания

многочисленных пользователей с самыми различными запросами. Командный язык

системы Multics позволяет вводить программы с терминала, осуществлять их

редактирование и передачу на выполнение в режиме диалога или в режиме пакетной

обработки. Система позволяет обращаться с терминала к любой известной ей

процедуре и обеспечивает доступ с терминала к любой совокупности данных.

Командный язык предусматривает определение прав доступа пользователя с

терминала к любой процедуре и организованной совокупности данных.

Разнообразные функции, доступных в других системах только программам,

работающим с интерфейсами расширенной машины, Мultics реализуются (хотя и в

иной синтаксической форме) с помощью терминальных команд. Кроме того,

команды могут обмениваться параметрами, получать необходимые значения в

результате вызова процедур, а также объединяться в командные процедуры

(напоминающие каталогизированные процедуры JCL), вызываемые по именам. В

системе Мultics нашли свое отражение многие характерные черты современных

командных систем, которые мы рассмотрим в следующем разделе.

2.3.4. Взаимосвязь между языками

и общение с системой

В течение последнего десятилетия вопросы, связанные с командными

языками и языками управления, вызывали серьезные дискуссии. Предметом

дискуссий служили как сущность, так и специфические особенности этих языков.

Конечно, на первый план выступала проблема сущности языков, поскольку с ней

соприкасаются и другие важные проблемы, например взаимоотношения системы со

средой, в которой она работает. Ниже приводятся некоторые соображения по этому

поводу, и, хотя они носят несколько философский характер, для их понимания не

требуются специальные знания в области системного программирования. Читателю

было бы даже полезнее представить себя не в роли профессионального системного

программиста, а скорее как ответственного за организацию работы и эксплуатацию

вычислительной машины.

1. Вопрос о том, какую именно информацию следует сообщать системе на

языке управления, никогда не исследовался серьезно. В результате мы имеем

параметры, значения которых, безусловно, должны задаваться самими

программистами (уровни буферизации, определения структур данных), а также

параметры, определяемые по правилам, установленным администрацией

(приоритеты, распределение устройств). Многие параметры подразумевают

выполнение процедур проверки информации, содержащейся в управляющих

предложениях. Языки управления, разрабатывавшиеся в последнее время, обладали

свойствами и операторских языков, и языков, используемых администрацией, и

частично языков программирования. При этом совершенно не учитывалось, кому

именно придется с ними работать.

2. Из-за отмеченной выше нечеткости большинство известных языков

программирования и командных языков имеют различные пересечения.

Описательные средства таких языков, как ПЛ/1, Кобол, Алгол, настолько различны,

что до сих пор не удалось выработать общего представления о том, что же следует

считать программными функциями, а что—запросами на обслуживание.

3. Языки управления являются специализированными и содержат громоздкие

конструкции. Это приводит к ошибкам в выборе требуемых ресурсов и среды

выполнения. Рассматриваемые языки удобны лишь разработчикам системы,

которые предусматривают возможность задания определенной информации в

подходящей для них форме.

4. Структура языков чересчур разнообразна. Существуют не только языки

программирования, операторские языки, языки управления и генерации, но и

служебные языки, предназначенные для редактирования текстов, редактирования

связей, сортировки и т. д., причем в каждом случае различные синтаксические

формы служат для выражения примерно одинаковой семантики.

5. Соотношение между обязательными параметрами и параметрами по

выбору редко бывает удачным. Действительно, сложность использования языков

управления противоречит их основному назначению, так как приводит к

непредусмотренным авторами формам их применения. Предполагалось, что языки

управления в конкретной ситуации позволят точно оговорить те услуги, которые

программист хочет получить от системы. При умелом управлении ресурсами это

должно снизить общую стоимость выполнения задания. Кроме того, определение

ресурсов, необходимых каждой программе, дает возможность оптимизировать

эксплуатацию аппаратуры. Но из-за сложности языков управления более широкое

распространение получили стандартные наборы управляющих предложений.

Программисты не только не изменяют управляющих карт при обработке одними и

теми же программами различных данных, хотя, конечно, для манипуляции с ними

нужны разные по размеру области памяти и различное время выполнения, но и

стараются придерживаться одной и той же проверенной последовательности

предложений при проведении любых работ, пусть даже требующих совершенно

различных ресурсов.

6. Поскольку языки управления существенно зависят от структур

операционных систем, каждый из них фактически годится только для некоторого

состояния системы. Вследствие развития систем и функционального обогащения

среды выполнения меняются как семантика запросов, так и отношения между

расширенными машинами и языками управления. Поэтому старые языки

управления неизбежно перестают соответствовать новым условиям.

Пользователи делятся на тех, кто стремится к активному управлению

вычислительными ресурсами, и на тех, кому такое стремление не свойственно.

Программисты, удовлетворенные стандартным набором ресурсов и стандартным

определением среды выполнения, воспримут необходимость самостоятельного

описания и распределения требуемых ресурсов как серьезное неудобство.

Пользователи же, высоко ценящие гибкость программирования, будут это

рассматривать как дополнительное удобство. (Разнообразие средств обременяет

одних, а их недостаток раздражает и сковывает других.) Конечно, хороший

синтаксис пред почтительнее, чем плохой, простота восприятия лучше, чем

сложность, четкость семантики удобнее, чем двусмысленность, но в конечном счете

достоинства языка определяются тем, насколько его возможности соответствуют

желаниям программиста по управлению вычислительной средой.

Уже неоднократно обсуждался вопрос о будущем языков управления.

Выдвигалось предложение о том, чтобы такие языки вообще отменить. Параметры

должны задаваться с помощью синтаксических конструкций языков

программирования или на уровне администрации вычислительного центра.

Подобные параметры предназначаются для описания типов пользователей, а также

абсолютной и относительной важности решаемых ими задач. Другая точка зрения

состоит в том, что со временем постепенно начнет повышаться роль работы в

диалоговом режиме. Это естественным образом приведет к исчезновению языков

управления и возникновению новых, более четких языков.

Один из редко обсуждающихся аспектов применения языков управления —

общение с системой. В прошлом вычислительные системы обычно ориентировались

на языки программирования как на основной интерфейс. Фактически системы

представляли собой реализации ПЛ/1-, Кобол- или Фортран-машин. В таких

условиях естественна была мысль о том, что задание параметров управляющего

языка связано с дополнительными хлопотами и мешает основной работе —

написанию программы. Теперь некоторые разработчики считают, что настоящим

системным интерфейсом служит язык управления. Общение с системой происходит

на языке управления, специализированными подмножествами которого являются

языки программирования. Язык управления должен иметь структуру, позволяющую

решать прикладные задачи с помощью команд самого языка. И утилиты, и пакеты

прикладных программ необходимо вызывать средствами языка управления. Может

случиться так, что средств этого языка, например команд SOРТ, СОРY и

SUММАRIZЕ, хватит для решения целиком всей прикладной задачи.

Если язык управления не содержит некоторой функции, то для ее описания

пользователю следует спуститься на уровень языков программирования, например,

таких, как РПГ или ПЛ/1. После этого соответствующую функцию можно сделать

функцией командного языка. Отношения между командным языком и языками

высокого уровня, таким образом, напоминают отношения между языками высокого

уровня и языком Ассемблера. В случае недостаточной гибкости используемого

языка программирования всегда можно обратиться к языку Ассемблера для

реализации какой-либо отсутствующей функции.

Рассмотренный подход привел бы к созданию систем со следующими

характеристиками:

• программа на командном языке выполнялась бы пошагово, команда за

командой, или компилировалась и затем выполнялась бы целиком;

• функции, доступные программам, выполняющимся на расширенной

машине, однозначно отображались бы в функции командного языка. Решение

неизбежного при создании системной поддержки вопроса о том, какие функции

следует вызывать до выполнения программы, а какие на этапе выполнения, не

влияло бы па структуру командного языка;

• командный язык предоставлял бы достаточные вычислительные средства,

что позволило бы минимизировать обращения к уровню языков программирования;

• синтаксис и семантика командного языка могли бы быть так же хорошо

изучены, как синтаксис и семантика языков программирования. Командный язык

имел бы несколько уровней и подмножеств, предназначенных для различных групп

пользователей.

Определить удобный системный интерфейс можно только обладая

достаточными знаниями о структуре системы. В заключение, чтобы создать у

читателей более полное представление о современных тенденциях в области

системного программирования, заметим, что существует определенная группа

теоретиков этой дисциплины, считающих вопросы, связанные с командными

языками и языками управления, неподходящими для рассмотрения в книге по

системному программированию.

Как утверждают сторонники этого подхода, определение рабочих

интерфейсов входит в компетенцию специалистов, изучающих потребности

соответствующих групп пользователей. Разработчику операционной системы

следует делать лишь то, что он может делать хорошо, т. е. обеспечивать некоторую

системную структуру и набор основных элементов, из которых в дальнейшем

можно строить необходимые интерфейсы.

2.3.5. Виды доступа

До сих пор мы рассматривали командные языки и языки управления, имея в

виду их применение в качестве среды доступа к вычислительной системе. Ниже

приводятся известные сегодня способы доступа.

1. Доступ по расписанию. Доступ этого вида предполагает наличие

специальной службы, которая составляет расписание работы с вычислительной

системой и следит за его соблюдением. Каждый пользователь на некоторое время

получает машину в свое полное распоряжение. Такой способ доступа является

простейшим и в настоящее время иногда применяется для выполнения работ,

требующих создания особых условий, например при разработке новой

операционной системы. Тестирование программ новой системы обычно сопряжено с

монопольным использованием аппаратных средств, исключающих возможность

одновременной работы какой-либо другой программной системы на этом

оборудовании. Современные виртуальные операционные системы способны

создавать эффект «чистого» оборудования путем моделирования, что очень удобно

при отладке новых систем. Программисты, выполняющие отладку в средах,

получают полную иллюзию доступа по расписанию.

2. Централизованный ввод заданий. В отличие от предыдущего способа здесь

исчезает служба расписаний, но появляется оператор. Заявки на выполнение работ

поступают в машинный зал в форме физических носителей, содержащих

предложения языка управления и собственно программы. Выполнение некоторого

конкретного задания практически считается завершенным, когда оператор кладет

листинг в специально отведенное место, откуда этот листинг может быть взят

пользователем. Операционная система 1) обрабатывает входной поток заданий,

поступающий обычно через устройство считывания перфокарт, и 2) организует

выполнение этих заданий в установленной оператором последовательности. В

принципе допускается изменение порядка выполнения заданий. Изменение порядка

характерно для систем третьего поколения. Заявки выстраиваются во внутреннюю

очередь, обрабатываемую компонентом операционной системы — так называемым

планировщиком. Исходная информация планировщику задастся оператором при

вводе последовательности заданий. Распределение происходит по заранее

определенным алгоритмам, причем приоритеты и выделяемые ресурсы

описываются с помощью соответствующих параметров предложений языка

управления.

3. Управляемый пользователем ввод пакетных заданий (Удаленный ввод

заданий}. При этом виде доступа, реализуемом в форме расширения операционной

системы, отпадает необходимость в посредничестве каких-либо служб между

пользователем и системой. Программисты могут работать непосредственно на

терминальной станции, оснащенной устройствами ввода с карт и печати.

Существует протокол связи между терминальной станцией и основной системой,

согласно которому при выполнении удаленного ввода задания активизируется

некоторый компонент операционной системы, принимающий заявку и ставящий

введенное задание в очередь заданий, ожидающих обслуживания. Терминальная

станция географически может находиться как рядом с основной системой, так и

вдали от нее. Важная особенность указанного способа доступа состоит в том, что

для принятия заявок и выдачи результатов не требуется оператор. Фактически

операционная система «выводится» за пределы машинного зала.

4. Интерактивный ввод пакетных заданий. Такой доступ четко отделяет

программирование от запросов на обслуживание, но зато сами запросы позволяет

формировать динамически. С телетайпа или терминала, оснащенного экраном,

пользователь осуществляет диалог с элементами системы, обслуживающими заявки

на выполнение заданий. Как правило, этому пользователю предоставляются

достаточно простой язык управления архивом и соответствующая библиотека. В

библиотеку записываются и в ней хранятся некоторые предложения языка

управления, а иногда и часть программ. Имеются средства изменения содержимого

библиотеки и формирования входного потока. Пользователю также может

разрешаться ввод предложений программы с построчной проверкой синтаксиса.

Когда задание будет полностью подготовлено, выдается команда, по которой

определенный входной поток обрабатывается как часть общего входного потока

системы с мультипрограммным режимом. Подсистема, обеспечивающая

диалоговую работу с терминала, передает введенное задание операционной системе

для выполнения в режиме пакетной обработки, и с этого момента оно перестает

быть доступным пользователю. Примером рассмотренного способа доступа может

служить компонент CRJE (Conversational Remote Job Entry — диалоговый

удаленный ввод заданий в операционной системе OS/МVТ фирмы IВМ).

5. Программирование в режиме диалога. Этот вид доступа в значительной

степени напоминает предыдущий. Сначала программа вводится, а затем выдается

команда RUN, в результате чего осуществляются ее компиляция и выполнение.

Такой порядок работы был принят в ранних системах ВASIС.

Однако процессы программирования и выполнения могут быть совмещены

по времени. При этом допускается выполнение синтаксически незавершенных

программ, причем фактическое программирование чередуется с выполнением уже

написанных частей. В системах, поддерживающих указанный способ доступа,

командные языки и языки программирования иногда объединяются. Подобными

свойствами обладала теперь уже очень старая система JOSS. Различные системы

разделения времени, ориентированные на одновременное обслуживание

многочисленных программистов, работающих за терминалами в режиме диалога,

позволяют получать различные соотношения между программированием, запросами

на обслуживание и выполнением.

6. Сетевой доступ. В последнее время возрос интерес к вопросам

дальнейшего развития способов доступа с целью обеспечения взаимодействия

систем. Сетевой доступ, или, как его иначе называют, способ распределенной

обработки, дает пользователю возможность обращаться к программам и данным,

находящимся не только на его вычислительной машине, но и на других установках.

При таком способе доступа возникает целый ряд проблем, связанных со степенью

осведомленности пользователя о месте фактического выполнения его программы: в

каких случаях программы должны перемещаться к данным, в каких — данные к

программам, как организовать общение между различными операционными

системами. Следующим принципиальным шагом в разработке операционных систем

должен стать выбор подходящих структур и. интерфейсов для обеспечения

сетевого доступа и распределенной обработки.

2.4. СОЗДАНИЕ ОПЕРАЦИОННОГО ИНТЕРФЕЙСА

Операционный интерфейс в узком смысле может быть определен как

совокупность работы оператора за пультом и осуществления манипуляции с

устройствами и носителями данных. В широком смысле этот термин связан, кроме

того, с ведением архива магнитных лент, выполнением соответствующих функций

системными программистами, диспетчерами, координаторами, службами

подготовки данных и с другой деятельностью, носящей административный и

операторский характер. В дальнейшем мы примем за основу первое определение

операционного интерфейса и сосредоточим свое внимание на одной из основных

проблем — отсутствии явных различий между административными и

операторскими функциями, что позволяет операторам, находящимся за пультом,

принимать чисто административные решения, изменяя статусы программ и их

приоритеты.

Задачи оператора не удалось четко сформулировать ни для одной из систем.

В некоторых системах функции программистов и операторов практически

объединены, но есть и системы, где имеет место строгое разделение обязанностей. В

системах диалогового типа различия между командными и операторскими языками

принимают чисто условный характер.

Обычно операторский язык позволяет выполнять следующие действия:

• изменять конфигурацию системы;

• запускать задание;

• приостанавливать или прекращать выполнение задания;

• получать информацию о статусе задания;

• изменять его приоритет;

• запускать и модифицировать систему («начальная загрузка»).

Кроме того, операционной системой ведется журнал регистрации событий, в

котором отмечаются завершения заданий, сбои, очередизация вывода и

распределение устройств. В нужные моменты также печатаются (или

высвечиваются на экране) директивы на установку и снятие носителей.

Изложенное выше позволяет получить представление о тех

административных функциях, которые могут быть выполнены оператором,

находящимся за пультом. Во многих системах для обеспечения контроля

предусматриваются средства по определению полномочий отдельных лиц из

обслуживающего персонала. Параметры, задаваемые при генерации операционной

системы. дают возможность создать парольную защиту операторских функций и их

распределение по терминалам.

В дополнение к распределению по полномочиям существует также

распределение по семантике операций. Например, при наличии нескольких пультов

системная поддержка, как правило, организована таким образом, что сообщения,

касающиеся выполнения заданий в пакетном режиме, поступают на один пульт, а

сообщения, касающиеся их выполнения в режиме диалога, — на другой.

Следовательно, все сообщения о подключении и отключении терминалов, а также

сообщения пользователей, работающих за терминалами, отделяются оператором от

прочих системных сообщений, отражающих процесс решения задач в пакетном

режиме и не требующих столь пристального внимания.

В рамках операционной системы также может осуществляться поддержка

работы терминалов, находящихся в помещениях для храпения дисков или лепт. С

этих терминалов передаются запросы на доставку дисков или лент в машинный зал,

а иногда и на установку лент или дисков на устройства, расположенные

непосредственно в архиве.

Специфика системно поддерживаемого операционного интерфейса обычно

отражает уровень распределения функций управления вычислительной установкой