장치 제어 블록

Unit Control Block

OS/360 및 후속 제품 라인의 IBM 메인프레임 운영 체제에서 유닛 제어 블록(UCB)은 운영 체제에 대한 단일 입력/출력 주변 장치(유닛) 또는 노출(일명)을 설명하는 메모리 구조 또는 제어 블록입니다.또한 UCB 내의 특정 데이터는 물리 디바이스 제어를 강화하기 위해 일반 IOS 처리 외에 특정 닫힌 서브루틴을 사용하도록 Input/Output Supervisor(IOS; 입력/출력 슈퍼바이저)에 지시합니다.

일부 다른 운영체제는 유사한 구조를 가지고 있습니다.

개요

현재 MVS 시스템의 초기[a] 프로그램 로드(IPL) 중에 Nucleus Initialization Program(NIP)은 I/O Definition File(IODF)에서 필요한 정보를 읽고 이를 사용하여 UCB를 구축합니다.UCB는 시스템 소유 메모리의 Extended System Queue Area(ESQA; 확장 시스템큐 영역)에 저장됩니다.IPL이 완료되면 UCB는 입출력 지원에 의해 소유됩니다.UCB에 저장되는 정보에는 디바이스 유형(디스크, 테이프, 프린터, 터미널 등), 디바이스 주소(1002 등), 서브채널 식별자와 디바이스 번호, 디바이스 경로를 정의하는 채널 경로 ID(CHPID), 일부 디바이스의 볼륨 시리얼 번호(VOLSER) 및 OS를 포함한 대량의 기타 정보가 포함됩니다.애니지먼트 데이터

UCB의 내용은 MVS의 진화에 따라 변화하고 있지만, 개념은 변하지 않았습니다.외부 디바이스의 운영체제를 나타냅니다.모든 UCB 내부에는 UCB가 있습니다.현재[1] IOS 큐 요소[2](IOQ), UCBIOQF 및 UCB로의 IOQ 포인터채널 프로그램(Chain of Channel Command Words(CCW;[4] 채널명령어 체인)을 시작하기 위해 Start Subchannel(SSCH; 시작 서브채널 식별어) 명령어로 사용되는 IOQ[b] 큐 및 서브채널 번호에 대한 IOQL[3] 포인터.

UCB는 디바이스에 관한 정보와 상태를 유지하는 앵커로 진화했습니다.UCB에는 현재 외부 인터페이스에 사용되는 영역이 5개 있습니다.디바이스 클래스 확장, UCB 공통 확장, UCB 프리픽스스탭, UCB 공통 세그먼트 및 UCB 디바이스 의존 세그먼트.[5]기타 구역은 내부 사용만 가능합니다.이 정보는 단말기에 대한 정보를 읽기 위해 사용할 수 있습니다.

이 OS의 초기 구현에서는 UCB(기초와 확장)가 SYSGEN 중에 조립되어 I/O 디바이스 룩업테이블이 16비트주소로 구성되었기 때문에 시스템영역의 첫 번째 64KB 내에 배치되어 있었습니다.이후 확장 기능을 통해 확장 기능을 64킬로바이트(65,536바이트) 행보다 높게 할 수 있게 되어 64킬로바이트 행보다 낮은 추가 UCB 기초 공간을 절약할 수 있게 되어 UCB 룩업테이블 아키텍처(CUU를 UCB 기초 주소로 변환)도 유지됩니다.

병렬 I/O 작업 처리

UCB는 1960년대에 OS/360과 함께 도입되었습니다.UCB에 의해 주소 지정되는 디바이스는 일반적으로 내부 캐시가 없는 이동식 헤드 하드 디스크 드라이브 또는 테이프 드라이브입니다.이 장치가 없으면 메인프레임의 채널 프로세서가 장치의 성능을 크게 앞질렀습니다.따라서 디바이스가 물리적으로 처리할 수 없기 때문에 동시에 복수의 입출력 조작을 실행할 필요가 없었습니다.1968년 IBM은 2305-1 및 2305-2 고정 헤드 디스크를 출시했습니다. 이 디스크는 디스크당 회전 위치 감지(RPS)와 8개의 노출(별칭 주소)을 지원했습니다. OS/360은 여러 개의 동시 채널 프로그램을 허용하기 위해 노출당 UCB를 제공했습니다.마찬가지로 OS/360에서 파생된 최신 시스템에서는 3850 Mass Storage System(MSS; 대용량 스토리지 시스템)에서 할당된 각 가상 볼륨과 3880-11, 3880-13 및 그 후속 시스템에서 노출될 때마다 추가 UCB가 필요했습니다.

병렬 액세스 볼륨(PAV)

한 번에 실행할 수 있는 채널명령어 또는 I/O는 1세트뿐이기 때문입니다.이것은 CPU가 느리고 I/O가 CPU가 처리할 수 있는 속도만큼만 처리될 수 있었던 1960년대에는 괜찮았습니다.시스템이 성숙하고 CPU 속도가 I/O 입력 용량을 크게 초과함에 따라 UCB 수준에서 시리얼화된 디바이스에 대한 접근은 심각한 병목현상이 되었습니다.

PAV(Parallel Access Volume)를 사용하면 UCB가 자신을 클로닝하여 여러 I/O를 동시에 실행할 수 있습니다.DASD 하드웨어에 의한 적절한 지원을 통해 PAV는 한 번에 여러 I/O를 단일 디바이스에 지원합니다.하위 호환성을 유지하기 위해 동작은 UCB 레벨 이하로 시리얼화됩니다.단, PAV에서는 같은 논리 디바이스에 대해 추가 UCB를 정의할 수 있습니다.각 디바이스는 추가 에일리어스 주소를 사용합니다.예를 들어 기본 주소 1000에 있는 DASD 디바이스의 에일리어스 주소는 1001, 1002 및 1003입니다.이러한 에일리어스 주소에는 각각 독자적인 UCB가 있습니다.1개의 디바이스에 4개의 UCB가 존재하기 때문에 4개의 동시 I/O가 가능합니다.같은 범위로 쓰기는 파일의 한 인접 영역에 할당된 디스크의 영역은 여전히 직렬화되지만 다른 읽기 및 쓰기는 동시에 수행됩니다.디스크 컨트롤러의 PAV의 첫 번째 버전은 UCB에 PAV를 할당합니다.PAV 처리의 두 번째 버전에서는 Workload Manager(WLM)가 PAV를 새로운 UCB에 수시로 재할당합니다.IBM DS8000 시리즈를 사용하는 세 번째 버전의 PAV 처리에서는 각 I/O가 필요한 UCB와 함께 사용 가능한 PAV를 사용합니다.

PAV의 순효과는 디스크 응답 시간의 IOSQ 시간 컴포넌트를 0으로 줄이는 것입니다.2007년 현재 PAV에 관한 제한은 에일리어스 주소의 수, 베이스 주소당 255개, 논리 컨트롤 유닛당 디바이스의 총수, 256개의 카운팅 베이스와 에일리어스뿐입니다.

정적 PAV와 동적 PAV

PAV 에일리어스 주소에는 스태틱과 다이내믹의 2종류가 있습니다.정적 에일리어스 주소는 특정 단일 기본 주소를 참조하기 위해 DASD 하드웨어와 z/OS 모두에서 정의됩니다.Dynamic은 특정 기본 주소에 할당된 에일리어스 주소의 수가 필요에 따라 변동하는 것을 의미합니다.이러한 동적 별칭의 관리는 목표 모드에서 실행되는 WLM에 맡겨집니다(지원되는 z/OS 레벨의 경우 항상 해당).PAV 를 실장하는 대부분의 시스템에서는, 통상, 양쪽의 PAV 타입이 혼재하고 있습니다.베이스 UCB마다 1개 또는2개의 스태틱에일리어스가 정의되어 WLM이 적합하다고 판단되는 대로 관리하기 위해 다수의 다이내믹에일리어스가 정의되어 있습니다.

WLM은 시스템 내의 I/O액티비티를 감시할 때 특정 PAV 대응 디바이스의 경합이 심해 중요도가 높은 워크로드가 지연되고 있는지 여부를 판단합니다.구체적으로는 디스크 디바이스의 경우 기본 UCB와 에일리어스 UCB가 부족하여 IOS 큐의 시간을 없앨 수 없습니다.경합이 심한 경우, WLM의 예측에 의해 워크로드가 보다 쉽게 목표를 달성할 수 있는 경우, 다른 기본 주소에서 이 디바이스로 에일리어스를 이동하려고 합니다.

또 다른 문제는 WLM 서비스 클래스에서 지정된 특정 퍼포먼스목표가 충족되지 않는 것입니다.다음으로 WLM은 중요하지 않은 태스크(서비스 클래스)의 작업을 처리하고 있는 에일리어스 UCB를 검색하고 필요에 따라 WLM은 보다 중요한 작업과 관련된 기본 주소에 에일리어스를 다시 연관짓습니다.

하이퍼 PAV

디스크 디바이스 간에 에일리어스를 이동하는 WLM의 동작은 효과가 나타나기까지 몇 초 걸립니다.많은 상황에서 이것은 충분히 빠르지 않습니다.HyperPAV는 단일 I/O 작업 기간 동안 풀에서 UCB를 취득한 후 풀로 되돌리기 때문에 응답성이 크게 향상됩니다.따라서 동일한 워크로드를 처리하기 위해 필요한 UCB 수는 다이내믹 PAV에 비해 적습니다.WLM이 [6]반응할 때까지의 지연은 없습니다.

기타 운영 체제

Digital의 VMS 운영체제는 동일한 이름의 구조인 UCB를 유사한 목적으로 사용합니다.각 I/O 디바이스용으로 UCB가 생성됩니다.UCB의 데이터에는 디바이스의 유닛 번호(디바이스명의 일부)와 보류 중인 I/O 요구가 큐잉되는 리스트헤드가 포함됩니다.UCB 에는,[7] 디바이스 마다 인스턴스화된 드라이버 정의 데이터를 드라이버가 유지할 수 있는 디바이스 드라이버 정의 확장이 있는 경우가 있습니다.

「 」를 참조해 주세요.

메모들

  1. ^ 일부 오래된 시스템에서는 UCB가 핵의 일부였으며 SYSGEN 프로세스 중에 조립되었습니다.
  2. ^ OS/360, OS/VS1 및 SVS에서는 Request Queue Elements(RQE; 요구 큐 요소)의 큐를 가리키는 필드가 있었습니다.

레퍼런스

  1. ^ "UCB Mapping" (PDF). z/OS 2.5 MVS Data Areas MVS Data Areas Volume 4 (RRP - XTL) (PDF). IBM. September 30, 2021. p. 994. GA32-0938-500. Retrieved May 9, 2022.
  2. ^ "IOQ Information" (PDF). z/OS 2.5 MVS Data Areas Volume 2 (IAX - ISG) (PDF). IBM. September 30, 2021. p. 1033–1039. GA32-0936-50. Retrieved May 8, 2022.
  3. ^ "IOSDUPFX mapping" (PDF). z/OS 2.5 MVS Data Areas Volume 2 (IAX - ISG) (PDF). IBM. September 30, 2021. p. 1181. GA32-0936-50. Retrieved May 9, 2022.
  4. ^ z/Architecture Principles of Operation. PubLibZ.Boulder.IBM.com. IBM. May 4, 2004. p. 14.3.9. Retrieved January 3, 2017.
  5. ^ "z/OS Release 11 MVS Data Areas" (PDF). PubLibZ.Boulder.IBM.com. IBM. 2009. Retrieved January 4, 2017.
  6. ^ Rogers, Paul; Salla, Alvaro; Sousa, Livio (September 2008). "7.22 HyperPAV feature for DS8000 series" (PDF). ABCs of z/OS System Programming (PDF). Redbooks. Vol. 10 (Fourth ed.). IBM. p. 494. SG24-6990-03. Retrieved May 5, 2022.
  7. ^ Goldenberg, Ruth; Saravanan, Sara (1994). OpenVMS AXP Internals and Data Structures. Digital Press. p. 753. ISBN 978-1555581206. The executive creates a unit control block (UCB) for each I/O device attached to the system.