버로우즈 MCP

MCP

개발자	버로우즈 / 유니시스
기입처	ESPOL, NEWP
동작 상태	현재의
소스 모델	사용 가능한 소스
초기 릴리즈	1961년; 61년 전 (2011년)
최신 릴리즈	20[1].0 / 2021년 5월
플랫폼	Unisys Clearpath/MCP를 포함한 대규모 시스템 버로우
체납 사용자 인터페이스	텍스트 사용자 인터페이스
면허증.	독자 사양
공식 웹사이트	MCP 사이트

MCP(Master Control Program)는 Unisys Clearpath/MCP 시스템을 포함한 소형, 중형 및 대형 시스템의 운영 체제입니다.

MCP는 원래 1961년에 ESPOL(이그제큐티브 시스템 문제 지향 언어)로 작성되었습니다.1970년대에 MCP는 보다 체계적이고 견고하며 안전한 ESPOL의 형태인 NEWP로 변환되었습니다.

MCP는 여러 프로세서를 관리하는 첫 번째 운영체제, 첫 번째 상용 가상 메모리 구현, 첫 번째 고급 언어로 작성된 첫 번째 OS 등 많은 분야에서 선두업체였습니다.

역사

1961년 MCP는 고급 언어(HLL)로만 작성된 최초의 OS였습니다.Burroughs Large System(B5000^[2] 및 후속 제품)은 시스템 소프트웨어를 포함한 모든 소프트웨어가 어셈블리 언어가 아닌 HLL로 작성될 것이라는 기대를 가지고 설계되었다는 점에서 독특했습니다.이것은 1961년에 독특하고 혁신적인 접근법이었습니다.

Gene Amdahl이 출시된 후 하드웨어 경쟁에 직면했던 IBM과 달리, Burroughs 소프트웨어는 호환되는 서드파티 하드웨어의 부족으로 인해 Burroughs 하드웨어에서만 실행되었습니다.이러한 이유로 Burroughs는 이러한 개방성을 염두에 두고 설계된 MCP를 포함하여 판매되는 모든 소프트웨어의 소스 코드를 자유롭게 배포할 수 있었습니다.예를 들어 업그레이드하려면 사용자가 시스템 소프트웨어를 다시 컴파일하고 필요한 로컬 패치를 적용해야 합니다.당시 이는 일반적인 관행이었고 고객(특히 연방준비제도이사회와 같은 대규모 고객)이 특정 ^[3]요구에 맞게 프로그램을 수정하는 것은 드문 일이 아니었기 때문에 필요했습니다.그 결과, Burroughs Users Group이 결성되었습니다.이 그룹은 연례 회의를 개최하여 사용자가 OS 및 시스템 소프트웨어 스위트의 다른 부분에 대한 자신의 확장을 교환할 수 있도록 했습니다.이러한 확장 기능의 대부분은 오랜 세월에 걸쳐 기본 OS 코드에 도입되어 모든 고객이 이용할 수 있게 되었습니다.따라서, MCP는 최초의 오픈 소스 프로젝트 중 하나로 간주될 수 있습니다.

Burroughs는 소스 코드를 배포한 최초의 제조업체가 아니며 (기존 경쟁업체인 NCR, IBM 및 Univac에 비해) 전자 컴퓨팅에 늦게 진입한 제조업체였습니다.MCP는 상용 하드웨어에서 실행되므로 MCP 기반 소프트웨어 스위트의 일부 요소는 Unisys에서 소스 형식으로 사용할 수 없게 되었습니다.

MCP는 가상 메모리를 제공하는 최초의 상용 OS로, 초기부터 Burroughs의 대규모 시스템 아키텍처에 의해 지원되고 있습니다.이 스킴은 전체 비본 노이만과 균일한 스택 기반 아키텍처의 결과로 고정 크기 메모리 페이지가 아닌 컴파일러 정의 객체를 저장하고 검색하기 때문에 업계에서 독특합니다.

파일 시스템

MCP는 계층형 디렉토리 구조를 가진 파일시스템을 제공합니다.초기 MCP 구현에서는 디렉토리 노드는 다른 시스템과 마찬가지로 디렉토리 엔트리가 있는 개별 파일로 표현되었습니다.그러나 1970년경부터 MCP는 내부적으로 볼륨 상의 모든 파일 경로를 나열하는 'FLAT' 디렉토리를 사용합니다.그 이유는 파일 경로에서 각 디렉토리를 열어 파일을 여는 것은 비효율적이고, 프로덕션 환경에서는 계층 이름 지정 체계를 유지하더라도 모든 파일을 단일 디렉토리에 보관하는 것이 더 낫기 때문입니다.프로그램적으로, 이것은 차이가 없습니다.사용자가 볼 수 있는 유일한 차이점은 엔티티 파일이 디렉토리와 동일한 이름을 가질 수 있다는 것입니다.예를 들어, "A/B"와 "A/B/C"는 모두 존재할 수 있으며, "B"는 파일과 디렉토리의 노드일 수 있습니다.

파일은 명명된 볼륨에 저장됩니다(예: 'myvol의 this/is/a/filename', 'myvol'은 볼륨 이름입니다).'myvol'이 포함된 디스크를 다른 물리적 디스크 드라이브로 이동하거나 복사할 수 있기 때문에 장치에 의존하지 않습니다.디스크를 연결하여 하나의 볼륨을 여러 드라이브에 설치할 수 있을 뿐만 아니라 중요한 데이터의 복구 기능을 위해 미러링할 수도 있습니다.유연성을 높이기 위해 각 프로그램은 볼륨 치환을 할 수 있으며 볼륨 이름은 프라이머리 및 세컨더리 대체 이름으로 대체할 수 있습니다.이를 프로세스의 패밀리라고 합니다.예를 들어 "FAMILY DISK = USERPACK 그렇지 않으면 SYPSACK" 할당은 볼륨 Disk에 논리적으로 지정된 파일을 볼륨 USERPACK에 저장하고 볼륨 USERPACK에서 먼저 파일을 검색합니다.이 검색이 성공하지 못하면 파일에 대한 다른 검색이 볼륨 SYPSACK에서 수행됩니다. 아무것도 지정되지 않은 경우 DISK가 기본 볼륨 이름입니다.

시스템의 각 파일에는 파일 속성 세트가 있습니다.이러한 속성은 파일에 대한 모든 종류의 메타데이터를 기록합니다. 가장 중요한 것은 파일의 이름과 형식(Macintosh의 4글자 파일 형식 코드와 같이 파일을 처리하는 방법을 시스템에 알려 줍니다).다른 속성에는 파일의 레코드 크기(상용 애플리케이션용으로 고정된 경우), 블록 크기(1개의 물리적 IO에서 읽고 쓰는 레코드 수를 MCP에 알려주는 여러 레코드) 및 여러 블록으로 구성된 영역 크기가 있으며, 이 영역 크기는 파일이 확장될 때 할당되는 디스크 영역의 크기를 제공합니다.

파일 형식은 파일이 문자 데이터인지, 특정 언어, 이진 데이터 또는 코드 파일로 작성된 소스 코드인지 나타냅니다.

파일은 퍼블릭 또는 프라이빗 등의 일반적인 보안 접근메커니즘에 의해 보호됩니다.또한 파일에는 소유자가 복잡한 보안 규칙을 지정할 수 있는 가드파일이 포함되어 있을 수 있습니다.

또 다른 보안 메커니즘은 신뢰할 수 있는 컴파일러에 의해서만 코드 파일을 생성할 수 있다는 것입니다.악성 프로그래머는 프로그램을 만들고 컴파일러라고 부를 수 없습니다.프로그램은 'mc' make compiler operator 명령을 사용하여 충분한 권한을 가진 오퍼레이터에 의해서만 컴파일러로 변환할 수 있습니다.

MCP는 저널링 파일 시스템을 구현하여 디스크 장애, 전원 상실 등에 대한 폴트 톨러런스를 제공합니다.파일 시스템을 손상시킬 수 없습니다(운영 체제 또는 하위 ^{[citation needed]}계층에 직접 액세스할 수 있는 다른 신뢰할 수 있는 시스템 소프트웨어 제외).

파일 시스템은 대소문자를 구분하지 않으며 이름에 따옴표를 추가하지 않는 한 대소문자를 구분하지 않습니다.

프로세스 관리

MCP 프로세스는 "Jobs" 및 "Tasks"라고 불립니다.작업에는 하나 이상의 태스크가 포함됩니다.작업 내의 태스크는 순차적으로 또는 병렬로 실행될 수 있습니다.로직은 작업레벨(일반적으로 MCP의 작업제어언어 WFL)로 구현되어 작업의 흐름을 제어할 수 있습니다.작업의 모든 태스크가 완료되면 작업 자체가 완료됩니다.

MCP 프로세스는 시스템에 들어간 시점부터 종료될 때까지 라이프 사이클을 거칩니다.작업의 초기 상태는 "Queue"입니다.Job이 여러 사용자 정의 Job Queues 중 하나에 상주하는 기간이 있습니다.Job이 큐에서 메모리로 이동하면 다음 상태는 "Scheduled"가 됩니다.작업 내 태스크는 대기열에 대기하지 않고 시작할 때 바로 '스케줄' 상태로 이동합니다.작업 또는 태스크가 시작되면 작업이 진행됨에 따라 "Active", "Waiting" 및 "Scheduled"로 전환할 수 있습니다.작업 또는 작업이 완료되면 '완료됨' 상태로 이동합니다.

실행 중인 프로세스는 프로세서 리소스를 사용하여 '실행 중'으로 표시된 프로세스입니다.프로세서에 할당할 준비가 된 프로세스는 빈 프로세서가 없는 경우 Ready 큐에 배치됩니다.프로세스에는 "Declared" 또는 "Visible" priority를 할당할 수 있습니다.일반적으로 기본값은 50이지만 사용자 프로세스의 경우 0 ~99입니다시스템 프로세스에는 더 높은 값을 할당할 수 있습니다.이 수치 priority는 작업 유형에 따라 전체 priority에 이어 두 번째입니다.인디펜던트 러너라고 불리는 운영 체제의 직접 일부인 프로세스는 숫자 우선 순위 값에 관계없이 가장 높은 우선 순위를 가집니다.다음으로 MCP 잠금을 사용한 프로세스, 다음으로 CANDE 등의 메시지 제어 시스템을 사용합니다.그 후 프로세스가 중단됩니다.다음으로 Work Flow Language 작업을 수행합니다.마지막으로 사용자 프로세스입니다.낮은 레벨에서는, 프로세서 슬라이스를 완전하게 사용하지 않는 태스크의 priority를 높이기 위한 Fine priority가 있습니다.이를 통해 IO 바인딩된 태스크는 선언된 동일한 우선순위로 프로세서 바인딩된 태스크보다 프로세서 시간을 먼저 얻을 수 있습니다.

파일 읽기 등 다른 리소스에서 대기 중인 프로세스는 EVENT 데이터 구조에서 대기합니다.따라서 단일 리소스를 대기하는 모든 프로세스는 단일 이벤트를 대기합니다.리소스를 사용할 수 있게 되면 이벤트가 발생하여 대기 중인 모든 프로세스가 웨이크업됩니다.프로세스는 타임아웃을 포함한 여러 이벤트가 발생할 때까지 대기할 수 있습니다.이벤트는 완전히 사용자가 프로그래밍할 수 있습니다.즉, 사용자는 MCP가 제공하는 범용 이벤트 시스템을 사용하는 시스템을 작성할 수 있습니다.

종료된 프로세스는 완료된 것으로 표시됩니다.

작동 시 시스템 내 모든 작업의 상태가 오퍼레이터에게 표시됩니다.실행 중인 프로세스와 준비 완료 프로세스는 모두 '액티브' 태스크로 표시됩니다(시스템은 프리엠프티브 멀티태스킹을 구현하기 때문에 준비 태스크에서 실행 태스크로 빠르게 이행하고 실행 중인 태스크는 모두 1초 안에 프로세서의 슬라이스를 얻을 수 있기 때문에 구별할 필요가 없습니다).모든 활성 작업은 'A' 명령을 사용하여 표시할 수 있습니다.

종료된 태스크는 종료 사유와 함께 완료된 태스크로, 정상 '작업 종료'의 경우 EOT로, 프로세스 장애의 경우 DSed로 표시됩니다.모든 공정에는 혼합 번호가 할당되며, 운영자는 이 번호를 사용하여 제어할 공정을 식별할 수 있습니다.이러한 명령어 중 하나가 DS 명령어입니다(대화 대상자에 따라 초기 컴퓨터 프로젝트에 해군 요원의 영향을 받은 후 Schedule, DiScontinue 또는 Deep Six 중 하나를 나타냅니다).오퍼레이터에 의해 종료된 태스크는 완전한 엔트리에 O-DS로 나열됩니다.

또한 잘못된 색인, 숫자 오버플로 등의 결함으로 인해 F-DS 또는 P-DS로 표시된 프로그램 결함으로 인해 작업이 종료될 수 있습니다.작업자는 'C' 명령을 사용하여 완료된 항목을 나열할 수 있습니다.

리소스 대기 태스크는 대기 항목과 대기 이유 아래에 나열됩니다.대기 중인 모든 작업은 'W' 명령을 사용하여 나열할 수 있습니다.대기 이유도 나열되며 'Y' 명령을 사용하면 작업에 대한 자세한 정보를 볼 수 있습니다.태스크가 오퍼레이터 입력을 기다리고 있을 수 있으며, 오퍼레이터 입력은 accept 'AX' 명령을 통해 태스크로 전송됩니다(오퍼레이터 입력은 GUI 인터페이스를 갖춘 네트워크 디바이스에서 입력되는 사용자 입력과 매우 다릅니다).

사용자 입력 또는 파일 읽기를 기다리는 작업은 일반적으로 오퍼레이터의 주의를 기다리는 대기 항목으로 나열되지 않습니다.작업이 대기하는 또 다른 이유는 파일 대기입니다.프로세스가 파일을 열었을 때 파일이 존재하지 않으면 태스크는 대기 엔트리에 배치되어 특정 파일에 대기하고 있음을 알 수 있습니다.운영자(또는 프로세스를 소유한 사용자)는 파일을 예상 위치에 복사하거나 작업을 리디렉션하여 다른 위치에서 파일을 읽을 수 있습니다. 그렇지 않으면 아직 완료되지 않은 독립 프로세스에 의해 파일이 생성될 수도 있습니다.

운영자가 리소스를 제공할 수 없는 경우 운영자는 마지막 수단으로 태스크를 DS할 수 있습니다.이는 파일과 같은 리소스를 사용할 수 없을 때 자동으로 작업을 종료하는 다른 시스템과 다릅니다.MCP는 오퍼레이터의 태스크 복구 기능을 이 수준으로 제공합니다.다른 시스템에서는 프로그래머가 파일에 액세스하기 전에 파일의 존재를 확인하기 위해 코드를 추가하도록 강제하고 있기 때문에 복구 기능 또는 프로세스 동기화를 제공하기 위해 모든 경우에 추가 코드를 작성해야 합니다.이러한 코드는 태스크를 대기시키는 것이 바람직하지 않은 경우 MCP 프로그램에 작성될 수 있지만 오퍼레이터 수준의 복구 기능을 통해 강제적으로 작성되지 않기 때문에 프로그래밍이 훨씬 단순해집니다.

프로그램 실행 전 또는 실행 중에 파일(또는 데이터베이스) 요구를 동적으로 다른 파일(또는 데이터베이스)에 재매핑하는 기능과 더불어 프로그래머가 오류를 검출하고 복구할 수 있는 몇 가지 메커니즘을 사용할 수 있습니다.한 가지 방법, 'ON' 선언은 수년 동안 존재해 왔습니다.특정 고장(예: 0으로 나누기)을 나열하거나 캐치올 '임의의 고장'을 사용할 수 있습니다.'ON' 스테이트먼트 뒤에 있는 스테이트먼트 또는 블록은 컴파일러에 의해 장애 처리 코드로 인식됩니다.실행 중 'on' 스테이트먼트의 범위에서 회복 가능한 장애가 발생하면 스택이 절단되고 컨트롤이 그 후의 스테이트먼트로 넘어갑니다.

ON 스테이트먼트의 이면에 있는 처리 로직의 문제 중 하나는 다른 원인이 있는 프로그램 종료가 아니라 프로그램 장애에 대해서만 호출된다는 것입니다.시간이 지남에 따라 비정상적인 종료에 대한 확실한 처리의 필요성이 커졌다.특히, 플러그인이 제대로 작동하지 않을 경우 프로그램이 고객이나 서드파티에 의해 작성된 플러그인을 위험 없이 호출할 수 있도록 하는 메커니즘이 필요했습니다.일반적인 플러그인 메커니즘 외에 새로운 형태의 동적 라이브러리 링크(Connection Libraries)는 프로그램이 함수 및 데이터를 가져오고 내보낼 수 있도록 하며, 따라서 하나의 프로그램이 다른 프로그램에 의해 공급된 코드를 실행합니다.

이러한 강화된 보호를 달성하기 위해 1990년대 중반에 새로운 메커니즘이 도입되었습니다.호환성에 대한 잘못된 시도에서, 이것은 같은 이름의 당시 제안된 C++ 언어 구조의 이름을 따서 명명되었습니다.두 개의 구문과 동작은 크게 다르기 때문에 같은 이름을 선택하면 혼란과 오해가 생깁니다.

구문론적으로 'try' 문장은 'if' 문처럼 보이는데, 'try' 문 뒤에 'else' 문 또는 다른 문 또는 블록이 이어집니다.첫 번째 절 뒤에 'else' 절이 추가될 수 있습니다.실행 중 'try' 절 뒤에 있는 코드에서 복구 가능한 종료가 발생하면 필요에 따라 스택이 축소되고 첫 번째 'else' 뒤에 있는 코드로 제어가 분기됩니다.또, 프로그램에서는, 무엇이 어디에서 일어났는지(특정 회선 번호를 포함한다) 판단할 수 있도록 어트리뷰트를 설정합니다.

작업이 종료되는 대부분의 이벤트는 복구할 수 있습니다.여기에는 스택 오버플로, 아웃바운드 어레이 액세스, 정수 오버플로우/언더플로우 등이 포함됩니다.오퍼레이터(또는 사용자) DS는 안전하지 않은 형식의 시행을 사용하는 권한 있는 작업을 통해서만 복구할 수 있습니다.

따라서 MCP는 다른 시스템의 크래시 앤 번 코어 덤프가 아닌 매우 폴트 톨러런스한 환경을 제공합니다.

파일 속성과 마찬가지로 태스크에는 태스크 우선순위(컴파일 시 또는 실행 시 할당되거나 태스크 실행 중에 변경될 수 있음), 프로세서 시간, 대기 시간, 상태 등의 속성이 있습니다.이러한 작업 속성은 파일의 속성을 파일화하는 것과 마찬가지로 프로그래밍 방식으로 액세스할 수 있습니다.상위 작업은 프로그래밍 방식으로 작업 유형의 작업 특성으로 사용할 수 있습니다.예를 들어 '나 자신'처럼요.initiator.name'은 현재 프로세스를 시작한 프로세스의 이름을 제공합니다.

GETSPACE그리고.FORGETSPACE는 메모리 할당과 할당 해제를 처리하는 두 가지 주요 절차입니다.프로세스 시작 시 및 어레이, 파일 등을 사용하는 블록이 입력될 때마다 메모리를 할당해야 합니다. GETSPACE그리고.FORGETSPACE메모리 공간을 처리할 뿐만 아니라 비메모리 상주 데이터가 중첩될 수 있는 디스크 공간을 할당하거나 할당 해제하기도 합니다.메모리는 SAVE(예: 메모리 상주), OVERLABLE(예: 가상 메모리) 또는 STICKY(예: 메모리 상주, 이동 가능)입니다.예를 들어 다음과 같이 요구됩니다.HARDWAREINTERRUPT프로세스가 초기화되지 않은 어레이에 주소를 지정하는 경우 또는FILEOPEN.

HARDWAREINTERRUPT하드웨어 인터럽트를 처리하여 다음 명령을 호출할 수 있습니다.GETSPACE,IO_FINISH뭐 그런 거.

BLOCKEXIT는 블록에서 나가는 태스크에 의해 호출됩니다.블록IT부문에 문의할 수 있습니다.FILECLOSE,FORGETSPACE그 블록 내에서 선언되어 사용되고 있는 자원을 정리 및 해제하는 등의 작업을 실시합니다.

J_EDGAR_HOOVER는 프로세스 시작, 파일 열기, 사용자 로그온 시 등에 호출되는 시스템의 주요 보안 보호자입니다.

GEORGE는 CPU 리소스를 수신할 다음 프로세스를 결정하는 절차이며, 따라서 MoveStack 명령을 사용하는 몇 안 되는 프로세스 중 하나입니다.

작업은 NASCENT부터 시작하여 다양한 상태를 거칩니다. DELivery 시 BORTH 이벤트가 발생하고 작업 상태가 ALIVE로 변경됩니다.PROCESSKILL이 호출되면 상태가 DISTABLED로 바뀝니다.DEATH가 발생하면 태스크는 MORGUE 구조에 배치되며, 그 후 PROCESSKILL이라는 프로세스를 통해 나머지 리소스가 모두 시스템으로 해방됩니다.

태스크가 ALIVE인 동안 MCP 기능은 특정 프로세스 상에서 실행되므로 CPU 리소스가 자동으로 MCP 오버헤드의 원인이 되는 태스크에 과금됩니다.또한 MCP 작업의 대부분은 특정 스택의 보안 권한으로 수행됩니다.MCP는 BORTH 전과 DEATE 후에만 다른 스택에서 동작해야 합니다.사용할 수 있는 것이 없는 경우 시스템은 아이돌스택을 유지합니다.

소프트웨어 컴포넌트 및 라이브러리

MCP 라이브러리는 프로세스 간에 데이터와 코드를 공유하는 방법을 제공합니다.Burroughs 대형 시스템에 대한 기사에서는 많은 프로세스가 (동기화된 업데이트를 제공하는 메커니즘과) 공통 데이터를 공유할 수 있도록 종속 프로세스를 비동기적으로 실행하는 방법에 대해 설명합니다.이러한 관련 프로세스군은 단일 프로그램 단위로 작성되어야 하며, 비동기 프로세스로서 상위 렉스 수준에서 처리 절차를 처리해야 하며, 하위 렉스 수준에서 글로벌 변수 및 기타 변수에 여전히 액세스할 수 있습니다.

라이브러리는 다음과 같은 이점을 가지고 이 시나리오를 완전히 반전시켰습니다.

• 라이브러리 및 독립 프로세스는 독립 프로그래밍 단위로 작성됩니다.
• 라이브러리는 공유 리소스에 대한 접근을 완전히 제어(데이터 캡슐화 및 숨기기)
• 라이브러리와 클라이언트는 다른 언어로 작성 가능
• 데이터에 안전하게 액세스하기 위해 프로세스 전환이 필요하지 않음

라이브러리 메커니즘이 매우 깨끗하고 급진적이었기 때문에 많은 시스템 소프트웨어가 대규모 개서를 거쳤고, 그 결과 시스템 구조가 개선되고 성능이 향상되었습니다.

라이브러리는 1980년대 초에 Burroughs의 Roy Guck과 다른 사람들에 의해 개발되어 MCP 시스템에 도입되었습니다.그들은 C와 매우 흡사하다. A. R. Hoare는 MCP EVENT와 Dahm 잠금 기술을 사용하여 클라이언트 프로세스 간에 상호 배제 및 동기화를 제어할 수 있는 기회를 제공합니다.라이브러리는 클라이언트가 라이브러리에 연결되기 전에 호환되는 인터페이스(가져온 프로시저의 모든 매개 변수 및 반환 유형 체크)를 확인하는 절차 진입점을 클라이언트에 제공합니다.라이브러리와 클라이언트는 다른 언어로 작성될 수 있습니다.장점은 모든 동기화가 라이브러리에서 제공되며 클라이언트 코드는 이 수준의 프로그래밍에 대해 전혀 걱정할 필요가 없다는 것입니다.클라이언트는 라이브러리의 동기화 코드를 손상시킬 수 없기 때문에 결과적으로 견고한 코드가 됩니다.(일부에서는 이것을 '신뢰할 수 있는 컴퓨팅 이니셔티브'라고 부릅니다).

라이브러리는 DLL과 같은 다른 시스템에 있는 보다 정교한 형태의 라이브러리입니다. MCP 라이브러리는 '모두 공유', '런유닛 공유' 또는 '프라이빗'으로 구성할 수 있습니다.프라이빗 케이스는 다른 시스템의 라이브러리에 가장 가깝습니다.클라이언트별로 라이브러리의 개별 복사가 호출되어 프로세스 간에 데이터 공유가 이루어지지 않습니다.

모두가 공유하는 것이 더 흥미롭다.클라이언트가 시작되면 라이브러리의 서비스가 필요할 때까지 잠시 동안 실행할 수 있습니다.라이브러리 진입점이 처음 참조되면 링크가 시작됩니다.라이브러리의 인스턴스가 이미 실행 중인 경우 클라이언트는 라이브러리의 해당 인스턴스에 연결됩니다.모든 클라이언트는 동일한 인스턴스를 공유합니다.

runununit에 의해 공유되는 것은 이 두 가지 공유 방식 간의 공유 메커니즘입니다.이것은 COBOL을 위해 특별히 설계되었으며, 여기서 런유닛은 원래의 시작 클라이언트 프로그램과 링크된 모든 라이브러리로 정의된다.각 런유닛은 라이브러리의 인스턴스를 하나씩 가져오고 런유닛마다 다른 인스턴스를 가져옵니다.이것은 COBOL 실행 유닛의 유일한 동적 구현입니다.

이것이 라이브러리의 첫 번째 호출이라면 라이브러리는 메인 프로그램(ALGOL 프로그램의 외부 블록)을 실행하여 글로벌 환경을 초기화합니다.초기화가 완료되면 프리즈가 실행되어 내보낸 모든 진입점을 클라이언트가 사용할 수 있게 됩니다.이 시점에서 라이브러리의 스택은 동결 해제될 때까지 이 스택에서 더 이상 실행되지 않기 때문에 동결되었다고 합니다.이 경우 정리 및 종료 코드가 실행됩니다.클라이언트가 라이브러리의 루틴을 호출하면 해당 루틴이 클라이언트스택 위에서 실행되어 로컬 변수와 임시 변수가 저장됩니다.이것에 의해, 많은 클라이언트가 동시에 같은 루틴을 실행하고, 라이브러리 스택의 글로벌 환경의 데이터에 액세스 하는 라이브러리 루틴에 의해서 동기화할 수 있습니다.

동결은 일시적, 영구적, 제어의 세 가지 형태로도 가능합니다.Temporary는 클라이언트 수가 0으로 떨어지면 라이브러리가 동결 해제되고 종료되는 것을 의미합니다.permanent는 클라이언트 수가 0으로 떨어져도 라이브러리가 추가 클라이언트에서 사용 가능한 상태를 유지함을 의미합니다.즉, 영속 라이브러리는 운영자가 NAW 명령을 사용하여 동결 해제할 수 있습니다.프리즈 제어란 라이브러리가 실제로 계속 실행되어 각 링크 클라이언트에 대해 모니터링 기능을 실행하고 데이터 초기화 및 정리 기능을 수행할 수 있음을 의미합니다.

라이브러리에는 '제목별' 및 '기능별'로 액세스할 수도 있습니다.클라이언트는 'title by title'에서 라이브러리의 파일 이름을 지정했습니다.'by function'은 클라이언트가 라이브러리의 함수 이름(예: 'system_support')만 지정하고 라이브러리의 실제 위치는 운영자가 이전에 'SL'(시스템 라이브러리) 명령으로 설정한 테이블(예: 'SL system_support = *system/support/support')에서 찾을 수 있는 간접적인 방식이었다.MCP의 폴트 톨러런스 자세는 여기서도 기능합니다.클라이언트가 존재하지 않는 라이브러리에 액세스하려고 하면 클라이언트는 '대기' 태스크에 들어가 라이브러리가 존재하거나 요청을 리다이렉트할 수 있습니다.

라이브러리는 즉시 갱신할 수도 있습니다.새로운 버전을 'SL'하기만 하면 됩니다.실행 중인 클라이언트는 종료될 때까지 이전 버전을 계속 사용하고 새 클라이언트는 새 버전으로 전송됩니다.

함수 라이브러리는 또한 매우 중요한 보안 기능인 링크 클래스를 구현했습니다.모든 일반 라이브러리의 링크 클래스는 0입니다.MCP 또는 기타 특권 시스템모듈에서 사용되는 라이브러리는 일반 프로그램에서는 사용할 수 없습니다.기능에 의해 액세스 되어 링크 클래스 1에서 강제됩니다.링크 클래스 0의 클라이언트는 링크 클래스1 진입점에 링크할 수 없습니다.일반 프로그램에 진입점을 제공해야 하는 링크 클래스 1이 있는 라이브러리는 '신뢰할 수 있음'으로 지정된 경우 이를 수행할 수 있습니다.링크 클래스 0에서 선택된 진입점을 제공할 수 있습니다.

전체 데이터베이스 시스템은 많은 클라이언트 간에 공유되는 데이터베이스에 매우 효율적이고 맞춤화된 액세스를 제공하는 라이브러리와 함께 구현됩니다.모든 네트워킹 기능 및 시스템 내장 기능에 대해서도 마찬가지입니다.

1990년대 중반에는 새로운 유형의 도서관을 이용할 수 있게 되었습니다.접속 라이브러리이들은 독립적으로 실행할 수 있을 뿐만 아니라 데이터 및 함수를 구조 블록의 배열에 있는 다른 프로그램으로 Import 및 내보낼 수 있는 자체적인 프로그램입니다.예를 들어 운영 체제의 네트워킹 구성 요소를 연결 라이브러리로 사용할 수 있으므로 다른 프로그램이 기능을 내보내고 가져와 서비스를 사용할 수 있습니다.링크 시 각 클라이언트는 상태 정보를 유지하는 전용 구조 블록을 받습니다.네트워크를 사용하는 프로그램은 네트워크 쓰기 기능을 가져오고 네트워크 읽기 기능을 내보낼 수 있습니다.따라서 네트워크 연결을 열면(예를 들어 TCP를 사용하여), 데이터를 읽을 수 있도록 데이터가 도착하면 네트워킹컴포넌트가 먼저 데이터를 버퍼에 복사하여 컨텍스트 전환을 수행할 필요 없이 함수를 직접 호출하여 데이터를 소비할 수 있습니다.마찬가지로 네트워크 쓰기 함수를 직접 호출하여 네트워크에 데이터를 쓸 수 있습니다.

Connection Libraries를 사용하면 링크를 상당히 제어할 수 있습니다.링크의 각 사이드는 임의로 링크를 승인할 수 있으며 필요에 따라 링크를 절단할 수 있습니다.상태는 링크 단위뿐만 아니라 글로벌하게 쉽게 유지할 수 있습니다.

포트 파일

Inter-Process Communication(IPC; 프로세스 간 통신)의 또 다른 기술은 포트 파일입니다.멀티웨이 및 양방향으로 일반화되어 있다는 점을 제외하면 Unix 파이프와 같습니다.이러한 기술은 라이브러리 등의 다른 IPC 기술보다 훨씬 느리기 때문에 IPC가 같은 머신상의 다른 프로세스 사이에 있는 경우에는 다른 기술을 사용하는 것이 좋습니다.

따라서 포트 파일은 분산 IPC에 가장 유리하게 사용됩니다.포트 파일은 BNA(Burroughs Network Architecture)와 함께 도입되었지만 OSI나 TCP/IP와 같은 표준 네트워킹 기술이 등장함에 따라 이러한 네트워크에서도 포트 파일을 사용할 수 있게 되었습니다.

착신 접속을 수신하고 있는 서버는, 포토 파일(PORT 와 같은 KIND 어트리뷰트를 가지는 파일)을 선언합니다.클라이언트로부터의 각 접속은 인덱스를 가진 서브파일을 작성하기 때문에 각 포트 파일은 네트워크상의 다른 클라이언트에 대한 여러 연결을 나타냅니다.

서버 프로세스는 포트 파일에 대한 읽기(서브파일에서 읽으려면 하위 파일 = 0)를 발행하여 네트워크상의 모든 위치에서 클라이언트 요청을 수신합니다.요청을 읽은 특정 서브파일에 기입하여 요청을 발행한 클라이언트에 대한 응답을 발행합니다.

동작 환경

또한 MCP는 정교하지만 단순한 운영 환경을 제공합니다.대규모 인스톨에서는, 프린터(용지 세트, 토너 카트리지 등)등의 물리 자원을 이용할 수 있도록 하기 위해서, 많은 오퍼레이터가 필요하게 되는 경우가 있습니다.스몰 오피스나 싱글 유저의 경우, 오퍼레이터가 필요 없는 환경(특히 노트북의 실장)이 필요한 경우가 있습니다.

대형 시스템에는 ODT(Operator Display Terminals)라는 전용 운영 단자가 있으며, 일반적으로 안전한 환경에 보관됩니다.소규모 시스템의 경우 MARC 프로그램(메뉴 지원 리소스 제어)을 사용하여 모든 단말기에서 머신을 제어할 수 있습니다(단, 단말기와 사용자에게 충분한 권한이 있는 경우).오퍼레이터 명령어는 익숙한 사용자도 사용할 수 있습니다.

연산자 명령어는 대부분 2글자(Unix와 마찬가지로)이며, 일부는 1글자에 불과합니다.즉, 오퍼레이터 인터페이스를 익혀야 하지만 대규모 메인프레임 시스템을 매일 실행하는 숙련된 오퍼레이터에게는 매우 효율적입니다.명령어는 대소문자를 구분하지 않습니다.

작업은 프로그램 '믹스'에 입력되며 라이브러리와 마찬가지로 혼합 번호로 식별됩니다.프로그램을 실행하기 위해 운영자는 'EX' 또는 'RUN' 명령 뒤에 프로그램 파일 이름을 사용할 수 있습니다.ODT는 일반적으로 ADM(Automatic Display Mode)을 사용하여 실행됩니다.ADM은 일반적으로 활성화, 대기 및 완료된 혼합 엔트리를 표시하도록 설정된 시스템 상태 및 오퍼레이터에 대한 알림 또는 오퍼레이터의 조치가 필요한 상황에 대한 시스템메시지를 표시합니다.

이러한 디스플레이의 전체 목록은 'A'(액티브), 'W'(대기), 'C'(완료) 및 'MSG'(메시지 명령)로 표시됩니다.

작업이 작업자의 작업을 대기하게 되면 작업자는 작업 번호 뒤에 'Y' 명령을 입력하여 작업이 무엇을 필요로 하는지 확인할 수 있습니다.(오브젝트 지향의 명령어 스타일에 주의해 주세요.오브젝트를 먼저 선택한 후 명령어를 선택합니다).예를 들어 '3456Y'입니다.

오퍼레이터는 stop 명령 '3456'을 사용하여 대기 중인 엔트리에 작업을 강제로 넣을 수 있습니다.'ST'를 선택하고 OK: '3456OK'를 눌러 다시 활성화하십시오.OK 명령어는 오퍼레이터가 리소스를 태스크에 사용할 수 있게 한 경우에도 사용할 수 있습니다.다만, MCP는 리소스가 사용 가능하게 된 것을 검출해, 오퍼레이터의 개입 없이 프로세스가 대기하고 있던 이벤트를 발생시킵니다.오퍼레이터에서 프로그램으로 텍스트 정보를 전달하려면 '3456AX MORE INFO' 수용 명령을 사용할 수 있습니다.프로그램은 DISPLAY 메커니즘을 사용하여 운영자에게 정보를 전달할 수 있으며, 이로 인해 DISPLAY 메시지가 MSG 디스플레이에 추가됩니다.

작업 및 프로세스뿐만 아니라 운영자도 파일을 제어할 수 있습니다.파일은 FILE 명령을 사용하여 나열하고, COPY를 사용하여 복사하고, REMOVE를 사용하여 제거하고, 이름을 변경할 수 있습니다.

MCP의 운영 환경은 강력하지만 단순하며 보통 다른 시스템의 운영자 수에 비해 극히 일부만 필요합니다.

운영 환경의 중요한 부분은 높은 수준의 워크플로우 언어입니다.

로깅

예를 들어 오퍼레이터에게 표시되는 모든 메시지와 오퍼레이터의 모든 액션이 기록됩니다.모든 중요한 프로그램 액션은 시스템 로그 및 프로그램 로그에 옵션으로 기록됩니다.예를 들어 WFL 작업의 시작을 위한 BOJ, WFL 작업 내 작업을 시작하는 작업을 위한 BOT, 태스크 및 작업의 끝을 위한 EOT 및 EOJ.또한 열린 파일과 닫힌 모든 데이터베이스를 기록할 수 있습니다.많은 이벤트를 로깅하면 Unix와 같은 시스템에 비해 MCP 운영 환경의 속도가 현저하게 느려집니다.모든 것이 기록될 때마다 프로그램 로그에 물리적인 쓰기가 강제되기 때문입니다.이것은 Unix와 같은 시스템이 시스템 로그에 너무 많은 것을 보관하고 있어도 하지 않는 것입니다.

이 로그는, 프로그램 또는 시스템에 장해가 발생했을 가능성이 있는 원인을 조사하기 위해서, 또는 시스템의 시큐러티를 침해하는 시도를 검출하기 위해서 사용할 수 있습니다.시스템 로그는 시스템 설정 가능 기간이 경과하고 새로운 로그가 열리면 자동으로 닫힙니다.시스템 로그에는 대량의 정보가 포함되어 있어 LOGANALYZER 등의 프로그램으로 필터링 및 분석할 수 있습니다.

DUMPANYZER는 테이프에 처음 기록된 메모리 덤프를 분석합니다.모든 컴파일러가 코드 파일에 LINEINFO를 추가했기 때문에 DUMPANYLYZER는 오류 발생 시 어떤 소스 문이 실행 중이었는지를 정확하게 파악할 수 있습니다.

또한 하나의 프로그램만 덤프된 일반 프로그램 덤프에는 소스 코드 시퀀스 번호 및 변수 이름에 대한 정보가 포함됩니다.

두 분석기는 모든 종류의 주요 진단 도구입니다.

혁신

MCP 설계의 많은 기술적 혁신 외에도, Burroughs Large Systems는 현재 인터넷 커뮤니티에서 널리 사용되고 있는 많은 관리 혁신을 가지고 있습니다.시스템 소프트웨어는 소스 코드와 새로운 버전의 MCP를 생성하는 데 필요한 모든 편집 및 컴파일 도구를 포함하여 고객에게 출하되었습니다.많은 고객이 MCP의 내부 작업에 대한 틈새 전문 지식을 개발했으며, 고객은 새로운 기능 강화 또는 고장 수정(FTR - field troubles reports)을 제안하기 위해 '패치'(시퀀스 번호가 있는 소스 코드 조각)를 자주 보냈습니다.제안된 패치의 대부분은 시스템 개발자에 의해 포함되어 다음 버전의 MCP 릴리스에 통합되었습니다.자발적이고 자칭하는 전문가 커뮤니티를 주류 기술 업무에 포함시키는 것은 현재 널리 행해지고 있으며 오픈 이노베이션의 정수입니다.이러한 공동체 개발의 경영 혁신은 1970년대로 거슬러 올라간다.

컴파일러

Unisys MCP는 다음과 같은 다양한 프로그래밍 언어를 지원하는 여러 세대의 컴파일러를 보유하고 있습니다.

• DCALGOL, BDMSALGOL 및 DMALGOL을 포함한 ALGOL.^[4]
• C^[5]
• COBOL74 및 COBOL85를^[7] 포함하는^[6] COBOL
• 포트란77^[8]
• 새로운 기능^[9]
• 파스칼^[10]
• RPG^[11]

기타 제품은 다음과 같습니다.

• 바인더^[12]
• 네트워크 정의 언어^[13]
• 워크플로우 언어^[14]

컴파일러는 이전에 ESPOL, COBOL(68), Fortran(66), APL 및 PL/I용으로 존재했습니다.

어셈블러

Unisys MCP 운영 체제에는 중간 시스템 패밀리를 제외하고 어셈블러가 없습니다.

요약

MCP는 고급 언어로만 개발된 최초의 OS였습니다.50년의 역사를 통해 가상 메모리, 대칭형 멀티프로세서, 고급 작업 제어 언어(WFL) 등 상용 구현에서 많은 첫발을 내디뎠습니다.MCP는 현재 널리 보급되어 있는 다른 운영체제에서만 볼 수 있는 많은 기능을 갖추고 있으며, Burroughs의 대규모 시스템 아키텍처와 함께 매우 안전하고 고성능, 멀티태스킹 및 트랜잭션 처리 환경을 제공합니다.

레퍼런스

외부 링크

• MCP 19.0 매뉴얼– 무료 접근, 단 저작권 인정이 필요할 수 있습니다.