Бурроустың MCP операциялық жүйесі: тарихы мен ерекшеліктері

Кіріспе

Мейнфрейм компьютерлік операциялық жүйе

MCP (Master Control Program) – Burroughs B5000/B5500/B5700 және B6500 және оның ізбасарларының, соның ішінде Unisys Clearpath/MCP жүйелерінің операциялық жүйесі. MCP бастапқыда 1961 жылы ESPOL (Executive Systems Problem Oriented Language) тілінде жазылған. 1970 жылдары MCP, ESPOL-дің жақсы құрылымдалған, сенімді және қауіпсіз түрі болған NEWP-ге түрлендірілді. MCP көптеген салаларда алғашқы болып табылды, оның ішінде: бірнеше процессорды басқаруға арналған алғашқы операциялық жүйе, виртуалды жадты алғашқы коммерциялық енгізілімі және жоғары деңгейдегі бағдарламалау тілінде жазылған алғашқы операциялық жүйе.

Тарих

1961 жылы MCP жоғары деңгейдегі тілде (HLL) ғана жазылған алғашқы операциялық жүйе болды. Burroughs Large System (B5000 және одан кейінгілері) ерекшеліктерінің бірі – барлық бағдарламалық жасақтама, оның ішінде жүйелік бағдарламалық жасақтама да, құрастыру тілінің орнына HLL-де жазылатын болады деген болжаммен жасалған. Бұл 1961 жылы өте жаңа және инновациялық тәсіл еді. Джин Амдал кеткеннен кейін аппараттық бәсекеге тап болған IBM-нен айырмашылығы, Burroughs бағдарламалық жасақтамасы тек Burroughs аппараттық құралдарында ғана жұмыс істеді, себебі үйлесімді үшінші тараптан аппараттық құралдар жетіспеді. Осы себепті, Burroughs өзі сатқан барлық бағдарламалық жасақтаманың, соның ішінде осы ашықтықты ескере отырып жасалған MCP-нің бастапқы кодын еркін тарата алды. Мысалы, жаңарту үшін пайдаланушы жүйелік бағдарламалық жасақтаманы қайта құрастырып, қажетті жергілікті түзетулерді енгізуі керек болды. Бұл сол кездегі қалыпты жағдай еді, себебі клиенттердің, әсіресе ірі клиенттердің (мысалы, Федералды резерв) бағдарламаны өздерінің нақты қажеттіліктеріне сәйкес өзгетуі жиі кездесетін жайт болатын. Осының нәтижесінде Burroughs пайдаланушылар тобы құрылды, ол жыл сайынғы жиналыстар өткізіп, пайдаланушыларға операциялық жүйеге және жүйелік бағдарламалық қамтамасыз ету жиынтығының басқа бөліктеріне өздерінің кеңейтулерін алмасуға мүмкіндік берді. Көптеген мұндай кеңейтулер жылдар бойы негізгі операциялық жүйе кодын құрап, қазір барлық клиенттерге қолжетімді. Осылайша, MCP ең алғашқы ашық кодты жобалардың бірі деп санауға болады. Burroughs бастапқы кодты таратқан алғашқы өндіруші емес, және ол электрондық есептеуге салыстырмалы түрде кеш кірді (дәстүрлі бәсекелестері NCR, IBM және Univac-пен салыстырғанда). Қазір MCP стандартты аппараттық құралдарда жұмыс істейтін болғандықтан, MCP-ге негізделген бағдарламалық жасақтаманың кейбір элементтері енді Unisys тарапынан бастапқы код түрінде қолжетімді емес. MCP виртуалды жадты қамтамасыз еткен алғашқы коммерциялық операциялық жүйе болды, және ол Burroughs ірі жүйелер архитектурасының бастапқы қағидаларының бірі болды. Бұл схема индустрияда бірегей, себебі ол компилятормен анықталған объектілерді сақтайды және қайтарып алады, ал белгіленген өлшемдегі жад беттері емес, оның жалпы фон Нейман емес және біркелкі стек негізделген архитектурасының салдары ретінде. Unisys 2010 жылдардың басында аппараттық құралдарды өндіруді тоқтатты, ал операциялық жүйе қазір эмуляция арқылы жұмыс істейді.

In 1961, the MCP was the first OS written exclusively in a high level language (HLL). The Burroughs Large System (B5000 and successors) were unique in that they were designed with the expectation that all software, including system software, would be written in an HLL rather than in assembly language, which was a unique and innovative approach in 1961. Unlike IBM, which faced hardware competition after the departure of Gene Amdahl, Burroughs software only ever ran on Burroughs hardware due to a lack of compatible third party hardware. For this reason, Burroughs was free to distribute the source code of all software it sold, including the MCP, which was designed with this openness in mind. For example, upgrading required the user to recompile the system software and apply any needed local patches. At the time, this was common practice, and was necessary as it was not unusual for customers (especially large ones, such as the Federal Reserve) to modify the program to fit their specific needs. As a result, a Burroughs Users Group was formed, which held annual meetings and allowed users to exchange their own extensions to the OS and other parts of the system software suite. Many such extensions have found their way into the base OS code over the years, and are now available to all customers. As such, the MCP could be considered one of the earliest open source projects. Burroughs was not the first manufacturer to distribute source code and was a late entry to electronic computing (compared to its traditional rivals NCR, IBM, and Univac). Now that MCP runs on commodity hardware, some elements of the MCP based software suite are no longer made available in source form by Unisys. The MCP was the first commercial OS to provide virtual memory, which has been supported by the Burroughs large systems architecture since its inception. This scheme is unique in the industry, as it stores and retrieves compiler defined objects rather than fixed size memory pages, as a consequence of its overall non von Neumann and uniformly stack based architecture. Unisys stopped producing the hardware in the early 2010s, and the operating system is now run under emulation.

Файл жүйесі

MCP иерархиялық каталог құрылымы бар файл жүйесін ұсынады. Алғашқы MCP нұсқаларында каталогтар басқа жүйелердегідей, каталог жазбалары бар жеке файлдар түрінде бейнеленген. Алайда, шамамен 1970 жылдан бастап MCP ішкі түрде 'FLAT' каталогын пайдаланады, онда томдағы барлық файлдық жолдар тізімделеді. Бұл, файлдарды файлдық жол бойынша іздеп, әрбір каталогты ашудың тиімсіздігіне және өндірістік ортада барлық файлдарды бір каталогта сақтаудың жақсырақ екендігіне байланысты болды, тіпті олар иерархиялық атау схемасын сақтайтын болса да. Бағдарламалық тұрғыдан бұл ешқандай айырмашылық жасамайды. Пайдаланушылар үшін көрінетін жалғыз айырмашылық – файлдың атауы каталогтың атауымен бірдей болуы мүмкін. Мысалы, "A/B" және "A/B/C" екеуі де қатар болуы мүмкін; "B" бір мезгілде файлда да, каталогта да түйін бола алады. Файлдар атаулы томдарда сақталады, мысалы, 'myvol' томындағы 'осы/осы/файл_атауы', мұнда 'myvol' – томның атауы. Бұл құрылғыдан тәуелсіз, себебі 'myvol' томын қамтитын дискіні басқа физикалық дискілерге көшіруге немесе көшіруге болады. Дискілерді бірнеше дискіде бір томды орнату үшін, сондай-ақ маңызды деректерді қалпына келтіру үшін айналдыруға болады. Қосымша икемділік үшін әрбір бағдарлама томдарды алмастыруды жасай алады, томның атауы негізгі және қосымша алмастыратын атаумен ауыстырылуы мүмкін. Бұл процесс 'FAMILY' деп аталады. Мысалы, 'FAMILY DISK = USERPACK OTHERWISE SYSPACK' тапсырмасы логикалық түрде DISK томында белгіленген файлдарды USERPACK томында сақтайды және файлдарды алдымен USERPACK томында іздейді. Егер бұл іздеу сәтті болмаса, файл SYSPACK томында ізделеді. Егер ешқандай том көрсетілмесе, DISK – әдепкі том атауы. Жүйедегі әрбір файлдың файл атрибуттарының жиынтығы болады. Бұл атрибуттар файл туралы барлық метадеректерді, ең бастысы оның атауын және түрін (Macintosh-тағы төрт таңбалы файл түрінің коды сияқты, файлды қалай өңдеу керектігін жүйеге хабарлайды) тіркейді. Басқа атрибуттарда файлдың жазба көлемі (егер коммерциялық қолданбалар үшін белгіленген болса), блок көлемі (бір физикалық I/O операциясында қанша жазбаны оқу және жазу керектігін көрсететін жазбалардың еселігі) және файл кеңейгенде бөлінетін дискілік аумақтардың көлемін анықтайтын блоктардың еселігіндегі аймақ көлемі болады. Файл түрі файлдың таңбалық деректер, нақты бір тілдерде жазылған бастапқы код, екілік деректер немесе код файлдары екенін көрсетеді. Файлдар әдеттегі қауіпсіздікке қол жеткізу механизмдерімен, мысалы, жалпыға қолжетімді немесе жекемен қорғалады, немесе файлдың иесі күрделі қауіпсіздік ережелерін анықтай алатын күзет файлы болуы мүмкін. Басқа қауіпсіздік механизмі – код файлдарын тек сенімді компиляторлар ғана құра алады. Зардапты бағдарламашылар бағдарламаны жасап, оны компилятор деп атауға құқылы емес. Бағдарламаны компиляторға жеткілікті құқықтары бар оператор 'mc' make compiler оператор командасы арқылы ғана түрлендіре алады. MCP журналдау файл жүйесін іске асырады, бұл дискінің істен шығуы, қуаттың жоғалуы және т.б. жағдайларда қатеге төзімділікті қамтамасыз етеді. Файл жүйесін бұзу мүмкін емес (оның төменгі қабаттарына тікелей қол жеткізімі бар операциялық жүйе немесе басқа сенімді жүйелік бағдарламалық жасақтамадан басқа). Файл жүйесі үлкен-кішілі әріптерге сезімтал емес және үлкен-кішілі әріптерді сақтамайды, егер атаудың айналасына тырнақшалар қосылмаса, онда ол үлкен-кішілі әріптерге сезімтал және үлкен-кішілі әріптерді сақтайды.

The MCP provides a file system with hierarchical directory structures. In early MCP implementations, directory nodes were represented by separate files with directory entries, as other systems did. However, since about 1970, MCP internally uses a 'FLAT' directory listing all file paths on a volume. This is because opening files by visiting and opening each directory in a file path was inefficient and for a production environment it was found to be better to keep all files in a single directory, even though they retain the hierarchical naming scheme. Programmatically, this makes no difference. The only difference visible to users is that an entity file can have the same name as a directory. For example, "A/B" and "A/B/C" can both exist; "B" can be both a node in a file and a directory. Files are stored on named volumes, for example 'this/is/a/filename on myvol', 'myvol' being the volume name. This is device independent, since the disk containing 'myvol' can be moved or copied to different physical disk drives. Disks can also be concatenated so that a single volume can be installed across several drives, as well as mirrored for recoverability of sensitive data. For added flexibility, each program can make volume substitutions, a volume name may be substituted with a primary and secondary alternate name. This is referred to as the process’ FAMILY. For instance, the assignment “FAMILY DISK = USERPACK OTHERWISE SYSPACK” stores files logically designated on volume DISK onto the volume USERPACK and will seek files first on volume USERPACK. If that search has no success, another search for the file is done on volume SYSPACK. DISK is the default volume name if none is specified. Each file in the system has a set of file attributes. These attributes record all sorts of meta data about a file, most importantly its name and its type (which tells the system how to handle a file, like the more limited four character file type code on the Macintosh). Other attributes have the file's record size (if fixed for commercial applications), the block size (in multiples of records that tells the MCP how many records to read and write in a single physical IO) and an area size in multiples of blocks, which gives the size of disk areas to be allocated as the file expands. The file type indicates if the file is character data, or source code written in particular languages, binary data, or code files. Files are protected by the usual security access mechanisms such as public or private, or a file may have a guard file where the owner can specify complex security rules. Another security mechanism is that code files can only be created by trusted compilers. Malicious programmers cannot create a program and call it a compiler – a program could only be converted to be a compiler by an operator with sufficient privileges with the 'mc' make compiler operator command. The MCP implements a Journaling file system, providing fault tolerance in case of disk failure, loss of power, etc. It is not possible to corrupt the file system (except by the operating system or other trusted system software with direct access to its lower layers)
The file system is case insensitive and not case preserving unless quotes are added around the name in which case it is case sensitive and case preserving.

Процестерді басқару

MCP процестері «Жұмыс» және «Тапсырма» деп аталады. Жұмыста бір немесе бірнеше тапсырма болады. Жұмыстағы тапсырмалар тізбектей немесе параллель түрде орындалуы мүмкін. Логиканы жұмыс деңгейінде, әдетте, MCP-нің жұмыс басқару тілінде (WFL) іске асыруға болады, жұмыс ағынын басқару үшін. Жұмыстағы барлық тапсырмалар орындалғаннан кейін, жұмыстың өзі аяқталады. MCP процесі жүйеге кіргеннен бастап, одан шыққанға дейін өмірлік циклден өтеді. Жұмыстың бастапқы күйі – «Кезекте». Жұмыс бірнеше пайдаланушы анықтаған жұмыс кезектерінің бірінде тұрған уақыт аралығы бар. Келесі күй – «Жоспарланған», өйткені жұмыс кезектен жадқа өтеді. Жұмыстағы тапсырмалар кезекке тұрмайды, олар басталған кезде тікелей «Жоспарланған» күйіне өтеді. Жұмысты немесе тапсырманы бастағаннан кейін, ол «Белсенді», «Күтуде» және «Жоспарланған» аралығында ауыса алады. Жұмыстың немесе тапсырманың аяқталуы «Аяқталды» күйіне ауысады. Іске қосылып жатқан процестер – процессор ресурсын пайдаланатын және «іске қосылып жатыр» деп белгіленетін процестер. Бос процессор болмаған кезде процессорға тағайындауға дайын процестер дайын кезекке орналастырылады. Процестерге «Жарланған» немесе «Көрінетін» басымдық беріледі, әдетте 50 – әдепкі мән, бірақ пайдаланушы процестері үшін 0-ден 99-ға дейін болуы мүмкін. Жүйелік процестерге жоғары мәндер берілуі мүмкін. Бұл сандық басымдық тапсырма түріне негізделген жалпы басымдыққа қарағанда екіншілік екенін ескеріңіз. Операциялық жүйенің тікелей бөлігі болып табылатын процестер, «Тәуелсіз орындаушылар» деп аталады, сандық басымдық мәніне қарамастан, ең жоғары басымдыққа ие. Содан кейін MCP құлпын пайдаланатын процестер, содан кейін CANDE сияқты хабарлама басқару жүйелері келеді. Содан кейін тоқтатылған процестер. Содан кейін Work Flow Language жұмыстары. Соңында пайдаланушы процестері келеді. Төменгі деңгейде процессордың толық бөлігін пайдаланбайтын тапсырмалардың басымдығын көтеруге арналған «Жұмсақ» басымдық бар. Бұл IO-ға байланысты тапсырмаға бірдей жарияланған басымдыққа ие процессорға байланысты тапсырмадан бұрын процессор уақытын алуға мүмкіндік береді. Басқа ресурстарды күтіп тұрған процестер, мысалы файлды оқу, EVENT дерек құрылымында күтеді. Осылайша, бір ресурсты күтіп тұрған барлық процестер бір оқиғаны күтеді. Ресурс қолжетімді болған кезде оқиға оянып, оны күтіп тұрған барлық процестерді оятады. Процестер кез келген оқиғаның пайда болуын бірнеше оқиғада күтуі мүмкін, соның ішінде белгілі бір уақыт өткеннен кейін. Оқиғалар толыққанды пайдаланушымен бағдарламаланады, яғни пайдаланушылар MCP ұсынған жалпыланған оқиғалар жүйесін пайдаланатын жүйелерді жаза алады. Аяқталған процестер «Аяқталды» деп белгіленеді. Операциялық жағынан операторға жүйедегі барлық тапсырмалардың жағдайы көрсетіледі. Барлық іске қосылып жатқан және дайын процестер «Белсенді» тапсырмалар ретінде көрсетіледі (жүйе алдын ала көп тапсырманы іске асыратындықтан, дайыннан іске қосылуға және кері қарай ауыстыру өте тез, сондықтан дайын және іске қосылып жатқан тапсырмаларды ажыратудың қажеті жоқ, өйткені олардың барлығы процессордың бір бөлігін бір секунд ішінде алады). Барлық белсенді тапсырмаларды «А» командасымен көрсетуге болады. Аяқталған тапсырмалар аяқталу себебімен аяқталған тапсырмалар ретінде көрсетіледі, әдеттегі «тапсырманың аяқталуы» үшін EOT, ал процесс қателігінің себебімен DSed көрсетіледі. Барлық процестерге аралас нөмір беріледі, ал операторлар осы нөмірді бақылауға арналған процесті анықтау үшін пайдалана алады. Мұндай командалардың бірі – DS командасы (Кіммен сөйлескеніңізге байланысты, Әскери-теңіз қызметкерлерінің алғашқы компьютерлік жобаларға тигізген әсерінен кейін Жоспардан өшіру, DiScontinue немесе Deep Six дегенді білдіреді). Оператормен аяқталған тапсырмалар толық жазбаларда O DS ретінде көрсетіледі. Тапсырмалар бағдарламаның қателері, F DS немесе P DS ретінде белгіленіп, жарамсыз индекс, сандық ағып кету және т.б. сияқты қателер үшін аяқталуы мүмкін. Орындалған жазбаларды оператор «С» командасымен тізімдей алады. Ресурста күтіп тұрған тапсырмалар күту жазулары мен күту себебі бойынша тізімделеді. Барлық күту тапсырмалары «W» командасымен тізімделуі мүмкін. Күтудің себебі де тізімделеді және «Y» командасымен тапсырма туралы қосымша ақпарат алуға болады. Мүмкін, тапсырма оператордың кірісін күтіп тұр, ол тапсырмаға «AX» командасын қабылдау арқылы жіберіледі (ескеріңіз, оператордың кірісі GUI интерфейсі бар желі құрылғысынан кіріс болатын пайдаланушының кірісінен мүлдем өзгеше). Пайдаланушы кірісін немесе файлды оқуды күтіп тұрған тапсырмалар әдетте оператор назарына арналған күту жазбалары ретінде тізімделемейді. Тапсырма күтудің тағы бір себебі – файлды күту. Процесс файлды ашқанда және файл болмаса, тапсырма күту жазбаларына орналастырылады, ол белгілі бір файлды күтіп тұрғанын көрсетеді. Оператор (немесе процесс иесі) файлды күтілетін жерге көшіруге немесе тапсырманы файлды басқа жерден оқуға қайта бағыттауға мүмкіндік алады, немесе файл басқа тәуелсіз процесспен жасалуы мүмкін, ол әлі аяқталмаған. Егер оператор ресурсты ұсына алмаса, оператор тапсырманы соңғы шара ретінде DS-теуге болады. Бұл басқа жүйелерден өзгеше, олар файл сияқты ресурс қолжетімсіз болған кезде тапсырманы автоматты түрде тоқтатып тастайды. MCP тапсырмаларды оператормен қалпына келтірудің осы деңгейін ұсынады. Басқа жүйелер бағдарламашыларды файлдың болуын тексеру үшін кодты қосуға мәжбүр етеді, сонымен қатар қалпына келтіруді қамтамасыз ету үшін әр жағдайда қосымша код жазылуы керек, немесе процесс синхрондауын қамтамасыз ету керек. Мұндай код MCP бағдарламасында тапсырма күтуі қажет болмаған жағдайда жазылуы мүмкін, бірақ оператор деңгейінде қалпына келтіруге мүмкіндік болғандықтан, бұл міндетті емес, сондықтан бағдарламалау әлдеқайда қарапайым. Файлдарды (немесе дерекқорларды) сұрауларды бағдарлама орындалуына дейін немесе орындалу кезінде басқа файлдарға (немесе дерекқорларға) қайта бағыттау мүмкіндігіне қоса, бағдарламашыларға қателерді анықтауға және олардан қалпына келтіруге мүмкіндік беретін бірнеше механизмдер бар. Бір жолы, «ON» операторы, көп жылдар бойы қолданылып келеді. Нақты қателер (мысалы, нөлге бөлу) тізімделуі мүмкін немесе «anyfault» қолданылуы мүмкін. «ON» операторынан кейін келетін оператор немесе блок компилятормен қателерді басқару кодын ретінде танылады. Орындалу кезінде, егер «on» операторының ауқытында қалпына келтірілетін қате туындаса, стек кешіріледі және басқару одан кейін келетін операторға беріледі. «ON» операторының артындағы басқару логикасымен байланысты мәселе, ол тек бағдарлама қателері үшін ғана шақырылатыны, басқа себептерге байланысты бағдарлама тоқтатылуы үшін емес еді. Уақыт өте келе, аномалды тоқтатуларды кепілді түрде басқару қажеттілігі артты. Атап айтқанда, бағдарламалар клиенттер немесе үшінші тараптар жазған плагиндерді шақыруға мүмкіндік беру қажет болды, егер плагин дұрыс жұмыс істемесе, ешқандай тәуекел болмайды. Жалпы плагиндер механизмдеріне қоса, динамикалық кітапхана байланысының жаңа түрі (Connection Libraries) бағдарламаларға функциялар мен деректерді импорттауға және экспорттауға мүмкіндік береді, сондықтан бір бағдарлама басқа бағдарлама ұсынған кодты орындайды. Мұндай күшейтілген қорғауды қамтамасыз ету үшін 1990 жылдардың ортасында жаңа механизм енгізілді. Қайта үйлесімділікке бағытталған қателік талпыныспен, ол сол кезде ұсынылған C++ тілінің құрылымымен аталды. Екі синтаксис және мінез-құлықтың өте үлкен айырмашылығына байланысты, бірдей атауды таңдау тек шатасу мен түсініксіздікке әкелді. Синтаксистік тұрғыдан алғанда, «try» операторлары «if» операторларына ұқсайды: «try», содан кейін оператор немесе блок, содан кейін «else» және тағы бір оператор немесе блок. Біріншісінен кейін қосымша «else» тармақтары келуі мүмкін. Орындалу кезінде, егер «try» тармағынан кейін келетін кодта қалпына келтірілетін тоқтату туындаса, стек қажет болса кешіріледі және басқару бірінші «else» тармағынан кейін келетін кодқа беріледі. Сонымен қатар, бағдарламаға не болғанын және қайда болғанын анықтауға мүмкіндік беретін атрибуттар орнатылады (соның ішінде нақты жол нөмірі). Тапсырманы тоқтатуға әкелетін көптеген оқиғаларды қалпына келтіруге болады. Бұған стек ағып кетуі, массивке шектен тыс кіру, бүтін санның асып кетуі/жетіспеуі және т.б. жатады. Оператордың (немесе пайдаланушының) DS-і қалпына келтірілмейді, егер UNSAFE түріндегі try қолданғандықтан ерекше құқықтары бар тапсырмалар болмаса. Осылайша, MCP өте қатеге төзімді ортаны ұсынады, басқа жүйелердегідей құлау және ядролық құлауды емес. Файлдармен айналысқанда...

MCP processes are called "Jobs" and "Tasks." A Job contains one or more tasks. Tasks within a job can run sequentially or in parallel. Logic can be implemented at the Job level, typically in the MCP's job control language WFL, to control the flow of a job. Once all tasks in a job are complete, the job itself is completed. An MCP Process goes through a life cycle from the time it enters the system until it leaves. The initial state for a Job is "Queued." There is a period of time while the Job resides in one of several user defined Job Queues. The next state is "Scheduled" as the Job moves from a queue into memory. Tasks within a job do not wait in queue; instead going directly to the 'Scheduled' state when initiated. Once a Job or Task is started, it can transition between "Active," "Waiting" and "Scheduled" as it progresses. Once a Job or Task completes, it moves to the 'Completed' state. Running processes are those that use a processor resource and are marked as 'running'. Processes that are ready to be assigned to a processor, when there is no free processor are placed in the ready queue. Processes may be assigned a “Declared” or “Visible” priority, generally 50 as the default, but can be from 0 to 99 for user processes. System processes may be assigned the higher values. Note that this numerical priority is secondary to an overall priority, which is based on the task type. Processes that are directly part of the operating system, called Independent Runners, have the highest priority regardless of numeric priority value. Next come processes using an MCP lock, then Message Control Systems such as CANDE. Then Discontinued processes. Then Work Flow Language jobs. Finally come user processes. At a lower level, there is a Fine priority intended to elevate the priority of tasks that do not use their full processor slice. This allows an IO bound task to get processor time ahead of a processor bound task on the same declared priority. Processes that are waiting on other resources, such as a file read, wait on the EVENT data structure. Thus all processes waiting on a single resource wait on a single event. When the resource becomes available, the event is caused, which wakes up all the processes waiting on it. Processes may wait on multiple events for any one of them to happen, including a time out. Events are fully user programmable – that is, users can write systems that use the generalized event system provided by the MCP. Processes that have terminated are marked as completed. Operationally, the status of all tasks in the system is displayed to the operator. All running and ready processes are displayed as 'Active' tasks (since the system implements preemptive multitasking, the change from ready to running and back is so quick that distinguishing ready and running tasks is pointless because they will all get a slice of the processor within a second). All active tasks can be displayed with the 'A' command. Terminated tasks are displayed as completed tasks with the reason for termination, EOT for normal 'end of task', and DSed with a reason for a process failure. All processes are assigned a mix number, and operators can use this number to identify a process to control. One such command is the DS command (which stands for either Delete from Schedule, DiScontinue, or Deep Six, after the influence of Navy personnel on early computer projects, depending on who you talk to). Tasks terminated by the operator are listed in the complete entries as O DS. Tasks can also terminate due to program faults, marked as F DS or P DS, for faults such as invalid index, numeric overflow, etc. Completed entries can be listed by the operator with the 'C' command. Tasks waiting on a resource are listed under the waiting entries and the reason for waiting. All waiting tasks may be listed with the 'W' command. The reason for waiting is also listed and more information about a task may be seen with the 'Y' command. It may be that a task is waiting for operator input, which is sent to a task via the accept 'AX' command (note that operator input is very different from user input, which would be input from a network device with a GUI interface). Tasks waiting on user input or file reads would not normally be listed as waiting entries for operator attention. Another reason for a task to be waiting is waiting on a file. When a process opens a file, and the file is not present, the task is placed in the waiting entries, noting that it is waiting on a certain file. An operator (or the user that owns the process) has the opportunity either to copy the file to the expected place, or to redirect the task to read the file from another place, or the file might even be created by an independent process that hasn't yet completed. If the resource cannot be provided by the operator, the operator can DS the task as a last resort. This is different from other systems, which automatically terminate a task when a resource such as a file is not available. The MCP provides this level of operator recoverability of tasks. Other systems force programmers to add code to check for the presence of files before accessing them, and thus extra code must be written in every case to provide recoverability, or process synchronization. Such code may be written in an MCP program when it is not desirable to have a task wait, but because of the operator level recoverability, this is not forced and therefore makes programming much simpler. In addition to the ability to dynamically remap file (or database) requests to other files (or databases), before or during program execution, several mechanisms are available to allow programmers to detect and recover from errors. One way, an 'ON' statement, has been around for many years. Specific faults (e. g., divide by zero) can be listed, or the catch all 'anyfault' can be used. The statement or block following the 'ON' statement is recognized by the compiler as fault handling code. During execution, if a recoverable fault occurs in scope of the 'on' statement, the stack is cut back and control transferred to the statement following it. One problem with the handling logic behind the ON statement was that it would only be invoked for program faults, not for program terminations having other causes. Over time, the need for guaranteed handling of abnormal terminations grew. In particular, a mechanism was needed to allow programs to invoke plug ins written by customers or third parties without any risk should the plug in behave badly. In addition to general plug in mechanisms, the new form of dynamic library linkage (Connection Libraries) allows programs to import and export functions and data, and hence one program runs code supplied by another. To accomplish such enhanced protection, a newer mechanism was introduced in the mid 1990s. In a misguided attempt at compatibility, it was named after the then proposed C++ language construct of the same name. Because the syntax and behavior of the two differ to such a large extent, choosing the same name has only led to confusion and misunderstanding. Syntactically, 'try' statements look like 'if' statements: 'try', followed by a statement or block, followed by 'else' and another statement or block. Additional 'else' clauses may follow the first. During execution, if any recoverable termination occurs in the code following the 'try' clause, the stack is cut back if required, and control branches to the code following the first 'else'. In addition, attributes are set to allow the program to determine what happened and where (including the specific line number). Most events that would result in task termination are recoverable. This includes stack overflow, array access out of bounds, integer over/under flow, etc. Operator (or user) DS is not recoverable except by privileged tasks using an UNSAFE form of try. MCP thus provides a very fault tolerant environment, not the crash and burn core dump of other systems. As with file attributes, tasks have attributes as well, such as the task priority (which is assigned at compile time or execution time, or can be changed while the task is running), processor time, wait time, status, etc. These task attributes can be accessed programmatically as can file attributes of files. The parent task is available programmatically as a task attribute that is of type task. For example, 'myself. initiator. name' gives the name of the process that initiated the current process. GETSPACE and FORGETSPACE are the two main procedures handling memory allocation and deallocation. Memory needs to be allocated at process initiation and whenever a block is entered that uses arrays, files, etc. GETSPACE and FORGETSPACE not only handle memory space, they also allocate or deallocate the disk space where non memory resident data may be overlaid. Memory may be SAVE (i. e., memory resident), OVERLAYABLE (i. e., virtual memory) or STICKY (meaning memory resident, but movable). They are called upon e. g. by HARDWAREINTERRUPT when a process addresses an uninitialized array or by FILEOPEN. HARDWAREINTERRUPT handles hardware interrupts and may call upon GETSPACE, IO FINISH or the like. BLOCKEXIT is called upon by a task exiting a block. BLOCKEXIT may in turn call FILECLOSE, FORGETSPACE or the like while cleaning up and releasing resources declared and used within that block. J EDGAR HOOVER is the main security guardian of the system, called upon at process start, file open, user log on, etc. GEORGE is the procedure that decides which process is the next one to receive CPU resources and is thus one of the few processes that uses the MoveStack instruction. A task goes through various states starting with NASCENT. At DELIVERY the event BIRTH is caused and the task's state changes to ALIVE. When PROCESSKILL is called upon, the state changes into DISEASED. When DEATH is caused the task gets put into the queue structure the MORGUE, after which all remaining resources are freed to the system by a process called PROCESSKILL. While the task is ALIVE, MCP functions are run on top of that particular process, thus CPU resources are automatically charged to the task causing the MCP overhead. Also, much of the MCP work is being performed with that particular stack's security rights. Only before BIRTH and after DEATH does the MCP need to be operating out of some other stack. If none is available, the system maintains an idle stack.

Порт файлдары

Процестер аралық байланыс (IPC) үшін тағы бір тәсіл – порт файлдары. Олар Unix құбырларына ұқсас, бірақ көп жолды және екі жақты болып келеді. Бұл тәсіл кітапханалар сияқты басқа IPC тәсілдерінен шамамен он есе баяу болғандықтан, егер IPC бір машинадағы әртүрлі процестер арасында болса, басқа тәсілдерді қолдану оңтайлы. Сондықтан порт файлдарын пайдаланудың ең тиімдісі – таратылған IPC үшін. Порт файлдары BNA (Burroughs Network Architecture) жүйесінде пайда болған, бірақ OSI және TCP/IP сияқты стандартты желілік технологиялардың дамуымен оларды осы желілерде де қолдануға болады. Кіріс байланыстарын күтіп отыратын сервер порт файлын жариялайды (KIND атрибуты PORT-қа тең файл). Клиенттен құрылған әрбір байланыс индексі бар қосалқы файлды құрайды, сондықтан әрбір порт файлы желідегі әртүрлі клиенттермен бірнеше байланысты көрсетеді. Сервер процесі порт файлынан оқу арқылы (кез келген қосалқы файлдан оқу үшін қосалқы файл = 0) желідегі кез келген жерден клиенттердің сұрауларын қабылдайды. Сұрауды жіберген клиентке жауап беру үшін, сұрау оқылған нақты қосалқы файлға жазу амалы қолданылады.

Жұмыс істеу ортасы

MCP сонымен қатар күрделі, бірақ қарапайым операторлық ортаны қамтамасыз етеді. Үлкен орналымдар үшін көптеген операторлар принтерлер (қағаз жүктеу, тонер картридждері және т.б.) сияқты физикалық ресурстарды қолжетімді етуі қажет болуы мүмкін. Кіші кеңселер немесе жеке пайдаланушылар үшін төменгі деңгейлі ортада операторсыз орта қажет болуы мүмкін (әсіресе ноутбук нұсқасында). Үлкен жүйелерде ODT (Операторлық дисплей терминалдары) деп аталатын арнайы операциялық терминалдар бар, олар әдетте қауіпсіз ортада сақталады. Кіші жүйелер үшін машиналарды кез келген терминалдан (терминал мен пайдаланушының жеткілікті құқықтары болған жағдайда) MARC бағдарламасы (Menu Assisted Resource Control) арқылы басқаруға болады. Оператор командаларын оларды білетін пайдаланушылар да қолдана алады. Оператор командалары көбінесе екі әріптен тұрады (Unix-тегідей), ал кейбіреулері бір әріптен ғана тұрады. Бұл оператор интерфейсін үйренуді талап етеді, бірақ тәжірибелі операторлар үшін, үлкен жүйемен күнделікті жұмыс істейтіндер үшін өте тиімді. Командалар регистрге сезімтал емес. Тапсырмалар 'mix' бағдарламасына енгізіліп, кітапханалар сияқты mix нөмірлерімен анықталады. Бағдарламаны орындау үшін операторлар 'EX' немесе 'RUN' командасын, содан кейін бағдарламаның файл атауын қолданады. ODT-лар әдетте ADM (автоматты дисплей режимі) арқылы іске қосылады, бұл жүйе күйінің бейімделетін дисплейі, әдетте белсенді, күтуде және аяқталған mix жазбаларын, сондай-ақ операторға хабарламалар немесе оператордың араласуын қажет ететін жағдайлар туралы жүйелік хабарламаларды көрсету үшін орнатылған. Бұл дисплейлердің толық тізімі 'A' (белсенді), 'W' (күтуде), 'C' (аяқталған) және 'MSG' (хабарлама командалары) арқылы беріледі. Егер тапсырма оператордың әрекетін күтіп тұрса, оператор тапсырманың не қажет екенін білу үшін оның mix нөмірін және 'Y' командасын енгізе алады. (Командалардың объектіге бағытталған стиліне назар аударыңыз, алдымен объектіні таңдап, содан кейін команданы таңдаңыз.) Мысалы, '3456Y'. Оператор '3456ST' тоқтату командасымен тапсырманы күту тізіміне мәжбүрлеп енгізе алады және оны 'OK' командасымен қайтадан белсенді ете алады: '3456OK'. OK командасы оператор ресурсты тапсырма үшін қолжетімді еткен кезде де қолданылуы мүмкін, бірақ көбінесе MCP ресурстардың қолжетімді болғанын анықтайды, бұл процестер күтіп тұрған оқиғаны тудырады, оператордың қосымша араласуынсыз. Оператордан бағдарламаға мәтіндік ақпаратты жіберу үшін '3456AX MORE INFO' қабылдау командасын пайдалануға болады. Бағдарламалар DISPLAY механизмін пайдалана отырып, операторларға ақпаратты жібере алады, бұл MSG дисплейіне DISPLAY хабарламаларын қосады. Тапсырмалар мен процестерден басқа, операторлар файлдарды да басқарады. Файлдарды FILE командасымен тізімдеуге, COPY командасымен көшіруге, REMOVE командасымен жоюға және қайта атауға болады. MCP-нің жұмыс ортасы қуатты, бірақ қарапайым және әдетте басқа жүйелердің операторларының санынан әлдеқайда азды құрайды. Операциялық ортаның маңызды бөлігі – жоғары деңгейдегі Жұмыс ағыны тілі.

The MCP also provides a sophisticated yet simple operator environment. For large installations, many operators might be required to make physical resources, such as printers (loading paper, toner cartridges, etc.) available. Low end environments for small offices or single user may require an operator free environment (especially the laptop implementation). Large systems have dedicated operations terminals called ODTs (Operator Display Terminals), usually kept in a secure environment. For small systems, machines can be controlled from any terminal (provided the terminal and user have sufficient privileges) using the MARC program (Menu Assisted Resource Control). Operator commands can also be used by users familiar with them. Operator commands are mostly two letters (as with Unix), and some are just one letter. This means that the operator interface must be learned, but it is very efficient for experienced operators who run a large mainframe system from day to day. Commands are case insensitive. Tasks are entered in the program 'mix' and identified by mix numbers, as are libraries. To execute a program, operators can use the 'EX' or 'RUN' command followed by the file name of the program. ODTs are run typically with ADM (Automatic Display Mode), which is a tailorable display of system status usually set up to display the active, waiting, and completed mix entries, as well as system messages to the operator for notifications or situations requiring operator action. Complete listing of these displays are given by the 'A' (active), 'W' (waiting), 'C' (completed), and 'MSG' (message commands). If a task becomes waiting on some operator action, the operator can find out what the task needs by entering its mix number followed by the 'Y' command. (Note the object oriented style of commands, selecting the object first, followed by the command.) For example, '3456Y'. An operator can force a task into the waiting entries with the stop command '3456ST' and make it active again with OK: '3456OK'. The OK command can also be used when an operator has made a resource available for a task, although more frequently than not, the MCP will detect that resources have become available, CAUSE the EVENT that processes have been waiting on without further operator intervention. To pass textual information from an operator to a program, the accept command ‘3456AX MORE INFO’ can be used. Programs can pass information to operators using the DISPLAY mechanism, which causes DISPLAY messages to be added to the MSG display. As well as tasks and processes, operators also have control over files. Files can be listed using the FILE command, copied using COPY, removed using REMOVE, and renamed. The operating environment of the MCP is powerful, yet simple and usually only requires a fraction of the number of operators of other systems. An important part of the operations environment is the high level Work Flow Language.

Ағаш кесу

Жүйедегі барлық әрекеттер тіркеледі, мысалы операторға көрсетілген барлық хабарламалар және оператордың барлық амалдары. Барлық маңызды бағдарламалық іс-әрекеттер жүйелік журналға және бағдарламалық журналға тіркеледі, мысалы, WFL жұмысының басталуы үшін BOJ, WFL жұмысындағы тапсырманың басталуы үшін BOT, тапсырмалар мен жұмыстардың аяқталуы үшін EOT және EOJ. Сонымен қатар, барлық файлдар мен деректер қорының ашылуы мен жабылуы тіркелуі мүмкін. Көптеген оқиғаларды тіркеу Unix сияқты жүйелерге қарағанда MCP операциялық ортасының баяу жұмыс істеуіне себеп болады, себебі әрбір жазбадан кейін барлығы физикалық жазу арқылы бағдарлама журналына жазылады, ал Unix сияқты жүйелер мұны жасамайды, тіпті олар жүйелік журналда көптеген ақпаратты сақтайды. Журналдар сот сараптамасы үшін бағдарламалардың немесе жүйелердің неге сәтсіз аяқталғанын анықтауға немесе жүйе қауіпсіздігін бұзу әрекеттерін анықтауға пайдаланылуы мүмкін. Жүйелік журналдар жүйеде белгіленген мерзім аяқталғаннан кейін автоматты түрде жабылады және жаңасы ашылады. Жүйелік журналдарда LOGANALYZER сияқты бағдарламалармен сүзгіленіп, талдауға болатын көп көлемде ақпарат бар. ДУМПАНАЛИЗЕР бастапқыда таспаға жазылған жадтың жадына түсірілуін талдайды. Барлық компиляторлар код файлдарына LINEINFO қосқандықтан, DUMPANALYZER қате кезінде қандай бастапқы кодтың орындалғанын дәл анықтай алады. Сондай-ақ, тек бір бағдарламаны құратын әдеттегі бағдарламалық құжатта бастапқы кодтың реттік нөмірі мен айнымалылардың атаулары туралы ақпарат болады. Екі анализатор да әртүрлі мақсаттар үшін маңызды диагностикалық құралдар болып табылады.

Жаңалықтар

MCP дизайнындағы көптеген техникалық жаңалықтардан өзге, Burroughs Large Systems жүйелерінде қазір жалпы интернет қоғамдастығы қолданып жүрген көптеген басқару инновациялары да болды. Жүйелік бағдарламалық жасақтама клиенттерге бастапқы кодты, сондай-ақ клиенттер үшін MCP-нің жаңа нұсқаларын жасауға қажетті барлық өңдеу және компиляция құралдарын қоса жеткізілді. Көптеген клиенттер MCP-нің ішкі құрылымын жақсы біліп, арнайы тәжірибе жинақтады және клиенттер жиі "түзетулерді" (тізбектелген нөмірлері бар бастапқы кодтың бөліктері) жаңа мүмкіндіктерді ұсыну немесе ақауларды жою (FTR – далалық қате туралы хабарламалар) ретінде жіберді. Ұсынылған түзетулердің көпшілігі жүйе әзірлеушілер тарапынан қабылданып, MCP-нің келесі нұсқасына енгізілді. Ерікті, өздерін сарапшы деп есептейтін мамандарды негізгі техникалық жұмысқа тарту қазір кеңінен қолданылады және ашық инновацияның мәнін құрайды. Қоғамдық дамудың бұл басқару инновациясы 1970 жылдарға дейін жетеді.

Құрастырушы

Unisys MCP операциялық жүйесінде құрастырушы бағдарламасы жоқ.

Қорытынды

MCP жоғары деңгейдегі тілде жасалған алғашқы операциялық жүйе болды. 50 жылдық тарихында коммерциялық іске асыруда көптеген жаңалықтарды көріп, виртуалды жад, симметриялық көппроцессорлық өңдеу және жоғары деңгейдегі жұмыс басқару тілі (WFL) сияқты мүмкіндіктерді енгізді. Ол көптен бері басқа кең таралған операциялық жүйелерде ғана қолданылатын көптеген мүмкіндіктерге ие, ал Берроуздың үлкен жүйелер архитектурасымен бірге MCP жоғары өнімділік, көп тапсырмалылық және транзакциялық өңдеу ортасын қамтамасыз етеді.