hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
허큘리스 (에뮬레이터) 운영체제 상태
허큘리스는 모든 IBM 메인프레임 운영 체제와 기술적으로 호환되며, 최신 메인프레임에서는 더 이상 실행되지 않는 이전 버전과도 호환된다. 그러나 많은 메인프레임 운영 체제는 합법적으로 실행하려면 공급업체 라이선스가 필요하다. OS/390, Z/OS, VSE/ESA, z/VSE, VM/ESA, Z/VM, TPF/ESA, z/TPF와 같은 최신 라이선스 운영 체제는 기술적으로 호환되지만 매우 제한적인 상황을 제외하고는 허큘리스 에뮬레이터에서 합법적으로 실행할 수 없으며, 항상 IBM에서 라이선스를 받아야 한다. 병렬 시스플렉스를 가능하게 하는 IBM의 커플링 시설 제어 코드와 UTS도 실행하려면 라이선스가 필요하다.
허큘리스에서 라이선스 비용 없이 합법적으로 실행할 수 있는 운영 체제는 다음과 같다.
허큘리스 (에뮬레이터) 운영체제 상태
허큘리스 에뮬레이터에서 오픈 소스 운영 체제인 리눅스 온 IBM Z 및 OpenSolaris for System z를 실행하는 데 알려진 법적 제한은 없다. 이들은 허큘리스에서 잘 실행되며, 많은 리눅스 온 IBM Z 개발자는 허큘리스를 사용하여 작업을 수행한다. 여러 배포업체는 64비트 Z/아키텍처 버전의 리눅스를 제공하며, 일부는 ESA/390 호환 버전도 제공한다. 메인프레임 리눅스 배포판에는 SUSE 리눅스 엔터프라이즈 서버, 레드햇 엔터프라이즈 리눅스, 데비안, CentOS, Slackware가 포함된다. Sine Nomine Associates는 z/VM이 제공하는 기능을 기반으로 OpenSolaris를 System z로 가져왔다. OpenSolaris를 위한 이러한 특정 z/VM 기능 에뮬레이션은 허큘리스 버전 3.07부터 포함된다.
허큘리스 (에뮬레이터) 사용법
허큘리스는 코드가 이식 가능한지(예: 리눅스 프로세서 아키텍처 전반에서), 대칭형 다중 처리(SMP)를 지원하는지, 64비트 "클린"한지 확인하기 위한 개발 환경으로 사용될 수 있다.
또한 현재 및 전직 메인프레임 운영자 및 프로그래머, 그리고 이전 경험이 없는 사람들도 취미 및 학습 목적으로 허큘리스와 퍼블릭 도메인 IBM 운영 체제를 사용하는 대규모 커뮤니티가 있다. 클래식 IBM 메인프레임 운영 체제 버전을 탐색하면서 습득한 대부분의 기술은 최신 버전을 실행하는 라이선스 IBM 머신으로 전환할 때 여전히 관련성이 있다.
허큘리스의 오픈 소스 특성으로 인해 누구나 자신만의 맞춤형 에뮬레이터 버전을 만들 수 있다. 예를 들어, 허큘리스 프로젝트와 독립적인 개발자 그룹은 허큘리스와 자유롭게 사용 가능한 MVS의 클래식 버전(이후 VM 및 DOS/VS) 모두를 수정하여 "S/380"이라고 부르는 하이브리드 메인프레임 아키텍처를 구현했으며, 이후 운영 체제 버전과의 31비트(2016년 기준, 64비트) 바이너리 호환성을 어느 정도 향상시켰다(2018년 기준, 32비트도 지원됨).
허큘리스 (에뮬레이터) 성능
허큘리스 에뮬레이션 성능이 실제 메인프레임 하드웨어와 정확히 어떻게 일치하는지 결정하기는 어렵지만, 성능 특성은 당연히 상당히 다르다. 이는 실제 메인프레임 하드웨어를 다른 PC 및 서버와 비교하기 어렵고 구체적이고 통제된 성능 비교가 부족하기 때문이기도 하다. 성능 비교는 라이선스 IBM 운영 체제의 경우 법적으로 불가능할 가능성이 높으며, 이들 운영 체제는 리눅스와 같은 다른 운영 체제와는 상당히 다르다.
허큘리스 (에뮬레이터) 성능
허큘리스는 처리 성능을 MIPS로 표현한다. 초기 System/360 및 System/370 하드웨어의 연식을 고려할 때, 소프트웨어에서 컴퓨터 구조를 에뮬레이트하는 상당한 오버헤드에도 불구하고 허큘리스가 적당히 강력한 하드웨어에서 실행될 때 이들보다 성능이 뛰어날 것이라는 것은 비교적 안전한 가정이다. 그러나 최신, 부분적으로 또는 완전히 구성된 System z 머신은 허큘리스를 훨씬 능가한다. 허큘리스를 실행하는 비교적 빠른 듀얼 프로세서 X86 머신은 실제 환경에서 두 프로세서를 모두 사용하는 코드에 대해 약 50~60 MIPS를 유지할 수 있으며, 최첨단(2009년 초) PC급 시스템에서는 300 MIPS에 달하는 지속적인 속도를 보고했다. 허큘리스는 합성 명령어 벤치마크 또는 기타 작고 컴퓨팅 집약적인 프로그램과 같이 밀접한 루프에서 실행될 때 1200 MIPS 이상의 최고치를 달성할 수 있다.
터보헤르큘리스의 공동 창립자 톰 레만은 다음과 같이 썼다.
허큘리스 (에뮬레이터) 성능
...우리는 적절한 크기의 부하(표준 패키지로 800 MIPS)를 실행할 수 있습니다. 해당 머신이 그보다 크다면, 쿼드 네할렘 기반 패키지로 1600 MIPS까지 확장할 수 있으며, 내년 초에 8웨이 네할렘 EX 기반 머신을 약속받아 3200 MIPS를 달성할 수 있을 것입니다. 그보다 큰 것은 시스템 컬렉션으로 복제됩니다.
허큘리스는 일반적으로 1990년대 중반 IBM의 PC 기반 메인프레임보다 성능이 뛰어나며, 광고된 최대 성능은 약 29 MIPS이다. 더 강력하지만 여전히 보급형인 IBM Multiprise 2000 및 3000 메인프레임(역시 1990년대 제품)과 비교할 때, 일반적인 x86 하드웨어의 허큘리스는 성능 면에서 미드레인지 서버로 간주될 것이다. 9672 1세대 이후의 모든 메인프레임에 대해 허큘리스는 일반적으로 가장 낮은 엔드 시스템일 것이다. 비교를 위해, 2010년대의 고급 IBM zEnterprise 196 시스템은 머신당 52,000 MIPS 이상을 제공할 수 있으며, 상당한 I/O 성능 이점을 가지고 있다. 동일한 수의 에뮬레이트된 Sys Z 프로세서를 사용할 경우 z/PDT는 허큘리스보다 약 3배 빠르다.
성능 외에도 메인프레임 운영자에게 일반적으로 관련이 있는 비기능적 시스템 속성들이 있다는 점에 유의해야 한다. 여기에는 고가용성, 페일오버, 핫플러그 CPU 및 RAM, I/O 메시를 통한 I/O 라우팅, 시스템 마이그레이션 및 LPAR 관리가 포함된다. 예를 들어, 370/390/ESA/z 아키텍처는 네 가지 명령어를 사용하여 I/O를 구현한다. 크고 복잡한 I/O 작업은 설정되어 주변 장치로 넘겨져 처리되며, CPU는 I/O 장치가 작업 완료를 통지할 때까지 I/O에 더 이상 관여하지 않는다. 이로 인해 메인프레임 CPU 자체가 아닌 I/O 주변 장치에 내장된 다양한 프로세서에서 "CPU 사이클"의 대부분이 사용되는 메인프레임 시스템이 된다. 메인프레임 CPU는 "계산" 그 자체보다는 데이터 이동을 조율하는 오케스트라 지휘자 역할을 더 많이 한다. 가장 간단한 I/O 장치는 에뮬레이트할 수 있지만, 복잡한 시스템은 어려움을 초래할 것이다.
허큘리스 (에뮬레이터) 터보헤르큘리스
2009년 로저 보울러는 프랑스에 터보헤르큘리스 SAS를 설립하여 허큘리스 기술을 상용화했다. 2009년 7월, 터보헤르큘리스 SAS는 IBM에 터보헤르큘리스가 판매하는 시스템에서 사용할 수 있도록 고객에게 Z/OS 라이선스를 요청했다. IBM은 회사의 요청을 거부했다. 2010년 3월, 터보헤르큘리스 SAS는 유럽 연합 집행위원회 규제 당국에 불만을 제기하여 IBM이 메인프레임 하드웨어를 메인프레임 운영 체제에 끼워파는 행위를 통해 EU 독점 금지 규정을 위반했다고 주장했고, EC는 예비 조사를 시작했다. 2010년 11월, 터보헤르큘리스는 마이크로소프트 코퍼레이션으로부터 투자를 받았다고 발표했다. 2011년 9월, EC 규제 당국은 아무런 조치 없이 조사를 종결했다.
ES EVM
ES EVM(러시아어: Единая система электронных вычислительных машин (ЕС ЭВМ), "통합 전자 계산기 시스템"), 또는 예스(YeS) EVM은 영어 문헌에서 통합 시스템 또는 랴트(러시아어: Ряд, "시리즈")로도 알려져 있으며, 소련의 주도로 경제상호원조회의 회원국에서 1968년부터 1998년 사이에 제작된 IBM의 System/360 및 System/370 메인프레임과 일반적으로 호환되는 일련의 메인프레임 컴퓨터이다. ES EVM 메인프레임은 15,000대 이상 생산되었다.
ES EVM 개발
1966년, 소련의 경제학자들은 상호 호환되는 통합 컴퓨터 시리즈를 만들 것을 제안했다. 미국의 IBM System/360의 성공으로 인해, 경제 기획자들은 IBM 설계를 사용하기로 결정했다. 비록 일부 저명한 소련 컴퓨터 과학자들은 이 아이디어를 비판하고 대신 BESM이나 민스크와 같은 소련의 고유 설계를 선택할 것을 제안했음에도 불구하고 말이다. 복제 작업은 1968년에 시작되었고, 생산은 1972년에 시작되었다. 또한, 1968년 이후 다른 경제상호원조회의 회원국들도 이 프로젝트에 참여했다.
몇몇 하드웨어 부품을 제외하고, ES EVM 기계는 서방 국가들에서 소련의 합법적인 특허를 기반으로 독자적으로 설계된 것으로 인정받았다. 상당히 독창적이었고 주로 역공학으로 만들어진 하드웨어와 달리, 소프트웨어의 대부분은 약간 수정되고 현지화된 IBM 코드를 기반으로 했다. 1974-1976년, IBM은 소련 당국과 접촉하여 ES EVM 개발에 관심을 표명했지만, 1979년 소련군이 아프가니스탄에 진입한 후, 미국의 소련과의 기술 협력 금수 조치로 인해 IBM과 ES 개발자 간의 모든 접촉은 중단되었다.
ES EVM 개발
코콤의 제한으로 인해, 많은 소프트웨어 현지화는 IBM 소프트웨어를 역어셈블하여 최소한의 수정으로 이루어졌다. 가장 일반적인 운영체제는 OS/360의 수정 버전인 OS ES(러시아어: ОС ЕС)였다. OS ES의 후기 버전들은 매우 독창적이었고 IBM OS와 달랐지만, 많은 원본 IBM 코드도 포함하고 있었다. 심지어 소련 프로그래머들 사이에서는 이 소련 운영체제에 비밀 명령어가 포함되어 있어서 미국 국가를 출력한다는 일화적인 소문도 있었다. 오늘날 ES EVM 작업에 참여했던 일부 러시아 기관들은 IBM과 협력하여 실제 IBM 메인프레임과 ES EVM 시스템 모두에 대한 레거시 지원을 계속하고 있다.
ES EVM 개발
ES EVM 기계는 모스크바의 전자 계산기 기계 과학 연구 센터(NITsEVT)에서, 아르메니아 예레반의 예레반 컴퓨터 연구 개발 연구소에서, 그리고 나중에는 민스크의 전자 계산기 기계 과학 연구소(NIIEVM)와 펜자의 펜자 컴퓨터 기계 과학 연구소에서 개발되었다. 이들은 민스크의 컴퓨팅 기계 민스크 생산 그룹(MPOVT)과 펜자의 펜자 전자 컴퓨터 공장에서 제조되었다. 일부 모델은 불가리아, 헝가리, 폴란드, 체코슬로바키아, 루마니아, 동독과 같은 다른 동구권 국가에서도 생산되었고, 일부 주변 장치는 쿠바에서도 생산되었다. 전 독일 총리인 앙겔라 메르켈은 1986년 박사 학위 논문을 위해 동독의 ES EVM 컴퓨터 중 하나를 사용했다.
ES EVM 컴퓨터는 랴트 1, 랴트 2, 랴트 3, 랴트 4로 알려진 네 가지 하위 시리즈 또는 세대(러시아어: ряд)로 분류되었는데, 이 명칭이 전체 프로젝트의 일반적인 이름이 되었다.
ES EVM 하드웨어 모델 및 기술 세부 정보
1969-1978년에 출시된 ES EVM의 첫 번째 하위 시리즈에는 System/360과 유사하며 10–450 kIPS로 작동하는 모델 1010, 1020, 1030, 1040, 1050과 IBM 버전과 호환되지 않는 더 희귀하고 고급 버전인 1022, 1032, 1033, 1052가 포함되었다. 첫 번째 모델의 일렉트로닉스는 TTL 회로를 기반으로 했고, 후기 기계는 ECL 설계를 사용했다. ES 1050은 최대 1M RAM과 64비트 부동 소수점 레지스터를 가졌다. 이 시리즈에서 가장 빠른 기계인 1978년에 개발된 ES 1052는 700 kIPS로 작동했다.
1977-1978년에 출시된 두 번째 하위 시리즈에는 System/370과 유사하며 33 kIPS—1.050 MIPS로 작동하는 모델 1015, 1025, 1035, 1045, 1055, 1060이 포함되었다. ES 1060은 최대 8M RAM을 가졌다.
ES EVM 하드웨어 모델 및 기술 세부 정보
1984년에 출시된 세 번째 하위 시리즈는 일부 독창적인 개선 사항이 적용된 System/370과 유사했으며, 1016, 1026, 1036, 1046, 1066을 포함했다. ES 1066은 최대 16M RAM을 가졌고 5.5 MIPS로 작동했다. 네 번째 하위 시리즈는 직접적인 IBM 아날로그가 없었으며, 1130, 1181, 1220을 포함했다. 1995년에 출시된 이 시리즈의 마지막 기계인 ES 1220은 여러 64비트 CPU 명령, 256M RAM을 지원했으며 7 MIPS로 작동했지만 성공적이지 못했다. 단 20대만 생산되었고, 1998년에 ES 메인프레임의 전체 생산이 중단되었다.
MUSIC/SP
MUSIC/SP(Multi-User System for Interactive Computing/System Product; 원래 McGill University System for Interactive Computing)는 1970년대에 맥길 대학교에서 초기 IBM 시분할 시스템인 RAX(원격 접근 컴퓨팅 시스템)에서 개발되었다.
이 시스템은 IBM S/360, S/370 및 4300 시리즈 메인프레임 하드웨어에서 실행되었으며, 파일 접근 제어 및 데이터 압축과 같은 당시에는 새로운 기능을 제공했다. 대부분의 메인프레임 컴퓨팅이 여전히 천공 카드로 이루어지던 시대에, 학계와 학생들이 단말기에서 대화식으로 프로그램을 만들고 실행할 수 있도록 설계되었다. 수년에 걸쳐 개발이 계속되었고, 이 시스템은 전자우편, 인터넷 그리고 궁극적으로 월드 와이드 웹을 포괄하도록 진화했다. 1980년대 후반에 정점에 달했을 때, 북아메리카와 남아메리카, 유럽 및 아시아에서 200개 이상의 대학, 단과대학 및 고등학교 교육구가 이 시스템을 사용했다.
MUSIC/SP
MUSIC은 원래 독립형 운영체제로 설계되었지만, IBM의 가상 머신 기능인 VM/370의 등장으로, VM/370에서 실행되는 게스트 운영체제로 MUSIC을 배포하는 것이 더 일반적이 되었다.
MUSIC/SP 역사
수년에 걸쳐 다음과 같은 사람들이 MUSIC 및 MUSIC/SP 시스템에 기여했다.
로이 밀러, 앨런 그린버그, 윌프 만델, 데이브 에드워즈, 넬슨 응우옌,
케빈 맥나미, 돈 판스워스 (IBM), 딘 다니엘 (IBM), 글렌 매튜스, 린다 체르나브로,
프랭크 페티니키오, 얼 린드버그, 피에르 고예트, 캐시 윌모트,
사이먼 풀링거, 데이비드 소프, 제럴드 래처, 해리 윌리엄스 (마리스트 칼리지),
데이브 주라세크 (노던 버지니아 커뮤니티 칼리지), 크리스티앙 로베르 (에콜 폴리테크니크),
시몬 스필러, 실비노 메짜리, 그리고 마이크 쇼트.
MUSIC/SP 기능
MUSIC/SP와 그 기능에 대한 완전한 설명은 광범위한 문서에서 찾을 수 있다. 주요 기능은 아래에 요약되어 있다.
MUSIC/SP 파일 시스템은 여러 면에서 독특했다. 시스템 전체에 걸친 단일 파일 인덱스가 있었다. 소유자의 사용자 ID와 파일 이름이 이 인덱스에서 파일을 찾기 위해 해시되었으므로, 시스템의 어떤 파일이든 단일 I/O 작업으로 찾을 수 있었다. 그러나 이것은 사용자에게 플랫 파일 시스템을 제공했다. 도스, 마이크로소프트 윈도우 및 유닉스 시스템에서 일반적으로 제공되는 디렉터리 구조가 없었다. 1990년에 파일 시스템의 "트리 구조" 디렉터리 보기가 위에 겹쳐져, 당시 사용 가능했던 파일 시스템과 더 일치하게 되었다. 기본적으로 파일에 저장된 정보는 압축되었다. 이는 디스크 공간을 상당히 절약할 수 있게 해주었다. 파일 시스템은 소유자가 파일 읽기, 쓰기, 추가 및 실행을 제어할 수 있도록 하는 상당히 정교한 접근 제어 체계를 가졌다. 또한 모든 사용자에게 보이는 "공개" 파일과 소유자에게만 보이는 "개인" 파일의 개념도 있었다.
MUSIC/SP 기능
시스템의 초기 버전은 가상 메모리 및 주소 변환을 지원하지 않았다. 한 번에 하나의 활성 사용자만 코어 메모리에 상주할 수 있었다. 스와핑 (디스크로)은 다른 사용자 간의 시분할을 위해 사용되었으며, 가변 길이 타임 슬라이스가 사용되었다. 가상 메모리 지원은 1985년에 도입되었다. 이를 통해 여러 사용자가 동시에 코어 메모리에 있을 수 있게 되었고, 실행할 수 있는 프로그램 크기의 많은 제한을 제거했으며, 상당한 성능 향상을 제공했다. 시스템 성능은 또한 일반적으로 사용되는 모듈을 시작 시 가상 메모리에 미리 로드하여 모든 사용자가 동시에 사용할 수 있도록 함으로써 향상되었다.
MUSIC/SP 기능
이 시스템은 학술 컴퓨팅 및 컴퓨터 과학 교육을 지원하도록 설계되었으므로, 풍부한 프로그래밍 언어 모음이 제공되었다. 시스템 핵심은 IBM/370 어셈블러로 작성되었지만, 대부분의 네이티브 애플리케이션은 포트란으로 작성되었다. 이 시스템은 워털루 WATFIV 및 WATBOL 컴파일러를 지원했으며, 파스칼, C, PL/I, 베이직, APL, 알골, RPG, 및 GPSS용 컴파일러도 제공했다. 1984년 CMS에서 REXX가 포팅될 때까지 시스템에는 명령 스크립팅 언어가 없었다. 나중에 1986년에는 완전히 REXX로 작성된 완전한 사용자 인터페이스가 있었다.
전자우편은 MUSIC/SP의 주요 응용 프로그램 중 하나였다. 전자우편 인터페이스는 처음에는 로컬 전자우편에 대한 접근을 제공했다. 네트워크가 발전함에 따라, 이는 BITNET 및 인터넷 기반 전자우편에 대한 접근을 제공하도록 확장되었다. MUSIC/SP는 1990년 위스콘신 대학교의 WiscNet TCP/IP 코드가 시스템에 포팅되어 모든 인터넷 서비스에 대한 접근을 제공할 수 있게 될 때까지 인터넷에 직접 접근할 수 없었다.
MUSIC/SP 기능
이 시스템의 주요 기능은 IBM의 주류 운영체제(MVS)에서 실행되도록 설계된 프로그램을 실행할 수 있다는 것이었다. 이것은 SVC (Supervisor Call instruction) 수준에서 시스템 호출을 가로채는 MVS 에뮬레이터를 사용하여 달성되었다. 대부분의 타사 응용 프로그램은 이 모드에서 실행되었다. MUSIC/SP 개발자들은 일반적으로 응용 프로그램의 자체 버전을 작성하는 대신 MVS 버전에서 시작하여 MVS 에뮬레이션 모드에서 실행되도록 재구축했다. MVS 에뮬레이션은 실제의 작은 부분 집합이었기 때문에, 응용 프로그램은 일반적으로 MUSIC/SP에서 더 효율적으로 실행되었다.
교육 환경에서 이 시스템이 가진 한 가지 주요 장점은 파일 상단에 "제어 카드"라는 특수 라인을 사용하여 지원되는 모든 언어의 소스 파일을 자동으로 적절한 컴파일러(포트란이 기본값)로 보내고, 컴파일, 링크 및 실행할 수 있다는 것이었다(컴파일, 링크 및 실행 옵션도 제어 카드에 지정됨). 이는 단순히 명령줄에 파일 이름을 입력하는 방식으로 이루어졌다.
1980년을 기준으로 다양한 단말기가 지원되었는데, IBM 독점 프로토콜을 사용하는 EBCDIC 기반 장치와 비동기 ASCII 기반 장치 모두 포함되었다. 단말기는 다양한 유형의 전단 처리기를 통해 연결되었기 때문에(당시나 지금이나 일반적인 IBM 시분할 방식과 같음), 상당한 시간 동안 CPU의 개입 없이 기능할 수 있었으며, MUSIC은 가변 길이 타임 슬라이스를 사용했다. 이는 컴퓨트 바운드 처리에서 타임 슬라이스당 최대 몇 초에 도달할 수 있었다. 반대로, 사용자가 출력 버퍼를 채우거나 대화형 읽기에 도달하면 타임 슬라이스는 즉시 종료되었다.
MUSIC/SP 에뮬레이션
Sim390 에뮬레이터에는 MUSIC/SP의 데모 시스템이 포함되어 있다. 이는 무료로 제공되며 마이크로소프트 윈도우에서 실행된다. 데모 시스템은 허큘리스에서도 실행된다.
SMP/E
시스템 수정 프로그램/확장(System Modification Program/Extended, SMP/E)는 시스템 수정 프로그램(System Modification Program, SMP)의 독점 버전으로, z/OS 시스템에 소프트웨어 제품 설치를 관리하고 해당 제품의 수정을 추적하도록 설계된 도구이다.:1
SMP/E는 여러 소프트웨어 버전을 관리하고, 패치 및 업데이트(PTF)를 적용하는 데 도움을 주며, 체계적인 테스트와 필요한 경우 이전 상태로의 복구를 용이하게 한다. 또한 실제 설치가 제대로 작동하는지 확인하기 위한 "시험 실행" 유사 설치를 허용하고, 승인된 소프트웨어 업데이트만 이루어지도록 감사 및 보안 기록을 유지하며, z/OS의 모든 소프트웨어 설치에 대한 고도로 발전된 중앙 집중식 제어를 제공한다.
SMP/E
SMP/E 없이 z/OS에 설치되는 소프트웨어 제품을 설계하고 출시할 수는 있지만, 대부분의 메인프레임 관리자는 적어도 중요하지 않은 패키지의 경우 SMP/E 지원 제품을 선호한다. SMP/E를 사용하려면 일반적으로 작업 제어 언어(JCL)에 대한 기본적인 지식이 필요하지만, 대부분의 제품은 샘플 JCL을 제공한다. SMP/E와 관련된 엄격한 소프트웨어 관리 규율은 제품 문서에도 적용되며, IBM 및 기타 공급업체는 SMP/E 작업 프로세스와 정확히 일치하는 표준화된 "프로그램 디렉토리" 설명서를 각 소프트웨어 제품에 대해 제공한다. 예를 들어, 프로그램 디렉토리는 사전 요구사항 및 동시 요구사항에 대한 자세한 정보를 제공한다.
SMP/E를 사용하여 시스템 업데이트를 관리하면 시스템이 일관된 상태를 유지하고 해당 상태에 대한 변경 사항이 제대로 감사되도록 함으로써 시스템 무결성을 보장하는 데 도움이 된다.
SMP/E 역사
IBM은 OS/360 및 OS/VS에 SMP를 도입하여 IEBEDIT 및 IMAPTFLE와 같은 도구를 포함하는 반자동 프로세스를 대체했다. IBM은 이후 3개의 SMP 무료 릴리스를 도입했으며, 특히 SMP3에서 SMP4로의 릴리스 간에 상당한 변경이 있었다. 네 가지 릴리스 모두 분할 데이터 세트(PDS)에 추적 데이터를 저장한다.
IBM은 OS/VS용 SMP/E를 도입했지만, SMP/E 릴리스 2는 OS/VS1을 지원하는 마지막 릴리스이다. SMP/E는 SMP 릴리스 1부터 4까지 사용했던 PDS 대신 VSAM 데이터 세트에 추적 데이터를 저장한다. 원래는 별도의 제품이었지만, SMP/E는 z/OS와 함께 번들로 제공된다.
IBM은 궁극적으로 다른 운영체제에도 유사한 도구를 도입했다. 예를 들어, DOS/360용 Maintain System History Program (MSHP), VM/SP부터 z/VM까지의 가상 머신 서비스 가능성 향상 단계 (VM/SP SES) (현재 VMSES/E) 등이 있다.
SMP/E 개념
모든 IBM 소프트웨어와 대부분의 비IBM 소프트웨어에는 해당 소프트웨어 조각과 릴리스 번호를 식별하는 최소 7자리 FMID(Function Modification ID)가 할당된다. 이 첫 번째 FMID를 기본 FMID라고 한다. 예를 들어, DB2 버전 9의 기본 FMID는 HDB9910이다. 별도로 설치 가능한 기능들도 기본 제품과 어떤 식으로든 관련되는 FMID(종속 FMID라고 함)를 갖는다. –  DB2 버전 9의 영어 언어 패널의 종속 FMID는 JDB9910이다.
소프트웨어 패키지는 오브젝트 파일(MOD), 매크로(MAC), 샘플 프로그램(SAMP) 등과 같은 개별 구성 요소인 요소로 구성된다.:p.37
CSI(Consolidated Software Inventory)는 SMP/E가 배포 및 대상 라이브러리의 내용을 추적하는 데 필요한 정보를 포함하는 데이터 세트이다. CSI는 설치된 FMID 및 요소, 최신 업데이트 ID, 관련 라이브러리에 대한 포인터를 식별하는 "메타데이터"를 포함한다.
SMP/E 개념
SYSMOD(System Modification)는 시스템에 대한 모든 수정 사항을 의미한다. 여기에는 다음이 포함된다.:p.38
각 SYSMOD에는 고유하게 식별하기 위해 7자리 SYSMOD ID가 할당된다. SYSMOD가 설치될 때 이 ID는 추가되거나 교체되는 요소의 CSI 항목에 기록되며 RMID(replacement module id)라고 불린다.
MCS(Modification Control Statements)라고 불리는 간단한 선언적 언어는 SYSMOD를 식별하고 설치 방법에 대한 정보를 SMP/E에 제공한다. 각 SYSMOD는 APAR 수정 또는 PTF로 식별하고 SYSMOD ID를 제공하며 해당 FMID를 식별하는 등 여러 MCS 문으로 시작된다. :pp.5ff
SMP/E 개념
선행 조건(prereqs)은 두 번째 SYSMOD가 설치되기 전에 설치해야 하는 SYSMOD이다. 공동 조건(coreqs)은 함께 설치되어야 하는 두 개 이상의 SYSMOD로, 다른 SYSMOD 없이는 어떤 SYSMOD도 설치할 수 없다. SYSMOD가 첫 번째 SYSMOD의 기능을 대체하는 경우 해당 SYSMOD를 대체(supersedes 또는 sups)한다. 이 prereq, coreq, sup 정보는 MCS에 제공된다. 필수 체인은 "주어진 SYSMOD의 필수 조건으로 직간접적으로 식별되는 SYSMOD의 시퀀스"이다. 예를 들어, A가 B의 prereq이고 B가 C의 prereq이면, A와 B는 C의 필수 체인이며 C가 설치되기 전에 둘 다 설치되어야 하지만, 반드시 별도의 SMP/E 실행에서 설치될 필요는 없다.:pp.231,226,236,232 필수 체인은 종종 매우 복잡해지며 수백 개의 SYSMOD를 포함할 수 있다.
SMP/E 개념
HOLDDATA는 특정 SYSMOD에 오류가 포함되어 있거나 설치하기 전에 SMP/E 범위 밖에서 수동 처리가 필요함을 나타내는 MCS 문 세트이다.:p.229 사용자는 보류된 SYSMOD를 설치하기 전에 가능하면 문제를 해결하기 위한 조치를 취해야 한다.
SMP/E는 두 가지 유형의 라이브러리를 관리한다. 대상 라이브러리(TLIBS)는 시스템을 실행하는 데 사용되는 실행 코드 및 기타 정보를 포함한다. 원래는 실행 프로그램용 SYS1.LINKLIB, 표준 매크로용 SYS1.MACLIB 등 제한된 수의 대상 라이브러리가 있었지만, 2012년 현재 각 소프트웨어 제품은 일반적으로 자체 대상 라이브러리 세트를 가지고 있다. 배포 라이브러리(DLIBS)는 시스템의 각 요소에 대한 마스터 복사본을 포함한다. 각 제품(FMID)은 일반적으로 SMP/E에 의해서만 사용되는 자체 배포 라이브러리 세트를 가지고 있다. OS/360의 라이브러리는 유닉스의 디렉토리와 달리 일반적으로 한 가지 유형 및 형식의 데이터만 포함한다. 소프트웨어 패키지에는 오브젝트 라이브러리(MOD), ISPF 패널(PNL), 매크로 라이브러리(MAC) 등이 있을 수 있다.
SMP/E 사용
SMP/E는 배치 작업으로 실행되는 단일의 큰 프로그램이다. 일련의 ISPF 패널을 사용하여 사용자 입력을 기반으로 SMP/E 작업 스트림을 대화식으로 구축할 수 있다.
일반적인 단계 순서는 각 단계에 사용되는 명령에서 따온 RECEIVE-APPLY-ACCEPT이다.
SMP/E RECEIVE 명령은 SMP 외부 소스의 SYSMOD를 처리한다. 이전에는 IBM에서 대략 매월 배포하는 PUT 테이프였을 수도 있다. 최근에는 인터넷을 통해 다운로드된 SYSMOD 컬렉션일 수도 있다. RECEIVE 프로세스는 MCS를 사용하여 각 SYSMOD에 대한 CSI 항목을 생성하고, 해당 상태를 "RECEIVED"로 표시하며, MCS 정보와 실제 SYSMOD 데이터를 저장한다.
REJECT 명령은 "RECEIVED" 상태의 SYSMOD를 삭제하는 데 사용될 수 있다.
SMP/E 사용
APPLY 명령은 하나 이상의 수신된 SYSMOD를 해당 대상 라이브러리에 설치한다. 적용할 SYSMOD는 다양한 기준에 따라 선택할 수 있다. 예를 들어, 단일 SYSMOD는 SYSMOD ID로 선택할 수 있고, 그룹으로 수신된 모든 SYSMOD는 SOURCEID로 선택할 수 있으며, 수신되었지만 아직 적용되지 않은 모든 SYSMOD를 적용할 수 있다. 지정된 SYSMOD에 대한 필수 체인이 확인되고, 적절한 필수 조건이 없거나, 보류 상태이거나, 대체된 SYSMOD는 오류로 표시되어 설치되지 않는다. 일반적으로 SMP/E는 이러한 오류를 최소화하기 위해 "RECEIVE" 상태의 필수 조건도 자동으로 적용하도록 지시된다. 설치된 SYSMOD는 CSI에서 상태가 "APPLIED"로 변경된다. APPLY CHECK는 실제 설치를 수행하지 않고도 설치할 SYSMOD를 확인하는 데 사용할 수 있다.
RESTORE 명령은 승인되지 않은 적용된 SYSMOD를 제거하는 데 사용될 수 있다.
ACCEPT 명령은 SYSMOD를 배포 라이브러리에 영구적으로 설치하고 CSI에서 상태를 "ACCEPTED"로 표시한다. 일반적으로 ACCEPT는 다음 서비스 APPLY 전에 SYSMOD가 올바르게 작동하는 것으로 확인되면 수행된다. SMP/E에는 CSI를 포함한 모든 설치 라이브러리를 삭제(그리고 설치를 다시 시작)하는 것 외에는 ACCEPT 작업을 취소하는 방법이 없다.
SMP/E SMP/E 데이터 세트
SMP/E는 크고 복잡한 프로그램이며, 각 릴리스마다 기능과 데이터 세트가 추가된다. 주요 SMP/E 데이터 세트는 다음과 같다.
CSI –  통합 소프트웨어 인벤토리
CSI에는 SMP/E가 배포 및 대상 라이브러리를 추적하는 데 필요한 모든 정보가 포함되어 있다.
PTS –  PTF 임시 저장소
PTS 데이터 세트는 수신된 PTF를 보관하는 데 사용된다.
MTS –  매크로 임시 저장소
MTS 데이터 세트는 배포 라이브러리에만 존재하는 매크로를 위한 대상 라이브러리로, APPLY 처리 중에 이러한 매크로의 현재 버전을 어셈블리에 사용할 수 있도록 한다.
STS –  소스 임시 저장소
STS 데이터 세트는 배포 라이브러리에만 존재하는 소스를 위한 대상 라이브러리로, APPLY 처리 중에 이러한 모듈의 현재 버전을 어셈블리에 사용할 수 있도록 한다.
SMP/E 출처
SMP
《OS/VS System Modification Program (SMP)》 (PDF) Seco판. Systems. September 1974. GC28-0673-1.
SMP4
《OS/VS System ModificationProgram (SMP) System Programmer's Guide》 (PDF) Seven판. Systems. September 1980. GC28-0673-6.
SMPE
《System Modification Program Extended - User's Guide - Release 6》 (PDF) Twelf판. Systems. April 1992. SC28-1302-11.
SMPEREF
《System Modification Program Extended - Reference - Release 8.1》 (PDF) Fourteen판. September 1994. SC28-1107-13.
SDSF
시스템 디스플레이 및 검색 기능(System Display and Search Facility, SDSF)은 IBM의 IBM 메인프레임 운영체제인 z/OS의 구성 요소로, 사용자와 관리자가 대화형 사용자 인터페이스를 사용하여 메인프레임 작동 및 시스템 리소스의 다양한 측면을 보고 제어할 수 있도록 한다. SDSF에 표시되는 정보 중 일부에는 배치 작업 출력, 유닉스 프로세스, 스케줄링 환경, 프린터 및 네트워크 라인과 같은 외부 장치의 상태, 배치 및 시스템 로그 파일 및 덤프가 포함된다.
SDSF 역사
현장 개발 프로그램 제품일 때 SDSF는 SPOOL 디스플레이 및 검색 기능으로 알려졌다. SPOOL이라는 단어는 1980년대 후반에 프로그램 제품이 되었을 때 System으로 변경되었다.
z/OS 릴리스 1.9부터 SDSF는 REXX 인터페이스를 지원하여 배치 프로그램이 SDSF 기능을 사용할 수 있도록 한다. 이 지원에는 SDSF에서 시작된 정보가 포함된 스템 변수가 포함된다.
z/OS 릴리스 1.10 이전에는 SDSF가 JES2와 함께만 사용하도록 지원되었고 JES3는 지원되지 않았다. 비록 독립 소프트웨어 개발 판매 회사인 피닉스 소프트웨어 인터내셔널과 톤 소프트웨어의 제품이 JES3에 유사한 기능을 제공했지만 말이다. z/OS 릴리스 1.10 이상에서는 SDSF가 JES3를 완벽하게 지원하며, JES3 작업의 데이터/세트 및 작업 출력을 표시하는 일부 새로운 명령(JDS 및 ODS)을 포함한다.
z/OS V1R13 릴리스와 함께 SDSF는 커서 감지 정렬 또는 포인트 앤 샷 정렬 및 Rexx 및 Java 프로그래밍 환경의 개방형 로그에 대한 광범위한 지원과 같은 몇 가지 흥미로운 기능이 포함되었다.
SDSF 기능
SDSF는 각 패널이 메인프레임 작동의 특정 측면에 대한 정보를 표시하는 패널 모음으로 구성된다. 현재 제공되는 패널은 다음과 같다.
ST 패널에서 SDSF는 각 배치 작업에 대해 다음 명령을 지원한다. 이러한 명령은 원하는 기능을 수행하는 JES2 또는 JES3 명령으로 변환된다.
EXEC 2
EXEC 2는 IBM 가상 머신/시스템 제품(VM/SP) 운영 체제의 CMS 구성 요소와 함께 원래 제공되었던 EXEC 2 프로세서에서 사용되는 해석된 명령 절차 제어 스크립트 언어이다.
EXEC 2 EXEC와의 관계
EXEC 2는 대부분 CMS EXEC와 호환되지만 EXEC 2 스크립트는 &TRACE 문으로 시작해야 한다. 일부 EXEC 문과 미리 정의된 변수는 EXEC 2에 존재하지 않지만, 일부 경우에는 유사한 것이 있다. 일부 문과 미리 정의된 함수에는 약간의 차이가 있다.
EXEC 2에는 다음과 같은 개선 사항이 있다.
EXEC의 일부 문은 EXEC 2에서 지원되지 않는다.
EXEC의 일부 미리 정의된 변수는 EXEC2에 정의되어 있지 않다.
EXEC 2 XEDIT 매크로
XEDIT 매크로는 파일 형식 XEDIT을 가진 파일이며, 내용은 CMS EXEC, EXEC 2 또는 REXX 구문을 사용하여 작성된다. 일반 EXEC 2 "EXEC" 명령 파일과 마찬가지로, CMS EXEC 파일과 구별하기 위해 "&TRACE" 문으로 시작한다.
EXEC 2 역사
1970년대에 작성되었고 VM/SP 릴리스 1에서 CMS용으로 공식적으로 도입된 EXEC 2는 CMS EXEC에 선행되었고 REXX에 의해 대체되었다.
CMS EXEC, EXEC 2 및 REXX 세 가지 명령 인터프리터는 모두 z/VM에 의해 계속 지원된다.
라파엘 전파의 작품 목록
이 문서는 라파엘 전파 구성원들의 그림 목록 및 라파엘 전파 양식과 관련된 다른 예술가들이 제작한 그림 목록이다. 여기에서 "라파엘 전파"라는 용어는 느슨하고 포괄적인 방식으로 사용되었다.
라파엘 전파의 작품 목록 관련 예술가
기사가 있는 그림:
(앤서니 프레데릭 아우구스투스 샌디스)
다른 작품 (날짜 미상):
미시간 터미널 시스템
미시간 터미널 시스템(Michigan Terminal System, MTS)은 최초의 시분할 컴퓨터 운영체제 중 하나이다. 1967년 미시간 대학교에서 IBM S/360-67, S/370 및 호환 메인프레임 컴퓨터용으로 개발되었으며, 미국, 캐나다, 영국의 8개 대학교 컨소시엄에 의해 33년간 (1967년 ~ 1999년) 개발되고 사용되었다.
미시간 터미널 시스템 개요
미시간 대학교 다중 프로그래밍 감독자 (UMMPS)는 원래 미시간 대학교 학술 컴퓨팅 센터 직원에 의해 IBM S/360-67, S/370 및 호환 컴퓨터 운영을 위해 개발되었다. 이 소프트웨어는 다중 프로그래밍, 다중 처리, 가상 메모리, 시분할 감독자로서 여러 상주 재진입 프로그램을 실행하는 것으로 설명될 수 있다. 이러한 프로그램 중에는 명령 해석, 실행 제어, 파일 관리 및 회계를 위한 미시간 터미널 시스템 (MTS)이 있다. 최종 사용자는 터미널, 배치 및 서버 지향 기능을 사용하여 MTS를 통해 컴퓨팅 자원과 상호 작용한다.
MTS라는 이름은 다음을 의미한다.
MTS는 미국, 캐나다, 영국, 브라질, 그리고 유고슬라비아 등 약 13개 사이트에서 상업적으로 사용되었으며, 여러 사이트에서 시험 또는 벤치마킹 목적으로 사용되었다. MTS는 MTS 컨소시엄에 포함된 8개 대학의 핵심 그룹에 의해 개발되고 유지되었다.
미시간 터미널 시스템 개요
미시간 대학교는 1988년에 "사용자가 요구하는 한 신뢰할 수 있는 MTS 서비스가 제공될 것이며 ... 대안이 사용자의 컴퓨팅 요구 사항을 충족할 수 있게 되면 MTS는 단계적으로 폐지될 수 있다"고 발표했다. 1996년 6월 30일에 최종 사용자를 위한 MTS 운영을 중단했다. 당시에는 대부분의 서비스가 클라이언트/서버 기반 컴퓨팅 시스템으로 전환되었는데, 일반적으로 서버는 유닉스, 클라이언트는 다양한 맥, PC, 유닉스 종류였다. 미시간 대학교는 1997년 5월 30일에 MTS 시스템을 마지막으로 종료했다.
렌슬리어 공과대학교 (RPI)가 MTS를 상용 환경에서 사용한 마지막 사이트로 알려져 있다. RPI는 1999년 6월에 MTS를 폐기했다.
오늘날 MTS는 허큘리스, Sim390 및 FLEX-ES와 같은 IBM S/370 에뮬레이터를 사용하여 여전히 실행된다.
미시간 터미널 시스템 기원
1960년대 중반, 미시간 대학교는 UMES(University of Michigan Executive System)의 통제하에 IBM 7090 하드웨어에서 일괄 처리 서비스를 제공하고 있었지만, 시분할을 사용하여 대화형 서비스를 제공하는 데 관심을 가졌다. 당시 컴퓨터가 수행할 수 있는 작업은 작은 실제 메모리 용량에 의해 제한되었다. IBM이 1960년대 중반 IBM 시스템/360 제품군을 출시했을 때, 이러한 제한에 대한 해결책을 제공하지 못했고 IBM 내부에서는 시분할의 중요성과 지원 필요성에 대해 상충되는 견해가 있었다.
매사추세츠 공과대학교 (MIT)에서 개발된 몇 가지 기본 아이디어를 바탕으로 브루스 아든, 버나드 갤러, 프랭크 웨스터벨트 (모두 미시간 대학교 학술 컴퓨팅 센터의 부소장) 및 톰 오브라이언이 작성한 "시분할 환경에서의 프로그램 및 주소 지정 구조"라는 제목의 논문이 1966년 1월에 발표되었다. 이 논문은 시분할을 구현하는 데 사용될 수 있는 동적 주소 변환 (DAT)을 사용하는 가상 메모리 아키텍처를 설명했다.
미시간 터미널 시스템 기원
1년간의 협상과 설계 연구 끝에 IBM은 가상 메모리를 지원하고 미시간 대학교의 시분할 지원 요구를 수용할 동적 주소 변환 (DAT) 기능을 갖춘 S/360-65 메인프레임 컴퓨터의 단일 버전을 만들기로 동의했다. 이 컴퓨터는 모델 S/360-65M으로 명명되었다. "M"은 미시간을 의미했다. 그러나 IBM은 처음에는 이 기계에 시분할 운영체제를 공급하지 않기로 결정했다. 한편, 제너럴 모터스, 매사추세츠 공과대학교 (MIT)의 링컨 연구소, 프린스턴 대학교, 카네기 공과대학교 (이후 카네기 멜런 대학교)를 포함한 여러 다른 기관들이 이 프로젝트에 대해 들었다. 그들은 모두 시분할 아이디어에 흥미를 느꼈고 수정된 IBM S/360 시리즈 기계를 주문하는 데 관심을 표명했다. 이러한 관심이 확인되자 IBM은 컴퓨터의 모델 번호를 S/360-67로 변경하고 지원 제품으로 만들었다. 100개 이상의 새로운 모델 S/360-67 요청이 들어오자 IBM은 시분할 시장이 있음을 깨달았고, 첫 번째 모델 S/360-67과 거의 동시에 출시될 새로운 시분할 운영체제인 TSS/360 (TSS는 Time-sharing System을 의미)을 개발하기로 동의했다.
미시간 터미널 시스템 기원
모델 65M이 도착하기를 기다리는 동안 미시간 대학교 컴퓨팅 센터 직원들은 ARPA CONCOMP (Conversational Use of Computers) 프로젝트의 자금 지원을 받은 IBM System/360 Model 50을 사용하여 초기 시분할 실험을 수행할 수 있었다. 시분할 실험은 "주방 식탁에 쓰여진 반 페이지의 코드"와 MIT의 링컨 연구소에서 온 작은 다중 프로그래밍 시스템인 LLMPS를 결합하여 시작되었으며, 이는 미시간 대학교 다중 프로그래밍 감독자 (UMMPS)로 수정되었고, 이는 다시 MTS 작업 프로그램을 실행했다. MTS의 이 가장 초기 버전은 새로운 IBM S/360 하드웨어 경험을 얻기 위해 사용되는 일회성 시스템으로 의도되었으며, IBM의 TSS/360 운영체제가 출시되면 폐기될 예정이었다.
미시간 터미널 시스템 기원
TSS 개발은 예상보다 오래 걸렸고, 출시일이 지연되었으며, 1967년 1월 S/360-67 (일련 번호 2)이 컴퓨팅 센터에 도착했을 때 아직 사용할 수 없었다. 이때 미시간 대학교는 모델 67을 반환하고 다른 메인프레임을 선택할지 아니면 TSS가 준비될 때까지 MTS를 임시 시스템으로 개발할지 결정해야 했다. 결정은 MTS 개발을 계속하는 것이었고, 직원들은 초기 개발 작업을 모델 50에서 모델 67로 옮겼다. TSS 개발은 결국 IBM에 의해 취소되었다가 다시 재개되었고, 다시 취소되었다. 그러나 이때 미시간 대학교는 자신들이 개발한 시스템을 좋아했고, 더 이상 임시 시스템으로 간주되지 않았으며, MTS는 미시간 대학교와 다른 사이트에서 33년간 사용되었다.
미시간 터미널 시스템 MTS 컨소시엄
MTS는 미국, 캐나다, 영국의 8개 대학 컨소시엄에 의해 개발, 유지 및 사용되었다.
여러 MTS 사이트에서 하나 이상의 MTS 시스템을 실행했다. NUMAC은 두 개 (처음에는 뉴캐슬, 나중에는 더럼), 미시간은 1980년대 중반에 세 개 (옥수수용 UM, 파란색용 UB, 인간 유전학용 HG), UBC는 여러 시기에 세 개 또는 네 개 (일반, 도서관, 관리 및 교육용 MTS-G, MTS-L, MTS-A, MTS-I)를 실행했다.
각 MTS 사이트는 MTS 개발에 기여했으며, 때로는 새로운 기능의 설계 및 구현을 주도하고 때로는 다른 곳에서 수행된 작업을 개선, 강화 및 비판했다. 많은 MTS 구성 요소는 여러 사이트의 여러 사람들의 작업이다.
초기에는 MTS 사이트 간의 협업이 대면 방문, 전화 통화, 우편을 통한 문서 및 자기 테이프 교환, SHARE 또는 기타 회의에서의 비공식적인 만남을 통해 이루어졌다. 나중에는 이메일, CONFER 및 *포럼을 사용한 컴퓨터 회의, 네트워크 파일 전송 및 이메일 첨부 파일이 이전 방법을 보완하고 결국 대부분 대체했다.
미시간 터미널 시스템 MTS 컨소시엄
MTS 컨소시엄 회원들은 1971년부터 1982년까지 총 82개의 MTS 뉴스레터를 발행하여 MTS 개발을 조정하는 데 도움을 주었다.
1974년 UBC에서 시작하여 MTS 컨소시엄은 회원 사이트 중 한 곳에서 연례 MTS 워크숍을 개최했다. 워크숍은 비공식적이었지만, 미리 제출된 논문과 세션 요약이 포함된 후속 발간된 회의록이 포함되었다. 1980년대 중반에는 MTS 사이트의 일부 (UBC, SFU, UQV, UM 및 아마도 RPI)가 참여하는 여러 서부 워크숍이 개최되었다.
연례 워크숍은 MTS 개발 작업이 줄어들기 시작한 후에도 계속되었다. 단순히 "커뮤니티 워크숍"이라고 불리며, 1990년대 중반까지 컴퓨팅 서비스 제공에 대한 전문 지식과 공통 경험을 공유하기 위해 계속되었는데, MTS가 더 이상 캠퍼스 컴퓨팅의 주요 원천이 아니었고 일부는 MTS 운영을 완전히 중단했음에도 불구하고 말이다.
미시간 터미널 시스템 MTS 컨소시엄
MTS 개발에 참여한 8개 MTS 컨소시엄 사이트 외에도 MTS는 다음을 포함한 여러 다른 사이트에서 실행되었다.
MTS 사본은 사라예보 대학교, 유고슬라비아에도 보내졌지만, 설치되었는지 여부는 알려져 있지 않다.
프랑스 그르노블에 있는 프랑스 국립 컴퓨터 과학 및 제어 연구소인 INRIA는 워털루 대학교, 남일리노이 대학교, 미국 해군대학원, 암달 코퍼레이션, 맥길 대학교 병원을 위한 ST 시스템, 스탠퍼드 대학교, 일리노이 대학교 등 여러 다른 사이트와 마찬가지로 시험적으로 MTS를 운영했다.
미시간 터미널 시스템 하드웨어
이론적으로 MTS는 IBM S/360-67, 가상 메모리를 포함하는 모든 IBM S/370 시리즈 및 그 후속 기종에서 실행된다. MTS는 다음 컴퓨터에서 생산, 벤치마킹 또는 시험 구성으로 실행되었다.
미시간 대학교는 1967년 IBM 외부의 첫 번째 IBM S/360-67 (일련 번호 2)에 MTS를 설치하고 운영했으며, 1975년에는 두 번째 암달 470V/6 (일련 번호 2)을 설치했다. 1982년에는 첫 번째 암달 5860 (일련 번호 1)을, 1986년에는 첫 번째 공장 출하 IBM 3090–400을 설치했다. NUMAC은 영국에서 첫 번째 S/360-67에 MTS를 운영했으며, 유럽에서도 아마 첫 번째일 것이다. 브리티시컬럼비아 대학교 (UBC)는 1974년 MTS를 IBM S/370 시리즈 (IBM S/370-168)에서 실행하도록 변환하는 데 주도적인 역할을 했다. 앨버타 대학교는 1975년 캐나다에서 첫 번째 암달 470V/6 (일련 번호 P5)을 설치했다. 1978년에는 NUMAC (뉴캐슬어폰타인 대학교와 더럼 대학교)이 주요 MTS 활동을 IBM S/370 시리즈 (IBM S/370-168)로 옮겼다.
미시간 터미널 시스템 하드웨어
MTS는 IBM S/360-67에서 최대 4개의 프로세서를 지원하도록 설계되었지만, IBM은 모델 67의 단일 (단순 및 반이중) 및 이중 (이중) 프로세서 구성만 생산했다. 1984년 RPI는 MTS를 IBM S/370-XA (확장 주소 지정) 하드웨어 시리즈에서 최대 32개의 프로세서를 지원하도록 업데이트했지만, 실제로 사용된 가장 큰 구성은 6개의 프로세서일 가능성이 높다. MTS는 벡터 기능을 지원하며, IBM 3090 및 ES/9000 시스템에서 옵션으로 사용할 수 있다.
미시간 터미널 시스템 하드웨어
1967년 초, UM에서 가상 메모리 지원 없이 단일 프로세서 IBM S/360-67에서 실행되는 MTS는 일반적으로 5개의 동시 터미널 세션과 하나의 배치 작업을 지원했다. 1967년 11월 가상 메모리 지원이 추가된 후, 동일한 IBM S/360-67에서 실행되는 MTS는 동시에 50개의 터미널 세션과 최대 5개의 배치 작업을 지원했다. 1968년 8월, 이중 프로세서 IBM S/360-67이 단일 프로세서 시스템을 대체하여 약 70개의 터미널과 최대 8개의 배치 작업을 지원했다. 1991년 말까지 UM의 MTS는 IBM ES/9000-720에서 실행되어 600개 이상의 동시 터미널 세션과 3~8개의 배치 작업을 지원했다.
MTS는 IPL-ed를 VM/370에서 실행할 수 있으며, 일부 MTS 사이트에서는 그렇게 했지만, 대부분은 가상 머신을 사용하지 않고 네이티브 하드웨어에서 MTS를 실행했다.
미시간 터미널 시스템 기능
MTS의 주목할 만한 기능 중 일부는 다음과 같다.
다음은 MTS를 위해 개발된 주목할 만한 프로그램 중 일부이다.
다음은 다른 시스템에서 MTS로 포팅된 주목할 만한 프로그램 중 일부이다.
MTS는 MTS를 위해 개발되었거나 다른 시스템에서 포팅된 다양한 프로그래밍 언어를 지원한다.
미시간 터미널 시스템 시스템 아키텍처
감독자인 UMMPS는 하드웨어를 완전히 제어하고 작업 프로그램 모음을 관리한다. 작업 프로그램 중 하나는 대부분의 사용자가 상호 작용하는 작업 프로그램인 MTS이다. MTS는 명령어 언어 서브시스템 (CLS) 모음으로 작동한다. CLS 중 하나는 사용자 프로그램 실행을 허용한다. MTS는 CLS, 사용자 프로그램 및 MTS 자체에서 사용할 수 있는 시스템 서브루틴 모음을 제공한다. 무엇보다도 이러한 시스템 서브루틴은 장치 종속 입출력을 수행하는 구성 요소인 장치 지원 루틴 (DSR)에 대한 표준 접근을 제공한다.
미시간 터미널 시스템 매뉴얼 및 문서
다음 목록은 미시간 대학교 중심적이다. 대부분의 다른 MTS 사이트에서는 이 자료 중 일부를 사용했지만, 해당 사이트의 요구에 맞춰 자체 매뉴얼, 메모, 보고서 및 뉴스레터도 제작했다.
MTS: 미시간 터미널 시스템 매뉴얼 시리즈는 1967년부터 1991년까지 1권부터 23권으로 발행되었으며, 불규칙하게 업데이트 및 재발행되었다. 볼륨의 초기 출시는 항상 숫자 순서로 발생하지 않았으며, 업데이트되거나 재출판될 때 볼륨 이름이 변경되기도 했다. 일반적으로 숫자가 높을수록 볼륨이 더 전문화되었다.
MTS 볼륨 I 및 II의 초기 버전은 이후 MTS 볼륨과는 다른 구성과 내용을 가졌으며, 일부 내부 및 최종 사용자 문서가 포함되었다. 1967년 12월의 2판은 다음을 다루었다.