OS 2200

OS 2200

개발자	유니시스
OS 패밀리	OS 2200
동작 상태	현재의
소스 모델	클로즈드대부분의 소스는 라이선스가 있는 클라이언트에서 사용할 수 있습니다.
초기 릴리즈	1967년; 55년 전(1967년) Exec 8로서
최신 릴리즈	18.0 / 2018년 7월 18일, 4년 전(2018-07-18)[1]
마케팅 대상	엔터프라이즈 / 메인프레임
갱신 방법	Exec 및 기타 컴포넌트: 라인 번호 기반 패키지 변경.대부분의 컴포넌트:중간 수정(IC)
패키지 매니저	PRIMUS(내부), COMUS 및 SOLAR(클라이언트 및 내부)
플랫폼	UNIVAC 1100/2200 시리즈 및 Unisys ClearPath Dorado 시스템
커널 타입	모노리식 커널(고유 하드웨어 지원)[citation needed]
체납 사용자 인터페이스	명령줄 인터페이스
면허증.	독자 사양입니다.라이선스 기간 또는 사용(미터링) 라이선스 비용 지불
공식 웹사이트	OS 2200 사이트

OS 2200은 Unisys ClearPath Dorado 패밀리 메인프레임 시스템용 운영 체제입니다.OS 2200의 운영체제 커널은 UNIVAC 1108용 Exec 8의 직계 후손입니다.현재 및 과거의 Unisys 시스템에 대한 문서 및 기타 정보는 Unisys 공개 지원 ^{[note 1]}웹 사이트에서 확인할 수 있습니다.

머신 아키텍처와 OS 2200 운영체제와의 관계에 대한 설명은 Unisys 2200 시리즈 시스템 아키텍처를 참조하십시오.

역사

1951년 1101년 이전 1100 시스템이 있었지만 1108은 멀티프로그래밍과 멀티프로세싱을 효율적으로 지원하기 위해 설계된 최초의 1100 시리즈 컴퓨터였습니다.이 새로운 하드웨어와 함께 운영체제 Exec 8 (1108용 Executive System)이 출시되었습니다.

UNIVAC 1108 컴퓨터는 1964년에 발표되어 1965년 말에 납품되었습니다.최초의 1108 컴퓨터는 UNIVAC 1107용으로 개발된 Exec I 및 Exec II를 사용했습니다.단, UNIVAC는 최대 4개의 프로세서를 탑재한 1108의 대칭형 멀티프로세서 버전을 제공할 계획이었으며, 이전 운영체제(실제로 기본적인 모니터 프로그램)는 제한된 멀티프로그래밍을 지원했지만 이를 위해 설계되지 않았습니다.

1972년 UNIVAC 1110이 도입되었을 때 운영체제명은 OS 1100으로 변경되어 보다 광범위한 시스템에 대한 지원을 반영하고 있습니다.OS 1100이라는 이름은 1988년까지 유지되었으며, Sperry 2200 시리즈가 1100 시리즈에 이어 OS 2200으로 명칭이 변경되었습니다.그 후 2200 시리즈는 Unisys ClearPath IX 시리즈로, 그 후 Unisys ClearPath Dorado 시리즈로 바뀌었지만 운영체제는 OS 2200의 이름을 그대로 유지했습니다.

회사명과 제품명도 시간이 ^[2]지남에 따라 변경되었습니다.세인트 폴의 엔지니어링 리서치 어소시에이션(ERA)은 레밍턴 랜드 사에 인수되었습니다.레밍턴 랜드는 또한 당시 UNIVAC 컴퓨터를 만들고 있던 필라델피아 Eckert-Mauchly Computer Corporation을 인수했습니다.이 둘은 윌리엄 노리스의 지휘 아래 레밍턴 랜드의 유니백 지부로 통합되었다.William Norris는 ERA의 창립자 중 한 명이었고 후에 Control Data Corporation을 시작하기 위해 Remington Rand를 떠났습니다.레밍턴 랜드가 스페리 코퍼레이션과 합병한 후 레밍턴 랜드 코퍼레이션의 유니백 사업부가 스페리 랜드 코퍼레이션의 유니백 사업부가 되었습니다.1970년대에 Sperry Rand는 회사명을 Sperry Corporation으로 바꾸고 모든 부문명을 Sperry로 시작하는 기업 아이덴티티 프로그램을 시작했습니다.그래서 컴퓨터 시스템 부문은 Sperry UNIVAC가 되었습니다.나중에 부서 이름이 떨어졌고 모든 것이 단순히 Sperry가 되었다.

operating system의 커널은, 대부분의 Unisys 및 고객의 스탭으로부터 「EXEC」라고 불리고 있습니다.그러나 Unisys가 나중에 "ClearPath OS 2200 Release n"이라고 불리는 시스템 기반 릴리스로 함께 테스트된 제품군을 출시하기 시작했을 때 OS 2200이라는 용어는 시스템 릴리스 및 Dorado 하드웨어 플랫폼용으로 비동기적으로 출시된 다른 제품군을 지칭하는 것으로 변경되었습니다.

1986년에 Burroughs와 Sperry사는 합병하여 Unisys가 되었습니다(일부 오랜 기간 동안 2200 시리즈 고객은 "UNIVAC Is Still Your Supplyer"^[3]의 약자로 알려져 있습니다).양사의 주요 메인프레임 제품 라인은 Burroughs의 MCP 운영체제, Sperry의 OS 2200 등 개발을 계속하고 있습니다.

2016년 Unisys는 교육 ^[4]및 레저 목적으로 Microsoft Windows 가상 버전의 OS2200을 무료로 이용할 수 있게 되었습니다.

Exec 8

EXEC 8(EXEC VIII라고도 함)은 1964년에 UNIVAC 1108용으로 개발된 UNIVAC의 운영 체제입니다.UNIVAC 1107에서 사용되었던 이전 운영 체제인 EXEC I과 EXEC II의 최고의 기능을 결합했습니다.EXEC 8은 상업적으로 성공한 최초의 멀티프로세서 운영체제 중 하나였습니다.배치, 시간 공유 및 실시간이 포함된 혼합 워크로드를 동시에 지원했습니다.하나의 파일 시스템은 많은 드럼과 스핀들에 걸쳐 평평한 명명 구조를 가지고 있었습니다.그것은 또한 좋은 평가를 받은 거래 처리 시스템을 지원했다.

이전의 시스템은 모두 리얼 모드 시스템으로 프로그램 및 운영 체제의 보호 및 분리에 대한 하드웨어 지원이 없었습니다.이전 시스템에서는 멀티프로그래밍이 지원되었지만 카드 리더, 프린터 및 카드 펀치 스풀러와 같이 동작이 양호한 것으로 알려진 여러 지원 기능과 동시에 하나의 사용자 작업을 실행하는 것으로 제한되었습니다.

Exec 8 운영체제는 처음부터 멀티프로그래밍 및 멀티프로세싱 운영체제로 설계되었습니다.이는 1108이 최대 4개의 CPU를 탑재하도록 설계되었기 때문입니다.메모리와 대용량 스토리지가 주요 시스템 제약사항이었습니다.1100 시리즈는 보다 일반적인 시장을 목표로 하는 것으로 생각되었지만, 궁극의 실시간 처리가 주요 ^[5]요건이었습니다.

Exec 8의 사양은 1964년 12월까지 예비 프로그래머 레퍼런스 매뉴얼(사용자 가이드)로 작성되어 1965년 ^[6][7]5월에 작업이 시작되었습니다.

Exec 8은 초기에 주로 과학 및 엔지니어링 작업에서 사용되는 실시간 운영체제로 시작되었지만 메시지 전환, 프로세스 제어, 시뮬레이션 및 미사일 발사 제어에도 사용되었습니다.128K 워드(IBM PC XT의 최대 메모리 크기보다 작은 576K 바이트)만 있는 시스템에서 실행되도록 설계되었으며, 실시간 및 배치 처리에 초점을 맞췄습니다.초기 릴리스 레벨은 128KW에서 작동했지만, 이후 릴리스에서는 기능이 향상되어 유용한 크기의 프로그램을 저장할 공간이 충분하지 않았기 때문에 이를 유지할 수 없게 되었습니다.1108의 최대 메모리 용량은 256KW(1,148KB)였습니다.따라서 코어 메모리가 시스템에서 가장 비싼 부분이기 때문에 메모리의 효율적인 사용이 가장 중요한 제약이었습니다.

대량 저장고는 256KW(FH-432 내)에서 2MW(FH-1782)를 수용할 수 있는 6피트 길이의 회전 드럼으로 구성되었습니다.최대 용량의 대용량 저장소는 FASTRAND 드럼으로, 22MW(99MB)를 수용했습니다.파일 조각화는 "파일 저장"이라고 불리는 프로세스로 처리되었으며, 일반적으로 하루에 한 번 야간에 처리되었습니다.여기에는 모든 파일을 테이프에 롤아웃하고 드럼 파일 시스템을 다시 초기화한 다음 파일을 다시 읽어들이는 작업이 포함됩니다.

메모리 제약이 심하고 실시간 사용이 가능하기 때문에 코어에 로드된 코드의 복사본을 하나만 보관해야 했습니다.1108은 멀티태스킹용으로 설계되어 있기 때문에, 시스템은 완전하게 「리엔트」(스레드 세이프)되어 있었습니다.각 재진입 모듈은 실행 데이터의 인스턴스마다 다른 단일 메모리 "기본 주소"를 통해 프로그램 데이터에 액세스했습니다.실행 컨텍스트 전환은 단일 레지스터에 다른 기본 주소를 설정하는 것만으로 단일 명령으로 수행할 수 있습니다.시스템은 공유 데이터 구조를 보호하기 위해 세분화된 잠금을 사용했습니다.이그제큐티브, 컴파일러, 유틸리티, 게다가 복수의 카피가 동시에 실행되고 있는 고도의 유저 애플리케이션도, 코드를 공유할 수 있도록 작성되어 있습니다.이렇게 하면 1개의 복사본만 메모리에 로드하면 되므로 공간과 코드를 로드하는 데 걸리는 시간이 모두 절약됩니다.

코드와 데이터를 서로 다른 부하 엔티티에 분리하는 또 다른 이유는 메모리가 IBANK와 DBANK (명령과 데이터)라고 불리는 두 개의 독립된 뱅크 (별도의 물리적 캐비닛)로 구현되었기 때문입니다.각각 독자적인 액세스 패스가 있기 때문에 CPU는 양쪽 뱅크를 동시에 읽을 수 있었습니다.실행 가능한 코드를 하나의 메모리 뱅크에 로드하고 데이터를 다른 메모리 뱅크에 로드함으로써 많은 프로그램의 실행 시간을 거의 절반으로 줄일 수 있었습니다.

재입력 코드는 스레드 세이프여야 합니다(실행 전용). 자체 수정 코드는 허용되지 않습니다.다른 프로그램에서는 실행 시 실행 가능한 코드를 수정하는 것이 1100 시리즈 컴퓨터 시절에는 여전히 허용 가능한 프로그래밍 기법이었지만 성능 저하를 이유로 사용자는 실행하지 않도록 권장되었습니다.대부분의 1100 시리즈 애플리케이션을 해킹해도 아무에게도 이득이 되지 않을 뿐만 아니라 당시 악의에 찬 해커도 거의 없었기 때문에 보안상의 이점을 높이 평가하지는 않았습니다.

Exec 8은 주로 애플리케이션('태스크'라고 함)에 스레드('액티비티'라고 함)의 CPU 스케줄링 우선순위를 매우 미세하게 제어하는 배치 처리 시스템입니다.프로세서 스위칭은 프리엠프티브로, 높은 우선순위의 스레드가 현재 프로그램 중 가장 우선순위가 낮은 스레드를 실행하고 있는 프로세서를 제어할 수 있게 되었습니다.실시간 시스템을 제외하고 우선순위가 가장 낮은 작업도 처리 시간을 어느 정도 확보했습니다.이는 완전히 대칭적인 프로세서 관리를 갖춘 멀티프로그래밍 및 멀티프로세싱 운영체제였습니다.하드웨어에 내장된 테스트 및 설정 명령을 통해 OS 및 멀티 스레드 애플리케이션 모두에서 매우 효율적이고 세밀한 잠금을 수행할 수 있었습니다.

Exec 8에서는 작업이 "실행"이라고 불리는 작업으로 구성됩니다.실행은 Uniservo 테이프 드라이브나 Fastrand 드럼 파일과 같은 잠금 가능한 리소스의 우선 순위와 필요에 따라 예약됩니다.제어 언어 구문에서는 제어문 인식 기호로 "@" 기호("마스터 공간"이라고 함)를 사용합니다.명령어 또는 프로그램 이름 바로 뒤에 쉼표 및 옵션 전환이 나타납니다.공백 문자 뒤에 이어지는 나머지 문장은 특정 명령어에 따라 다릅니다.FORTRAN 프로그램을 컴파일하는 명령어는 "@FOR[,options] sourcefile, objectfile"처럼 보입니다.응용 프로그램의 입력 데이터는 파일(일반적으로 카드 이미지)에서 읽거나 실행 스트림에서 @ 명령을 바로 따를 수 있습니다.sentinel 명령어 "@END"까지의 모든 행은 입력 데이터로 간주되었기 때문에 삽입을 잊으면 컴파일러가 후속 명령을 프로그램 데이터로 해석하게 됩니다.따라서 데이터를 실행 스트림에 입력하는 것보다 파일로 처리하는 것이 더 바람직했습니다.

1968년에 Exec 8에 시분할 기능을 추가하는 작업이 시작되었습니다.1969년에 간부급 23급과 함께 배달되었다.시간 공유(요구 모드라고 함)는 배치 및 실시간 프로세스와 동일한 기능을 가지고 있었습니다.일괄적으로 실행할 수 있는 모든 것은 ASCII 단말기에서 실행할 수 있습니다.요구 모드에서는 작업 스트림 I/O가 카드 이미지(입력) 및 스풀(출력) 파일이 아닌 터미널 핸들러에 첨부되었습니다.두 가지 모두에 동일한 실행 제어 언어가 사용되었습니다.몇 년 후, 보다 구체적인 시분할 명령어가 추가되었고, 경영진이나 실행 중인 프로그램 중 어느 쪽도 데이터를 예상하지 못한 경우에도 일부 제어문을 즉시 처리하기 위해 비동기식으로 발행할 수 있었습니다.단말기에서만 입력할 수 있는 이러한 명령어는 "@@"로 시작되었습니다.같은 단말기에서 진행 중인 다른 작업을 중지하지 않고 실행할 수 있기 때문에 이러한 명령어를 트랜스페어런트명령어라고 부릅니다.처음에는 현재 프로그램을 종료하거나 터미널 출력을 파일로 리디렉션하기 위한 문이었지만, 결국 거의 모든 제어 문장이 "즉시" 허용되었습니다.

배치 실행과 디맨드 실행은 모두 @FIN 문으로 종료됩니다.디맨드 사용자가 실행 중 세션을 종료하면 Exec은 자동으로 실행을 종료합니다.@FIN은 필요하지 않습니다.

통신 소프트웨어

거래 처리 능력은 1960년대 후반에 유나이티드 항공과의 공동 프로젝트로 개발되었으며, 이후 에어 캐나다와의 또 다른 공동 프로젝트로 개선되었다.이 기능은 1972년에 운영체제에 완전히 통합되어 1100 시리즈의 미래 성장의 기반이 되었습니다.초기 사용자들은 실시간 프로그램 내에서 직접 통신회선을 제어했다.트랜잭션 처리 개발의 일부에는 통신 회선을 관리하고 트랜잭션으로 스케줄링되는 메시지를 Exec 8에 제공하는 커뮤니케이션 메시지 시스템이 포함되어 있습니다.이것에 의해, 모든 로우 레벨의 통신 물리 회선 관리 및 프로토콜이 애플리케이션으로부터 CMS 1100 애플리케이션으로 이동했습니다.

CMS 1100 자체는 실시간 멀티 스레드 프로그램으로 실행되어 통신 회선의 제어권을 획득하고 스케줄링을 위해 트랜잭션 메시지를 제출할 수 있는 특권을 가지고 있습니다.이로 인해 Exec 8에서는 무결성 문제가 발생하지 않도록 모든 종류의 애플리케이션을 세심하게 제어할 필요가 있다는 개념이 도입되었습니다.보안은 확실히 우려 사항이었지만, 초기에는 시스템의 신뢰성과 무결성이 훨씬 더 큰 문제였습니다.시스템은 여전히 주로 일괄 처리 및 트랜잭션 처리 중이었고, 시스템에 승인되지 않은 코드를 설치할 가능성은 거의 없었습니다.CMS 1100은 나중에 디맨드 터미널과 트랜잭션 터미널의 인터페이스로 사용할 수 있는 기능을 추가함으로써 터미널을 양쪽에서 사용할 수 있게 되었고 초기 터미널 드라이버를 Exec에서 삭제할 수 있게 되었습니다.CMS 1100은 이후 CPComm(ClearPath Enterprise Servers Communications Platform)와 SILAS(Legacy Application Systems)^[8][9]의 조합으로 대체되었습니다.인텔 기반의 Dorado 서버 모델의 경우 하위 레벨의 통신은 펌웨어로 이행되었으며 상위 레벨은 SILAS 및 CPCommOS(ClearPath Enterprise Servers Communications Platform for Open Systems)^[10]에서 처리되었습니다.

이그제큐티브

Exec에는 시스템에서 가장 높은 권한 수준에서 실행할 수 있는 모든 코드가 포함되어 있습니다.다른 코드가 이러한 특권 수준으로 승격되는 메커니즘은 없습니다.

Exec은 시스템 하드웨어 관리, 작업 예약 및 관리, 운영자 및 관리자와의 통신을 담당합니다.

릴리스 16.0에서는 Exec은 레벨 49R2(49.70.5)입니다.내부 시스템 레벨에서는 21.92.42와 같은 3개의 부품 번호가 사용됩니다(이전 릴리스는 여러 사이트에서 프로덕션에서 사용되었지만 가장 널리 사용되는 프로덕션 시스템이었습니다).첫 번째 숫자 부분은 줄자 수준이며 이전 모든 업데이트가 새 기본 버전으로 통합된 Exec의 새 버전을 나타냅니다.이것은 드문 프로세스이며 몇 년 간격으로 발생합니다.두 번째 숫자 부분은 메이저레벨의 업데이트 버전을 나타내며 일주일에 여러 번 발생합니다.기능의 내용을 동결하고 릴리스를 준비하기로 결정되면 세 번째 파트가 실행되고 수정 및 마이너 기능 업데이트가 적용되면 프리 릴리즈 레벨의 버전이 표시됩니다.릴리스 레벨의 준비와 동시에, 엔지니어가 장래의 릴리스에 대비해 변경을 통합하는 것에 의해서, 「메인 라인」의 갱신은 계속됩니다.수년간 공식 릴리즈 레벨은 3부로 구성된 풀 넘버였습니다.그 이후의 릴리스에서는 단순히 44R1, 44R2, 49R2 등의 이름이 붙었는데, 3개의 부품 번호는 아직 내부적으로 사용되고 있습니다.

작업 수행 중

Exec은 기본적으로 실시간 멀티 스레드 배치 처리 시스템입니다.그 모델을 중심으로 모든 것이 구축되어 있습니다.Exec 자체는 대부분 실시간 프로그램으로 구성되어 있습니다.윈도우즈에서 서비스로 수행되거나 리눅스 및 유닉스에서 Daemons로 수행되는 기능은 Exec 내의 작업 또는 백그라운드에서 항상 실행되는 배치 프로그램으로 구현됩니다.

시간 공유(디맨드 모드) 및 트랜잭션 처리는 특수한 배치 사례로 구현됩니다.그 결과 시분할 사용자 또는 트랜잭션 프로그램이 수행할 수 있는 작업에 대한 제한이 거의 없습니다.트랜잭션 프로그램 작성자에게 테이프 마운트를 요구하는 경우 등에 퍼포먼스에 만족하지 못할 것이라는 경고는 많이 있지만 허용됩니다.

가장 큰 작업 단위는 "Run"입니다.이는 공장에서의 "실가동" 용어에서 따온 것으로, 일반적으로 다른 시스템에서의 작업 또는 세션에 해당합니다.실행은 "실행 스트림"으로 정의됩니다.실행 스트림은 수행할 단계를 나타내는 일련의 제어 문입니다.여기에는 파일 처리, 프로그램 실행 및 제어 지점이 포함될 수 있습니다.배치 실행은 일반적으로 파일로 저장되며, 다른 실행 내에서 "시작" 명령 또는 운영자에 의해 예약됩니다.시분할 단말기에서 로그인하여 @RUN 명령을 입력하면 시분할 Run이 시작됩니다.대부분의 경우 @RUN 문과 두 번째 제어문(@ADD 또는 프로그램 실행)이 사용자 프로파일에 따라 자동으로 생성됩니다.보안 허가는 인증된 사용자 ID 및 Run 제어 문에 제공된 기타 정보를 기반으로 검증됩니다.

거래는 특별한 경우입니다.실제로 제어 문은 없지만 실행의 내부 데이터 구조가 생성됩니다.이를 통해 Exec은 동일한 보안, 계정, 디버깅 등의 메커니즘을 트랜잭션프로그램과 연관지을 수 있습니다.일반적으로 보안 프로파일은 트랜잭션 사용자가 인증될 때 메모리에 캐시되며 트랜잭션이 스케줄링될 때 사용자의 세션 데이터에서 트랜잭션 실행 상태로 복사됩니다.각 트랜잭션인스턴스는 기본적으로 실행이므로 계정, 로깅 및 오류 처리는 모두 실행 메커니즘에 의해 캡슐화됩니다.

집단

배치 작업(Runs)은 파일에 저장된 런스트림(작업 제어 언어 문)을 갖는 것이 특징입니다.배치 작업에는 항상 파일의 첫 번째 레코드로 @RUN 문이 포함됩니다.이 문은 실행 이름(runid)을 지정하고 우선순위를 정의하며 작업에서 사용할 것으로 예상되는 최대 SUPS(Standard Units of Processing) 수를 정의합니다.작업은 @START 제어문이 있는 다른 작업 또는 ST 키인을 통해 오퍼레이터에 의해 시작됩니다.기동시에, 임의의 수의 작업에 대해서 자동적으로 @START 스테이트먼트를 발행하도록 시스템을 설정할 수 있습니다.이러한 작업은 초기화, 복구 및 백그라운드 기능을 수행하는 데 사용됩니다.

@RUN 문의 모든 필드는 @START 문의 대응하는 필드에 의해 덮어쓸 수 있습니다.@START가 특권 사용자에 의해 실행되는 경우를 제외하고 userid 및 기타 보안 상태는 항상 @START 실행 시부터 취득됩니다.

@RUN 문에는 2개의 priority 필드가 있습니다.하나는 백로그 priority 지정에 사용됩니다.26개의 백로그priority 레벨(A ~Z)이 있습니다.Exec에는 열려 있는 배치 실행의 최대 수가 설정되어 있습니다.이 수준에 도달하면 백로그 큐에서 우선순위에 따라 작업이 선택됩니다.priority 내에서는 보통 FIFO가 선택됩니다.그러나 Exec은 파일 이름과 릴 번호를 찾는 첫 번째 프로그램 실행 시까지 작업 제어 스테이트먼트를 미리 검사합니다.필요한 일부 리소스를 사용할 수 없기 때문에 작업이 즉시 중지되는 경우 작업을 건너뛰고 동일한 우선 순위 수준에서 다른 작업을 시작할 수 있습니다.

두 번째 우선 순위 수준은 실행 프로세서 리소스 그룹을 정의합니다.일반적으로 실행 그룹의 우선순위가 높을수록 처리 시간이 길어집니다.

OS 2200 작업 제어 언어는 완전한 프로그래밍 기능을 지원하지 않지만 @ADD 제어문을 통해 제어 언어의 시퀀스를 동적으로 추가할 수 있습니다.추가할 파일이 추가되기 직전에 동일한 작업에 의해 생성되었을 수 있습니다.@ADD 및 기타 대부분의 제어문은 실행 중인 프로그램 내에서 ^[11]API를 통해 제출할 수도 있습니다.SSG(^[12]Symbolic Stream Generator)를 사용하여 간접적으로 추가 프로그래밍 기능을 사용할 수 있습니다.SSG는 입력 파라미터 및 시스템 정보에서 텍스트파일을 조작 및 작성하기 위한 프로그래밍 언어입니다.구성 관리(메이크) 처리 및 텍스트 이미지를 프로그래밍 방식으로 생성해야 하는 기타 기능에 많이 사용됩니다.결과 출력은 동일한 실행으로 "@ADD"될 수 있으므로 간접적으로 프로그래밍 가능한 런스트림을 제공할 수 있습니다.

연산자 명령은 실행의 백로그 및 실행 우선순위를 모두 변경하는 데 사용할 수 있습니다.모든 오퍼레이터 명령어는 API에 의해 적절한 권한을 가진 사용자에게 제공되므로 원격 관리자가 이를 자동화하거나 제어할 수 있습니다.

마감일은 배치의 특별한 경우입니다.마감 실행은 @RUN 또는 @START 제어 문에 마감 시간이 지정되어 있다는 점을 제외하고는 다른 배치 실행과 동일합니다.마감시간은 제어문의 최대 SUPS(시간 추정치)와 함께 사용됩니다.마감 작업은 마감 시간을 놓칠 수 있는 것으로 보이지 않는 한, 또는 그 때까지 일반 배치 우선순위로 실행됩니다.그러면 마감까지의 시간과 나머지 SUPS의 불일치가 클수록 우선순위는 높아집니다.마감일은 트랜잭션을 완전히 종료할 수 없고 실시간에 영향을 미치지 않지만, 목표를 달성하기 위해 필요한 경우 시스템 내의 다른 대부분의 처리를 효과적으로 종료할 수 있습니다.

요청.

OS 2200 시분할 세션은 ('온 디맨드'에서) 디맨드라고 불립니다.이들은 배치 실행과 동일한 제어 언어를 사용하며 "즉시" 제어문으로 알려진 몇 가지 추가 사항을 사용합니다.즉시 제어문은 프로그램이 실행 중인 경우에도 즉시 실행되어야 함을 나타내는 "@@" 센티넬을 사용합니다.파일을 작성하거나 할당하는 데 사용할 수 있지만 가장 중요한 것은 실행 중인 프로그램을 오류 종료하거나 신호를 보낼 수 있습니다.

트랜잭션

트랜잭션은 실행 시 실행되지만 저장되거나 제출된 제어문은 없습니다.대신 트랜잭션세션으로 정의된 세션에서 메시지를 수신하면 메시지가 스캔되어 해당 메시지가 배치되는 트랜잭션큐가 결정됩니다이것은 보통 메시지의 첫 글자에 의해 결정되지만 사용자가 작성한 스캐너가 ^[13]추가될 수 있습니다.

최대 250,000개의 활성 세션을 처리할 수 있는 통신 매니저는 착신 트랜잭션메시지를 받아 메시지큐잉 소프트웨어에 전달합니다.메시지 큐잉 아키텍처를 사용하여 큐잉된 메시지를 무제한으로 처리할 수 있습니다.오퍼레이팅시스템의 Transaction Interface Package(TIP; 트랜잭션인터페이스 패키지) API를 호출하여 적절한 큐잉 포인트로 트랜잭션을 큐잉합니다.각 큐잉 포인트는 작업의 우선순위 및 동시성 수준과 실행되어야 할 관련 트랜잭션 프로그램을 식별한다.

트랜잭션 프로그램 스케줄링 트리는 클라이언트가 트랜잭션 프로그램 그룹에 대한 상대적인 사용을 확립할 수 있도록 한다.동시성 제한은 시스템을 지배하는 한 가지 유형의 작업을 다른 작업의 배제로 회피하고 리소스의 과도한 커밋을 발생시키는 것을 방지합니다.트리에 최대 4094개의 노드를 생성할 수 있습니다.

• 트리의 각 노드에 대해 지정된 최대 동시 실행 수
• 상위 노드의 동시성으로 인해 종속 노드의 총 동시성이 제한됨
• 노드가 가장 높은 동시성으로 인해 시스템 동시성이 제한됨

트랜잭션 프로그램별로 우선순위(0~63)와 동시성 수준(1~2047)을 지정할 수 있습니다.

가장 우선순위가 높은 트랜잭션은 해당 노드 및 상위 노드에 대해 유효한 동시성 정책에 의해 제한되는 경우를 제외하고 스케줄링 대상으로 선택됩니다.

실시간

실시간은 다른 유형의 실행이 아닙니다.오히려 어떤 활동에서도 요구될 수 있는 일련의 우선순위.실시간은 일반적으로 OS 2200 통신 매니저 CPComm과 같은 장기간 실행되는 배치 프로그램에서 사용되지만, 이에 국한되지는 않습니다.

API에서는 응용 프로그램에서 사용할 수 있는 36가지 실시간 우선 순위가 있습니다.사용자와 계정은 실시간priority를 사용할 수 있는 권한이 있어야 합니다.애플리케이션이 priority 레벨을 사용하는 방법을 제어하는 것은 사이트에 달려 있습니다.실시간 우선순위가 낮은 우선순위를 완전히 지배하기 때문에 동작하지 않는 실시간 프로그램이 1개 이상의 프로세서를 묶을 가능성이 매우 높습니다.

실시간 우선순위는 개별 활동(스레드)에 적용되므로 프로그램은 실시간 스레드와 비실시간 스레드를 동시에 실행할 수 있습니다.

CPU 디스패치

실행이 시작되면 프로세서에 액세스하여 프로세서의 진행 속도를 제어합니다.Exec의 핵심은 모든 ^[14]프로세서를 관리하는 디스패처입니다.

대부분의 사이트에서 이들 중 극히 일부만 정의하고 있지만 Exec은 최대 4095개의 디스패치priority를 지원합니다.상위 2개의 "우선순위"는 바꿀 수 없습니다.이것은, 자신이 기동하고 있던 프로세서에서, 제어를 자발적으로 포기할 때까지 계속할 필요가 있는 특정의 처리 타입을 인식한 것입니다.인터럽트 록아웃은 인터럽트가 도착했을 때 또는 다른 EXEC 코드가 모든 인터럽트를 차단했을 때(인터럽트 핸들러도 액세스 할 수 있는 일부 데이터를 변경하기 위해) 발생합니다.

인터락은 동일한 물리적 프로세서에서 실행되어야 하거나 단순히 중단되어서는 안 되는 사후 처리 루틴에 의해 사용됩니다.Dispatcher, I/O 완료 및 I/O 초기화가 몇 가지 예입니다.이러한 우선순위에 의해 사용되는 모든 잠금은 스핀잠금입니다.다른 사용자가 설정할 수 있는 유일한 방법은 다른 프로세서뿐이기 때문에 설계상 매우 짧은 명령 시퀀스에 대해서만 설정해야 합니다.

높은 Exec 우선 순위는 오퍼레이터 명령 핸들러 및 실시간프로그램에 제어가 있는 경우에도 실행해야 하는 기타 기능에 의해 사용됩니다.그들은 매우 짧은 시간만을 사용할 것으로 예상된다.시간이 더 필요한 경우 Low Exec 작업에서 처리할 작업을 대기열에 넣어야 합니다.

실시간 액티비티는 프로세서의 퀀텀이 무제한이며 우선순위가 높은 실시간액티비티 또는 하이 Exec 액티비티에 의해 중단되지 않는 한 스위칭 없이 실행됩니다.실시간 액티비티에서는 우선순위가 낮은 것을 실행하는 사용 가능한 프로세서를 제어할 수 있습니다.즉시 가용성을 확보하기 위해 필요한 경우 프로세서 간에 인터럽트가 전송됩니다.고객은 미사일 비행, 시뮬레이터 실행 및 즉각적인 대응이 필요한 기타 기능에 실시간을 사용합니다.

트랜잭션 우선순위는 사이트에서 정의한 대로 두 가지 방법으로 처리될 수 있습니다.우선 순위만 중요하고 양자 크기는 본질적으로 무한하다는 점에서 우선순위가 낮은 실시간일 수 있습니다.이는 항공사 예약과 같은 매우 짧은 트랜잭션에 적합합니다.프로그래밍 오류로 인해 루프가 발생할 경우 Exec은 설정된 최대 시간이 매우 짧을 때 종료합니다.다른 형식을 사용하면 Exec이 범위 내에서 우선순위를 변경하여 시스템 리소스 사용을 최적화할 수 있습니다.이 접근방식은 I/O가 제한되고 우선순위가 점차 낮아지는 프로그램에는 우선순위가 높고 시간이 짧은 슬라이스를 부여하지만 컴퓨팅 프로그램에는 우선순위가 긴 슬라이스를 제공합니다.프로그램이 서로 다른 시간에 양방향으로 동작하는 경우가 많기 때문에 Exec은 동작을 기반으로 이러한 우선순위를 동적으로 조정합니다.이 접근법은 데이터베이스 조회나 항공사 운임 견적과 같이 장기간 실행되는 거래에 적합합니다.

배치와 수요는 항상 동적으로 조정된 우선순위를 사용합니다.I/O가 제한되거나 시분할 사용자와 대화 중인 프로그램은 우선순위가 높지만 짧은 시간이 걸립니다.컴퓨팅 지향 프로그램이 많을수록 우선순위가 낮아지고 시간이 길어집니다.

Exec에는 디스패치를 최적화하기 위한 두 가지 메커니즘이 있습니다.하나는 어피니티 기반의 디스패치입니다.가능한 경우 Exec은 지난번과 동일한 프로세서에서 액티비티를 실행하여 나머지 캐시 콘텐츠를 최대한 활용합니다.이것이 불가능할 경우 캐시 및 메모리 액세스 시간의 관점에서 "가장 가까운" 프로세서의 액티비티를 유지하려고 합니다.두 번째는 '공정성' 정책 메커니즘이다.사이트에서는 트랜잭션, 수요 및 배치 각각에 할당되는 자원의 상대적 비율을 정의할 수 있습니다.트랜잭션 및 배치 내에는 우선순위에 할당해야 하는 그룹 시간의 비율을 더 자세히 나타낼 수 있는 우선 순위 그룹이 있습니다.이렇게 하면 트랜잭션이 시스템을 지배할 수 없기 때문에 배치 작업이 수행되지 않습니다.다양한 priority 그룹 내에서는 (그룹 퍼센티지가0이 아닌 한) 각 그룹에 대해 어느 정도의 진척을 보증할 수 있습니다.이러한 「공정성」알고리즘은, 프로세서의 사용율이 매우 높을 때만 유효하게 됩니다만, OS 2200 시스템은, 거의 100%의 사용율로 모든 프로세서를 사용해 동작하는 경우가 많습니다.

미터링

OS 2200은 시스템 퍼포먼스 ^[15]관리를 위해 몇 가지 모델을 지원합니다.고객은 일정한 고정 퍼포먼스레벨을 구입할 수 있으며, Exec은 퍼포먼스가 그 수준을 넘지 않도록 프로세서의 사용 상황을 감시합니다.또한 워크로드가 증가하거나 긴급 상황이 발생했을 때 시스템의 최대 용량까지 일시적으로 또는 영구적으로 추가 성능을 구입할 수 있습니다.

최근에는 미터링 기능이 추가되었습니다.이 모드에서는, 고객이 항상 시스템의 풀 파워를 이용할 수 있습니다(단, 관리상의 제한도 있습니다).사용량은 한 달에 걸쳐 누적되며 보고된 사용량은 Unisys 과금으로 전송됩니다.특정 계약 조건에 따라서는, 클라이언트는 그 달의 계약 베이스라인을 넘는 초과 사용의 과금 청구서를 받거나, 계약 총 사용액이 감소했음을 나타내는 문구를 수신할 수 있습니다.첫 번째 양식은 휴대폰 요금 청구서처럼 몇 분 이상 충전될 가능성이 있다.후자는 선불 전화 카드를 사는 것과 같다.

파일 시스템

OS 2200에는 다른 대부분의 운영 체제와 달리 계층형 파일 시스템이 없습니다.오히려 구조화된 명명 규칙과 프로그램 파일이라고 불리는 컨테이너 파일의 개념을 가지고 있습니다.

OS 2200 의 파일은, 파일내의 워드 오프셋 또는 파일내의 섹터(28 워드 단위) 오프셋에 의해서 행선지가 지정되는 단순한 컨테이너입니다.이 28단어는 초기 대용량 저장 장치(FASTRAND 드럼)의 과거 단위로, 물리적 트랙당 64개의 장치를 수용할 수 있습니다.그럼에도 불구하고, 이것은 운 좋은 역사적 사고이다.4개의 28워드 단위 또는 112단어가 504바이트를 차지합니다.오늘날의 대용량 스토리지 디바이스는 모두 512바이트의 물리 레코드를 사용하고 있기 때문에 OS 2200 클라이언트는 거의 모두 112단어의 배수를 물리 레코드 크기와 데이터베이스 페이지 크기로 채택하고 있습니다.I/O 프로세서는 504 <-> 512 바이트 매핑에 대해 자동으로 조정되며 쓰기 시 8 바이트를 추가하고 각 물리 레코드의 읽기 시 0을 제거합니다.OS2200은 112 워드의 배수가 아닌 사이즈를 사용하는 어플리케이션을 데이터 체인에 의해 포함 물리 레코드를 불가분하게 읽어내고, 변경되지 않은 부분과 변경된 부분을 다시 기입함으로써 처리한다.특수 잠금 기능을 통해 장치 오류가 발생한 경우에도 클러스터 내의 여러 시스템에서 분리할 수 없습니다.

파일 형식 및 기타 내부 데이터 구조는 데이터 구조 프로그래밍 참조 ^[16]매뉴얼에 설명되어 있습니다.

파일명

Exec-8 이후 파일명은 Qualifier*Filename(f-cycle)(예: "Personnel*EMOPES(+1)")^[11] 형식으로 되어 있습니다.한정자와 파일명은 클라이언트가 원하는 이름 구조를 작성하기 위해 사용되는 12자 문자열입니다.F-cycle은 0 ~999 의 수치로, 복수의 파일을 생성할 수 있습니다.이 값은 상대적인 번호(+1) 다음 또는 새 사이클, (-1) 이전 사이클, (+0) 전류 사이클로 참조할 수 있습니다.사이클을 끄면 기본적으로 현재 사이클이 사용됩니다.새로운 세대의 파일을 작성하는 배치 실가동에서는, 이 어프로치를 사용합니다.숫자는 999 이후가 됩니다.한 번에 존재할 수 있는 상대 사이클 번호는 32개뿐입니다.(+1)을 작성하면 (-31)이 삭제됩니다.

모든 파일을 프로그램 파일로 사용할 수 있습니다.프로그램 파일에는 일반적으로 파일 역할을 하는 요소가 포함되어 있습니다.요소의 이름은 Qualifier*Filename(f-cycle)입니다.요소/버전(e-cycle)(예: "Personnel*PROGMS").TAXCALC/2008")요소 및 버전은 사용자가 원하는 방식으로 사용되는 12자 이름입니다.E-cycle은 생성 번호를 나타내지만 32개의 동시 사이클로 제한되지 않으며 제한은 256K 사이클이라는 점에서 f-cycle과 유사합니다.그러나 e-cycle은 텍스트 요소에만 적용되며 텍스트 요소의 각 행에는 삽입 및 삭제 시점의 사이클 번호가 표시됩니다.요소에는 유형 및 하위 유형도 있습니다.가장 일반적으로 사용되는 유형은 "text"와 "object"입니다.기본 유형이 적합하지 않은 경우 옵션을 통해 적절한 유형을 선택합니다.텍스트 요소에는 일반적으로 프로그래밍 언어를 나타내는 하위 유형(예: "ASM", "C", "COB", "FOR")도 있습니다.오브젝트 파일의 기본 요소 이름은 오브젝트 파일이 생성된 텍스트파일과 동일합니다.

오브젝트 요소는 메인 프로그램인 경우 또는 메인 프로그램을 포함한 다른 오브젝트 요소와 링크된 경우 실행해도 된다.링크는 정적 또는 동적일 수 있습니다.메인 프로그램은 모든 필수 서브 프로그램이 동일한 프로그램 파일, 시스템 라이브러리 또는 다른 방법으로 알려진 경우 사전 링크 없이 실행될 수 있습니다.완료되지 않은 참조에 대한 동적 링커의 검색을 지시하는 규칙을 프로그램 파일에 포함할 수 있습니다.링커를 사용하여 여러 오브젝트모듈을 정적으로 링크하여 원래 오브젝트모듈 내의 모든 명령, 데이터 및 기타 정보를 포함하는 새로운 오브젝트모듈을 형성할 수도 있습니다.

옴니버스 요소는 응용 프로그램에 의해 데이터로 사용될 수도 있고 응용 프로그램 및 시스템 유틸리티에 대한 구조화된 정보를 유지하는 역할을 할 수도 있습니다.옴니버스 요소에는 가정된 구조가 없습니다.

이전(기본 모드) 프로그래밍 모델과의 호환성을 위해 재배치 가능한 요소 유형과 절대 요소 유형이 있습니다.재배치 가능한 요소는 기본 모드 컴파일러의 출력입니다.기본 모드 스태틱링커(@MAP – collector)에 의해 결합되어 실행 가능한 "절대" 요소를 형성할 수 있습니다.

파일 관리

OS 2200은 완전한 가상 파일 시스템을 구현합니다.파일은 모든 대용량 저장 장치에 걸쳐 어디에서나 할당할 수 있습니다.대용량 스토리지는 가상 메모리가 관리되는 방식과 유사한 대용량 공간 풀로 취급됩니다.가능한 한 연속된 공간을 할당하는 한편, 대용량 스토리지는 8KB 크기의 페이지 세트로 취급되며, 파일을 필요한 만큼 동일하거나 다른 디바이스의 영역에 배치할 수 있습니다.파일의 동적 확장에서는 이전 할당에 인접한 공간을 할당하려고 하지만 사용 가능한 모든 위치에 공간이 할당됩니다.실제로 파일을 사용하기 위해 대용량 스토리지에 있을 필요도 없습니다.Exec과 파일 백업 시스템이 완전히 통합되어 있습니다.파일 백업이 이루어지면 테이프 릴 번호가 파일 디렉토리에 기록됩니다.대용량 저장공간이 부족할 경우 일부 파일에 현재 백업 복사본이 있고 사용 가능한 공간이 있으면 단순히 "언로드됨"으로 표시됩니다.이 방법으로 충분한 공간을 찾을 수 없는 경우 백업이 시작됩니다.

언로드된 파일에 대한 참조는 파일이 대량 저장소로 복사되는 동안 큐에 저장됩니다.전체 시스템은 자동적이며 일반적으로 사용자에게 ^[17]투명합니다.

액세스 방법

일반적으로 Exec은 액세스 방법을 제공하지 않습니다.파일은 단순한 컨테이너입니다.액세스 방법은 언어 런타임 시스템 및 데이터베이스 관리자에 의해 제공됩니다.단, 대량의 트랜잭션 ^[18]처리를 위해 제공되는 고정 블록액세스 방식은 예외입니다.데이터베이스 매니저보다 오버헤드는 훨씬 적지만 모든 잠금, 클러스터링 및 복구 메커니즘에 참여합니다.

리무버블 팩

클라이언트는 파일 위치를 보다 명확하게 제어하고 싶은 경우 "이동 가능한 팩" 개념을 사용할 수 있습니다.한때는 물리적으로 분리 가능한 디스크 팩을 나타내어 운영체제는 필요에 따라 오퍼레이터에게 팩마운트 요청을 자동으로 생성합니다.

오늘날에도 파일(일반적으로 데이터베이스 파일 또는 트랜잭션 파일)을 하나 이상의 디스크 볼륨에 배치하는 데 사용됩니다.파일은 여러 Disk 볼륨에 걸쳐 있을 수 있으며, 이제 파일 생성 시 볼륨 이름 목록이 제공됩니다.이러한 볼륨 그룹에 있는 파일은 계속 백업되지만 자동 가상 공간 관리의 대상이 되지 않습니다.

CIFS

OS 2200 에서는 Common Internet File System(CIFS)^[19]도 완전하게 실장되어 있습니다.CIFS 에서는 Microsoft 서버와 UNIX/Linux Samba 소프트웨어가 사용하는 SMB 프로토콜을 실장하고 있습니다.ClearPath OS 2200용 CIFS는 다른 CIFS 준거 시스템에 대한 파일 서버이자 파일 클라이언트입니다.여기에는 Windows를 실행하는 데스크톱 PC도 포함됩니다.CIFS는 SMB 메시지 서명을 지원합니다.

OS 2200 보안을 유지하기 위해 CIFS for ClearPath OS 2200은 두 가지 수준의 보호를 제공합니다.첫째, OS 2200 파일은 CIFS 명령어로 "공유"로 선언될 때까지 네트워크에 표시되지 않습니다.공유를 선언할 수 있는 사용자를 제어하는 특정 권한이 있습니다.두 번째 수준의 제어는 모든 액세스가 OS 2200 보안에 의해 보호된다는 것입니다.CIFS 경유로 OS 2200에 액세스 하는 클라이언트는 NTLM 또는 Kerberos 경유로 자동으로 식별하거나 OS 2200 사용자 ID와 패스워드에 대한 쿼리를 표시할 필요가 있습니다.

CIFS를 사용하면 OS 2200 파일을 계층 뷰로 표시할 수 있습니다.일반적으로 수식자는 트리의 최상위 레벨로 나타나며 그 뒤에 파일 이름, 요소 이름 및 버전이 표시됩니다.또, 완전한 Windows 파일명 형식을 사용해 OS 2200 서버에 파일을 보존할 수도 있습니다.Windows 애플리케이션은 OS 2200을 다른 파일 서버로 인식합니다.OS 2200 어플리케이션에는 네트워크 내의 Windows 파일서버 등 다른 CIFS 준거 서버에 존재하는 파일을 읽고 쓸 수 있는 API가 있습니다.텍스트 파일은 OS 2200 내부 포맷으로 자동 변환됩니다.이진 파일은 응용 프로그램에서 이해해야 합니다.

OS 2200에서 실행되는 CIFSUT 유틸리티는 암호화된 압축 파일을 WinZip 등의 다른 소프트웨어와 교환할 수 있습니다.

서브시스템

서브시스템과 보호 서브시스템의 개념은 OS 2200 설계의 중심입니다.하위 시스템은 Windows의 .dll과 가장 유사합니다.시스템에서 ^[20]실행 중인 모든 프로그램 간에 공유할 수 있는 코드와 데이터입니다.OS 2200 에서는, 각 서브 시스템은 독자적인 뱅크 세트를 가지고 있습니다.이 뱅크 세트는 주소 공간의 다른 부분에 존재하며, 어떤 사용자 프로그램에서도 직접 액세스 할 수 없습니다.대신 하드웨어와 OS는 콜 명령의 타깃이 될 수 있는 '게이트'를 제공합니다.자세한 내용은 Unisys 2200 시리즈 시스템 아키텍처를 참조하십시오.

데이터베이스 매니저, 런타임라이브러리, 메시징 시스템 및 기타 많은 시스템 기능이 서브시스템으로 구현됩니다.런타임 라이브러리 등 보통 순수한 코드로 구성된 일부 서브시스템은 게이트를 필요로 하지 않고 콜 명령의 직접 타깃이 될 수 있습니다.이러한 하위 시스템은 사용자 프로그램의 보호 환경에서 실행됩니다.데이터베이스 관리자와 같은 다른 서브시스템은 코드와 데이터 또는 특권 코드로 구성되며 게이트를 통해서만 호출할 수 있습니다.이들 서브시스템에 관련되어 있는 액세스컨트롤 리스트가 있어 콜하는 사용자를 제어할 수도 있습니다.보다 중요한 것은 게이트가 표시되는 특정 엔트리 포인트, 서브시스템이 실행되는 보호 환경 및 대부분의 경우 발신자에 대한 추가 보안 정보를 제공하는 사용자 고유의 파라미터를 제어합니다.

보안.

B1 보안

OS 2200 보안 시스템은 무단 액세스, 변경 또는 노출로부터 데이터를 보호하도록 설계되었습니다.여기에는 DoD Orange Book B1 레벨 ^[21]사양의 구현이 포함됩니다.OS 2200은 1989년 9월에 처음으로 B1 평가에 성공했습니다.그 평가는 1994년까지 유지되었다.그 후 OS 2200 개발자는 B1 평가에서 요구되는 개발 및 문서화를 계속 수행했습니다.

B1 시스템의 중심에는 사용자와 ^[22][23]객체의 개념이 있습니다.사용자는 ID, 간격 수준, 칸막이 및 권한을 가집니다.오브젝트에는 다양한 유형의 접근을 위해 오브젝트의 특정 조합이 필요합니다.OS 2200의 오브젝트는 파일, 보호된 서브시스템, 디바이스 및 테이프 릴로 구성됩니다.

사용자 세션의 보안 프로파일에는 사용자 ID, 클리어런스 수준(0-63), 컴파트먼트 세트 및 허용되는 권한 세트가 포함됩니다.OS 2200은 기밀성(읽기 없음, 쓰기 없음)과 Biba 무결성 모델(읽기 없음, 쓰기 없음)을 위해 Bell-La Padula 모델에 기반한 필수 접근컨트롤(MAC)과 임의 접근컨트롤(DAC)을 모두 구현하고 있습니다.실행이 파일을 읽거나 실행하려면 실행의 간격 수준이 파일의 간격 수준 이상이어야 하며, 파일의 간격 수준이 0이거나 실행의 간격 수준 범위 내에 있어야 합니다. 또한 실행의 실행 컴파트먼트 세트에는 파일의 구획 세트가 포함되어야 합니다.OS 2200은 Bell-La Padula와 Biba 모델의 요건을 조합하고 있기 때문에 실행의 클리어런스 레벨과 컴파트먼트세트는 파일에 쓰거나 삭제할 수 있도록 파일의 레벨과 정확하게 일치해야 합니다.

DAC는 접근컨트롤 목록을 객체에 관련짓습니다.이 목록은 접근권을 가진 사용자와 사용자 그룹을 식별하고 사용자 또는 그룹이 허용하는 접근 유형(읽기, 쓰기, 실행 또는 삭제)을 정의합니다.

대부분의 환경에서는 B1 컨트롤의 전체 세트가 너무 제한적이기 때문에 시스템 관리자는 적용할 컨트롤을 선택하여 서버를 구성할 수 있습니다.기본 보안에서 보안 수준 3까지 일련의 보안 수준이 시작점이 됩니다.

보안 책임자

모든 OS 2200 시스템에는 보안 책임자로 지정된 사용자가 1명씩 있습니다.기본 보안이 설정된 시스템에서는 보안 담당자만 특정 작업을 수행할 수 있습니다.보안 수준이 높은 시스템에서는 신뢰할 수 있는 다른 사용자가 이러한 작업 중 일부를 수행할 수 있습니다.

OS 2200은 최소 특권의 원칙에 따라 세분화된 보안 메커니즘을 제공합니다.이 원칙에서는 필요한 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 합니다.따라서 OS 2200에는 모든 사용자가 수행할 수 있는 "슈퍼 사용자" 역할의 개념이 없습니다.대신 각 사용자에게 개별적으로 부여될 수 있는 많은 특정 권한 세트를 사용합니다.각 특권은 특정 권한과 관련지어집니다.

파일 보안

보안 수준 1 이상으로 구성된 시스템에서는 개체를 생성하는 사용자가 개체의 소유자가 됩니다.디폴트로는 오브젝트는 작성 사용자에게는 비공개이지만 퍼블릭 또는 접근컨트롤 리스트에 의해 제어되는 경우도 있습니다.소유자 또는 보안 담당자는 해당 객체에 대한 접근컨트롤 목록을 작성할 수 있습니다.

기본 보안으로 구성된 시스템에서는 파일에 소유자가 없습니다.대신 계정 또는 프로젝트에 대해 비공개로 생성되거나 공용입니다.이러한 액세스에 대한 액세스는 읽기 및 쓰기 키로 제어할 수 있습니다.

인증

사용자는 시스템에 로그온할 때 자신을 식별하고 필요에 따라 이 세션에서 사용할 간격 수준과 컴파트먼트 세트를 선택합니다.

OS 2200은 유연한 인증 시스템을 제공합니다.여러 인증 메커니즘이 동시에 지원됩니다.클라이언트 또는 서드파티에 의해 작성된 인증 소프트웨어도 사용할 수 있습니다.표준 인증 기능은 다음과 같습니다.

• OS 2200에 의해 암호화된 파일에 유지되는 사용자 ID 및 비밀번호
• 사용자 ID 및 비밀번호 메커니즘을 사용하여 Microsoft Windows 등의 외부 시스템에 의해 실행되는 인증
• NTLM
• 케르베로스
• LDAP

마지막 두 가지에서는 바이오메트릭스, 스마트카드 및 이들 테크놀로지가 지원하는 기타 인증 메커니즘을 사용할 수 있습니다.

암호화

OS 2200은 발신자 ^[24]데이터를 암호화 및 복호화하는 소프트웨어 서브시스템인 Cipher API를 통해 미사용 데이터에 대한 암호화를 제공합니다.Cipher API는 벌크 데이터 암호화를 위한 하드웨어 액셀러레이터 카드 사용도 지원합니다.

CMOS 기반의 Dorado 서버의 경우 CPComm은 전송 중인 데이터의 SSL/TLS 암호화를 제공합니다.인텔 기반의 Dorado 서버의 경우 SSL 및 TLS는 open에 의해 제공됩니다.Dorado 펌웨어에 포함되어 있다SSL 。모든 Dorado 서버는 SSLv3뿐만 아니라 TLS 수준 1.0 - 1.2를 지원하지만 프로토콜의 취약성으로 인해 SSL이 기본적으로 비활성화됩니다.

CPComm API와 Cipher API 모두 FIPS 인증 소프트웨어 암호화 모듈인 CryptoLib의 암호화 서비스를 사용합니다.AES 알고리즘과 Triple DES 알고리즘은 CryptoLib에 실장되어 있는 알고리즘 중 하나입니다.

OS 2200 에서는, 테이프 드라이브의 암호화도 서포트하고 있습니다.이것에 의해, 아카이브 데이터의 암호화가 실현됩니다.

클러스터링

OS 2200 시스템은 클러스터화되어 단일 시스템보다 뛰어난 퍼포먼스와 가용성을 실현할 수 있습니다.최대 4대의 시스템을 공유 디스크를 통해 데이터베이스와 파일을 공유하는 클러스터로 결합할 수 있습니다.하드웨어 디바이스인 XPC-L은 데이터베이스 및 파일 ^[25]접근을 위한 고속 잠금 매니저를 제공함으로써 시스템 간의 조정을 제공한다.

클러스터 환경에서는 각 시스템이 공유 파일 및 하나 이상의 공유 응용 프로그램 그룹과 함께 고유한 로컬 파일, 데이터베이스 및 응용 프로그램 그룹을 가질 수 있습니다.로컬 파일 및 데이터베이스는 단일 시스템에서만 액세스할 수 있습니다.공유 파일 및 데이터베이스는 클러스터의 모든 시스템에서 동시에 액세스할 수 있는 디스크에 있어야 합니다.

XPC-L은 액션을 조정하기 위한 시스템 간의 통신 경로를 제공합니다.또한 매우 빠른 잠금 엔진을 제공합니다.XPC-L 에의 접속은, 매우 짧은 레이텐시로 동작하는 특수한 I/O프로세서를 개입시켜 행해집니다.XPC-L의 잠금 매니저는 파일 잠금과 데이터베이스 잠금 모두에 필요한 모든 기능을 제공합니다.여기에는 교착 상태 감지 및 실패한 응용 프로그램의 잠금을 해제하는 기능이 포함됩니다.

XPC-L은 완전히 용장화된 구성을 작성하기 위해 2대의 물리 서버와 함께 구현됩니다.유지보수(XPC-L 펌웨어의 새로운 버전을 로드하는 등)는 한쪽 서버에서 다른 한쪽 서버에서 계속 실행할 수 있습니다.1대의 서버에 물리적인 손상을 포함한 장해가 발생해도 클러스터는 정지하지 않습니다.이것은, 모든 정보가 양쪽 서버에 보관되기 때문입니다.

운용 및 관리

운용

OS 2200 의 운용은, 액티브한 오퍼레이터와 1 개 이상의 콘솔을 중심으로 구축됩니다.각 콘솔은 터미널 창으로,^[26] 일부는 시스템 내 액티비티에 대한 요약 정보로 자주 업데이트되는 고정 디스플레이용으로 예약되어 있습니다.

콘솔의 나머지 부분은 이벤트의 스크롤 표시로 사용됩니다.오퍼레이터의 응답이 필요한 메시지가 발행되면 0 ~9 의 번호가 지정되며 응답할 때까지 디스플레이에 남아 있습니다.테이프 마운트 메시지는 다른 메시지와 함께 스크롤되지만 테이프가 마운트될 때까지 2분마다 반복됩니다.

Operations Sentinel은 모든 OS 2200 ^[27]작업에 사용됩니다.OS 2200 콘솔은 Operations Sentinel 디스플레이 내의 창일 뿐입니다.디스플레이 PC는 필요한 수만큼 배치할 수 있습니다.리모트 조작이 일반적입니다.Operations Sentinel은 임의의 수의 ClearPath, 윈도우즈, 리눅스 및 UNIX 시스템을 지원합니다.

자동 액션 메시지 데이터베이스는 ^[28]제품과 함께 릴리스됩니다.이 데이터베이스를 통해 Operations Sentinel은 메시지를 인식할 수 있습니다.스크립트는 응답이 필요한 메시지에 자동으로 응답하거나 원하지 않는 메시지를 숨기거나 다른 언어로 번역하거나 이벤트를 생성하도록 작성될 수 있습니다.일부 클라이언트에서는 완전 암실 조작을 사용하고 있습니다.시스템을 감시하고 특정 이벤트가 발생했을 때 경보를 생성하는 원격 위치에 Operations Sentinel이 표시됩니다.

행정부.

OS 2200 시스템의 관리는 시스템의 특정 영역에 특화된 다양한 도구를 사용하여 수행됩니다.예를 들어 트랜잭션 환경 관리에 사용되는 툴이 있습니다.이 툴은 새로운 트랜잭션프로그램의 설치를 허용하고, 이 프로그램에 필요한 모든 정보를 지정하며, 큐잉 구조, 우선순위 및 동시성 수준을 변경합니다.^[29]

그 외의 툴은, 시큐러티 책임자 전용으로, 유저의 작성, 허가된 권한의 변경,^{[22],[30],[23]} 시스템 시큐러티 설정의 변경등을 가능하게 합니다.

대부분의 툴은 그래픽 인터페이스를 갖추고 있지만 그렇지 않은 툴도 있습니다.모두 일괄 저장 파일인터페이스를 제공합니다.이 인터페이스에서는 모든 액션이 제어 스트림에서 지정됩니다.이를 통해 로컬사이트 또는 기타 이벤트에 따라 또는 리모트사이트에서 모든 관리 인터페이스를 스크립팅할 수 있습니다.관리 영역마다 고유한 권한이 필요합니다.

응용 프로그램 그룹

응용 프로그램 그룹은 Universal Data System(UDS;^[31] 유니버설데이터 시스템) 인스턴스, 메시지큐 서브시스템 인스턴스 및 일부 트랜잭션세트로 구성된 논리 구성입니다.각 응용 프로그램 그룹에는 자체 감사 내역이 있습니다.OS 2200은 시스템 내에서 최대 16개의 애플리케이션 그룹을 지원합니다.

애플리케이션 그룹의 개념은 흔히 "애플리케이션"이라고 불리는 것에 해당합니다.즉, 연결된 처리의 더 큰 단위를 나타내는 프로그램 및 데이터 세트입니다.예를 들어, 애플리케이션 그룹은 항공사 시스템을 나타낼 수 있다.다른 애플리케이션 그룹은 기업 재무 시스템을 나타낼 수 있습니다.또는 애플리케이션 그룹은 은행 지점과 같이 동일한 애플리케이션 및 데이터 모델의 인스턴스를 나타낼 수 있습니다.중요한 것은 각 애플리케이션 그룹에 고유한 환경, 세션, 복구 등이 있다는 것입니다.

애플리케이션 그룹은 개별적으로 시작, 중지 및 복구할 수 있습니다.

응용 프로그램 그룹에는 자체 계정 및 스케줄링 규칙이 없습니다.여러 응용 프로그램 그룹의 트랜잭션은 동일한 우선순위를 공유하고 인터리브 우선 순위를 가질 수 있습니다.이를 통해 사이트에서는 시스템 전체에서 트랜잭션의 상대적 우선순위를 제어할 수 있습니다.

「 」를 참조해 주세요.

• Unisys 2200 시리즈시스템 아키텍처에서는 하드웨어 아키텍처에 대한 정보를 제공합니다.
• OS 2200 컴파일러 및 링커에 대한 정보를 제공하는 Unisys OS 2200 프로그래밍 언어.
• OS 2200 데이터베이스 및 데이터베이스 매니저에 대한 정보를 제공하는 Unisys OS 2200 데이터베이스.
• OS 2200 통신에 대한 정보를 제공하는 Unisys OS 2200 통신.
• Unisys OS 2200 분산 처리에서는 OS 2200 분산 처리에 대한 정보를 제공합니다.

원료의 기타 위치

Unisys 이력 뉴스레터에는 Unisys 이력 및 컴퓨터에 대한 기사가 포함되어 있습니다.Unisys 이력 뉴스레터 외에 다른 사이트로의 링크도 있습니다.

유니시스의 역사 자료 대부분은 미네소타 대학의 찰스 배비지 연구소와 델라웨어의 해글리 박물관과 도서관에 있습니다.Charles Babbage Institute는 ERA의 아카이브, 세인트 폴, MN, 버로우스의 초기 레밍턴 랜드 아카이브를 보유하고 있습니다.Hagley Museum and Library는 Sperry 기록 보관소의 대부분을 보유하고 있습니다.

레퍼런스

각주