StorageTek Enterprise Library Software

HSC 및 VTCS 관리

릴리스 7.3

E63452-02

2016년 9월

StorageTek Enterprise Library Software HSC 및 VTCS 관리, 릴리스 7.3

E63452-02

Copyright © 2015, 2016, Oracle and/or its affiliates. All rights reserved.

본 소프트웨어와 관련 문서는 사용 제한 및 기밀 유지 규정을 포함하는 라이센스 합의서에 의거해 제공되며, 지적 재산법에 의해 보호됩니다. 라이센스 합의서 상에 명시적으로 허용되어 있는 경우나 법규에 의해 허용된 경우를 제외하고, 어떠한 부분도 복사, 재생, 번역, 방송, 수정, 라이센스, 전송, 배포, 진열, 실행, 발행, 또는 전시될 수 없습니다. 본 소프트웨어를 리버스 엔지니어링, 디스어셈블리 또는 디컴파일하는 것은 상호 운용에 대한 법규에 의해 명시된 경우를 제외하고는 금지되어 있습니다.

이 안의 내용은 사전 공지 없이 변경될 수 있으며 오류가 존재하지 않음을 보증하지 않습니다. 만일 오류를 발견하면 서면으로 통지해 주기 바랍니다.

만일 본 소프트웨어나 관련 문서를 미국 정부나 또는 미국 정부를 대신하여 라이센스한 개인이나 법인에게 배송하는 경우, 다음 공지 사항이 적용됩니다.

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

본 소프트웨어 혹은 하드웨어는 다양한 정보 관리 애플리케이션의 일반적인 사용을 목적으로 개발되었습니다. 본 소프트웨어 혹은 하드웨어는 개인적인 상해를 초래할 수 있는 애플리케이션을 포함한 본질적으로 위험한 애플리케이션에서 사용할 목적으로 개발되거나 그 용도로 사용될 수 없습니다. 만일 본 소프트웨어 혹은 하드웨어를 위험한 애플리케이션에서 사용할 경우, 라이센스 사용자는 해당 애플리케이션의 안전한 사용을 위해 모든 적절한 비상-안전, 백업, 대비 및 기타 조치를 반드시 취해야 합니다. Oracle Corporation과 그 자회사는 본 소프트웨어 혹은 하드웨어를 위험한 애플리케이션에서의 사용으로 인해 발생하는 어떠한 손해에 대해서도 책임지지 않습니다.

Oracle과 Java는 Oracle Corporation 및/또는 그 자회사의 등록 상표입니다. 기타의 명칭들은 각 해당 명칭을 소유한 회사의 상표일 수 있습니다.

Intel 및 Intel Xeon은 Intel Corporation의 상표 내지는 등록 상표입니다. SPARC 상표 일체는 라이센스에 의거하여 사용되며 SPARC International, Inc.의 상표 내지는 등록 상표입니다. AMD, Opteron, AMD 로고, 및 AMD Opteron 로고는 Advanced Micro Devices의 상표 내지는 등록 상표입니다. UNIX는 The Open Group의 등록상표입니다.

본 소프트웨어 혹은 하드웨어와 관련문서(설명서)는 제3자로부터 제공되는 컨텐츠, 제품 및 서비스에 접속할 수 있거나 정보를 제공합니다. 사용자와 오라클 간의 합의서에 별도로 규정되어 있지 않는 한 Oracle Corporation과 그 자회사는 제3자의 컨텐츠, 제품 및 서비스와 관련하여 어떠한 책임도 지지 않으며 명시적으로 모든 보증에 대해서도 책임을 지지 않습니다. Oracle Corporation과 그 자회사는 제3자의 컨텐츠, 제품 및 서비스에 접속하거나 사용으로 인해 초래되는 어떠한 손실, 비용 또는 손해에 대해 어떠한 책임도 지지 않습니다. 단, 사용자와 오라클 간의 합의서에 규정되어 있는 경우는 예외입니다.

목차

그림 목록

테이블 목록

제목 및 저작권 정보

머리말

- 대상

- 필수 조건

- 설명서 접근성

- 이 설명서에 대한 정보

새로운 기능

1 툴킷

- HSC 툴킷

- VTCS 툴킷

2 CDS 관리

- CDS 백업

- 백업 빈도

- PITCOPY를 사용하여 CDS 백업

- BACKup 유틸리티를 사용하여 CDS 백업

- CDS 로깅 관리

- 주기적으로 로그 파일 오프로드

- 로그 파일 확장 또는 재할당

- 수동으로 다른 CDS 복사본으로 전환

- CDS 확장

- CDS 교체

- CDS 이름 바꾸기

- CDS Disable 및 Enable 명령을 사용하여 CDS 이름 바꾸기

- CDS 재배치

- 카탈로그화가 취소된 CDS 복사본 재배치

- CDS 스왑

- CDS 복원

- 백업 복사본에서 CDS 복원

3 TapePlex 관리

- 라이브러리 하드웨어 관리

- ACS 관리

- SL8500 중복 전자 부품 관리

- 이중 라이브러리 컨트롤러 구성

- SL8500 중복 전자 부품 환경

- SL8500 LC 작동

- ACS 상태 표시

- 중복 LC 작동 개요

- LC 전환 개요

- LC 전환 결과

- 자동 LC 전환

- 운영자가 시작한 LC 전환

- CAP 수동 복구

- Enter 함수가 활성 상태인 경우 전환 발생

- Eject 함수가 활성 상태인 경우 전환 발생

- CAP가 자동 모드로 설정된 경우 전환 발생

- CAP 관리

- 수동 RTD 정의

- 테이프 데이터 보호

- 고유 테이프 데이터 보호

- VTV 데이터 보호

- MVC 데이터 보호

- 라이브러리 볼륨 관리

- 볼륨 보고서 사용

- 문제 볼륨 및 선택된 볼륨

- 일치하지 않는 VOLPARM과 외부 레이블 상태

- 볼륨이 VOLPARM에 포함되지 않음

- 스크래치 하위 풀 관리

- VOLRPT를 사용하여 청소 카트리지 사용 추적

- 마운트 성능 최적화

- 볼륨 액세스 보안 사용

- RACF 속성

- WORM(Write Once/Read Many) 지원

- 스크래치 볼륨 관리

- 스크래치 볼륨 추가

- 니어라인 볼륨 정의

- 새 LSM 채우기

- 기존 LSM에 볼륨 추가

- 카트리지 넣기

- 볼륨 꺼내기

- 스크래치 볼륨 꺼내기

- 청소 카트리지 관리

- 청소 카트리지 선택

- 청소 카트리지 꺼내기

- 수동으로 사용된 청소 카트리지 꺼내기

- 문제 해결

- 문제 카트리지 복구

- 중복 VOLSER 및 읽을 수 없는 VOLSER 넣기

- 중복 볼륨 넣기

- 외부 레이블이 누락되거나 외부 레이블을 읽을 수 없는 카트리지 넣기

- CAP에서 복구 상태 지우기

- 할당된 CAP 해제

- 호스트 간 통신 서비스 복원

- 가능한 손실된 마운트 요청 해결

- 손실된 마운트 응답 해결(ORH)

- Overdue Response Handler

- 마운트, 마운트 해제, 이동 및 스왑에 운영자 응답 필요

- 소프트웨어 진단 사용

4 VTCS 대시보드 사용

- 가상 테이프 상태 확인(일간)

- 가상 테이프 상태를 확인하려면 다음과 같이 하십시오.

- 니어라인 테이프 상태 확인(일간)

- 니어라인 테이프 상태를 확인하려면 다음과 같이 하십시오.

- 전체적인 상태 파악(주간)

- VTV 보고서 사용

- MVC 보고서 사용

- 요약

5 VTCS 필수(비정기적) 작업 목록 처리

- 요청식 공간 재생, 마이그레이션 및 회수 수행

- 요청식 MVC 공간 재생 수행

- 요청식 VTV 마이그레이션 수행

- 요청식 VTV 회수 수행

- RTD 작업

- RTD 장치 유형 변경

- MVC 작업

- MVC 추가

- VTV 정의

- 볼륨 정의 검증 및 적용

- 풀에서 MVC 제거

- MVC 영구 제거

- 일시적으로 MVC 제거

- MVC 배출

- MVCMAINT를 사용하여 MVC 속성 변경

- MVC 또는 VMVC 확인

- 단일 VMVC에 대해 MV 수행

- MVC 풀별 MV 수행

- MVC Volser별 MV 수행

- 스토리지 클래스별 MV 수행

- VTSS 작업

- 서비스를 위해 VTSS 중지

- VTSS 제거

- VTV 작업

- 스크래치 VTV 삭제

- DELTSCR JCL 예

- VTVMAINT를 사용하여 VTV 속성 변경

- VTV 관리 클래스 변경 및 VTV와 MVC 링크 해제

- 오프라인 VTSS에서 논리적으로 VTV 마운트 해제

- CTR(Cross-TapePlex Replication)을 통해 복제된 VTV 관리

- RECONcil을 사용하여 VTV 스토리지 클래스 변경

- RECONcil 작업 실행

- FOR_LOSTMVC를 사용하여 VTV 복구

- FOR_LOSTMVC 복구 절차

6 관리 및 스토리지 클래스를 사용하는 첨단 솔루션

- VTCS CDS 레벨

- 관리 및 스토리지 클래스란?

- VTCS 관리 및 스토리지 클래스 만들기 및 사용: 기본 사항

- VSM 관리 및 스토리지 클래스를 만들고 사용하려면

- 관리 및 스토리지 클래스 유지 관리

- 관리 및 스토리지 클래스를 사용하여 수행할 수 있는 첨단 기술

- 공유 MVC에서 여러 작업 로드 그룹화

- 별도의 MVC 세트에 개별 작업 로드 분리

- 데이터 아카이브

- 아카이브 사용 시 참고 사항

- VTV 매체 및 위치 조정

- 조정 예

- RECONcil 사용 시 참고 사항

- 이름이 지정된 MVC 풀 사용 여부

- 이름이 지정된 MVC 풀 만들기 및 사용

7 VTCS 문제 파악 및 해결

- 일반적인 문제 해결

- VTV 마운트 성능 저하

- 마이그레이션 성능 저하

- 마이그레이션 실패

- 메시지 개선

- STORCLas 표시

- MVC 풀 검증 개선

- 스토리지 클래스 검증 개선

- RTD/MVC 실패

- 불량 MVC?

- 데이터 확인을 사용하여 MVC 복구

- RTV 유틸리티 사용

- RTV 유틸리티로 복구 가능한 항목

- 보안 고려 사항

- JCL 예

- MVC의 VTV 나열

- Volser를 지정하여 단일 VTV 변환

- Volser 및 블록 ID를 지정하여 단일 VTV 변환

A LCM 제어문

인덱스

그림 목록

- 3-1 이중 LC 구성

- 3-2 볼륨 보고서(일치하지 않는 VOLPARM과 외부 레이블)

- 3-3 볼륨 보고서(스크래치 하위 풀)

- 3-4 볼륨 보고서(청소 카트리지)

- 4-1 Display MVCPool의 출력 예(지정된 풀 이름 없음)

- 4-2 Display MVCPool의 출력 예 - ACS01의 문제

- 4-3 VTVRPT의 출력 예

- 4-4 VTVRPT의 출력 예(UNAVAIL 옵션)

- 4-5 MVC 요약 보고서 예

- 4-6 MVC 요약 보고서 예(추가 필드)

테이블 목록

- 1-1 HSC 운영자 명령

- 1-2 HSC PARMLIB 제어 명령문

- 1-3 HSC 유틸리티(다르게 지정되지 않은 경우 SLUADMIN)

- 1-4 진단

- 1-5 HSC 성능 도구

- 1-6 VTCS 툴킷

- 3-1 스크래치 볼륨 관리 작업 및 도구

- 3-2 HSC 소프트웨어 진단 도구

- 4-1 Display VTSS의 출력 예 - 양호한 VTSS 상태

- 4-2 Display VTSS의 출력 예 - 주요 작동 문제가 있는 VTSS

- 4-3 Display VTD의 출력 예 - 올바르게 작동

- 4-4 Display SCRATCH의 출력 예

- 4-5 VT Display RTD 명령의 출력 예 - 모두 양호

- 4-6 VT Display RTD 명령의 출력 예 - 문제가 있는 RTD

- 5-1 VTSS 상태

- 5-2 대체 VTV 복사본 및 복구 프로세스

- 6-1 지원되는 VTCS 버전에 대한 CDS 레벨

- A-1 LCM 제어문

머리말

오라클의 StorageTek ELS(Enterprise Library Software)는 다음과 같은 기본 소프트웨어로 구성된 솔루션입니다.

- StorageTek SMC(Storage Management Component)

- StorageTek HSC(Host Software Component)

- StorageTek VTCS(Virtual Tape Control Software)

- StorageTek CDRT(Concurrent Disaster Recovery Test)

ELS 패키지에는 다음 소프트웨어도 제공됩니다.

- StorageTek LCM(Library Content Manager)(이전의 ExLM) LCM에는 Offsite Vault Feature라고 알려진 이전 제품의 향상된 버전이 포함되어 있습니다.

- StorageTek MVS/CSC(MVS 환경에 대한 Client System Component)

- StorageTek LibraryStation

대상

이 설명서는 ELS 관리를 책임지고 있는 오라클 또는 고객 담당자를 대상으로 합니다.

필수 조건

이 설명서에 설명된 작업을 수행하려면 다음 사항을 이해하고 있어야 합니다.

- MVS 운영 환경

- JES2 또는 JES3

- Enterprise Library Software (ELS)

설명서 접근성

오라클의 접근성 개선 노력에 대한 자세한 내용은 http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc에서 Oracle Accessibility Program 웹 사이트를 방문하십시오.

오라클 고객지원센터 액세스

지원 서비스를 구매한 오라클 고객은 My Oracle Support를 통해 온라인 지원에 액세스할 수 있습니다. 자세한 내용은 http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info를 참조하거나, 청각 장애가 있는 경우 http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs를 방문하십시오.

이 설명서에 대한 정보

이 설명서는 HSC 및 VTCS가 작동 및 실행되도록 유지하는 업무를 담당하는 모든 사람을 대상으로 합니다. HSC/VTCS는 기본적으로 서버이며, 모든 서버와 마찬가지로 올바르게 설치 및 구성하고 효과적인 정책을 수립하며 적정 수준의 세심한 관리를 제공하면 자체적으로 운영됩니다. HSC 및 VTCS는 CDS 유지 관리와 같은 일부 공통 작업을 공유하고, 실제 볼륨 작업이나 VTV 및 MVC 작업과 같이 일부 병렬적이지만 별도인 작업을 가집니다. 트리오의 할당 멤버 관리에 대한 자세한 내용은 SMC 관리를 참조하십시오.

어떤 종류의 ”양심적인 관리”가 필요할까요? ”HSC 및 VTCS를 관리”하려면 어떻게 해야 할까요? 다음 목록에서는 이 설명서의 절 및 해당하는 관리 작업을 설명합니다.

- 툴킷에서는 HSC 및 VTCS를 관리하는 데 사용하는 도구를 표 형식으로 설명합니다. 이 절에서는 이러한 도구에 대한 특정 작업 및 기능을 설명합니다. 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

- CDS 관리에서는 CD를 안전하게 보호하는 방법과 하나 이상의 CDS 복사본을 손실한 경우 복구하는 방법을 설명합니다.

- TapePlex 관리에서는 TapePlex를 관리하는 데 필요한 정기적 작업 및 필요시 작업을 설명합니다.

- VTCS 대시보드 사용에서는 지속적으로 수행해야 하는 작업에 대해 설명합니다. VTCS 시스템의 상태 모니터링 이외에 필요시 MVC 공간 확보 일괄 처리 작업과 같이 마련해 두어야 하는 몇 가지 주요 항목이 있습니다.

- VTCS 필수(비정기적) 작업 목록 처리는 VTCS에 대해 필요할 때 수행해야 하는 항목으로 구성됩니다.
정기적인 관리와 필요시 관리 사이에는 일부 중복되는 부분이 있으며, 이러한 두 범주와 문제 해결 사이에도 일부 중복되는 부분이 있습니다. 대부분의 경우 관리 작업에 대해 주의를 기울인다면 많은 문제를 해결하지 않아도 되고, 반대의 경우도 마찬가지입니다. ”정기적” 및 ”필요시”는 두 가지 일반적인 범주이며, 조직의 필요에 따라 조정해야 합니다.

- 관리 및 스토리지 클래스를 사용하는 첨단 솔루션은 VTCS 환경에서 모든 최첨단 기술의 기본이 되는 관리 및 스토리지 클래스에 대한 내용입니다.

- VTCS 문제 파악 및 해결은 문제가 발생할 때 어떻게 해야 하는지에 대한 내용입니다.

- LCM 제어문은 HSC 및 LCM에서 수행할 수 있는 작업에 대한 편리한 상호 참조입니다.

새로운 기능

이 개정에는 다음과 같은 업데이트가 포함됩니다.

- CAP 크기 목록에 대량 CAP 크기(36셀)가 추가되었습니다.
"CAP 관리"를 참조하십시오.

- 구성에서 MVC 또는 VTV를 삭제할 때 몇 가지 조건이 추가되었습니다.
MVC 작업 및 "VTV 작업"을 참조하십시오.

- 지원되는 VTCS 버전의 CDS 레벨 표에 I 레벨을 추가했습니다. 이 CDS 레벨은 32GB VTV 지원에 필요합니다.
"VTCS CDS 레벨"을 참조하십시오.

1 툴킷

아래의 표에서는 HSC 및 VTCS를 관리하는 데 필요한 도구를 인터페이스별로 그룹화하여 설명합니다. 도구에 대한 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

주:
중요사항: HIPER 통지 등록. 항상 최신 유지 관리 상태를 유지하고 문제를 미연에 방지하도록 오라클은 HIPER 통지를 Knowledge Base 경보 문서로 게시하고 있습니다. MOS(My Oracle Support) 홈 페이지에서 키워드 "HIPER"를 검색하여 전체 HIPER 통지 목록을 검색할 수 있습니다. 또한 MOS 핫토픽 전자 메일로 자동으로 새로운 HIPER 통지 경보 문서를 수신하려면 등록해야 합니다. Knowledge Base 문서 793436.1(MOS 홈 페이지에서 번호로 검색 가능)에는 핫토픽 전자 메일 기능과 구독 방법이 설명되어 있습니다. 관심 있는 모든 Oracle StorageTek 제품을 핫토픽 전자 메일 프로파일에 추가하십시오. Add를 눌러 특정 제품을 포함시킨 다음 Add Product 상자의 Product 필드에 StorageTek을 입력할 때 나타나는 목록에서 제품을 선택하면 됩니다. 각 제품을 선택할 때 Alert 문서 유형을 선택하십시오.

HSC 툴킷

테이블 1-1 HSC 운영자 명령

명령:

기능:

참조 항목:

CDS ENABLE/DISABLE

CDS 복사본을 전환, 확장 및 이동합니다.

수동으로 다른 CDS 복사본으로 전환

COMMPATH

통신 설정을 변경합니다.

스크래치 볼륨 추가

DISPLAY ACS

ACS의 상태를 표시하며, 여기에는 ACS, LMU 및 스테이션에 대한 하드웨어 상태와 사용 가능한 스크래치 볼륨 및 사용 가능 셀이 포함됩니다.

ACS 관리

DISPLAY ALL

DISPLAY ACS의 모든 항목과 함께 LSM 및 CDS 상태를 표시합니다.

ACS 관리

DISPLAY CAP

CAP 정보를 표시합니다.

스크래치 볼륨 추가

DISPLAY EXCEPTNS

라이브러리 하드웨어 문제를 표시합니다.

라이브러리 하드웨어 관리

DISPLAY LSM

LSM 상태를 표시합니다.

카트리지 넣기

DISPLAY SCRATCH

하위 풀을 기준으로 스크래치 수 정보를 표시합니다.

스크래치 볼륨 추가

DISPLAY THRESHLD

Warn 명령으로 설정된 임계값을 표시합니다.

스크래치 볼륨 추가

DISPLAY VOLUME

물리적 볼륨 정보를 표시합니다.

문제 볼륨 및 선택된 볼륨

EJECT

최대 9999개의 카트리지를 추출합니다.

카트리지 넣기

ENTER

하나 이상의 볼륨을 입력합니다.

카트리지 넣기

MNTD AUTOCLN EJCTAUTO

MAXCLEAN 값을 초과한 청소 카트리지의 자동 드라이브 청소 및 자동 추출을 결정합니다.

청소 카트리지 관리

MODIFY

LSM 및 CAP 상태를 변경합니다.

- ACS 관리

- 스크래치 볼륨 추가

OPTION ENTDUP

중복 볼륨 입력에 대한 응답을 결정합니다.

중복 볼륨 넣기

RELEASE

CAP을 해제하고 사용 가능하도록 합니다.

할당된 CAP 해제

SMC RESYNCH

손실된 마운트를 재드라이브합니다.

스크래치 볼륨 추가

SCRATCH

특정 볼륨을 스크래치합니다.

스크래치 볼륨 추가

UNSCRATCH

특정 볼륨을 스크래치 해제합니다.

스크래치 볼륨 추가

WARN

스크래치 경고 임계값을 설정합니다.

스크래치 볼륨 추가

테이블 1-2 HSC PARMLIB 제어 명령문

제어 명령문:

기능:

참조 항목:

CDSDEF

CDS 복사본의 데이터 세트 이름을 지정합니다.

- CDS 확장

- CDS 이름 바꾸기

- CDS 재배치

테이블 1-3 HSC 유틸리티(다르게 지정되지 않은 경우 SLUADMIN)

유틸리티:

기능:

참조 항목:

BACKUP

기본 CDS를 백업합니다.

BACKup 유틸리티를 사용하여 CDS 백업

FMTLOG

로그 파일을 사전 포맷합니다.

CDS 로깅 관리

LOGUTIL

로그 파일을 사용하여 CDS 복구를 돕습니다.

백업 복사본에서 CDS 복원

OFFLOAD LOGFILE

현재 로그 파일에서 트랜잭션을 오프로드하고 새 로그 파일을 활성화합니다.

CDS 로깅 관리

RESTORE

백업 복사본에서 CDS를 복원합니다.

백업 복사본에서 CDS 복원

스크래치 변환(SLUCONDB)

TMS 스크래치 목록에서 HSC 스크래치 목록을 업데이트합니다.

스크래치 볼륨 추가

SCREDIST

ACS의 지정된 LSM 사이에 스크래치 볼륨 수 균형을 맞춥니다. 하위 풀별로 균형을 맞추기 위한 옵션을 제공합니다.

스크래치 볼륨 추가

SET LOGFILE

로그 파일 데이터 세트를 지정합니다.

CDS 로깅 관리

SET VOLPARM

모든 유형의 볼륨 및 풀을 정의합니다.

- 스크래치 볼륨 추가

- 니어라인 볼륨 정의

- 스크래치 볼륨 추가

PITCOPY

기본 CDS를 백업합니다(특정 시점).

PITCOPY를 사용하여 CDS 백업

UNSELECT

볼륨 선택 상태를 재설정합니다.

문제 볼륨 및 선택된 볼륨

VOLRPT

물리적 볼륨 보고서를 제공합니다.

볼륨 보고서 사용

테이블 1-4 진단

진단 도구:

기능:

참조 항목/문서:

Generalized Trace Facility

GTF(Generalized Trace Facility)는 최근 과거의 하위 레벨 내역을 제공합니다.

스크래치 볼륨 추가

Supervisor Call and Abnormal End Dumps(ABEND)

소프트웨어 실패 진단에 적절한 경우 SVC 및 ABEND 덤프가 수행됩니다.

스크래치 볼륨 추가

오류 기록 데이터 세트 레코드

소프트웨어 실패가 해당 오류 기록 데이터 세트에 기록됩니다. MVS 루틴을 통해 4480 카트리지 부속 시스템 및 3278 터미널 부속 시스템 ERDS(오류 기록 데이터 세트) 레코드가 작성됩니다.

스크래치 볼륨 추가

HSC LIST 명령

LIst 명령은 HSC 데이터 구조를 표시하고 HSC에 대한 진단 지원을 제공하는 데 사용됩니다. 이 명령은 오라클 고객 지원 센터 담당자의 지시에 따라 사용하십시오.

ELS Command, Control Statement, and Utility Reference

테이블 1-5 HSC 성능 도구

성능 도구:

기능:

참조 항목:

작업 보고서

다양한 라이브러리 작업에 대한 성능 값을 식별하는 상세 보고서를 생성합니다.

마운트 성능 최적화

스크래치 재배포 유틸리티

특정 ACS 내의 LSM에 걸쳐 스크래치 볼륨을 재배포합니다.

- 마운트 성능 최적화

- 스크래치 볼륨 추가

WARN 명령

HSC가 운영자에게 ACS의 부족한 스크래치 카트리지 수량을 통지할 때 제어하는 임계값을 설정합니다.

스크래치 볼륨 추가

CAPPREF 명령

CAP에 대한 환경 설정 값을 지정합니다.

스크래치 볼륨 추가

SMF 레코드

분석을 위해 ACS 작업 및 성능 데이터를 기록합니다.

마운트 성능 최적화

VTCS 툴킷

테이블 1-6 VTCS 툴킷

명령:

기능:

참조 항목/문서:

AUDIT

HSC CDS의 MVC 및 VTV 정보를 업데이트합니다.

- RTD 장치 유형 변경

- RTD 장치 유형 변경

- 오프라인 VTSS에서 논리적으로 VTV 마운트 해제

DELETSCR

VTSS에서 스크래치 VTV를 삭제하고 MVC에서 마이그레이션된 모든 VTV의 링크를 해제합니다.

요청식 MVC 공간 재생 수행

DISPLAY

기본 도구 중 하나로서 VTCS의 모든 상태를 표시합니다.

- 가상 테이프 상태 확인(일간)

- 가상 테이프 상태 확인(일간)

- 요청식 MVC 공간 재생 수행

- 요청식 MVC 공간 재생 수행

- VTV 마운트 성능 저하

- VTV 마운트 성능 저하

- RTD/MVC 실패

- VTV 마운트 성능 저하

MIGRATE

필요시 VTV를 MVC로 마이그레이션합니다.

요청식 MVC 공간 재생 수행

MVCDRAIN

MVC에서 모든 현재 및 스크래치된 VTV를 회수하고, 선택적으로 MVC를 ”가상으로” 추출합니다(라이브러리에서 물리적으로 추출하지 않고 VSM 사용이 불가능하도록 만듦).

요청식 MVC 공간 재생 수행

MVCMAINT

MVC 속성을 설정합니다.

RTD 장치 유형 변경

MVCPLRPT

MVCPOOLS 및 스토리지 클래스를 관리합니다.

ELS Command, Control Statement, and Utility Reference

MVCRPT

VSM 시스템의 MVC 상태를 보고하고 Primary Wellness Meter #2입니다.

- 가상 테이프 상태 확인(일간)

- 요청식 MVC 공간 재생 수행

- PITCOPY를 사용하여 CDS 백업

- 일반적인 문제 해결

RECALL

필요시 VTV 회수를 수행합니다.

요청식 MVC 공간 재생 수행

RECLAIM

필요시 MVC 공간 확보를 수행합니다.

요청식 MVC 공간 재생 수행

RECONCIL

VTV 매체 및 위치를 조정합니다(한 스토리지 클래스에서 다른 스토리지 클래스로 VTV 이동).

VTSS 작업

RTV 유틸리티

MVC에 포함된 VTV를 니어라인 볼륨(실제 테이프 볼륨)의 데이터 세트로 변환합니다.

일반적인 문제 해결

SET MIGOPT

다음 마이그레이션 매개변수를 변경합니다.

- 최대 및 최소 동시 자동 마이그레이션, 즉시 마이그레이션 및 migrate-to-threshold 작업.

- 상한 및 하한 AMT.

- 가상 테이프 상태 확인(일간)

- 요청식 MVC 공간 재생 수행

VARY RTD

RTD 상태를 변경합니다.

- 가상 테이프 상태 확인(일간)

- VTSS 작업

VARY VTSS

모든 호스트에서 VTSS 상태를 변경합니다.

VTSS 작업

2 CDS 관리

CDS에는 중요한 데이터가 포함되어 있으므로 CDS 관리 작업은 매우 중요합니다. 다음 절에서는 CDS를 보호하는 방법과 하나 이상의 CDS 복사본을 손실한 경우 복구하는 방법에 대해 설명합니다. CDS 계획 및 생성에 대한 자세한 내용은 Configuring HSC and VTCS를 참조하십시오.

CDS 백업

모든 CDS 복사본을 사용할 수 없는 경우(기본, 보조 및 대기 복사본을 손실한 경우) 백업에서 CDS를 복원해야 합니다. 비ELS 기능(예: 디스크 미러링), 타사 백업 소프트웨어(예: IBM DFSMSdss 및 Innovation FDR) 또는 타사 특정 시점 복사 소프트웨어(예: IBM FlashCopy)를 사용하여 CDS를 백업할 수 있습니다. 하지만 이러한 방법으로는 CDS 일관성과 무결성이 보장되지 않으므로 Oracle은 이러한 방법을 권장하지 않습니다.

대신 다음과 같은 CDS 백업 방법을 권장합니다.

- 스냅샷 백업 생성 기능을 사용할 수 있는 경우 CDS 일관성이 유지된 후 해당 유틸리티를 호출하는 HSC PITCOPY 유틸리티를 사용하십시오. 특히 큰 CDS의 경우 표준 BACKUP 유틸리티에 비해 백업 시간이 현저히 단축됩니다.

- 스냅샷 백업 생성 기능을 사용할 수 없는 경우 HSC BACKUP 유틸리티를 사용하십시오.

백업 빈도

Oracle은 최소한 매일 CDS를 백업할 것을 권장합니다. CDS 로깅을 사용하는 경우 복구 중 복구용 백업 파일에 해당하는 로그 오프로드 파일을 선택할 수 있도록 CDS를 백업한 후 바로 로그 파일 오프로드 작업도 실행해야 합니다.

또한 다음 등의 구성 변경 및 기타 중요한 이벤트에 앞서 CDS를 백업해야 합니다.

- SLUADMIN SET 유틸리티 실행

- VTCS CONFIG 유틸리티 실행

- CDS 이동

- CDS 확장

- CDS 병합

PITCOPY 함수의 경우 HSC가 활성 상태가 아니어도 됩니다. 단, HSC가 활성 상태가 아닌 경우 CDS 데이터 세트에 대한 DD 문을 제공해야 합니다.

PITCOPY를 사용하여 CDS 백업

PITCOPY 유틸리티는 다음과 같은 스냅샷 메소드를 지원합니다.

- StorageTek SVAA 스냅샷(SIBBATCH)

- DFSMSdss 스냅샷/DFSMSdss FlashCopy(ADRDSSU)

- FDR 적용 스냅샷(FDRSNAP)

필요한 JCL DD 문 및 제어 카드에 대해서는 사용자 환경의 유틸리티 설명서를 참조하십시오.

SLUADMIN 유틸리티 및 스냅샷 유틸리티에 필요한 DD 문 이외에 PITCOPY 함수에는 다음 DD 문이 필요합니다.

- SLSPARMP: 환경에서 SLSCNTL로 정의된 데이터 세트를 백업할 스냅샷 제어문을 포함하는 데이터 세트입니다.

- SLSPARMS: 환경에서 SLSCNTL2(있을 경우)로 정의된 데이터 세트를 백업할 스냅샷 제어문을 포함하는 데이터 세트입니다.

- SLSPARMB: 환경에서 SLSSTBY(있을 경우)로 정의된 데이터 세트를 백업할 스냅샷 제어문을 포함하는 데이터 세트입니다.

- SYSIN: PITCOPY 유틸리티가 읽고 쓸 수 있는 데이터 세트로 정의되어야 합니다.

PITCOPY 함수의 경우 HSC가 활성 상태가 아니어도 됩니다. 단, HSC가 활성 상태가 아닌 경우 CDS 데이터 세트에 대한 DD 문을 제공해야 합니다.

다음 예에서는 모든 PIT 복사 메소드에 필요한 일반 JCL을 보여줍니다.

//PITCOPY EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//* If HSC IS NOT OR MAY NOT BE ACTIVE, INCLUDE THE
//* FOLLOWING:
//SLSCNTL DD DSN=primary.cds.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.cds.name,DISP=SHR
//SLSSTBY   DD DSN=standby.cds.name,DISP=SHR
//SLSPARMP DD DSN=hlq.PARMLIB(BKPCNTL),DISP=SHR
//SLSPARMS DD DSN=hlq.PARMLIB(BKPCNTL2),DISP=SHR
//SLSPARMB DD DSN=hlq.PARMLIB(BKPSTBY),DISP=SHR
//SYSIN          DD UNIT=SYSDA,SPACE=(TRK,1)
//* THE FOLLOWING IS USED BY THE SNAPSHOT UTILITY:
//SYSPRINT  DD  SYSOUT=*
//SLSPRINT   DD SYSOUT=*
//SLSIN         DD *
PITCOPY METHOD=(SIBBATCH|ADRDSSU|FDRSNAP)

추가 JCL 요구 사항은 사용 중인 스냅샷 유틸리티에 대한 사용 설명서를 참조하십시오.

- SLSPARMP, SLSPARMS 및 SLSPARMB의 제어 카드는 스냅샷 기능 호출에 필요한 제어 카드입니다. 필요한 제어 카드의 형식은 사용 중인 스냅샷 유틸리티에 대한 사용 설명서를 참조하십시오. PITCOPY 유틸리티를 사용하면 일련화가 수행되므로 데이터 세트에서 대기열에 넣지 않도록 요청하는 제어 카드 옵션을 사용해야 합니다.

BACKup 유틸리티를 사용하여 CDS 백업

BACKup 유틸리티 실행:

1. SLSBKUP 데이터 세트를 할당합니다.
CDS보다 약간 커야 합니다. 크기는 발견된 불일치 수에 따라 다릅니다. 단, 권장 크기는 현재 CDS보다 5% 큰 크기입니다.

백업 데이터 세트의 형식이 RECFM=F, BLKSIZE=4096으로 지정됩니다. 논리 레코드 길이는 LRECL=0일 수 있습니다. 이 경우 LRECL=0은 블록 크기를 기본값으로 설정함을 나타냅니다.

2. BACKup 유틸리티를 실행합니다.
데이터를 SLSBKUP 데이터 세트에 복사할 수 있도록 충분히 오랫동안 CDS가 예약 상태로 지정됩니다. 백업 처리 중에는 다른 함수가 CDS 데이터 세트에 액세스할 수 없습니다.

- HSC가 활성 상태가 아닌 경우 JCL에서 SLSCNTL, SLSCNTL2 및 SLSSTBY DD 문을 지정하여 백업에 사용할 기본, 보조 및 대기 CDS를 식별해야 합니다.

- HSC가 활성 상태이며 JCL에서 SLSCNTL, SLSCNTL2 및 SLSSTBY DD 문을 지정하여 백업에 사용할 기본, 보조 및 대기 CDS를 식별하면, 유틸리티가 실행 중인 호스트에서 HSC가 활성 상태인 경우에도 DD 문이 사용됩니다. HSC가 활성 상태이며 해당 DD 문이 생략된 경우 유틸리티가 실행 중인 호스트에서 활성 HSC가 사용하는 데이터 세트가 사용됩니다.
기본, 보조 및 대기 CDS 백업용 JCL 예:

//JOBBKUP   job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSBKUP   DD DSN=backup.dataset.name(+1),DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=
//SLSCNTL   DD DSN=primary.dataset.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR
//SLSSTBY DD DSN=standby.dataset.name,DISP=SHR
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
BACKUP

CDS 로깅 관리

HSC 트랜잭션 로깅 서비스는 1개(또는 선택적으로 2개)의 로그 파일에 정보를 기록하는 내부 HSC 서비스입니다. 모든 CDS 복사본을 사용할 수 없는 경우(기본, 보조 및 대기 복사본을 손실한 경우) 백업에서의 복구 작업이 오래 걸릴 수 있습니다. 백업에서 복구할 때 CDS 로깅을 사용하면 CDS와 VSM 부속 시스템의 데이터 컨텐츠를 다시 동기화할 수 있습니다. 처음으로 구성에서 로깅을 설정하는 경우 Configuring HSC and VTCS를 참조하십시오. 다음 절에서는 CDS 로깅 관리 방법에 대해 설명합니다.

주:
로그 파일을 사용하여 복구할 때는 최신 버전의 데이터에 대한 액세스를 복원하기 위해 로그 데이터가 분석되고 필요한 MVC 감사문이 구성됩니다. 이 단계에서는 CDS가 실패 전 상태 그대로 복구되지 않습니다! 예를 들어, VTV가 여러 MVC에 존재할 수 있습니다. 감사 작업에서는 해당 VTV의 모든 복사본에 대한 액세스를 복구하지만 복사본이 CDS 손실 전과 동일한 MVC에 존재하지 않을 수도 있습니다. CDS 로깅은 CDS를 조금씩 복구하기 위한 것이 아니라 데이터에 대한 액세스를 복구하기 위한 것입니다!

주기적으로 로그 파일 오프로드

로그 파일이 가득 쌓여 로깅이 중지되지 않도록 주기적으로 로그 파일을 오프로드해야 합니다. 최상의 오프로드 방법은 다음과 같습니다.

- 주기적으로 로그 파일을 오프로드하도록 PROC를 설정합니다. 정상 작동 또는 최고 작동 상태에서 로그 파일을 채우는 데 걸리는 시간을 확인하기 위해 잠깐 동안 시험해 본 후 해당 간격으로 로그 오프로드를 실행합니다.

- 로그 파일 데이터 세트가 70% 채워지기 시작했다고 표시하는 SLS1781E 메시지를 가로채기 위해 자동 작동 패키지를 설정하는 것도 좋습니다.

- 복구 중 복구용 백업 파일에 해당하는 로그 오프로드 파일을 선택할 수 있도록 주기적 CDS 백업을 실행할 때 로그 파일 오프로드가 실행되도록 예약해야 합니다.

- CDS가 손실된 경우(세 가지 복사본이 모두 손실된 경우) 또는 특정 원인으로 CDS를 신뢰할 수 없는 경우 로그 파일 오프로드를 시도하지 마십시오. 대신 "CDS 복원"을 참조하십시오.

로그 파일 확장 또는 재할당

로그 파일을 확장해야 하거나 특정 원인으로 재할당해야 하는 경우 다음 작업을 수행하십시오.

1. 새 로그 파일을 만들고 형식을 지정합니다.
할당되는 로그 파일의 크기는 시스템에서 생성하는 트랜잭션 수와 오프로드 수행 빈도에 따라 다릅니다. Oracle은 몇 가지 테스트 로그 파일을 할당 및 활성화하고 채우기 빈도를 결정한 후 운용 로그 파일 크기를 결정할 것을 제안합니다.

샘플 JCL:

//FMTLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSLOG1 DD DSN=hlq.CDSLOG1,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,100)
//SLSLOG2 DD DSN=hlq.CDSLOG2,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,100)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
FMTLOG

2. SET LOGFILE을 실행하여 새 로그 파일을 지정합니다.
샘플 JCL:

//SETLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
SET LOGFILE(hlq.CDSLOG1,hlq.CDSLOG2)

3. OFFLOAD LOGFILE을 실행하여 이전 로그 파일을 오프로드합니다.

//JOBOFFL job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=
//SLSCNTL   DD DSN=primary.dataset.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR
//SLSSTBY DD DSN=standby.dataset.name,DISP=SHR
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
OFFLOAD LOGFILE

그러면 HSC가 새 로그 파일로 자동으로 전환됩니다.

수동으로 다른 CDS 복사본으로 전환

"CDS 백업"에 설명된 대로 CDS 복사본을 여러 개 지정하는 경우 기본 CDS가 실패하면 HSC가 자동으로 다른 CDS 복사본으로 전환합니다. 수동으로 다른 CDS 복사본으로 전환하는 데는 몇 가지 이유가 있습니다. 기본적으로 다음 경우 중 하나에 해당합니다.

- CDS 이동 및/또는 확장 작업을 수행하려는 경우

- HSC가 자동으로 CDS 복사본을 전환한 후 사용자가 이전 기본 복사본을 삭제하고 재할당한 후 다시 채우려는 경우. 재할당된 기본 CDS를 사용으로 설정하면 HSC가 백업 복사본에서 해당 CDS로 유효한 CDS 데이터를 다시 복사합니다.

CDS ENABLE/DISABLE 명령을 사용하여 CDS 복사본을 전환, 확장 또는 이동할 수 있습니다. 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

CDS 확장

CDS EXpand 명령을 사용하여 VOLPARM 데이터, VTCS CONFIG 데이터 또는 원격 보관된 볼륨 데이터를 CDS에 추가할 수 있습니다. CDS 크기를 늘려야 할 수 있는 다른 구성 변경 사항(예: LIBGEN이 FUTRACS 및 FUTRLSM 매개변수를 사용하지 않은 경우 새 ACS 및 LSM 추가)을 적용하려면 CDS EXpand 명령 대신 다른 메소드를 사용해야 합니다. 자세한 내용은 Configuring HSC and VTCS의 "Reconfiguring a TapePlex"를 참조하십시오.

주의:
오라클은 모든 CDS 복사본을 백업한 후 CDS EXpand 명령을 실행할 것을 권장합니다. 확장 작업 중 실패하는 경우 일반적으로 CDS를 사용하지 못하게 됩니다. 따라서 확장 작업 중 실패하는 경우 CDS의 최신 복사본을 사용할 수 있도록 CDS EXpand 명령을 호출하기 전에 CDS를 백업해야 합니다.

CDS EXpand 지침은 다음과 같습니다.

- CDS EXpand 명령을 사용할 때 HSC가 활성 상태여야 하며 테이프가 작동 중일 수 있습니다.

- 여러 호스트에서 동시에 CDS Enable 및/또는 Disable 명령을 실행하지 마십시오. 실행하는 경우 HSC가 오류 메시지를 표시할 수 있습니다. 오류 메시지가 표시되면 ELS Messages and Codes를 참조하여 사용자 작업이 필요한지 여부를 결정하십시오.

- 확장 작업 결과와 일치하도록 필요에 따라 HSC PARMLIB에서 CDSDEF 제어문을 업데이트합니다.

- 보다 큰 미리 할당된 데이터 세트로 CDS를 복원하는 작업을 통해서는 CDS를 동적으로 확장할 수 없습니다. 추가 공간이 포맷되지 않은 상태이므로 그대로 사용할 수 없습니다.

- Oracle은 동일한 양의 DASD 공간을 사용하여 모든 CDS를 할당할 것을 권장합니다. CDS의 사용 가능한 공간은 DASD 공간 할당이 가장 작은 CDS에 적합한 4096바이트 블록 수에 따라 결정됩니다.

모든 CDS를 확장하려면 다음과 같이 하십시오.

1. CDS DISABLE 명령을 사용하여 각 CDS를 한 번에 하나씩 사용 안함으로 설정합니다.

2. 기본 공간 수량을 늘려 각 CDS를 재할당합니다.
보조 공간 수량을 지정하지 마십시오. 모든 CDS에는 확장 영역이 하나만 있어야 합니다.

3. CDS ENABLE 명령을 사용하여 각 CDS를 다시 사용으로 설정합니다.

4. CDS EXpand 명령을 입력합니다.
HSC에서 확인된 모든 CDS(사용으로 설정된 모든 CDS)가 한 번의 CDS EXpand 명령 호출로 동시에 확장됩니다.

CDS 교체

CDS 이름은 CDS 자동 또는 수동 전환으로 인해 변경되지 않습니다. 일련의 CDS Disable 및 Enable 명령을 사용하여 순서를 복원하고 데이터 세트 이름과 예상 역할을 일치시킬 수 있습니다.

CDS를 교체하려면 다음과 같이 하십시오.

1. CDS 표시 명령을 입력하여 CDS의 현재 상태 및 지정을 확인합니다.

SYS000001 = ELS.SYSCNTL2
PRIVOL = PROD02 FLAGS(40) ACTIVE
SYS000002 = ELS.SYSCNTL
SECVOL = PROD01 FLAGS(40) ACTIVE

SYSCNTL(원래 기본)이 보조로 설정되고 SYSCNTL2(원래 보고)가 기본으로 설정되었음을 알 수 있습니다.

2. 현재 기본을 사용 안함으로 설정합니다.

CDS DISABLE PRIMARY

ELS.SLSCNTL2가 사용 안함으로 설정되고 ELS.SLSCNTLT가 기본으로 바뀝니다.

3. 새 활성 보조로 ELS.SLSCNTL2를 다시 사용으로 설정합니다.

CDS ENABLE DSN(ELS.SLSCNTL2)

4. CDS 표시 명령을 입력하여 CDS가 교체되었는지 확인합니다.

SYS000001 = ELS.SYSCNTL
PRIVOL = PROD02 FLAGS(40) ACTIVE
SYS000002 = ELS.SYSCNTL2
SECVOL = PROD01 FLAGS(40) ACTIVE

CDS 이름 바꾸기

다음과 같은 두 가지 방법으로 CDS의 이름을 바꿀 수 있습니다.

- CDS Disable 및 Enable 명령을 사용하여 HSC 중지 없이 이름을 바꿉니다.

- HSC를 중지하고 BACKup 및 RESTore 유틸리티를 사용하여 이름을 바꿉니다.

BACKup 및 RESTore 유틸리티를 사용하는 경우 HSC를 중지해야 한다는 분명한 단점이 있지만 CDS 백업본이 만들어진다는 이점도 있습니다.

CDS Disable 및 Enable 명령을 사용하여 CDS 이름 바꾸기

명령을 사용하여 CDS 이름을 바꾸려면 다음과 같이 하십시오.

1. 모든 호스트에서 이름을 바꿀 CDS를 사용 안함으로 설정합니다.
예를 들면 다음과 같습니다.

CDS DISABLE DSN(ACS.DBASEOLD)

2. CDS가 포함된 데이터 세트의 이름을 바꿉니다.
예를 들어, ACS.DBASEOLD를 ACS.DBASECPY로 이름을 바꿉니다.

3. 새 이름으로 CDS를 사용으로 설정합니다.
예를 들면 다음과 같습니다.

CDS ENABLE DSN(ACS.DBASECPY)

이름이 바뀐 CDS에 대해 Enable 명령이 실패하는 경우 명령이 실행되기 전 상태로 CDS 정의가 복원됩니다. 활성 CDS와의 일관성이 유지되도록 HSC PARMLIB에서 CDSDEF 제어문을 수정합니다.

CDS 이름이 DHB(데이터베이스 하트비트) 레코드에 기록됩니다. HSC 초기화 중 DHB의 데이터 세트 이름이 HSC PARMLIB의 CDSDEF 제어문에서 지정된 데이터 세트 이름과 비교됩니다.

CDSDEF 문에서 지정된 데이터 세트 이름이 DHB에 기록된 CDS 이름과 일치하지 않을 경우 해당 CDS가 사용 안함으로 설정됩니다. 지정된 모든 CDS가 사용 안함으로 설정되면 HSC가 초기화되지 않습니다. 사용으로 설정된 CDS를 기본, 보조 및 대기 CDS에 특별히 지정하는 작업은 데이터베이스 하트비트 레코드에 기록된 CDS 지정을 기반으로 합니다.

CDS의 이름을 바꿔야 하는 경우 아래의 이름 바꾸기 절차에 설명된 대로 HSC BACKup 및 RESTore 유틸리티를 사용하십시오. MVS, TSO ISPF 또는 타사 유틸리티를 사용하여 BACKup 및 RESTore 유틸리티를 실행하지 않은 상태로 CDS의 이름을 바꾸지 마십시오.

CDS 재배치

CDS를 재배치하려면 다음과 같이 하십시오.

1. 모든 호스트에서 재배치할 CDS를 사용 안함으로 설정합니다.
예를 들면 다음과 같습니다.

CDS DISABLE DSN(ACS.DBASECPY)

2. 적절한 CDS 속성을 사용하여 새 데이터 세트를 할당합니다.

자세한 내용은 Configuring HSC and VTCS를 참조하십시오.

3. 2단계에서 할당된 데이터 세트가 속한 CDS를 사용으로 설정합니다.
예를 들면 다음과 같습니다.

CDS ENABLE DSN(ACS.DBASENEW)NEWLOC

주:
지정되지 않은 경우 MVS에서 카탈로그 서비스를 사용하여 볼륨 및 장치 정의를 확인합니다.

이름 바꾸기 또는 재배치 작업이 실패하는 경우 명령이 실행되기 전 상태로 CDS 정의가 복원됩니다. 활성 CDS와의 일관성이 유지되도록 CDSDEF 제어문을 수정합니다.

카탈로그화가 취소된 CDS 복사본 재배치

ACS.DBASECPY가 사용 안함으로 설정되고 삭제(또는 카탈로그화 취소)되었으며 ACS.NOTCATLG가 할당되고 카탈로그화되었다고 가정합니다. 다음 명령은 카탈로그화가 취소된 CDS 복사본을 재배치합니다.

CDS ENABLE DSN(ACS.NOTCATLG) NEWVOL(HSC001),NEWUNIT(ABC)

이 명령에서 CDS 정의와의 일관성이 유지되도록 CDSDEF 제어문을 수정합니다. 이름 바꾸기 또는 재배치 작업이 실패하는 경우 명령이 실행되기 전 상태로 CDS 정의가 복원됩니다.

CDS 스왑

HSC 명령 또는 유틸리티를 사용하여 CDS를 재배치하는 것과는 다르게, 데이터 세트 사용자에게 영향을 끼치지 않고 특정 위치에서 다른 위치로 디스크 데이터 세트를 스왑할 수 있도록 해주는 다양한 타사 소프트웨어 제품이 있습니다. HSC 및 VTCS 유틸리티가 항상 새 CDS 위치를 사용할 수 있게 TDMF, FDRPAS 또는 P/DAS 스왑 작업이 수행된 후 몇 초 이내에 CDS에 저장된 장치 주소 정보를 동적으로 업데이트하도록 HSC가 향상되었습니다.

이 향상된 기능으로 인해 제한 없이 CDS를 이동할 수 있는 것은 아닙니다. PPRC 또는 스왑 작업 이외의 다른 방법으로 CDS를 이동하려면 CDS의 VOLSER를 변경해야 합니다. CDS의 VOLSER가 변경되는 경우 기존 CDS의 SLUADMIN BACKup 및 RESTore 프로세스를 통해 장치 주소 및 볼륨 일련 번호 정보를 재설정해야 합니다.

CDS 복원

모든 CDS 복사본을 사용할 수 없는 경우(기본, 보조 및 대기 복사본을 손실한 경우) 백업에서 CDS를 복원해야 합니다. CDS 복사본 하나를 손실한 경우(복사본이 여러 개 있으면) CDS ENABLE/DISABLE 명령을 사용하여 유효한 복사본에서 실행을 계속하고 오류가 있는 복사본을 다시 만들 수 있습니다. 자세한 내용은 "수동으로 다른 CDS 복사본으로 전환"을 참조하십시오.

주의:
CDS의 모든 복사본을 손실한 경우 실제로 백업에서 CDS를 복원해야 하는지 확인하고 필요에 따라 복원 프로세스를 지원 받으려면 오라클 소프트웨어 지원 센터에 문의하십시오.

주:

- CDS 백업을 만들 때 PITCOPY를 사용했든 SLUADMIN BACKUP을 사용했든 상관없이 복원 프로세스는 동일합니다.

- 복원을 수행하기 전에 손상된 CDS의 백업을 새로 수행하거나 현재 모든 CDS 복사본의 이름을 바꿔 이후 분석을 위해 보존해야 합니다.

백업 복사본에서 CDS 복원

백업 복사본에서 CDS를 복원하려면 다음과 같이 하십시오.

1. HSC가 활성 상태인 호스트가 있을 경우 활성 HSC 시스템을 중지합니다.
로깅이 사용으로 설정된 경우 계속해서 단계 2를 수행하여 VSM 데이터를 재동기화합니다. 그렇지 않은 경우 단계 3을 수행합니다.

2. CDS에 액세스할 수 있을 경우 일반 로그 파일 오프로드 작업을 실행합니다.

이 오프로드는 마지막 오프로드 이후의 VSM 작동을 캡처합니다.

//JOBOFFL job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=
//SLSCNTL   DD DSN=primary.dataset.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR
//SLSSTBY DD DSN=standby.dataset.name,DISP=SHR
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
OFFLOAD LOGFILE

CDS에 액세스할 수 없을 경우 LOGDSN 매개변수를 사용하여 로그 파일을 오프로드합니다. 일반 CDS 로깅 프로세스에서는 CDS에 저장된 로그 정보를 사용합니다. CDS에 액세스할 수 없을 경우 LOGDSN 매개변수로 지정한 현재 로그 파일에 있는 로깅 정보를 사용해야 합니다.

//JOBOFFL job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
OFFLOAD LOGFILE LOGDSN(hsc.log1)

주:
CDS에 액세스할 수 없을 경우 LOGDSN 옵션을 사용하지 않은 상태로 CDS를 복원한 후 OFFLOAD LOGFILE 유틸리티를 실행하려고 시도하면 오프로드가 실패하거나 잘못된 로그 오프로드 파일이 만들어질 수 있으므로 유의하십시오.

3. 마지막으로 알려진 올바른 백업에서 CDS를 복원합니다.

//JOBREST job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSBKUP   DD DSN=backup.dataset.name(0),DISP=SHR
//SLSCNTL   DD DSN=primary.dataset.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR
//SLSSTBY DD DSN=standby.dataset.name,DISP=SHR
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
RESTORE

주의:
RESTORE JCL에서는 사용 중인 모든 HSC 데이터 세트(기본, 보조, 대기)를 지정해야 합니다.

자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

주:
로컬/원격 링크 라이브러리가 서로 독립적으로 CDS를 실행하는 경우 BACKup 및 RESTore를 실행하기 위해 특별한 예방 조치를 취해야 합니다. 로컬 및 원격 라이브러리를 연결하는 링크가 중단되는 경우 이러한 예방 조치를 따라야 합니다. 자세한 내용은 ELS Legacy Interfaces Reference를 참조하십시오.

복구를 위해 로그 파일을 사용 중인 경우 계속해서 4단계를 수행합니다. 그렇지 않을 경우 9단계로 이동합니다.

4. 복원된 CDS가 올바른 로그 파일 정보를 참조하고 있는지 확인합니다.

- SET LOGFILE(OFF)을 실행합니다.

//SETLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
SET LOGFILE(OFF)

- FMTLG 유틸리티를 실행하여 로그 파일의 형식을 다시 지정합니다.

//FMTLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSLOG1 DD DSN=hlq.CDSLOG1,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,100)
//SLSLOG2 DD DSN=hlq.CDSLOG2,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,100)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
FMTLOG

- SET LOGFILE을 다시 실행하여 새로 초기화된 로그 파일의 이름을 지정합니다.

//SETLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
SET LOGFILE(hlq.CDSLOG1,hlq.CDSLOG2)

5. LOGUTIL 명령을 실행하여 복구에 필요한 AUDIT MVC 명령으로 데이터 세트를 생성하고 해당 데이터 세트에서 명령을 실행합니다.

다음 예에서는 2009년 5월 12일 오후 10시에 마지막으로 알려진 올바른 CDS 백업이 생성되었다고 가정합니다.

- LOGIN 문은 마지막으로 알려진 올바른 백업으로 만들어진 로그 파일부터 시작하여 2에서 만든 로그 파일로 끝나는 각 오프로드 로그 파일에 대한 DD 문을 지정합니다.

- LOGUTIL GENAUDIT는 RECVCMD를 VSM 데이터 복구 명령이 포함된 데이터 세트의 DD 이름으로 지정합니다.

//JOBLOGR job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//LOGIN        DD DSN=offload.dataset.name(-2),DISP=OLD
//             DD DSN=offload.dataset.name(-1),DISP=OLD
//             DD DSN=offload.dataset.name(0),DISP=OLD
//RECVCMD      DD DSN=offload.dataset.genaudit,DISP=(,CATLG,DELETE),
//                UNIT=SYSDA,SPACE=
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
LOGUTIL FROMDATE(2009-5-12) FROMTIME(22:00:00)  LOGDD(LOGIN)
GENAUDIT COMMANDS(RECVCMD)

6. 현재 VTCS 구성에 LOGPOL=REQUIRED가 지정된 경우 다음과 같이 합니다.

CONFIG GLOBAL 문에서 LOGPOL=OPTIONAL을 지정하고 CONFIG를 실행하여 VTCS 구성에서 일시적으로 로깅을 사용 안함으로 설정합니다. HSC/VTCS가 활성 상태가 아닌 동안 MVCMAINT 명령을 성공적으로 실행하려면 이 작업을 수행해야 합니다.

7. 감사 대상 MVC를 읽기 전용 상태로 설정합니다.
HSC/VTCS가 비활성 상태인 감사 대상 MVC에 대해 MVCMAINT READONLY(ON) 명령을 실행합니다. 그러면 HSC/VTCS가 활성 상태일 때 MVC가 사용되지 않습니다.

//JOBAUDIT job (account),programmer,REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM='execution parameters'
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
MVCMAINT READONLY(ON) MVC( +
mvc1 +
mvc2 +
…    +
mvcn +
)

8. VTCS 구성에서 LOGPOL=REQUIRED가 필요한 경우 다음과 같이 합니다.
CONFIG GLOBAL 문에서 LOGPOL=REQUIRED를 지정하고, (위의) 6단계에서 LOGPOL=OPTIONAL이 일시적으로 지정된 경우 CONFIG를 실행합니다.

9. 하나의 호스트에서 HSC를 다시 시작하되 테이프 작동은 시작하지 않습니다.

10. CDS의 비VSM 부분을 복구하려면 모든 ACS에서 SLUADMIN AUDIT를 실행합니다.

//JOBAUDIT job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
AUDIT ALL

주:
라이브러리 감사가 시작되면 11단계, 12단계 및 13단계를 동시에 실행할 수 있습니다.

11. 모든 VTSS를 감사합니다.

//JOBAUDITV job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
AUDIT VTSS(VTSS0,VTSS1)

12. 스크래치 동기화를 실행합니다.

SLUCONDB를 실행하여 HSC 스크래치 상태를 TMS와 동기화합니다. 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오. LCM을 사용 중인 경우 LCM 사용 설명서에서 동등한 LCM 유틸리티를 참조하십시오.

13. 로깅을 사용 중인 경우 단계 5에서 만든 데이터 세트에서 복구 명령을 사용하여 영향을 받는 MVC를 감사합니다.

//JOBRMVC job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSIN DD DSN=offload.dataset.genaudit,DISP=SHR
//SLSPRINT DD SYSOUT=*

로깅을 사용 중이 아닌 경우 감사해야 할 MVC를 결정하는 데 도움이 필요하면 오라클 소프트웨어 지원 센터에 문의하십시오.

14. 모든 호스트에서 HSC를 시작합니다.

15. 테이프 작동을 다시 시작합니다.

3 TapePlex 관리

일반적으로 TapePlex 관리는 VTCS 관리와 유사하며 (1) 주기적이고 지속적으로 TapePlex의 상태를 확인하고 (2) 요구 사항이 발생할 때 필요시 작업을 수행합니다. 하지만 이 장에는 TapePlex의 물리적 요소를 다룰 때 수행하는 필요시 작업과 주기적인 작업, 정상적인 작동을 유지하기 위해 수행해야 할 작업이 혼합되어 있습니다. SMC/HSC/VTCS는 서버 소프트웨어이므로 자동 해결이 가능하도록 설계되어 있습니다. 마찬가지로 라이브러리 하드웨어 자체에도 중복성 및 복원성이 내장되어 있습니다. 소프트웨어 및 하드웨어의 상태를 자주 확인하여 문제를 수정하면 대부분의 TapePlex 관리 작업이 처리됩니다.

라이브러리 하드웨어 관리

최적의 상태 도구 중 하나로 DISPLAY EXCEPTNS를 들 수 있습니다. 여기서 "exceptions"는 최적 성능에 미치지 못하는 하드웨어 상태입니다. 명령 출력으로 "감지된 하드웨어 구성 요소 이름 문제가 없습니다"라는 일련의 메시지가 표시되기를 원할 것입니다. 시스템 문제가 발생한 경우 이 종류의 출력은 하드웨어가 정상임을 나타내지만 소프트웨어 문제가 발생했을 수 있습니다.

반면 "CAP 작동 안함", "로봇 손 유지 관리 필요", "LSM 오프라인" 등의 출력이 표시되면 문제가 소프트웨어와 관련된 것인지 아니면 하드웨어와 관련된 것인지 확인할 수 있는 추가 정보가 필요합니다. 따라서 해당 메시지가 표시되면 자세한 설명 및 사용자 응답이 제공되는 ELS Messages and Codes에서 확인하십시오. 어떤 경우에는 응답이 명확하고 간단합니다. 로봇 손에 대한 유지 관리가 필요한 경우 CSE에 요청하면 됩니다. 하지만 응답이 명확하지 않은 경우도 있습니다. LSM이 오프라인일 경우 명확한 조치는 LSM을 다시 온라인으로 수정하는 것입니다. 단, 유지 관리를 위해 LSM의 작동이 중지되거나 드라이브 장치 주소를 변경하고 있지 않아야 합니다. 그렇지 않으면 LSM을 다시 온라인으로 전환하기 전에 작업이 완료될 때까지 기다리십시오.

DISPLAY EXCEPTNS를 첫번째 진단 도구로 사용했을 때 문제가 발견되지 않았거나 문제가 발견되었지만 해결되었으며 현재 작업 및 ACS 일별 보고서를 사용하여 라이브러리 성능을 조정 중인 경우 라이브러리 하드웨어 관리와 관련된 다음 단계는 무엇일까요? 다음 절에서는 상태 명령 및 해당 명령으로 표시되는 상태에 대한 응답을 자세히 설명합니다.

ACS 관리

DISPLAY ACS와 DISPLAY ALL이라는 서로 다른 두 가지 명령은 반드시 이해한 후 사용해야 합니다. DISPLAY ACS는 ACS, LMU 및 스테이션에 대한 하드웨어 상태, 스크래치 볼륨 및 사용 가능한 셀을 비롯하여 ACS 상태를 보여줍니다. DISPLAY ALL은 LSM 및 CDS 상태를 비롯하여 모든 상태를 알려줍니다. ACS 연결 해제됨, 스테이션 오프라인 또는 대기 모드, LSM 오프라인 등 온라인 또는 작동 상태가 아닌 구성 요소가 표시될 수 있습니다. MODIFY 명령을 사용하여 LSM 및 CAP의 상태를 변경하고, VARY 명령을 사용하여 ACS 상태를 변경할 수 있습니다. 하지만 앞서 설명된 대로 하드웨어 상태를 변경 중인 이유와 변경 방법을 파악한 후 적절한 명령을 입력해야 합니다. 유지 관리를 위해 LSM을 오프라인으로 수정해야 하는 경우 작업을 수행하기 전에 해당 LSM에 대한 테이프 작동을 중지했는지 확인하고 이에 따라 유지 관리가 완료된 후 LSM을 온라인으로 변경해야 합니다.

SL8500 중복 전자 부품 관리

중복 전자 부품 옵션을 사용하면 LC(라이브러리 컨트롤러) 전환을 자동화하여 라이브러리 컨트롤러 실패로 인한 제어 경로 작동 중지 시간을 최소화할 수 있습니다. 이 구성에서 두번째 라이브러리 컨트롤러는 라이브러리 컨트롤러를 LSM에 연결하는 LAN에 연결됩니다. HSC는 하나의 라이브러리 컨트롤러(활성 LC)로 모든 작업을 보내며 두번째 LC(대기 LC)는 준비된 백업 컨트롤러로서 전원이 켜진 상태로 유지됩니다. 활성 및 대기 LC 지정은 동적이며 LC의 역할은 환경 조건에 따라 달라집니다.

이 절에서 설명되는 명령 및 유틸리티에 대한 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

이중 라이브러리 컨트롤러 구성

이 구현의 경우 이중 LC 구성은 설치 후 스트링의 단일 라이브러리에 네트워크로 연결되는 한 쌍의 LC입니다. 이 구성만 유효한 구성입니다. 그림 3-1은 이 구성의 예를 보여줍니다.

그림 3-1 이중 LC 구성

이중 LC 구성에는 다음 규칙이 적용됩니다.

- 두 LC는 모든 호스트에 연결되어야 합니다.

- 항상 두 LC의 전원을 켤 수 있습니다.

- 두 LC는 LAN 0과 LAN 1에 연결되어야 합니다.

활성 LC에서 실패가 발생하는 경우 자동 전환이 발생하여 대기 LC가 활성 LC 역할을 맡습니다. 알림을 받은 HSC는 운영자에게 전환을 통지합니다. 대부분의 미해결 요청은 다시 진행되며 모든 미래 라이브러리 요청은 새로 활성화된 LC로 전송됩니다. 실패한 LC가 복구되고 전원이 켜지면 대기 역할을 맡습니다.

동적으로 대기 LC를 활성화하는 것이 좋을 경우 사용할 운영자 SWitch 명령이 제공됩니다. 운영자가 Switch 명령을 실행하면 이전 활성 LC에 재부트 시작이 지시된 후 대기 LC가 활성 LC 역할을 맡습니다. 이전 활성 LC가 성공적으로 재부트되면 대기 LC 역할을 맡습니다.

주:
이중 LC 환경에서의 작동에 적용되는 경고 및 예방 조치가 있습니다. 중복 LC 작동 개요를 참조하여 해당 요구 사항을 숙지하십시오.

HSC가 설치된 경우 활성 LC와 대기 LC에 대한 네트워크 연결을 지정해야 합니다.

SL8500 중복 전자 부품 환경

모든 네트워크 연결 경로가 LC에 대해 오프라인이거나 모든 네트워크 연결 경로가 비작동 상태인 경우 라이브러리 요청을 자동화할 수 없습니다. 중복 전자 부품 환경에서 모든 네트워크 연결 경로가 활성 LC에 대해 비작동 상태인 경우 HSC SWitch 명령을 사용하여 작업 부하를 대기 LC로 옮기십시오.

SL8500 LC 작동

LC(라이브러리 컨트롤러)는 HSC를 통해 호스트의 마운트 및 마운트 해제 요청에 응답하고 적절한 LSM으로 각 요청을 전달하여 요청된 물리적 작업을 수행합니다.

이 절에서는 다음 절차에 대해 설명합니다.

- ACS 상태 표시

- "중복 LC 작동 개요."

주:

- LC를 재부트하는 경우 메시지 앞에 다음과 같은 오류 메시지가 나타납니다.

... ACS AA LSM LL ready; ...

이는 무시할 수 있습니다. 메시지 뒤에 표시되는 오류 메시지는 무시하지 마십시오.

- 라이브러리 컨트롤러 패널에 대한 설명 및 독립형 LC 구성과 중복 LC 구성에서 라이브러리 컨트롤러의 전원을 켜고 끄며 라이브러리 컨트롤러를 부트하는 방법은 적절한 Oracle 하드웨어 운영자 설명서를 참조하십시오.

ACS 상태 표시

LC 상태를 확인하려면 다음 명령을 실행하십시오.

Display Acs acsid

명령 응답에는 다음 항목이 나열됩니다.

- ACS의 현재 상태

- 다음 등 중복 LC(구성된 경우)의 현재 상태

- HSC/LC 호환성 레벨

- 활성 LC

- 대기 LC

- 각 LC의 온라인, 오프라인 또는 대기 상태

중복 LC 작동 개요

중복 전자 부품 구성에서는 활성 LC가 실패하는 경우 인계할 수 있는 백업 LC를 제공합니다. 이중 LC 옵션에 대한 설명은 이중 라이브러리 컨트롤러 구성을 참조하십시오. 두 LC가 모두 활성화될 수 있지만 지정된 시점에는 하나만 활성 LC가 될 수 있습니다. 각 LC는 LAN을 통해 정기적으로 다른 LC의 상태를 확인합니다. HSC는 활성 LC로 모든 I/O를 보냅니다.

이중 LC 구성에서 특정 LC의 전원이 켜진 경우 이 LC는 자체적으로 대기 상태가 되며 활성 LC가 있는지 확인합니다. 활성 LC가 있을 경우 두번째 LC가 대기 LC로서 준비 상태로 유지됩니다. 활성 LC가 없을 경우 완전히 초기화될 첫번째 LC가 활성 역할을 맡습니다.

두 LC의 전원이 성공적으로 켜지면 다음과 같은 HSC 메시지가 표시됩니다.

... ACS AA: RE LIBID C1 is configured; Active is y, Standby is ready

여기서 y는 구성된 LC 식별자("A" 또는 "B")입니다.

LC 전환 개요

다음과 같은 방식으로 활성 LC 기능을 전환할 수 있습니다.

- 활성 LC의 자동으로 감지된 실패 또는 전원 공급 장치 문제로 인한 자동 전환

- 모든 온라인 스테이션이 통신할 수 없는 상태가 된 후 운영자가 시작한 전환(SWitch 명령 사용)

- 온라인 스테이션이 활성 LC와 통신할 수 있는 동안 운영자가 시작한 전환(SWitch 명령 사용)

- 활성 LC의 재부트 스위치가 작동된 경우 전환

- 활성 LC의 전원이 꺼진 경우 전환

LC 전환 결과

LC 전환이 발생하면 일련의 콘솔 메시지가 활성 및 대기 LC의 상태 변경을 추적합니다. 중요한 상태 변경은 강조 표시된 메시지로 표시되어 상태가 해결되거나 메시지가 대체될 때까지 화면에 유지됩니다.

상태가 변경되고 대기 LC가 준비된 경우 다음 메시지가 표시됩니다.

... ACS AA: RE LIBID C1 is configured; Active is y, Standby is ready

상태 변경이 있으며 LC 오류가 발생한 경우 다음 메시지가 표시됩니다.

... ACS AA: : RE LIBID C1 Is Not configured; Active Is y, Standby is not ready

상태 변경이 있으며 대기 LC가 준비되지 않은 경우 다음 메시지가 표시됩니다.

... ACS AA: : RE LIBID C1 Is configured; Active Is y, Standby is not ready

위 메시지에서 y는 구성된 LC 식별자("A" 또는 "B")입니다.

LC 전환이 발생하면 HSC가 각 LC에서 정보를 얻어 현재 상태를 확인합니다. 각 스테이션의 상태는 온라인, 오프라인, 대기, 온라인 보류, 오프라인 보류 또는 강제 오프라인 보류로 유지 관리됩니다. Display Acs acsid 명령을 사용하여 각 스테이션 및 LC의 상태를 확인할 수 있습니다.

주:
LSM이 초기화를 완료할 때까지 LC 전환 중 자동 모드 CAP가 잠겨 있습니다.

자동 LC 전환

LC 마이크로코드가 ACS 작동을 유지하기 위해 필요에 따라 LC 실패를 감지, 보고 및 처리합니다. 이 동작은 자동으로 실행되어 일부 작업이 LC 내에서 처리 중일 수 있으므로 유의하십시오. 대기 LC가 활성 역할을 맡으면 HSC에 변경된 상태가 통지되고 LC 준비 신호가 전송됩니다. HSC는 ACS의 다양한 LSM 내에서 이동 중인 카트리지와 관련하여 새 활성 LC가 제공하는 복구 정보를 읽습니다. 그런 다음 HSC는 다음 작업을 수행합니다.

- 이동 중인 카트리지의 현재 위치가 반영되도록 대기열에 있는 요청을 수정하거나 "completed"로 표시합니다.

- 모든 미완료 요청을 활성 LC로 보냅니다.

- 요청을 완료할 수 없을 경우 카트리지를 문제 상태로 표시합니다.

주:
넣기 및 꺼내기 작업은 LC 전환 후 다시 시작해야 할 수도 있습니다.

운영자가 시작한 LC 전환

일부 네트워크 연결이 통신 중인 경우 LC 전환을 시작하기 전에, LC 전환을 즉시 수행해야 할지 여부 또는 전환을 시작하기 전에 처리를 완료할 수 있는지 여부를 결정하십시오. 반드시 LC를 전환하지 않아도 되는 경우 LSM이 비교적 유휴 상태일 때까지 기다리십시오.

다음 명령을 실행하여 라이브러리 ID에 대한 LC 전환을 시작하십시오.

SWitch Acs acsid LIB libid

명령은 대기 LC를 통해 연결이 해제된 LC로 경로 지정되므로 재부트해야 합니다. 이벤트 순서는 다음과 같습니다.

1. HSC가 메시지를 발행합니다.

... ACS AA: Switch initiated, expect notification in 20 seconds

2. 대기 LC가 활성 LC 역할을 맡습니다("ACTIVE" 표시기가 켜짐).

3. 온라인 LSM이 빠른 초기화를 수행합니다.

4. 각 LSM이 준비되면 HSC가 메시지를 발행합니다.

... ACS AA LSM LL Ready; Temp Outage Queue Will Be ReDriven

5. 이전 활성 LC가 성공적으로 재부트를 완료하면 대기 LC 역할을 맡습니다.

처리가 활성 상태인 동안 SWitch 명령이 실행되면 다양한 LSM에서 카트리지가 이동 중일 수 있습니다. "자동 LC 전환"에 설명된 대로 자동으로 복구 절차가 수행됩니다. LC 준비 신호가 수신되면 HSC는 LSM이 빠른 초기화를 완료할 때까지 기다렸다가 임시 중단 대기열 처리를 통해 요청을 다시 진행합니다.

CAP 수동 복구

LC 전환이 발생하고 특정 CAP 기능이 요청(넣기/꺼내기)을 처리 중인 경우 전환이 완료된 후 복구에 대한 수동 간섭이 필요합니다. 다음은 각각에 대해 적절한 해결 절차가 제시된 다양한 CAP 시나리오입니다.

Enter 함수가 활성 상태인 경우 전환 발생

전환이 발생하고 enter 함수가 활성 상태이면 전환이 완료된 후 두 가지 이벤트가 동시에 또는 개별적으로 발생할 수 있습니다.

- 전환이 발생한 경우 카트리지가 HSC/ELS에 의해 선택되지만 LSM 홈 셀로 이동되지 않습니다. 전환이 완료된 후 카트리지가 선택되며 LSM 셀로 이동될 수 없습니다.

- LSM으로 이동될 CAP의 카트리지가 이동 중 라이브러리로부터 SLS0699I 메시지 - 03/01 오류를 수신합니다. 전환이 완료된 후 CAP에 카트가 있으므로 라이브러리가 CAP를 예약합니다. 카트리지가 제거될 때까지 라이브러리가 CAP의 소유권을 보유합니다. 이는 SL8500 라이브러리의 정상 동작입니다.

해결 절차:

- SL8500 운영자 설명서의 절차에 따라 SLC를 사용하여 CAP에서 카트리지를 수동으로 제거합니다.

- 영향을 받는 특정 CAP에 대해 Display Cap aa:ll:cc 명령을 실행합니다.

- CAP가 오프라인일 경우 Modify CAP aa:ll:cc,online 명령을 실행합니다.

- ENter aa:ll:cc 명령을 실행하여 CAP에 대한 enter 함수를 다시 시작합니다.

- CAP가 자동인 경우 다음 명령을 실행합니다.

CAPP x aa:ll:cc MANual
CAPP x aa:ll:cc AUTO

그러면 자동 모드로 재설정됩니다.

- 이전 enter 함수에서 제거된 카트리지 밸런스를 CAP에 삽입합니다.

- volser가 중복되었음을 알리는 SLS0251E 메시지가 표시되면 UNSELECT 유틸리티를 실행하여 volser의 선택을 취소합니다. 그런 다음 volser를 LSM에 넣을 수 있습니다.
volser를 넣을 때 중복 volser로 수행하려는 작업을 묻는 SLS0694D 메시지가 표시되면 logically delete로 응답해야 합니다.

Eject 함수가 활성 상태인 경우 전환 발생

전환이 발생하고 eject 함수가 활성 상태이면 전환이 완료된 후 CAP로 이동될 LSM의 카트리지가 이동 작업에 대해 라이브러리로부터 SLS0699I 메시지 - 03/01 오류를 수신합니다. 전환이 완료된 후 CAP에 카트가 있으므로 라이브러리가 CAP를 예약합니다. 카트리지가 제거될 때까지 라이브러리가 CAP의 소유권을 보유합니다. 이는 SL8500 라이브러리의 정상 동작입니다.

해결 절차:

- SL8500 운영자 설명서의 절차에 따라 SLC를 사용하여 CAP에서 카트리지를 수동으로 제거합니다.

- 영향을 받는 특정 CAP에 대해 Display Cap aa:ll:cc 명령을 실행합니다.

- CAP가 오프라인일 경우 Modify CAP,online 명령을 실행합니다.

- EJECT vol-list 또는 vol-range aa:ll:cc 명령을 다시 실행하거나 꺼내기 유틸리티를 다시 시작하여 카트리지 밸런스를 꺼냅니다.

- eject 함수를 실행하기 전 CAP가 자동인 경우 CAPP x aa:ll:cc manual을 실행한 후 CAPP x aa:ll:cc auto를 다시 실행하여 자동 모드로 재설정합니다.

CAP가 자동 모드로 설정된 경우 전환 발생

전환이 발생하고 CAP가 자동 모드로 설정되면 전환이 완료될 때 CAP 예약 중 라이브러리로부터 07/05 오류의 반환/원인 코드와 함께 SLS0699I 메시지가 표시될 수 있습니다. 전환이 완료된 후 CAP가 완전히 초기화되지 않았기 때문입니다. 이는 SL8500 라이브러리의 정상 동작입니다.

해결 절차:

- 전환된 라이브러리의 마지막 LSM에 대해 SLS0668I 메시지가 발행될 때까지 기다립니다.

- 각 자동 CAP에 대해 CAPPref prefvalue aa:ll:cc MANual을 실행합니다.

- 자동으로 설정할 각 CAP에 대해 CAPPref prefvalue aa:ll:cc AUTO를 실행합니다.

CAP 관리

DISPLAY CAP는 CAP 설정 및 상태를 보여주며 MODIFY CAP는 CAP 상태를 변경합니다. 기본 상태 이외에 DISPLAY CAP는 CAP 상태를 변경할지 여부와 변경할 경우 시기를 결정하는 데 도움이 되는 몇 가지 유용한 정보를 제공합니다.

- CAPid

- CAP 크기: PCAP(우선 순위 CAP), 21셀 또는 14셀 9740(표준 CAP), 40셀(향상된 CAP), 20셀(9360 CAP), 30셀(9360 선택적 CAP), 36셀 대량 CAP(SL8500) 또는 39셀(SL8500 CAP)

- CAP를 소유한 호스트의 호스트 ID

- 우선 순위: CAP 환경 설정 값

- CAP 모드: 청소, 비우기, 꺼내기, 넣기 또는 유휴

- CAP 상태: 활성, 자동 모드, 수동 모드, 오프라인, 온라인 및/또는 복구 필요

CAPPREF 명령을 통해 CAP 모드(수동 또는 자동) 및 선택에 대한 우선 순위(0-9 중 9가 우선 순위가 가장 높음)를 설정할 수 있습니다. 수동 모드 CAP의 경우 ENTER 명령을 사용하여 잠금을 해제해야 합니다. 자동 모드 CAP의 경우 이 작업이 필요하지 않습니다. 일반적으로 CAP 모드 및 우선 순위는 HSC PARMLIB 멤버의 구성 시 CAPPREF 명령에서 지정되며 해당 설정으로 실행됩니다. CAP 설정을 변경해야 하는 경우 CAPPREF 명령을 입력하여 동적으로 변경할 수 있습니다. 예를 들어, 시스템에 높은 레벨의 넣기 및 꺼내기가 발생하는 경우 향상된 CAP에 대한 CAP 우선 순위를 높일 수 있습니다. CAP 우선 순위를 설정할 때는 PCAP(우선 순위 CAP)가 사용 가능한 상태로 유지되도록 PCAP의 우선 순위가 항상 0(특별히 요청되지 않은 경우 선택되지 않음)이어야 합니다.

수동 RTD 정의

DR 상황에서는 자동화된 테이프 리소스를 사용하지 못할 수 있습니다. 비라이브러리 VSM 구성을 지원하려면 존재하지 않는 ACS에서 수동 RTD를 정의해야 합니다.

수동 RTD를 정의하려면 다음과 같이 하십시오.

1. LIBGEN 매크로를 생성하여 존재하지 않는 ACS를 정의합니다.
SLIDRIVS 매크로는 수동 RTD에 대한 장치 주소를 정의합니다.

주:
존재하지 않는 ACS의 LSM을 SL8500 또는 SL3000으로 정의하여 MODIFY CONFIG 명령을 활용할 수 있습니다.

2. SLICREAT 유틸리티를 실행하여 새 CDS의 형식을 지정합니다.

3. SET SLIDRIVS 유틸리티를 실행하여 수동 RTD에 대한 MODEL을 설정합니다.
SET SLIDRIVS(400,401,402,403) MODEL(T9840C)을 예로 들 수 있습니다.

주:
동일한 패널의 수동 RTD는 동일한 드라이브 유형이어야 합니다.

4. VTCS CONFIG 유틸리티를 실행하여 VSM 시스템을 정의합니다.

5. VTCS IMPORT 유틸리티를 사용하여 수동 RTD에서 사용할 CDS로 MVC를 가져옵니다.
해당 MVC는 비라이브러리 볼륨으로 간주됩니다.

테이프 데이터 보호

이 절에서는 실제 테이프 볼륨과 가상 테이프 볼륨에서 데이터 덮어쓰기를 방지하는 데 사용할 수 있는 ELS 기능에 대해 설명합니다.

고유 테이프 데이터 보호

테이프에 상주하는 데이터용으로 다시 쓰기가 가능하지 않은 보호 솔루션을 제공하는 VOLSAFE 보안 매체 기술과 함께 Oracle/StorageTek T9840, T9940B 및 T10000 테이프 카트리지를 주문할 수 있습니다. VOLSAFE 카트리지는 WORM(Write Once Read Many) 카트리지라고도 합니다.

VOLSAFE 보안 매체에 데이터를 쓴 후 추가는 가능하지만 수정 또는 삭제는 불가능합니다. 이러한 카트리지에는 비VOLSAFE 카트리지와의 구분을 위해 물리적, 시각적 및 전자적 기능이 포함되어 있습니다.

VTV 데이터 보호

이제 VSM 시스템은 VTV에 대한 VOLSAFE 보호를 제공합니다. VTV가 비스크래치인 경우 마운트된 항목을 스크래치하고 이 속성을 유지하면 VTV에 보호 속성이 지정됩니다. VOLSAFE 보호 VTV를 스크래치하려면 TAPEVOL 클래스에 대해 RACF ALTER 권한이 필요합니다.

VTCS는 다음과 같이 VTV VOLSAFE 정책을 지정하는 MGMTclas WRITE 매개변수를 통해 이 보호를 가능하게 해줍니다.

MANY

VOLSAFE 쓰기 보호가 없도록 지정합니다(기본값).

ONCE

읽기 전용 보호를 제공합니다. 비스크래치인 경우 VTV를 수정할 수 없습니다.

MVC 데이터 보호

HSC는 MVC를 스크래치로 표시할 수 있도록 허용하지 않지만 다음과 같은 다른 방법으로 MVC 데이터를 보호하는 것이 좋습니다.

- HSC 작업만 MVC 볼륨에 쓸 수 있도록 RACF 권한을 설정합니다.

- MVCMAINT 유틸리티를 사용하여 MVC를 읽기 전용으로 설정합니다.

- VOLSAFE 보호 매체를 MVC로 사용합니다. 고유 테이프와 마찬가지로 VOLSAFE 보안 MVC에 데이터를 쓴 후 추가는 가능하지만 수정 또는 삭제는 불가능합니다.

- 풀에 대한 공간 확보를 방지하기 위해 VOLSAFE 볼륨이 포함된 MVC 풀에 대해 POOLPARM MVC NORECLAM 매개변수를 지정합니다. 그러면 쓰기 가능한 EOT 위치가 보장됩니다.

- VOLSAFE MVC에 대한 모든 VTV 회수 처리는 영향을 받지 않습니다.

라이브러리 볼륨 관리

라이브러리 볼륨을 관리할 때는 시작 작업인 볼륨 보고서 사용부터 청소 카트리지 관리까지 광범위한 작업이 수행됩니다.

볼륨 보고서 사용

VOLRPT 유틸리티는 라이브러리에서 물리적 볼륨을 관리하는 데 유용한 볼륨 정보를 제공합니다. VOLRPT 유틸리티 함수는 Unified User Interface를 사용하므로 텍스트, XML 또는 CSV(콤마로 구분된 값)를 출력 형식으로 제공합니다. XML 및 CSV 형식 요청 방법에 대한 자세한 내용과 출력 설명, 명령 구문 세부정보는 ELS Command, Control Statement, and Utility Reference 및 ELS Programming Reference를 참조하십시오.

다음 절에서 설명되는 것과 같이 주기적으로 VOLRPT를 실행하여 볼륨 예외 상태를 표시하고 해결할 수도 있고 볼륨 상태를 표시하기만 할 수도 있습니다.

- 문제 볼륨 및 선택된 볼륨

- 일치하지 않는 VOLPARM과 외부 레이블 상태

- 볼륨이 VOLPARM에 포함되지 않음

- 스크래치 하위 풀 관리

- "청소 카트리지 관리"

VOLRPT는 여러 가지 다른 용도로 사용됩니다. 볼륨을 선택하고 VOLRPT 출력을 정렬하는 다른 방법은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

문제 볼륨 및 선택된 볼륨

샘플 VOLRPT 제어 카드:

VOLRPT SORT(LOC) INCLUDE(SEL,ERR)

이 요청은 위치 시퀀스에 있는 모든 문제 카트리지와 선택된 카트리지에 대한 보고서를 생성합니다.

일반적으로 "selected" 상태는 일시적이며 특정 위치에서 다른 위치로 이동되고 있거나 스크래치되고 있는 카트리지를 나타냅니다. 보고서의 각 "selected" 볼륨에 대해 DISPLAY VOLUME 콘솔 명령을 실행하여 볼륨의 선택이 취소되었는지 여부를 확인해야 합니다. 볼륨이 선택된 채로 유지된 경우 볼륨이 선택된 동안 호스트가 비정상적으로 종료되었음을 나타내는 것일 수 있습니다. 현재 볼륨이 사용되고 있지 않을 경우 UNSELECT 유틸리티를 실행하여 selected 상태를 재설정할 수 있습니다.

문제 볼륨은 마지막으로 알려진 위치에 없는 볼륨입니다. 문제 볼륨을 꺼내거나 마운트하려고 시도하면 HSC가 홈 셀, 마지막으로 알려진 소스 위치 및 마지막으로 알려진 대상 위치에서 볼륨을 확인합니다. 해당 위치에 볼륨이 없을 경우 ACS 감사를 실행하여 볼륨을 찾아야 할 수도 있습니다.

일치하지 않는 VOLPARM과 외부 레이블 상태

샘플 VOLRPT 제어 카드:

VOLRPT INCLUDE(NONMEDEQ)

이 요청은 카트리지의 매체 레이블이 VOLPARM 매체 유형과 일치하지 않는 모든 볼륨에 대한 보고서를 생성합니다.

매체 앞의 문자는 감지된 불일치 유형을 나타냅니다. '*' 문자는 레이블이 VOLPARM 매체 코드와 일치하지 않음을 의미합니다. '-' 문자는 볼륨과 일치하는 VOLPARM이 없음을 의미합니다. 해당 볼륨의 스크래치 하위 풀은 '*NON-VOLPARM*'입니다. '@' 문자는 볼륨에 물리적 매체 레이블이 없음을 의미합니다.

이 명령의 샘플 출력은 그림 3-2에 표시됩니다.

그림 3-2 볼륨 보고서(일치하지 않는 VOLPARM과 외부 레이블)

볼륨이 VOLPARM에 포함되지 않음

하위 풀 합계를 통해 *NON-VOLPARM* 풀의 볼륨만 표시되는 경우 해당 볼륨에 대한 자세한 목록을 확인하고자 할 수 있습니다. 해당 볼륨을 선택할 수 있는 특별한 제어 카드는 없지만 INCLUDE(NONMEDEQ)를 사용할 수 있습니다. VOLPARM 매체가 볼륨 레이블의 매체와 일치하지 않는 볼륨도 표시됩니다.

스크래치 하위 풀 관리

명령을 실행하여 개별 볼륨을 나열하지 않고 하위 풀, 라이브러리 위치 및 매체 유형별로 하위 풀 합계를 보여주는 보고서를 얻을 수 있습니다.

VOLRPT SUMM(SUBPOOL) NOVOL

이 명령의 샘플 출력은 그림 3-3에 표시됩니다.

그림 3-3 볼륨 보고서(스크래치 하위 풀)

VOLRPT를 사용하여 청소 카트리지 사용 추적

다음 명령을 사용하여 청소 카트리지만 포함하며 사용 횟수를 기준으로 정렬된 보고서를 생성할 수 있습니다.

VOLRPT VOL(CLN%%%) SORT(USE) DESCEND

샘플 출력은 그림 3-4에 표시됩니다.

그림 3-4 볼륨 보고서(청소 카트리지)

청소 사용 횟수는 실제로 맨 오른쪽에 있는 "Times Selected" 레이블의 필드입니다. 보고서 가운데에 있는 "Cln Use" 레이블의 필드는 클리너 과용 시 Y를 나타냅니다.

마운트 성능 최적화

"최적의 마운트 성능"은 실제 테이프 볼륨의 마운트 및 마운트 해제 속도로 측정됩니다. 최상의 도구는 SMF 레코드에서 데이터를 가져오고 ACS 및 LSM에서 마운트/마운트 해제 작업의 균형을 맞추는 데 유용한 정보를 제공하는 작업 보고서입니다. 이 보고서는 다음과 같이 분류된 총 마운트 및 마운트 해제 작업을 보여줍니다.

- 스크래치 마운트/총 마운트 및 마운트당 평균 시간

- 비스크래치 마운트/총 마운트 및 마운트당 평균 시간

- 다른 LSM의 스크래치 마운트/총 마운트, 마운트당 평균 시간 및 평균 통과 수

- 다른 LSM의 비스크래치 마운트/총 마운트, 마운트당 평균 시간 및 평균 통과 수

스크래치 마운트로 인해 작업 보고서가 성능 문제를 다루지 않는 경우 HSC 스크래치 재분배 유틸리티 또는 LCM을 사용하여 특정 ACS 내 LSM에서 스크래치 볼륨을 재분배할 수 있습니다. 스크래치 볼륨이 부족한 경우 스크래치 볼륨과 최신이 아닌 데이터에 대해 스크래치 동기화를 실행하거나 ACS에 더 많은 스크래치 볼륨을 넣을 수 있습니다. 통과 작업이 과도하거나 비스크래치 볼륨에 대한 마운트 시간이 오래 걸리는 경우 LCM을 사용하여 비스크래치 볼륨을 재분배할 수 있습니다.

볼륨 액세스 보안 사용

HSC 볼륨 액세스 사용자 종료(SLSUX14)는 볼륨이 있는지 확인하는 보안입니다. SLSUX14가 사용으로 설정되면 마운트, 꺼내기 및 스크래치 요청에 대해 볼륨이 있는지 확인하는 보안이 수행됩니다. LibraryStation set_scratch 요청에 대해서는 볼륨 액세스 사용자 종료가 호출되지 않습니다.

프로그래밍 세부정보는 ELS Programming Reference, Volume Access User Exit(SLSUX14)를 참조하십시오.

SLSUX14를 통해 요청을 완료하거나 거부할 수 있습니다. SLSUX14에서 코딩은 RACROUTE 매크로를 실행하거나 다른 방법으로 요청을 계속 진행할지 아니면 거부할지 결정할 수 있습니다. 또는 SLSUX14를 통해 HSC가 RACROUTE 및 RACF 정의를 사용하여 요청 성공/거부를 결정하는 보안 검사를 수행하도록 지정할 수도 있습니다. 특정 SLSUX14 반환 코드는 TAPEVOL 클래스가 볼륨 액세스 검사에 사용되도록 지정합니다. 다른 SLSUX14 반환 코드는 사용자 종료가 볼륨 액세스 검사에 사용할 RACF 클래스를 매개변수 목록에 배치하도록 지정합니다. 그러면 HSC는 볼륨 보안 검사에 RACF 클래스를 사용합니다.

RACF 속성

HSC가 RACROUTE 매크로를 수행할 때 요청이 성공하려면 다음 볼륨 요청을 실행하는 사용자에게 다른 RACF 권한이 필요합니다.

- MOUNT – RACF UPDATE 권한은 마운트를 계속 진행할 수 있도록 허용합니다.

- MOUNT – RACF READ 권한은 마운트를 계속 진행할 수 있도록 허용합니다. 볼륨이 쓰기 보호 상태로 마운트됩니다.

- EJECT – 꺼내기 요청의 경우 사용자에게 RACF UPDATE 권한이 필요합니다.

- SCRATCH – 스크래치 요청의 경우 사용자에게 RACF CONTROL 권한이 필요합니다.

다음은 RACF 권한 설정 명령의 예를 보여줍니다.

RDEFINE TAPEVOL 111111 UACC(NONE)
PERMIT 111111 CLASS(TAPEVOL) ID(USER1) ACCESS(READ)
PERMIT 111111 CLASS(TAPEVOL) ID(USER2) ACCESS(UPDATE)
PERMIT 111111 CLASS(TAPEVOL) ID(USER3) ACCESS(CONTROL)

이 예에서 알 수 있듯이 USER1은 읽기 액세스(쓰기 보호)를 위해 볼륨 111111을 마운트할 수 있습니다. USER2는 쓰기 액세스를 위해 볼륨 111111을 마운트할 수 있습니다. 기타 모든 사용자의 경우 111111에 대한 마운트 요청이 거부됩니다. USER3은 스크래치 요청을 수행할 수 있습니다.

WORM(Write Once/Read Many) 지원

WORM 시나리오를 지원하려는 경우 다음 예에서 설정된 업데이트된 명령에서와 같이 SLSUX14를 사용하여 "never scratch" 정책을 적용할 수 있습니다.

RDEFINE TAPEVOL 111111 UACC(NONE)
PERMIT 111111 CLASS(TAPEVOL) ID(USER1) ACCESS(READ)
PERMIT 111111 CLASS(TAPEVOL) ID(USER2) ACCESS(UPDATE)

이 예에서 USER3은 볼륨 111111에 대해 더 이상 CONTROL 액세스 권한을 갖지 않습니다. 따라서 RACF 구성을 정의하고 CONTROL 권한을 얻은 사용자를 제외한 모든 사용자의 볼륨 111111에 대한 SCRATCH 요청은 거부됩니다.

주:
LibraryStation set_scratch 요청에 대해서는 UX14가 호출되지 않습니다. LibraryStation set_scratch 요청의 경우 LSINIT 명령의 LibraryStation VOLAUTH 및 VOLACC 매개변수를 통해 볼륨 액세스 보안이 제어됩니다.

스크래치 볼륨 관리

기본적으로 스크래치 볼륨 관리는 과하지 않을 정도의 충분한 스크래치 볼륨을 올바른 위치(충분한 드라이브 유형이 볼륨 매체와 호환되는 LSM이 권장됨)에 지정하는 것입니다. 테이블 3-1에서는 스크래치 볼륨 관리 작업 및 연관된 도구에 대해 설명합니다.

테이블 3-1 스크래치 볼륨 관리 작업 및 도구

작업

도구

참고 사항

충분한 스크래치 카트리지 수량 유지 관리

- Warn 명령 - 스크래치 경고 임계값을 설정합니다.

- Display THReshld 명령 - 하위 풀 이름, ACS ID, LSM ID, 매체 및 기록 기술별로 스크래치 수 및 스크래치 임계값 정보를 표시합니다.

일반적으로

Warn 명령을 사용하여 스크래치 경고 임계값을 설정하고 Display THReshld 명령을 사용하여 스크래치 볼륨 레벨과 임계값을 모니터합니다.

스크래치 볼륨이 부족한 경우 먼저 스크래치 동기화를 실행하고 스크래치 볼륨을 재분배한 후 더 많은 스크래치 볼륨을 추가합니다. 자세한 내용은 "스크래치 볼륨 추가"를 참조하십시오.

CDS 스크래치 상태와 TMS 상태 동기화

- SMC 테이프 관리 추출 유틸리티(SMCUDBX)가 사용되는 클라이언트/서버 구성용 HSC SLUCONDB 스크래치 변환 유틸리티

또는

- LCM OPTIONS SYNC 매개변수 프로세스

앞서 설명된 대로 스크래치 동기화는 스크래치 볼륨을 해제할 수 있습니다. 일반적으로 일별 TMS 실행 후 스크래치 동기화를 수행합니다.

스크래치 볼륨 재분배

HSC 스크래치 재분배 유틸리티 또는 LCM을 사용하여 특정 ACS 내 LSM에서 스크래치 볼륨 재분배

"마운트 성능 최적화"에 설명된 대로 스크래치 분배가 잘못되면 라이브러리 성능이 최적화될 수 없습니다. 스크래치 재분배는 ACS 내 지정된 LSM 간에 스크래치 볼륨 수의 균형을 조정하며 하위 풀에 의해 수행될 수 있습니다.

특정 볼륨 스크래치

- HSC SCRAtch 명령을 통해 하나 이상의 볼륨 스크래치

- HSC UNSCratch 명령을 통해 하나 이상의 볼륨에 대한 스크래치 해제

명령에 대한 권한이 부여된 경우 실제로 특정 볼륨을 스크래치하고 스크래치를 해제할 수 있습니다. 하지만 일반적으로 수행 중인 작업에 대해 잘 모를 경우 명시적으로 특정 볼륨을 스크래치하지 마십시오. TMS가 볼륨 스크래치 상태를 관리하고 스크래치 동기화를 수행하도록 하십시오.

스크래치 하위 풀 정보 표시

Display SCRatch

명령이 실행된 호스트에 대해서만 스크래치 하위 풀 정보를 표시합니다. 모든 스크래치 하위 풀 정보를 표시하려면 VOLRPT 유틸리티를 사용합니다.

스크래치 볼륨 추가

라이브러리에 스크래치 볼륨을 추가하는 것은 다음과 같은 두 가지 경우로 구분되는 일반적인 작업입니다.

- 새 LSM 채우기

- 기존 LSM에 볼륨 추가

두 가지 경우에서 먼저 "니어라인 볼륨 정의"에 설명된 대로 새 볼륨에 대한 POOLPARM 및 VOLPARM 정의를 만들어야 합니다.

니어라인 볼륨 정의

니어라인 볼륨을 정의하려면 다음과 같이 하십시오.

1. POOLPARM 문을 만들어 볼륨 스크래치 풀을 정의합니다.
예를 들어, 호스트 MVS1 및 MVS2용 스크래치 풀을 정의하려면 다음 명령을 사용합니다.

POOLPARM NAME(SYS19840P22)TYPE(SCRATCH)HOSTID(MVS1,MVS2)LABEL(SL

2. VOLPARM 문을 만들어 볼륨을 정의합니다.
예를 들어, 9840C 볼륨 범위를 정의하려면 다음 명령을 사용합니다.

VOLPARM VOLSER(C2000-C2999)MEDIA(STK1R)RECTECH(STK1RC)

3. SET VOLPARM 명령을 입력하여 볼륨 정의를 적용합니다.

SET VOLPARM APPLY(YES)

새 LSM 채우기

POOLPARM 및 VOLPARM 정의를 완료한 후 새 LSM을 채우려면 다음 방법 중 하나를 사용하십시오.

- 하나 이상의 CAP를 자동 모드로 설정하고 반복적으로 CAP를 열어 새 카트리지로 채웁니다.

- LSM이 비스트림라인 라이브러리이며 작업자가 들어가기에 충분한 경우 다음 작업을 수행합니다.

1. LSM 액세스 도어를 엽니다.

2. 수동으로 카트리지를 LSM의 스토리지 셀에 넣습니다.

3. 액세스 도어를 닫고 잠급니다.

4. LSM에 대해 HSC 감사를 실행합니다.
전체 LSM 감사는 오래 걸릴 수 있지만 CAP를 통해 카트리지를 넣을 수 있으므로 사용자가 보다 빠른 방법을 결정해야 합니다.

기존 LSM에 볼륨 추가

POOLPARM 및 VOLPARM 정의를 완료한 후 "카트리지 넣기"에 설명된 대로 카트리지를 넣으십시오.

카트리지 넣기

카트리지는 ACS에 넣을 때까지는 단순한 카트리지이지만 CDS에서는 볼륨이 됩니다. 스크래치 카트리지, 비스크래치 카트리지, MVC로 사용할 카트리지 또는 청소 카트리지를 넣을 수 있습니다.

카트리지를 넣으려면 다음과 같이 하십시오.

1. 카트리지를 넣을 LSM이 온라인인지 확인합니다.
예를 들어, LSM 00:00의 상태를 확인하려면 다음 명령을 사용합니다.

DISPLAY LSM 00:00

SLS0054I 메시지 "현재 LSM 00:00 온라인"은 확인을 성공했음을 나타냅니다. 그렇지 않은 경우 문제를 파악하고 최소한 MODIFY LSM aa:cc ONLINE 명령을 입력하여 온라인으로 되돌립니다.

2. CAP 모드를 확인합니다.

예를 들어, LSM 00:00의 PCAP 상태를 확인하려면 다음 명령을 사용합니다.

DISPLAY CAP 00:00:02

CAP 모드가 자동인 경우 단계 4를 수행합니다. 그렇지 않은 경우 계속해서 단계 3을 수행합니다.

3. CAP 모드가 수동인 경우 사이트의 관행에 따라 두 가지 중 하나를 선택할 수 있습니다.

- CAP 모드를 자동으로 변경합니다.
예를 들어, 2단계의 PCAP에 대해 CAP 우선 순위를 0(PCAP에 항상 필요)으로 설정하고 모드를 자동으로 설정합니다.

CAPPREF 0 00:00:02 AUTO

- ENTER를 사용하여 CAP가 카트리지를 넣을 수 있는 상태로 준비되도록 설정합니다. 이때 모드는 수동으로 유지합니다.
예를 들어, 2단계의 PCAP에 대해 CAP가 카트리지를 넣을 수 있는 상태로 준비되도록 설정하고 넣은 카트리지에 대한 스크래치 상태 on을 설정합니다.

ENTER 00:00:02 SCRATCH

주:
현재 모든 CAP가 꺼내기에 사용되고 있는 경우 SENter 명령을 사용하여 카트리지를 넣을 CAP를 예약할 수 있습니다.

4. 사용 중인 LSM 유형에 맞는 운영자 설명서에 설명된 대로 카트리지를 넣습니다.

볼륨 꺼내기

다음 절에 설명된 대로 볼륨을 꺼내려는 이유는 기본적으로 세 가지입니다.

- 스크래치 볼륨을 너무 많이 정의했으며 일시적으로 특정 볼륨에 대한 공간이 필요합니다. "스크래치 볼륨 꺼내기"를 참조하십시오.

- 더 이상 사용되지 않는 특정 볼륨이 있어 원격 보관하려고 합니다. 자세한 내용은 ELS Disaster Recovery and Offsite Data Management Guide를 참조하십시오.

- 매체 보증 수명이 곧 만료되는 특정 9x40 또는 T10000 볼륨이 있습니다. 그림 3-2는 맨 오른쪽에 있는 %MWL 열을 사용하여 볼륨 보고서를 보여줍니다. 이 열은 볼륨에 사용된 매체 보증 수명의 백분율을 보여줍니다. 여기서 %100은 볼륨이 매체 보증 수명을 초과했음을 의미합니다.

주:
9x40 또는 T10000 볼륨의 경우 MIR(매체 정보 레코드)에 수명 중 카트리지가 마운트된 횟수가 저장됩니다. 마운트 해제 처리 중 HSC는 MIR에서 읽은 마운트 횟수 값을 사용하여 %MWL 계산을 수행합니다. HSC가 라이브러리 상주 볼륨에 대한 MWL% 보고를 수행하려면 라이브러리에 추가된 후 볼륨이 한 번 이상 마운트 및 마운트 해제되었어야 합니다. 볼륨을 꺼낸 경우 연관된 CDS VAR 레코드가 삭제되고 HSC는 볼륨이 라이브러리 외부에 있는 동안 더 이상 해당 볼륨에 대한 MWL% 보고를 수행할 수 없습니다. 하지만 마운트 횟수는 MIR에서 유지 관리되며 다음 번에 볼륨을 라이브러리에 넣고 한 번 이상 마운트 및 마운트 해제할 경우 HSC는 볼륨이 라이브러리에 상주하는 동안 해당 볼륨에 대한 MWL% 보고를 다시 수행할 수 있습니다.
전송에서 MIR을 읽거나 쓸 수 없을 경우 드라이브는 볼륨의 어느 곳에서나 새 MIR을 다시 초기화할 수 있습니다. MIR을 처리하는 동안에는 오류가 거의 발생하지 않으며, 드라이브가 새 MIR을 재구성해야 하는 경우 이 작업을 수행하기는 하지만 드라이브가 실패한 MIR의 마운트 횟수를 교체용 MIR로 전송하지 못할 수도 있습니다. 이 경우 드라이브는 교체용 MIR에서 마운트 횟수를 0으로 초기화합니다. 볼륨 보고서에서 MWL% 모니터 등을 통해 볼륨에 대해 0이 아닌 마운트 횟수가 0으로 바뀐 것으로 확인되면 이 볼륨에서 SYSLOG를 검사하여 데이터를 확인하고 테이프 드라이브를 검사해야 하며 이 볼륨을 회수하는 것이 좋습니다.

매체 보증 수명 기능에 필요한 항목은 다음과 같습니다.

- 테이프 라이브러리 LMU 호환성 레벨 21

- 1.42 드라이브 펌웨어가 사용되는 T9x40 전송

주:
메모리 제약 조건으로 인해 T9840B는 지원되지 않습니다.

- 1.38 드라이브 펌웨어가 사용되는 T10000A 및 T10000B

- PTF SES700 L1H154V

- 유효 수명을 초과한 청소 카트리지가 있어 교체해야 합니다. "수동으로 사용된 청소 카트리지 꺼내기"를 참조하십시오.

스크래치 볼륨 꺼내기

스크래치 볼륨을 꺼내려면 다음과 같이 하십시오.

1. 볼륨을 꺼낼 LSM이 온라인인지 확인합니다.
예를 들어, LSM 00:00의 상태를 확인하려면 다음 명령을 사용합니다.

DISPLAY LSM 00:00

SLS0054I 메시지 "현재 LSM 00:00 온라인"은 확인을 성공했음을 나타냅니다. 그렇지 않은 경우 문제를 파악하고 최소한 MODIFY LSM aa:cc ONLINE 명령을 입력하여 온라인으로 되돌립니다.

2. EJECT를 사용하여 꺼내기 작업을 시작합니다.
예를 들어, 풀 SYS19840P1에서 매체 STK1R 및 rectech STK1RC가 포함된 100개의 스크래치 볼륨을 꺼내려면 다음 명령을 사용합니다.

EJECT SCRTCH SUBPOOL(SYS19840P1)VOLCNT(100) MEDIA(STK1R) RECTECH(STK1RC)

WAITCAP(YES)가 기본값입니다.

3. CAP를 비우도록 운영자 메시지를 받은 경우 CAP에서 볼륨을 제거합니다.

청소 카트리지 관리

ELS를 구성할 때 충분한 청소 카트리지를 정의했어야 합니다. 그렇지 않은 경우 Configuring HSC and VTCS에서 방법을 확인하십시오. 청소 카트리지를 정의한 후 "카트리지 넣기"에 설명된 대로 청소 카트리지를 넣으십시오. 청소 카트리지 관리를 위해 (PARMLIB 멤버 또는 명령을 통해) MNTD로 수행할 수 있는 몇 가지 추가 작업이 있습니다.

주:
HSC가 청소 카트리지를 관리하도록 하려면 청소 카트리지에 접두어 CLN과 3자리 숫자로 구성된 외부 레이블이 부착되어 있어야 합니다. 하지만 일부 LTO 카트리지의 외부 레이블은 이 형식을 따르지 않습니다. 이 경우 오라클 담당자에게 LTO 청소 카트리지에 대한 외부 레이블을 얻는 방법을 문의하십시오.

청소 카트리지 선택

드라이브를 청소해야 할 때 자동으로 청소 카트리지가 선택되도록 하려면 "auto clean" 옵션 on을 설정하십시오.

MNTD AUTOCLN(ON)

드라이브 청소 프로세스가 청소해야 할 드라이브에 가장 가까운 LSM에서 청소 카트리지를 선택합니다. 청소 작업이 완료되면 "float" 옵션에 따라 카트리지가 홈 셀로 반환될지(float off) 아니면 현재 LSM의 새 홈 셀에 지정될지 결정됩니다(float on). float on을 설정하면 통과 작업이 줄어들게 되므로 성능이 향상됩니다.

MNTD FLOAT(ON)

청소 카트리지 꺼내기

POOLPARM MAXCLEAN 매개변수는 지정된 청소 카트리지 세트에 대한 최대 청소 작업 수를 지정합니다. ELS가 MAXCLEAN 값을 초과한 청소 카트리지를 자동으로 꺼내도록 하려면 다음 명령을 입력하십시오.

MNTD EJCTAUTO(ON)

ExLM을 실행 중인 경우 ExLM이 일정에 따라 청소 카트리지 꺼내기를 관리하도록 하는 것이 좋습니다. 이 경우 "auto eject" off를 설정하십시오. 이는 "lights-out" 데이터 센터에 매우 유용합니다.

ExLM이 없을 경우 자동 꺼내기 기술이 권장됩니다. 그렇지 않으면 CLEAN 명령을 사용하여 수동으로 청소를 예약하고 "수동으로 사용된 청소 카트리지 꺼내기"에 설명된 대로 카트리지가 모두 사용된 경우 수동으로 카트리지를 꺼내야 합니다. 자동 꺼내기의 경우 사용 가능한 CAP가 필요합니다. CAP를 사용할 수 없을 경우 수동 꺼내기를 수행해야 합니다.

최신 드라이브는 사용된 청소 카트리지를 식별하고 MAXCLEAN 사용 횟수에 관계없이 ELS에 통지합니다. "auto eject"가 on인 경우 라이브러리가 "spent" 조건을 감지할 때 카트리지가 배출됩니다. 그렇지 않은 경우 ExLM을 사용하여 "spent" 청소 카트리지 꺼내기를 예약할 수 있습니다.

청소 카트리지를 꺼낸 후에는 일반적으로 새 카트리지를 넣어 사용한 카트리지를 교체합니다. volser가 ELS에 정의되지 않은 청소 카트리지를 넣으려는 경우 Configuring HSC and VTCS에서 청소 카트리지 정의에 대한 자세한 내용을 참조하십시오.

수동으로 사용된 청소 카트리지 꺼내기

사용된 청소 카트리지를 교체하려면 다음과 같이 하십시오.

1. 카트리지를 꺼낼 LSM이 온라인인지 확인합니다.
예를 들어, LSM 00:00의 상태를 확인하려면 다음 명령을 사용합니다.

DISPLAY LSM 00:00

SLS0054I 메시지 "현재 LSM 00:00 온라인"은 확인을 성공했음을 나타냅니다. 그렇지 않은 경우 문제를 파악하고 최소한 MODIFY LSM aa:cc ONLINE 명령을 입력하여 온라인으로 되돌립니다.

2. EJECT를 사용하여 꺼내기 작업을 시작합니다.
예를 들어, 9840 청소 카트리지 범위를 꺼내려면 다음 명령을 사용합니다.

EJECT (CLN300-CLN310) SEQ(YES)

WAITCAP(YES)가 기본값이며 볼륨이 순서대로 CAP에 지정됩니다.

3. CAP를 비우도록 운영자 메시지를 받은 경우 CAP에서 청소 카트리지를 제거합니다.

4. 교체용 청소 카트리지를 넣을 CAP의 CAP 모드를 확인합니다.

예를 들어, LSM 00:00의 PCAP 상태를 확인하려면 다음 명령을 사용합니다.

DISPLAY CAP 00:00:02

5. CAP 모드가 수동인 경우 사이트의 관행에 따라 두 가지 중 하나를 선택할 수 있습니다.

- CAP 모드를 자동으로 변경합니다.
예를 들어, 단계 4의 PCAP에 대해 CAP 우선 순위를 0(PCAP에 항상 필요)으로 설정하고 모드를 자동으로 설정합니다.

CAPPREF 0 00:00:02 AUTO

- ENTER를 사용하여 CAP가 카트리지를 넣을 수 있는 상태로 준비되도록 설정합니다. 이때 모드는 수동으로 유지합니다.
예를 들어, 단계 4의 PCAP에 대해 CAP가 카트리지를 넣을 수 있는 상태로 준비되도록 설정하고 넣은 카트리지에 대한 스크래치 상태 on을 설정합니다.

ENTER 00:00:02 SCRATCH

문제 해결

다음 절에서는 발생 가능한 문제에 대한 해결책을 제공합니다.

문제 카트리지 복구

HSC가 LSM에서의 볼륨 위치를 제대로 확인하지 못할 경우 카트리지가 문제 상태로 설정됩니다. 다음과 같은 경우 카트리지가 문제 상태로 설정될 가능성이 있습니다.

- 운영자가 FORCE 옵션을 사용하여 LSM을 오프라인으로 수정합니다.

- 볼륨이 CDS를 통해 지정된 셀 위치에 없습니다.

- LMU에 복구할 수 없는 오류가 발생합니다.

- LSM에 복구할 수 없는 오류가 발생합니다.

다음과 같은 경우 문제 볼륨 복구가 자동으로 수행됩니다.

- HSC가 문제 상태로 표시된 카트리지를 사용하려고 시도하는 경우

- ACS가 연결된 경우

- LSM이 온라인으로 수정된 경우

- 호스트 간 복구가 수행된 경우

HSC가 다음 메시지를 발행합니다.

... Attempting to locate errant volume VVVVVV

원래 소스 위치 또는 대상 위치를 확인하여 카트리지를 찾은 경우 HSC가 카트리지를 문제 상태에서 제거합니다.

카트리지를 찾을 수 없는 경우 운영자에게 다음 메시지가 표시됩니다.

... Volume VVVVVV not found; Eject or Ignore (E|I)?

다음 중 하나로 응답하십시오.

- 카트리지가 라이브러리에 없는 것이 확실한 경우 "E"로 응답합니다. 그러면 CDS에서 카트리지가 삭제됩니다(논리적으로 배출됨).

- 카트리지 위치를 모를 경우 카트리지를 문제 상태로 유지하려면 "I"로 응답합니다. 수동으로 카트리지를 찾는 데 필요한 경우 유용할 수 있는 감사 추적이 카트리지에 대해 유지 관리됩니다.
나중에 카트리지를 찾은 경우 HSC는 카트리지를 문제 상태로 인식하고 문제 상태에서 제거합니다. 카트리지가 홈 셀 위치로 반환되거나 요청을 위해 선택된 것으로 표시됩니다.

중복 VOLSER 및 읽을 수 없는 VOLSER 넣기

다음 절에서는 VOLSER 관련 문제에 대해 설명합니다.

중복 볼륨 넣기

이미 CDS에 기록된 볼륨을 넣으려고 시도하면 HSC가 홈 셀 위치 또는 대상 위치를 확인하여 원래 카트리지를 찾으려고 시도합니다. 볼륨이 발견되면 HSC가 중복 카트리지를 거부합니다.

볼륨을 찾을 수 없는 경우 HSC 응답은 OPTion ENTdup 명령 설정에 따라 결정됩니다.

- OPTion ENTdup가 Auto로 설정된 경우 HSC는 자동으로 CDS에서 원래 볼륨을 삭제하고 새 볼륨을 넣습니다.

- OPTion ENTdup가 Manual로 설정된 경우 HSC는 다음 메시지를 발행하여 운영자에게 지원을 요청합니다.

... ENTER of volume VVVVVV encountered missing duplicate volser;
(Logically) Delete, or Ignore (D,I)?

CDS에서 원래 볼륨을 삭제하고 새 볼륨을 넣으려면 "D"로 응답하십시오.

주:
명령 구문 및 매개변수에 대한 자세한 내용은 ELS Command, Control Statement, and Utility Reference의 OPTION 명령 및 제어문을 참조하십시오. 라이브러리가 분할되고 중복 볼륨을 다른 분할 영역에 넣은 경우 스트림라인 라이브러리에 중복 볼륨을 넣을 수 있습니다.

외부 레이블이 누락되거나 외부 레이블을 읽을 수 없는 카트리지 넣기

레이블을 읽을 수 없는 테이프 카트리지는 CAP를 통해 라이브러리에 넣을 수 없습니다. 레이블이 없거나 로봇이 읽을 수 없는 레이블이 있는 카트리지를 넣으려고 시도하면 다음 HSC 메시지가 발행됩니다.

... UnNamed Cartridge in CAP CELL AA:LL:RR:CC;
reply "V,volser" or "EJECT"

다음 중 하나를 수행합니다.

- VOLSER를 지정하여 카트리지를 넣으려면 "V,volser"로 응답합니다. 지정된 VOLSER는 영구적으로 CDS의 카트리지에 지정됩니다.

주:
레이블이 없는 카트리지 또는 레이블을 읽을 수 없는 카트리지를 수동으로 라이브러리에 넣으면 감사 중 배출됩니다. 오라클은 사용자가 모든 카트리지에 대한 외부 매체 레이블을 제공할 것을 권장합니다.

- CAP의 잠금이 해제된 경우 "EJECT"로 응답하고 CAP에서 카트리지를 제거합니다.

CAP에서 복구 상태 지우기

CAP 상태가 RECOVERY인 경우 다음 절차에 따라 강제로 CAP 복구를 수행하십시오.

주:
이 절차로 RECOVERY 상태가 지워지지 않을 경우 "할당된 CAP 해제"를 시도해 보십시오.

CAP의 RECOVERY 상태를 지우려면 다음과 같이 하십시오.

1. 다음 명령을 실행합니다.

ENTER capid

여기서 capid는 복구할 CAP입니다.

다음 동작이 발생합니다.

1. LSM 로봇이 CAP로 이동하고 CAP 카탈로그를 수행합니다.

2. CAP에서 카트리지가 감지되면 HSC가 운영자에게 카트리지를 제거하도록 알리는 메시지를 발행합니다.

3. HSC가 메시지를 발행합니다.

... Open CAPid AA:LL:CC for entering when unlocked

4. CAP ENTER 표시기가 켜지거나 디스플레이 패널에 Enter가 표시됩니다.

2. 해당 CAP에 대해 DRAin 명령을 실행합니다.
CAP가 잠기고 상태가 INACTIVE로 설정됩니다.

할당된 CAP 해제

주의:
이 절차는 CAP가 사용되고 있지 않은 경우에만 수행하십시오. 활성 명령 또는 유틸리티에서 CAP를 해제하면 예측할 수 없는 결과가 발생할 수 있습니다. 예를 들어, 다음과 같습니다.

- CAP 정리

- 문제 카트리지

- CAP에 남아 있지만 HSC에서 확인되지 않은 카트리지

활성 프로세스가 CAP를 사용 중인 동안 복구를 수행하지 않은 채로 호스트가 종료되면 CAP가 호스트에 할당된 상태로 유지되고 다른 모든 호스트에서 CAP를 사용할 수 없습니다. HSC가 해당 호스트에서 다시 시작되면 초기화 후 CAP를 해제합니다. 그렇지 않으면 연결된 호스트에서 다음 명령을 실행하여 CAP를 해제할 수 있습니다.

RELEASE capid

설명:

capid는 해제할 CAP를 지정합니다.

HSC가 CAP를 해제할 것인지 확인하는 메시지를 발행합니다.

- 해제를 취소하려면 "N"으로 응답합니다.

- 해제를 계속하려면 다음 작업을 수행합니다.

1. 육안으로 CAP를 검사하고 다른 호스트에서 Display Cap 명령을 실행하며 다른 담당자와 함께 점검하여 CAP가 사용되고 있지 않은지 확인합니다.

2. 메시지에 "Y"로 응답합니다.
CAP가 해제되었음을 알리는 확인 메시지가 표시됩니다.

호스트 간 통신 서비스 복원

COMMPath 명령 및 제어문을 통해 HSC 호스트 간의 계층형 통신 서비스를 정의할 수 있습니다. 이 유형의 서비스가 준비되면 HSC는 호스트가 현재 통신 경로를 통해 메시지를 보내려는 중 오류가 발생했음을 알리는 메시지를 수신한 경우 자동으로 경로 전환을 수행합니다. 정의된 경로에 따라 자동 전환은 동등한 경로 유형(특정 LMU 경로에서 다른 LMU로) 또는 보다 성능이 낮은 방법(예: VTAM에서 LMU로)으로 수행될 수 있습니다.

HSC는 두 호스트의 콘솔에 다음 메시지를 발행하여 전환이 발생할 때 이를 통지합니다.

... A communications path switched from XXXX1 to XXXX2; ...

설명:

XXXX1은 이전 통신 경로를 지정합니다.

XXXX2는 현재 통신 경로를 지정합니다.

메시지에서는 전환을 시작하거나 실패가 발생한 호스트도 식별합니다.

HSC가 하향 전환을 수행한 후에는 COMMPath 명령을 통해 상향 전환만 수행할 수 있습니다.

상향 전환을 수행하려면 다음과 같이 하십시오.

1. 전환을 발생시킨 문제를 찾아 해결합니다.

2. 명령을 실행하여 이전 통신 방법으로 돌아갑니다.

COMMPATH HOSTID(hostid) METHOD(method)

설명:

hostid는 명령으로 영향을 받는 호스트를 지정합니다.

method는 현재 방법으로 설정할 방법을 지정합니다.

가능한 손실된 마운트 요청 해결

마운트는 여러 가지 원인 중 하나로 손실될 수 있습니다.

- HSC가 활성 상태인 동안 SMC가 비활성 상태인 경우 MVS 및/또는 TMS 메시지를 가로채지 않습니다.

- SMC가 활성 상태인 동안 HSC가 비활성 상태인 경우 MVS 및/또는 TMS 메시지를 가로채지만 마운트 요청을 수신할 자동 라이브러리 제어 시스템이 없습니다.

- 하드웨어 LMU 오류가 발생할 수 있습니다.

일반적으로 이러한 문제를 해결하려면 SMC RESYNC 명령을 사용하여 손실된 마운트 요청을 모두 다시 진행합니다.

손실된 마운트 응답 해결(ORH)

응답이 LMU에서 수신되지 않아 HSC 대기열 중 하나에서 마운트 요청이 멈추는 경우도 있습니다. 이 경우 볼륨은 selected 상태로 유지되며 ORH(Overdue Response Handler)가 운영자에게 통지합니다.

Overdue Response Handler

30초마다 ORH는 모든 대기열에서 각 ACS를 검사하여 응답 대기 시간 간격이 만료되었으며 시퀀스 번호가 있는 요청을 식별합니다. 시간 간격이 만료되면 HSC가 메시지를 발행합니다.

... ORH interval expired: ...

그러면 ORH가 요청 유형 코드를 확인합니다. 마운트, 마운트 해제, 이동 및 스왑 이외의 모든 요청 유형 코드의 경우 ORH는 자동으로 3, 5, 10 또는 60분 증분 단위로 요청의 대기 시간을 연장하고 메시지를 발행합니다.

... ORH interval extended: ...

마운트, 마운트 해제, 이동 및 스왑에 운영자 응답 필요

마운트, 마운트 해제, 이동 및 스왑 요청의 경우 운영자에게 메시지가 표시됩니다.

... ORH: ABORT/EXTEND...

다음 중 하나로 응답하십시오.

- ABORT — 작동을 요청한 작업에 ORH가 요청을 비정상적으로 종료했음이 통지됩니다. 그러면 selected 상태에서 볼륨이 제거되고 필요에 따라 HSC Mount 또는 DISMount 명령을 실행하여 작업 이동을 계속할 수 있습니다. 전송 관련 실패의 경우 ABORT 응답을 사용해야 합니다. 통과 포트, SL8500 엘리베이터, 로봇 또는 전송 실패를 예로 들 수 있습니다.

- EXTEND — ORH가 요청에 10분 증분을 더 추가하고 현재와 동일한 대기열에 유지합니다. 요청할 수 있는 연장 횟수는 제한이 없습니다.

소프트웨어 진단 사용

어떤 문제는 직접 해결할 수 있는 범위를 벗어나므로 일반적으로 오라클 소프트웨어 지원 센터에 문의하게 됩니다. 그러면 테이블 3-2에 설명된 대로 하나 이상의 HSC 소프트웨어 진단 도구를 사용하도록 요청을 받을 수 있습니다.

테이블 3-2 HSC 소프트웨어 진단 도구

진단 도구

설명

GTF(Generalized Trace Facility) 추적(GTRACE)

GTF(Generalized Trace Facility)는 낮은 레벨의 과거 내역을 제공합니다. HSC는 작동 중 중요한 이벤트에 대한 GTRACE 요청을 실행합니다. HSC JCL 프로시저의 EXEC 문(PARM=)에서 FID(형식 ID) 및 EID(이벤트 ID)가 매개변수로 지정됩니다. 프로시저 예는 HSC Configuration Guide의 "Creating an HSC START Procedure"를 참조하십시오.

감독자 호출(SVC), 덤프(SDUMP) 및 비정상 종료(ABEND)

덤프

소프트웨어 실패 진단에 적절한 경우 SVC 및 ABEND 덤프가 수행됩니다. HSC JCL에서 SYSUDUMP, SYSMDUMP 또는 SYSABEND DD 문을 사용하지 마십시오. 이러한 ABEND 유형은 HSC 주소 공간에 대해 충분한 정보를 제공하지 않습니다.

ERDS(오류 기록 데이터 세트)

소프트웨어 실패가 해당 오류 기록 데이터 세트에 기록됩니다. MVS 루틴을 통해 4480 카트리지 부속 시스템 및 3278 터미널 부속 시스템 ERDS(오류 기록 데이터 세트) 레코드가 작성됩니다.

LIst 명령

LIst 명령을 사용하여 HSC 데이터 구조를 표시하고 HSC에 대한 진단 지원을 제공할 수 있습니다. 이 명령은 오라클 고객 지원 센터 담당자의 지시에 따라 사용하십시오.

Display 명령

Display 명령은 진단용으로 유용한 여러 가지 옵션을 제공합니다.

4 VTCS 대시보드 사용

”VTCS 대시보드 사용”은 기본적으로 MVC 및 VTC 보고서 검토에 대한 것입니다. 가상 테이프 구성의 기본과 부속 부분은 VTSS, VTD, VTV, RTD 및 MVC이므로 이 모두가 정상적으로 작동하는지 여부를 확인하는 것이 여러분이 수행하는 주요 일간 및 주간 업무라는 사실은 새삼스러운 일이 아닙니다.

가상 테이프 상태 확인(일간)

VTSS를 니어라인 ACS의 가상 상대로, VTD를 니어라인 실제 테이프 드라이브의 가상 상대로, VTV를 니어라인 볼륨의 가상 상대로 간주하면 모든 VTSS, VTD 및 VTV가 정상적으로 작동하는지 확인하는 것이 중요한 이유를 쉽게 알 수 있을 것입니다.

가상 테이프 상태를 확인하려면 다음과 같이 하십시오.

1. Display VTSS 명령을 입력합니다.

테이블 4-1과 유사한 결과가 표시됩니다.

테이블 4-1 Display VTSS의 출력 예 - 양호한 VTSS 상태

VTSS NAME

CAPACITY(MB)

DBU

HI AMT

LOW AMT

VTV COUNT

MX MT

MN MT

DEF ACS

AUTO MIG

STATE

HBVTSS16

56,209

55

80

60

2440

6

3

02

-

ONLINE

HBVTSS17

56,209

50

80

60

2180

6

3

02

-

ONLINE

HBVTSS18

56,209

52

80

60

2288

6

3

01

-

ONLINE

HBVTSS19

93,184

45

80

60

1900

6

3

01

-

ONLINE

테이블 4-1은 4개의 ”정상적으로 작동하는” VTSS의 상태를 보여줍니다.

- 우선 모든 VTSS가 온라인이며, 이는 일반적으로 적절한 상태입니다.

- LAMT는 모두 60이고 HAMT는 모두 80이며, 이는 VTSS 사용량 최적화 및 효과적인 자동 마이그레이션을 촉진하는 데 적절한 범위입니다.

- DBU는 모두 HAMT보다 낮은데 이는 자동 마이그레이션이 시작되기 전에 VTSS에서 증가할 공간이 여전히 있음을 의미합니다. 가상 테이프에 대한 투자를 최적화하기 위해 이러한 VTSS에 더 많은 작업 경로를 지정하는 것도 고려할 수 있습니다.

- 각 VTSS에 8개의 RTD가 연결되어 있다고 가정해 보겠습니다. MX MT(최대 마이그레이션 작업)는 6으로 설정되어 있고 MN MT(최소 마이그레이션 작업)은 3으로 설정되어 있는데 이는 적절한 설정입니다. 최대 6개는 2개의 RTD가 회수/확보를 위해 남아 있고, 최소 3개는 적은 수의 마이그레이션이 갑자기 시작될 경우에도 로드를 처리할 수 있는 작업 여유가 있도록 해줍니다.

Display VTSS가 별로 좋게 보이지 않는다면 어떻게 될까요? 아마도 테이블 4-2와 유사할 수 있습니다.

테이블 4-2 Display VTSS의 출력 예 - 주요 작동 문제가 있는 VTSS

VTSSNAME

CAPACITY(MB)

DBU

HI AMT

LOW AMT

VTV COUNT

MX MT

MN MT

DEF ACS

AUTO MIG

STATE

HBVTSS16

56,209

90

80

60

27,888

4

2

02

-

ONLINE

HBVTSS17

56,209

92

80

60

28,974

4

2

02

-

ONLINE

HBVTSS18

56,209

90

80

60

22,005

4

2

01

-

ONLINE

HBVTSS19

93,184

92

80

60

26,009

4

2

01

-

ONLINE

테이블 4-2는 몇 가지 주요 작동 문제가 있는 4개의 VTSS 상태를 보여줍니다.

- 적어도 모두 온라인입니다. 그렇지 않은 경우 오프라인이거나 유지 관리 모드가 되어야 하는 이유를 알지 못한다면 몇 가지 Vary VTSS 명령을 입력하여 온라인으로 전환합니다.

- DBU가 모두 너무 높습니다. 90이 넘는 범위는 VTSS가 VTV를 자동 마이그레이션하는 데 어려움이 있으며, 이것은 다음과 같은 원인으로 인한 당연한 결과입니다.

- 각 VTSS에 8개의 RTD가 연결되어 있다고 가정해 보겠습니다. MX MT(최대 마이그레이션 작업)는 4로 설정되어 있고 MN MT(최소 마이그레이션 작업)는 2로 설정되어 있는데 이는 현재 마이그레이션 로드에 대해 약간 부족한 것이 사실입니다.
이 문제를 해결하려면 단계 2로 이동하십시오.

2. 단계 1에 나온 것이 만족스럽지 않다면 작동 매개변수를 조정합니다.

우선, 더 많은 마이그레이션 작업을 진행합니다.

set migopt vtss(vtssname) maxmig(8) minmig(8) high(70) low(40)

이제 모든 RTD가 모든 VTSS에서 마이그레이션에 완전히 투입되었습니다. DBU를 통제할 수 있을 때까지 이대로 진행한 다음 최대값 6, 최소값 3과 같이 돌아갑니다. AMT도 하한 40, 상한 70으로 변경했습니다. 그러면 문제가 발생하지 않으며, 다음 번에는 마이그레이션이 더 일찍 시작되고 버퍼가 더 낮은 DBU로 회복됩니다.

그런 다음 Display VTD를 입력하여 시스템의 VTD를 파악합니다.

테이블 4-3은 Display VTD 출력의 예를 보여줍니다.

테이블 4-3 Display VTD의 출력 예 - 올바르게 작동

DRIVE

LOCATION

VTV

STATUS

A800

HBVTSS16

X00778

MOUNTED

A801

HBVTSS16

X00775

MOUNTED

A802

HBVTSS16

-

AVAILABLE

A803

HBVTSS16

-

AVAILABLE

다시 한 번 테이블 4-3에서 일부 VTD가 사용 중이고 다른 일부는 사용할 준비가 되어 있는 양호한 상태가 됩니다.

모든 VTD가 마운트된 VTV를 표시한다면 어떻게 될까요? 이는 바람직하지 않습니다. 그 이유는 사용 가능한 드라이브가 없을 경우 작업 할당 실패의 위험이 있기 때문입니다. 단계 2에서 발생한 것과 유사한 문제가 원인이라면 이를 받아들이고 이후부터 VTD가 데이터의 유입을 더욱 잘 처리할 수 있도록 작업 로드를 조정하십시오. 하지만 장기적인 문제라면 더 많은 VTSS가 필요하거나 더 많은 용량과 더 많은 VTD를 가진 VTSS로 업그레이드해야 할 수 있습니다.

3. 이제 Display SCRATCH 명령을 입력하여 충분한 스크래치 VTV를 보유하고 있는지 알아볼 때입니다. 그러면 테이블 4-4와 유사한 출력이 표시됩니다.

테이블 4-4 Display SCRATCH의 출력 예

SUBPOOL-NAME

SCRATCH-COUNT

VIR000

14,364

VIR0002

13,582

VIRTUAL

19,132

VIRTUAL1

9,905

테이블 4-4에서 보이는 것은 HSC 하위 풀에 대한 VTV 스크래치 수입니다. VTV에 대해 HSC 하위 풀을 사용하지 않는 경우 시스템에 정의된 모든 VTV에 대한 VTV 스크래치 수를 보게 됩니다. 일부 사용 가능한 스크래치 VTV가 있다면 스크래치 수에 대한 좋거나 나쁜 수는 없습니다. ”사용 가능한 스크래치의 알맞은 수”는 조직의 필요와 작업 로드에 따라 달라집니다.

테이블 4-4에서 각 하위 풀에 대해 사용 가능한 스크래치가 50 이하로 나타날 경우 약간 문제가 될 수 있습니다. 이 경우 다음 중 하나 이상의 작업을 수행할 수 있습니다.

- 최신이 아닌 데이터가 있는 VTV를 스크래치하여 VTV volser 확보. 이 작업은 시스템에 충분한 총 VTV가 있지만 사용 가능한 충분한 스크래치 볼륨이 없는 경우 수행합니다.
실제로는 여러분이 스크래치를 수행하지 않으며 TMS에서 수행해야 할 작업이고, 초기 구성에서 TMS에 VTV volser를 정의했어야 합니다. 이렇게 정의되지 않은 경우 돌아가서 그렇게 하십시오. 또한 VTCS CONFIG 명령문을 통해 VTV 범위를 추가하고 TMS에 새 범위를 정의하는 것을 잊어버렸을 수 있으므로 돌아가서 해당 문제를 해결하십시오. 이 내용은 모두 ELS 설치에 설명되어 있습니다.

하지만 TMS에서 VTV를 스크래치로 표시하는 것은 해결책의 일부에 불과합니다. 함께 수행해야 하는 작업은 VSM의 누군가가 VTV 데이터를 최신이 아님(따라서 쓰기 가능)으로 표시하고, VTSS 상주 VTV의 경우 버퍼에서 삭제해야 합니다.

VTV 데이터를 실제로 삭제하는 것은 중대한 결정(데이터가 없어짐)이므로 신중한 판단을 내리고 ”필요에 따른” 작업이 되어야 합니다. 이 경로를 따를 경우 "요청식 MVC 공간 재생 수행"을 참조하십시오.

- POOLPARM 또는 VOLPARM을 사용하여 VTV 추가. 이 작업은 차선의 옵션이며, 최신이 아닌 데이터가 있는 VTV가 실제로 없을 때 수행합니다. POOLPARM 또는 VOLPARM만이 아니라 적절한 TMS 정의 등도 수행해야 합니다. 이 내용도 모두 ELS 설치에 설명되어 있습니다.

- 추가 VTV를 정의할 수 있을 때까지 임시로 테이프 작업을 니어라인 HSC 처리로 재지정하도록 TAPEREQ 명령문 또는 SMS 루틴 변경. 원래 VSM으로 전송하려고 했던 데이터를 니어라인 테이프로 전송해야 하고 정리 작업이 만만치 않으므로 이 작업은 가장 권장되지 않는 옵션입니다. 그래도 사용 가능한 니어라인 리소스가 있고 데이터를 스크래치 볼륨에 즉시 기록해야 한다면 이 작업을 (임시로) 수행할 수밖에 없습니다.

니어라인 테이프 상태 확인(일간)

"가상 테이프 상태 확인(일간)"에서는 시스템의 VTSS, VTD 및 VTV가 정상적으로 작동하는지 확인하는 것이 얼마나 중요한지에 대해 설명합니다.

VTV가 마이그레이션되고 회수되는 장소이며 일부 MVC 공간 확보가 백그라운드에서 진행되는 VSM의 니어라인 구성 요소(RTD 및 MVC)임을 고려하면 이 영역도 철저한 주의가 요구되는 부분임을 동의할 것입니다.

니어라인 테이프 상태를 확인하려면 다음과 같이 하십시오.

1. Display RTD를 입력합니다.
양호한 상태는 테이블 4-5와 유사합니다.

테이블 4-5 VT Display RTD 명령의 출력 예 - 모두 양호

RTD

STATUS

MOUNT

ALLOC

HOST

VTSS

B200

ONLINE/FREE

-

-

-

HBVTSS16

B201

ONLINE/FREE

-

-

-

HBVTSS16

0B79

ONLINE/FREE

-

-

-

HBVTSS16

0B7A

RECALL VTV

DMV051*

DMV051

EC20

HBVTSS16

1600

MVS1 :MIGRATE

-

-

-

-

1601

MVS1 :MIGRATE

-

-

-

-

테이블 4-5에서는 마이그레이션, 회수 및 새로운 작업을 위해 사용 가능한 RTD의 균형이 잘 맞으므로 모든 것이 순조롭게 진행되지만, 테이블 4-6에서는 그렇지 않습니다.

테이블 4-6 VT Display RTD 명령의 출력 예 - 문제가 있는 RTD

RTD

STATUS

MOUNT

ALLOC

HOST

VTSS

B200

MVS1 :MIGRATE

-

-

-

-

B201

MVS1 :MIGRATE

-

-

-

-

0B79

MVS2 :MIGRATE

-

-

-

-

0B7A

MVS2 :MIGRATE

-

-

-

-

1600

MVS1 :MIGRATE

-

-

-

-

1601

MVS1 :MIGRATE

-

-

-

-

테이블 4-6이 단계 2에서 수행된 일종의 긴급 조치 결과라면 상황이 정상화될 때까지 기다리는 수밖에 없습니다. 하지만 사용 가능한 다른 RTD(예를 들어, MVS 및 VSM와 수동으로 공유 중인 RTD)가 있다면 MVS에 오프라인으로 전환하고 Vary RTD를 사용하여 VTCS에서 사용할 수 있도록 만듭니다.

2. 그런 다음, Display MVCPool 명령을 사용하여 MVC의 상황을 확인합니다.

그림 4-1은 지정된 MVC 풀 이름이 없으므로 모든 시스템의 MVC에 대한 정보가 표시되는 Display MVCPool 출력의 예를 보여줍니다.

그림 4-1 Display MVCPool의 출력 예(지정된 풀 이름 없음)

그림 4-1은 MVC 모음이 양호한 조건임을 보여줍니다. 많은 사용 가능 MVC(100% 사용 가능한 공간, 마이그레이션된 VTV 없음)와 여러 ACS 및 MVC 매체 유형에 걸쳐 많은 사용 가능 공간이 있는 것으로 보입니다. 확보 가능한 MVC 수가 비교적 낮다는 것은 자동 공간 확보가 마이그레이션/회수 작업에 방해가 되지 않는다는 의미일 것입니다.

ACS 01, ECART 및 ZCART 매체를 제외하고 사용된 MVC는 사용 가능 MVC와 비교할 때 모두 정상인 것으로 보입니다. 이러한 MVC에 대해서는 추가 조사가 필요할 수 있습니다. 어떤 스토리지 클래스가 이러한 MVC를 나타내는지, 어떤 관리 클래스가 이러한 스토리지 클래스에 해당하는지 파악하고 관리 클래스별로 일부 VTV를 스크래치합니다.

Display MVCPool이 그림 4-2와 유사하게 표시된다면 어떻게 될까요?

그림 4-2 Display MVCPool의 출력 예 - ACS01의 문제

여기서 알 수 있듯이 ACS 01에서 상황이 더 악화되었습니다. 이제 어떻게 해야 할까요? 다음 방법을 가능한 순서대로 고려하십시오.

- 필요시 확보를 수행하여 공간을 확보합니다. 자세한 내용은 "요청식 MVC 공간 재생 수행"을 참조하십시오.

- "RTD 장치 유형 변경"에 설명된 대로 MVC를 추가합니다.

- 어떤 스토리지 클래스가 이러한 MVC를 나타내는지, 어떤 관리 클래스가 이러한 스토리지 클래스에 해당하는지 파악하고 관리 클래스별로 일부 VTV를 스크래치합니다.
후속 작업으로 현재 정책을 검토하고 필요에 따라 조정합니다. 이러한 정책을 변경하여 사용 가능 MVC를 만들거나 MVC에서 공간을 확보할 수 있습니다.

전체적인 상태 파악(주간)

이 작업은 별로 복잡하지 않고 기본적으로 주마다 두 가지 기본적인 상태 도구(MVC 보고서 및 VTV 보고서) 실행으로 구성됩니다.

VTV 보고서 사용

주:
VTV 보고서는 다음 명령 중 하나를 사용하여 실행됩니다.

- VTVRPT BASIC - EXPORT 명령을 사용하여 MVC로 마이그레이션된 모든 VTV 복사본을 보여줍니다.

- VTVRPT COPIES - EXPORT 명령을 사용하여 MVC로 마이그레이션된 모든 VTV 복사본을 보여주고, 추가적으로 EEXPORT 명령을 사용하여 마이그레이션된 모든 VTV 복사본을 보여줍니다.

VTV 보고서부터 살펴보면 그림 4-3과 유사하게 표시됩니다.

그림 4-3 VTVRPT의 출력 예

언뜻 보면 VTV 보고서는 시스템의 각 VTV 및 모든 VTV에 대해 알고자 하는 모든 것을 설명하는 수많은 데이터 라인이 있어 복잡하고 직관적이지 않게 보입니다.

VTV 보고서를 상황에 좀더 유용하게 만들 수 있는 방법은 없을까요? 우선 volser 목록, volser 범위 또는 개별 volser에 대해 VTVRPT 유틸리티를 실행할 수 있습니다. 조사하고자 하는 특정 VTV가 있다면 이러한 선택 옵션 중 하나를 사용합니다.

둘째, VTVRPT 유틸리티는 사용할 수 없는 VTV에 대한 보고서를 생성하는 OPTION(UNAVAIL) 매개변수도 제공하며, 그림 4-4와 유사하게 표시됩니다.

그림 4-4 VTVRPT의 출력 예(UNAVAIL 옵션)

상주하는 것으로 간주한 VTV에 액세스할 수 없는 작업(또는 VTCS) 보고서가 있었다면 분명히 OPTION(UNAVAIL)은 가장 적절한 옵션입니다.

또한 VTVRPT 유틸리티의 XML 출력에서 유연성을 얻을 수 있습니다. 선택한 보고서 및 유틸리티에 대해 구조화된 XML 또는 CSV(Comma Separated Variables) XML로 출력을 생성할 수 있습니다.

구조화된 XML과 CSV 출력의 차이는 무엇일까요? 다음을 고려하십시오.

- 구조화된 XML에는 각 명령이나 유틸리티에 대해 표시되는 모든 태그 및 구조가 포함됩니다(그런 다음 선택한 프로그래밍 언어를 사용하여 원하는 대로 처리할 수 있음).

- CSV 출력에서는 원하는 태그(및 순서)만 선택할 수 있습니다. 각 출력 라인에는 콤마로 구분된 고정 필드 수가 포함되며, 나중에 사용자 정의 가능한 분석이나 보고서를 위해 스프레드시트 또는 보고서 작성기에 입력할 수 있습니다.

이제 조직의 필요에 따라 기본적인 VTV 보고서를 효과적으로 사용자 정의할 수 있는 두 가지 방법을 갖게 되었습니다. 이 항목에 대한 자세한 내용은 ELS Programming Reference를 참조하십시오.

마지막으로, LCM이 VTCS MVC 및 VTV 보고서를 포함하여 ELS/VTCS 기능에 해당하는 향상된 관리 및 보고 기능을 제공한다는 사실을 알고 있어야 합니다. 자세한 내용은 "LCM 제어문"을 참조하십시오.

MVC 보고서 사용

마지막으로 MVC 요약 보고서를 살펴보면 그림 4-5와 유사하게 표시됩니다.

그림 4-5 MVC 요약 보고서 예

MVC 요약 보고서는 기존의 VTV 보고서와 많이 유사합니다. 찾고 있는 것을 알고 있다면 괜찮지만 그렇지 않다면 정보가 너무 많습니다.

MVC 상세 보고서에서 얻을 수 있는 추가 필드가 전체적인 상황을 파악하는 데 더 유용할 수 있습니다. 그림 4-6을 보십시오.

그림 4-6 MVC 요약 보고서 예(추가 필드)

여기에는 필요한 경우 몇 가지 진단 작업을 수행할 수 있는 MVC의 VTV에 대한 자세한 정보가 있습니다.

VTV 보고서와 마찬가지로 MVC 보고서에서도 다음 중 하나의 작업을 수행할 수 있습니다.

- ELS Programming Reference에 설명된 대로 구조화된 XML 또는 CSV(Comma Separated Variables) XML로 출력을 생성합니다.

- "LCM 제어문"에 설명된 대로 해당하는 LCM 보고서를 사용합니다.

요약

VTCS 대시보드 사용에 대한 모든 것을 설명했습니다. 명명된 MVC 풀을 사용한 경우 MVC 풀 보고서 실행 등과 같이 여러분이 수행할 수 있고 아마도 수행하게 될 몇몇 다른 작업도 있습니다. 그러나 이것은 ”필요에 따른” 관리 작업에 대한 정보입니다.

이 장에서 배워야 하는 가장 중요한 것은 가상 테이프 상태 확인(일간) 및 니어라인 테이프 상태 확인(일간)에 설명된 대로 일간 작업을 수행하고, "전체적인 상태 파악(주간)"에 설명된 대로 주간 작업을 수행하여 VTCS 시스템이 정상적으로 실행되도록 유지하는 것입니다.

5 VTCS 필수(비정기적) 작업 목록 처리

"필요시 작업 목록"이라고도 하는 "VTCS 필수(비정기적) 작업 목록"에 대한 설명을 시작합니다. 예를 들어 이번 주에 DELETSCR을 실행하여 중요한 VTSS 및 MVC 공간의 많은 양을 차지하고 있는 스크래치된 VTV 목록을 삭제하려고 합니다. 작업이 잘 수행되었습니다. 같은 작업을 실행하기 전에 이 작업이 얼마나 오래 유지될 것이라고 생각합니까? 특히 스크래치에 대한 삭제 정책을 변경하지 않은 경우 얼마나 오래 유지될 것이라고 생각합니까? 답: 일, 월, 년일 수 있지만 이 작업을 다시 수행해야 합니다.

그러나 걱정하지 마십시오. 여기에서 필수(비정기적) 작업 목록을 줄이는 데 도움이 되는 유용한 절차에 대해 설명합니다. 또한 "VTCS 대시보드 사용"에서 이미 설명했으므로 MVC 및 VTV 보고서를 꼼꼼하게 살펴본다면 필수/필요시 작업을 수행해야 할 때를 알 수 있으므로 이러한 목록이 필요하지 않을 수 있습니다.

또한 거의 정책 결정 사항인 다른 클래스의 "필수(비정기적)" 작업 목록도 있습니다. 이 작업 목록은 다음과 같은 이유로 여기에 포함됩니다. (a) 사전 예방적 작업이므로 "필요시" 작업의 모범 사례로 매우 중요합니다. (b) 작업장에 도움이 되거나 도움이 되지 않을 때 언제든지 사용, 취소 및 재도입할 수 있는 운영 기술입니다. 그렇지만 "요청식 공간 재생, 마이그레이션 및 회수 수행"에서는 이 범주에서 즐겨 사용하는 세 가지 범주에 대해 먼저 설명합니다.

요청식 공간 재생, 마이그레이션 및 회수 수행

이러한 작업은 선택적이지만, 특히 요청식 공간 재생의 경우 앞으로 설명할 이유에 대한 모범 사례로 매우 권장됩니다.

요청식 MVC 공간 재생 수행

이미 알고 있는 바와 같이, VSM은 재생을 실행하는 각 호스트에서 자동으로 MVC 공간을 회수합니다. 여기서 중요한 점은 자동으로 수행된다는 점입니다. 즉, 공간 재생은 작업을 찾으면서 계속 실행됩니다. 백그라운드 작업이기는 하지만, 단편화된 MVC가 많을 경우 사용량이 많은 처리 기간 동안에는 공간 재생 작업이 마이그레이션/회수 작업을 심각하게 방해할 수 있습니다.

MVC 요약 보고서 또는 MVCPool 화면에 시스템의 MVC에서 높은 레벨의 조각화가 발생한 것으로 나타나며, 이 레벨은 CONFIG RECLAIM THRESHLD 매개변수 또는 MVCPool THRESH 매개변수에 지정된 값보다 낮을 경우 비정규 시간에 일괄 처리 작업으로 수행되도록 요청식 MVC 공간 재생을 예약할 수 있습니다.

요청식 MVC 공간 재생은 RECLaim을 사용하여 수행할 수 있습니다. ELS Command, Control Statement, and Utility Reference에서는 요청식 재생을 최적화하고 가장 효과적으로 실행하는 데 사용할 수 있는 유용한 도구를 소개합니다.

- MVCPOOL, STORCLAS, ACSid, MVC 매개변수 중 하나만 사용하여 처리할 MVC 목록을 필터링할 수 있습니다. "VTCS 대시보드 사용"에 설명된 MVC 및 VTV 보고서는 가능성 있는 후보 목록을 MVC 풀, 스토리지 클래스, 특정 ACS, MVC 범위 또는 목록으로 좁히는데 도움이 됩니다. 이 목록을 RECLaim에 입력하면 올바른 작업 도구를 사용하는 것입니다.
이러한 매개변수 중 하나를 지정하지 않을 경우 공간 재생 시 사용 가능한 공간이 가장 필요할 때 이름이 지정된 MVC 풀(구현된 경우) 또는 매체 유형(다중 MVC 매체 환경)에서 MVC가 선택됩니다.

- MAXMVC(한 개의 공간 재생 작업으로 처리되는 최대 MVC 수), THRESH(재생 대상으로 설정되는 MVC 단편화 백분율) 및 CONMVC(VTCS에서 배출 및 재생을 위해 동시에 처리하는 최대 MVC 수) 매개변수를 사용하여 요청식 재생의 해당 CONFIG RECLAIM 전역 매개변수를 대체할 수 있습니다. 이 경우 요청식 마이그레이션이 자동 마이그레이션보다 더 공격적이거나 덜 공격적이도록 조정할 수 있습니다.

- NOWAIT는 프로세스의 속도를 높이는 방법이고 CONMVC는 한 번에 처리되는 MVC 수에 영향을 미치는 또 다른 조정 방법입니다. 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

- ELAPSE는 지정한 간격 내에 요청식 재생이 발생하지 않았는지 탐지하는 방법입니다. 이 기간 내에 재생이 발생하지 않은 경우 작업이 중지됩니다.

- 또한 VTCS에서는 가장 엄격한 제한 계수가 적용됩니다. 예를 들어 RECLAIM을 실행하고 ELAPSE를 5시간, MAXMVC를 10으로 설정한 다음 VTCS에서 1시간에 MVC를 10개 재생할 경우, ELAPSE 값이 만료되기 전에 VTCS에서 재생이 종료됩니다.

- RECLAIM 요청을 처리하기 위해서는 VTCS 및 HSC가 활성 상태여야 합니다.

요청식 VTV 마이그레이션 수행

이미 언급했듯이, VTCS/ELS는 기본적으로 서버입니다. 예를 들어 VSM은 VTSS 공간을 자동으로 관리하고 최적의 데이터 가용성, 리소스 사용, 데이터 보호가 균형을 이룰 수 있도록 VTV를 마이그레이션합니다.

안정적인 환경에서는 문제 없지만, VSM 시스템에 아주 많은 응용 프로그램 데이터를 수신한다면 어떻게 해야 될까요? 답: 앞에서 언급한 테이프 처리 이벤트가 최고로 많이 발생하기 전에 요청식 마이그레이션 일괄 처리 작업을 실행하여 VTSS 공간을 확보해야 합니다.

물론 요청식 마이그레이션은 MIGRATE를 사용하여 수행합니다. 이때 제공되는 옵션은 다음과 같습니다.

- 다음 기준에 따라 VTV를 마이그레이션할 수 있습니다.

- volser(반복 허용)

- 관리 클래스

- VTV와 연관된 데이터 세트 이름(가장 효과적).

DELETE(YES) 옵션은 성공적으로 마이그레이션한 후 VTSS 공간에서 VTV를 삭제하는 데 사용할 수 있습니다. 다시 액세스하지 않을 VTV에 대해서는 보통 DELete(YES)(기본값)를 사용합니다. 다른 방법으로, DELete(NO)를 지정하면 다시 액세스되지 않을 VTV에 대해 중요한 데이터가 사용 가능해져서 신속하게 마이그레이션됩니다.

- NOWAIT 옵션을 사용하면 프로세스의 속도를 높일 수 있습니다. MIGRATE 형식 1을 사용하면 됩니다. 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

- 또 다른 방법으로 MIGRATE 형식 2를 사용하여 모든 또는 특정 VTSS에 대해 요청식 migrate-to-threshold를 수행할 수 있습니다. 이는 원하는 DBU를 얻기 위한 좋은 도구이며 세부정보는 VTCS에서 처리합니다.

또한 참고로, SET MIGopt를 사용하면 높은 AMT를 낮춰 효과적으로 요청식 마이그레이션을 수행할 수 있습니다.

요청식 VTV 회수 수행

VTCS는 자동 회수 프로세스를 제공하는데, 이 프로세스는 테이프로 마이그레이션된 VTV의 데이터 세트를 요청하는 작업이 있지만 이 데이터 세트가 VTSS에 없을 때 시작됩니다. 그러나 위 상황과 반대라면 어떻게 해야 될까요? 예를 들어 연말 처리 중인데 테이프에만 있는 VTV에서 데이터를 읽어오려는 일련의 작업이 있음을 알게 됩니다. 이 경우 요청식 회수가 해결책입니다.

RECALL을 통해 필요한 사항을 융통성 있게 제어할 수 있습니다.

- MIGRATE와 마찬가지로, volser, 관리 클래스 또는 연관된 데이터 세트 이름으로 VTV를 회수할 수 있습니다.

- VTV를 회수할 VTSS를 지정할 수 있습니다. 그렇지 않은 경우 기본값은 VTSS 생성이며, VTSS 회수 정책과 관련된 몇 가지 고려 사항이 있습니다. 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

- RECALWER을 사용하여 읽기 데이터 검사와 함께 VTV를 회수할지 여부를 지정할 수 있습니다.

- 프로세스의 속도를 높일 수 있는 NOWAIT 옵션이 있습니다.

RTD 작업

거의 독점적인 오류 복구 시나리오인 "VTCS 문제 찾기 및 수정"으로 국한되는 RTD 관리가 많이 있습니다. RTD에 대한 모범 사례는 이것으로 충분하며, 모두 작동되어 실행 중이어야 합니다. RTD는 마이그레이션, 회수 및 재생에 사용되므로 이러한 모든 작업에 대해 RTD를 올바르게 혼합하는 것이 중요한 해결 조치입니다. 작동 매개변수를 통해 이러한 혼합을 조정하려면 "가상 테이프 상태 확인(일간)"을 참조하십시오.

RTD 작동 매개변수를 조정하는 것 이외에도 RTD와 관련된 다른 주요 도구는 RTD 상태를 변경하는 데 사용되는 VTCS Vary RTD 명령입니다. RTD에서 유지 관리를 수행해야 하는 경우 RTD를 온라인, 오프라인 또는 유지 관리 모드로 변경할 수 있습니다.

발생할 수 있는 주요한 필요시 작업과 관련이 있으며 처음 두 개의 작업이 Vary RTD를 사용합니다.

- "RTD 장치 유형 변경" - 기본적으로 시스템의 일부 또는 전체 RTD에 대한 기술 업그레이드를 수행하는 방법입니다.

- MVC 매체 지정 방법을 고려해야 합니다. 이는 실제로 MVC 고려 사항이지만, RTD 장치 유형의 변경으로 인해 발생합니다. 자세한 내용은 Configuring HSC and VTCS를 참조하십시오.

RTD 장치 유형 변경

다음 절차를 수행하여 RTD 장치 유형을 변경할 수 있습니다. RTD 장치 유형을 변경하려면 모든 호스트에서 VTCS를 중지해야 합니다.

RTD 장치 유형을 변경하려면 다음을 수행하십시오.

1. VSM 정책을 검토합니다.
예를 들어 이 RTD 장치 유형이 마이그레이션에 사용된 경우 관리 클래스 및 스토리지 클래스 정의를 검토할 수 있습니다.

2. 이전 RTD를 VTCS에 대해 오프라인으로 변경합니다.

3. 새 RTD 장치가 새 MVS 장치 주소를 사용하는 경우 다음을 수행합니다.

- MVS에 대한 새 주소를 정의합니다.

- DECOMP를 실행하여 CONFIG 문을 출력합니다.

- CONFIG 문을 편집하여 RTD 주소를 새 값으로 변경합니다.

- CONFIG RESET을 실행합니다.

주의:
새 전송은 MVS에 대해 온라인으로 변경하지 마십시오! 변경할 경우 니어라인 전송으로 할당될 수 있습니다.

4. 새 RTD를 설치합니다.

5. 전송이 대체된 LSM을 오프라인 상태로 변경합니다.

6. 전송이 대체된 LSM을 온라인 상태로 변경합니다.

7. 새 RTD를 VTCS에 대해 온라인으로 변경합니다.

8. 필요한 경우 MVC를 추가합니다.
자세한 내용은 "MVC 추가"를 참조하십시오.

MVC 작업

이미 알고 있는 바와 같이, 가상 엔티티 중 하나에 대해서만 설명하기는 어렵습니다. MVC에는 VTV가 포함되어 있어 설명할 때 둘 다 언급할 수 밖에 없으므로 이들을 따로 떼어 설명할 수는 없습니다. 또한 VTV에 대해 설명하는 경우 VTSS 및 VTD에 대해서도 언급하게 됩니다.

그렇지만 다음 절에서는 여러 가지 이유로 수행되는 매우 일반적인 MVC 관련 "필요시" 작업을 수행하는 기본적인 절차에 대해 다룹니다. 예를 들어 이전 시나리오에서 설명한 것과 같이 공간 부족 때문에 또는 문제를 사전에 예방하기 위해 MVC를 추가할 수 있습니다.

주:
SET VOLPARM 또는 CONFIG MVCVOL 처리의 결과로 구성에서 MVC를 삭제하는 경우 다음 사항에 유의하십시오.

- volser를 구성에 VTV로 다시 입력할 수 없습니다.

- 고유의 HSC 테이프에 volser를 사용하지 마십시오.

메시지 SLS6944I는 삭제된 MVC 수를 나타냅니다.

MVC 추가

ELS 7.2는 볼륨 추가가 훨씬 쉬워졌습니다. 이제 HSC VOLPARM 및 POOLPARM 문을 사용하여 모든 볼륨과 풀(고유 니어라인 볼륨, 청소 카트리지, MVC 및 VTV)을 정의하고, HSC SET VOLPARM 유틸리티를 사용하여 이들을 로드할 수 있습니다. 자세한 내용은 Configuring HSC and VTCS 및 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

MVCS를 추가하려면 다음을 수행하십시오.

1. MVC를 정의하는 VOLPARM 문을 작성합니다.
예를 들어 암호화할 T10000 전체 볼륨의 범위를 정의하려면 다음과 같이 작성합니다.

VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE)

2. MVC 풀을 정의하는 POOLPARM 문을 작성합니다.
예를 들어 재생 매개변수를 사용하여 T10000 MVC 풀을 정의하려면 다음과 같이 작성합니다.

POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)

3. 필요한 경우 MGMTCLAS 또는 STORCLAS 문을 작성하거나 업데이트합니다.

예를 들어 새 MVC 매체 유형을 추가한 경우 Configuring HSC and VTCS에 설명된 권장 사항을 따릅니다.

4. 필요한 경우 POLICY 또는 TAPEREQ 출력 매개변수를 업데이트합니다.
예를 들어 3 단계에서 새 관리 클래스를 만든 경우 새 관리 클래스를 가리키도록 TAPEREQ 또는 POLICY 문을 업데이트하거나 작성합니다.

5. VTV를 정의해야 합니까?
그렇다면 "VTV 정의"로 이동하고, 그렇지 않으면 "볼륨 정의 검증 및 적용"으로 이동합니다.

VTV 정의

VTV를 정의하려면 다음을 수행하십시오.

1. VTV를 정의하는 POOLPARM 또는 VOLPARM 문을 작성합니다.
예를 들어 MVS1 및 MVS2 호스트에서 사용할 두 가지 범위의 VTV를 정의하려면 다음과 같이 작성합니다.

POOLPARM NAME(SYS1VTV1)TYPE(SCRATCH)
VOLPARM VOLSER(V5000-V5499)MEDIA(VIRTUAL)
POOLPARM NAME(SYS1VTV2)TYPE(SCRATCH)
VOLPARM VOLSER(V5500-V5999)MEDIA(VIRTUAL)

2. "볼륨 정의 검증 및 적용"으로 이동합니다.

볼륨 정의 검증 및 적용

1. SET VOLPARM을 실행하여 VOLPARM/POOLPARM 문을 검증합니다.

SET VOLPARM APPLY(NO)

APPLY(NO)는 명령문을 로드하지 않은 상태로 검증합니다. 결과에 만족할 경우 2단계로 이동합니다. 그렇지 않은 경우 볼륨을 다시 정의하고 2단계로 이동합니다.

2. SET VOLPARM을 실행하여 VOLPARM/POOLPARM 문을 로드합니다.

SET VOLPARM APPLY(YES)

3. 물리적으로 ACS에 실제 카트리지를 넣습니다.

4. 자세한 내용은 "카트리지 넣기"를 참조하십시오.

풀에서 MVC 제거

풀에서 MVC를 제거하려는 이유는 무엇입니까? 일반적인 시나리오는 RTD의 기술 새로고침을 위해 오래된 드라이버를 교체하고 오래된 매체를 처분하려는 경우입니다. 이 경우 MVC 추가의 설명에 따라 새 MVC를 풀에 추가한 다음 "MVC 영구 제거"의 설명에 따라 오래된 매체를 제거하십시오.

풀에서 MVC를 일시적으로 제거하고자 하는 경우도 있습니다. 예를 들어 불량 매체 또는 불량으로 의심되는 매체를 사용하고 있을 수 있습니다. "일시적으로 MVC 제거"의 설명에 따라 기본적으로 동일한 volser 하에서는 불량 매체를 제거하고 대체 매체를 삽입할 수 있습니다.

MVC 영구 제거

풀에서 MVC를 영구적으로 제거하려면 다음을 수행하십시오.

1. MVCDRain을 입력하여 MVC를 배출합니다.

예를 들어 MVCDRain을 실행하여 스토리지 클래스 STORCL1에서 MVC를 배출하고 가상으로 MVC를 꺼냈다가 요청이 제출된 후 다시 넣으려면 다음과 같이 입력합니다.

MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT

2. ACS에 더 이상 MVC가 필요하지 않을 경우 HSC Eject 명령을 사용하여 MVC를 ACS에서 꺼냅니다.

3. MVC에 대해 정의한 보안 제한 사항과 테이프 관리 시스템 제한 사항을 제거합니다.

VOLPARM 및 POOLPARM 정의를 사용하고 가상 CDS 레벨이 G 이상일 경우 4단계로 이동합니다. 그렇지 않을 경우 5단계로 이동합니다.

4. 니어라인(비VTCS) 사용에 테이프 volser를 재사용하고 VOLPARM/POOLPARM 정의를 사용하려면 다음을 수행합니다.

1. 제거하려는 MVC에 대해 POOLPARM/VOLPARM 문을 업데이트합니다.

2. 모든 호스트에서 SET VOLPARM APPLY(YES)를 실행하여 변경사항을 적용합니다.

3. HSC SCRAtch 명령을 실행하여 더 이상 MVC가 아닌 볼륨을 스크래치합니다.

5. 니어라인(비VTCS) 사용에 테이프 volser를 재사용하고 VOLPARM 및 POOLPARM을 사용하지 않으려면 다음 중 하나를 수행합니다.

1. HSC EJECT 명령을 실행하여 ACS에서 MVC를 제거합니다.

2. 카트리지에 있는 외부 바코드 레이블을 변경합니다.
원래 MVC volser는 CDS에 유지되고 MVC로만 사용할 수 있으므로 외부 바코드 레이블을 변경해야 합니다.

3. 카트리지를 다시 ACS에 넣습니다.

또는

1. 새 CDS 데이터 세트를 만듭니다.

2. 불필요한 MVC 범위를 제거하도록 DELVirt를 지정하여 HSC MERGECDS 유틸리티를 실행합니다.

주:
새 CDS 데이터 세트가 만들어지므로 이 옵션을 사용할 경우 HSC를 모두 중지해야 합니다.

일시적으로 MVC 제거

풀에서 MVC를 일시적으로 제거하려면 다음을 수행하십시오.

1. MVC에 대해 MVCDRain Eject를 입력합니다.
예를 들어 MVCDRain을 실행하여 스토리지 클래스 STORCL1에서 MVC를 배출하고 가상으로 MVC를 꺼냈다가 요청이 제출된 후 다시 넣으려면 다음과 같이 입력합니다.

MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT

다음이 수행됩니다.

- MVC에서 VTV를 모두 회수하여 새 MVC에 다시 마이그레이션합니다.

- VTCS 마이그레이션에 대해 MVC를 선택 불가능하게 설정합니다.

2. MVC를 다시 MVC 풀에 넣으려면 MVC에 대해 MVCDRain을 입력합니다.

MVC에 대한 EJect 매개변수 없이 MVCDRain을 입력하면 다시 사용할 수 있습니다.

예를 들어 MVCDRain을 실행하여 스토리지 클래스 STORCL1에서 MVC를 배출하고 요청이 제출된 후에 다시 넣으려면 다음과 같이 입력합니다.

MVCDRAIN STORCLAS(STORCL1) NOWAIT

주:
또 다른 방법으로, MVCMAINT를 사용하여 MVC를 읽기 전용으로 표시할 수 있습니다. 이 경우 VTCS에서 마이그레이션할 MVC를 선택할 수 없지만 MVC에서 VTV가 제거되지는 않습니다. MVCMAINT를 사용하여 읽기 전용을 해제할 수도 있습니다.
VOLPARM/POOLPARM 정의를 사용할 경우 POOLPARM 문에 NOMIGRAT 옵션을 지정하여 새 마이그레이션에 MVC가 사용되지 않도록 할 수 있습니다.

MVC 배출

MVCDRain을 사용하여 MVC를 "배출"(MVC에 있는 모든 VTV 회수)할 수 있습니다. MVC 배출은 보통 다음과 같은 이유로 수행됩니다.

- MVC 보고서 또는 화면에 MVC에 대한 데이터 검사 오류가 표시됩니다. VSM가 MVC로 마이그레이션되지 않으므로 MVC 풀에서 제거해야 합니다.

- MVC 보고서 또는 화면에 MVC에 대한 데이터 검사 오류 이외의 다른 오류가 표시됩니다.

- 스토리지 클래스 또는 이름이 지정된 MVC 풀이 더 이상 사용되지 않으므로 연관된 MVC를 제거하거나 재사용하려고 합니다.

다음 매개변수 중 하나를 지정하여 배출할 MVC를 선택할 수 있습니다.

- MVCid - volser를 기준으로 하나 이상의 MVC를 배출합니다.

- MVCPOOL - 이름이 지정된 MVC 풀에 있는 MVC를 배출합니다. 이름이 지정된 MVC 풀에 대한 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

- STORCLAS - 스토리지 클래스에 있는 MVC를 배출합니다. 스토리지 풀에 대한 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

MVCDRain을 사용하여 CONFIG RECLAIM CONMVC 설정을 대체할 수 있습니다. 각 호스트에서 MVCDRain을 실행할 수 있습니다. 그러면 CONMVC 값과 같은 호스트에서 배출 작업이 시작됩니다. 이 배출 작업은 다른 호스트에서 시작된 배출 작업과 동시에 실행할 수 있습니다.

또한 다음 사항에 유의하십시오.

- VMVC의 경우, EJECT 매개변수와 함께 MVCDRAIN을 사용하면 VTV가 물리적으로 삭제됩니다.

주의:
DRCHKPT 유틸리티 및/또는 CONFIG GLOBAL PROTECT 매개변수를 사용하여 VMVC에 대한 CDS 백업 컨텐츠를 보호할 경우 MVCDR EJECT를 지정하면 CDS 백업의 VMVC 컨텐츠가 무효화됩니다.

- VMVC 및 MVC의 경우, EJECT 매개변수 없이 MVCDRAIN을 사용하면 VTV가 삭제되지는 않지만, VMVC/MVC에 있는 VTV를 표시하지 않도록 CDS 레코드가 업데이트됩니다.

자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

MVCMAINT를 사용하여 MVC 속성 변경

MVCMAINT는 VSM 영역의 편리한 도구로, 해당 매개변수는 기능을 설명합니다.

- 먼저 MVC volser(범위, 목록, 개별 volser) 또는 MANIFEST는 두 가지 MVC 선택 기준입니다. MVC volser는 이해가 되지만, MANIFEST는 왜 선택 기준일까요? 매니페스트 파일(MVC 및 포함된 VTV 목록)은 EXPORT(MVC를 다른 시스템으로 이동할 때 수행됨)를 실행할 때 만듭니다. MVC를 새 시스템으로 가져오면 MVC가 읽기 전용 모드로 시작되므로 제대로 정의할 수 있을 때까지 덮어쓸 수 없습니다.

- READONLY(ON 또는 OFF) - 위 글머리 기호를 참조하십시오. 또한 MVC를 풀에 추가하는 작업에 대해 설명한 내용이 기억납니까? MVC를 ACS에 스크래치 상태로 넣으려는데, 일부 작업장에서는 모든 MVC를 비스크래치 상태로 가져와서 정렬합니다. 새 MVC를 쓰기 가능 상태로 설정해야 하는 경우 MVCMAINT READONLY(OFF)를 사용합니다.

- LOST(ON 또는 OFF) - MVC는 어떻게 손실될까요? 예를 들어 MVC는 손실될 수 있을까요? 믿지 않을지 모르겠지만 손실될 수 있습니다. 예를 들어 VTCS에서 시작된 MVC 마운트가 완료되지 못한 경우(오류와 함께 완료된 경우와 반대) VTCS는 CDS에서 해당 MVC를 "손실"로 표시하고 환경 설정에서 제거합니다.
"손실된" MVC에 있는 멀티플렉싱 VTV는 대체 MVC에서 회수됩니다. 다른 유효한 MVC가 있는 경우 VTCS에서는 "손실된" MVC를 마이그레이션에 사용하지 않습니다. "손실" 상태의 MVC가 성공적으로 마운트되면 MVC 레코드에서 "손실" 상태가 제거됩니다.

MVC가 실제로 손실되지 않았다면 어떻게 해야 될까요? 답: MVCMAINT를 사용하여 LOST 상태를 해제할 수 있습니다.

설명할만한 가치가 있는 흥미로운 MVCMAINT 용도가 있습니다. 일시적으로 수동 모드인 LSM인 있다면 어떻게 해야 될까요? 해당 LSM에서 선택한 MVC를 (일시적으로) 환경 설정에서 제거할 수 있는데, 이 작업은 LOST(ON)를 사용하여 수행할 수 있습니다. 그런 다음 LSM이 다시 자동 모드가 되면 LOST(OFF)를 사용하여 이 프로세스를 반대로 수행합니다.

- ERROR(ON 또는 OFF) - MVC는 다음과 같은 여러 가지 이유로 (잘못) 오류 상태가 될 수 있습니다.

- VTCS에서 RTD에 마운트된 볼륨이 MVC로 인식되지 않습니다. 이는 일부 MVS 작업이 MVC를 덮어쓰기 때문에 발생할 수 있습니다. MVC에 발생한 상황을 확인하고, MVC에 유효한 VTV 데이터가 포함되어 있지 않을 경우 볼륨을 다시 초기화하고 MVC 풀로 돌아가십시오.

- MVC에 쓸 수 없습니다. 이는 섬 휠(thumb wheel)이 읽기 전용으로 설정되었거나 보안 패키지에서 VTCS가 볼륨에 쓰는 것을 허용하지 않기 때문일 수 있습니다. 섬 휠을 재설정하거나, MVC에 쓸 수 있도록 보안 패키지의 규칙을 변경하십시오.

- 잘못된 블록 ID가 감지되었습니다. MVC를 감사(VTCS)하여 조건을 수정해야 합니다.
설명한 대로 오류 조건을 수정한 후에는 MVCMAINT를 사용하여 MVC 상태를 ERROR(OFF)로 재설정하십시오.

- EJECT(ON 또는 OFF) - MVC의 "논리적 꺼내기" 상태를 지정합니다. 이 상태는 어떻게 설정하며 이 상태를 변경하려는 이유는 무엇일까요? MVCDRAIN을 사용하여 MVC를 명시적으로 배출한다면 잘못된 매체라고 생각하고 있기 때문일 수 있습니다. 따라서 "논리적 꺼내기" 상태를 설정하여 매체를 환경 설정에서 제거하십시오. 그런 다음 실제로 MVC를 꺼내 몇 가지 테스트를 실행하고 올바른 상태인지 확인한 다음 다시 넣으십시오. 이때 MVCMAINT를 사용하여 EJECT(OFF)를 설정하십시오.

- T9840/T9940 매체에만 해당하는 MVC 속성 그룹이 있으며, 모두 ON/OFF 스위치가 있습니다.

- WARRANTY - VTCS는 또한 매체 보증 만료를 감지하고 WARRANTY 상태를 ON으로 설정합니다. 또는 SMF, LOGREC 데이터 또는 MVC 및 VTV 보고서를 사용하여 수명이 다해가는 MVC를 감지한 다음 MVCMAINT를 사용하여 수동으로 WARRANTY ON으로 설정할 수 있습니다. 보증이 만료된다는 사실을 알고 있다면 매체의 수명이 다하기 전에 매체 교체에 대비할 수 있습니다. 실수로 MVC를 보증 만료로 표시한 경우 어떻게 해야 될까요? 답: MVCMAINT를 사용하여 보증 만료 상태를 재설정하기만 하면 됩니다.

- RETIRED - VTCS는 또한 매체의 수명 종료를 감지하고 RETIRED 상태를 ON으로 설정합니다. 위에서 언급했듯이, SMF, LOGREC 데이터 또는 MVC 및 VTV 보고서를 사용하여 수명이 다해가는 MVC를 감지한 다음 MVCMAINT를 사용하여 수동으로 RETIRED ON으로 설정하거나, 실수로 RETIRED로 표시한 MVC에 대해 상태를 RETIRED OFF로 설정할 수 있습니다.

- VTCS는 잘못된 MIR(매체 정보 영역)을 자동으로 감지한 다음 INVLDMIR 상태를 ON으로 설정합니다. MIR은 전송의 운영자 패널을 통해 사용 가능한 유틸리티를 사용하거나 MPST를 통해 사용 가능한 유틸리티를 사용하여 복구할 수 있습니다. MIR을 다시 만든 후에는 MVCMAINT를 사용하여 MVC에 대해 INVLDMIR OFF로 설정할 수 있습니다.

주:
MVCMAINT를 실행하면 MVCMAINT 작업의 영향을 받는 볼륨의 MVC 보고서도 생성됩니다.

MVC 또는 VMVC 확인

MEDVERfy 유틸리티는 MVC 또는 VMVC에서 VTV 데이터를 읽을 수 있는지 확인하는 방식으로 MV(매체 확인)를 수행하지 않습니다(ELS 7.1 및 VLE 1.2 이상만 해당). VLE의 경우, MEDVERfy를 사용하여 중복 제거된 VMVC를 "다시 복원"(다시 구성)할 수 있는지 확인할 수 있습니다.

이 유틸리티는 확인을 통과 또는 실패한 MVC를 보고하고 XML 출력도 생성합니다. MEDVERfy 유틸리티에 대한 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

다음 절에서는 MV에 MEDVERfy 유틸리티를 사용하는 예를 보여줍니다.

단일 VMVC에 대해 MV 수행

MEDVERFY   MVC(VMC000)

이 예에 대한 설명은 다음과 같습니다.

- MEDVERfy는 단일 VMVC를 선택합니다.

- MAXMVC의 기본값은 99입니다.

- CONMVC의 기본값은 1이므로 한 번에 한 개의 MVC만 처리됩니다.

- 시간 초과는 지정되어 있지 않습니다.

MVC 풀별 MV 수행

MEDVER   MVCPOOL(MP1)

이 예에 대한 설명은 다음과 같습니다.

- MEDVERfy는 MVC 풀 MP1에서 처리할 MVC를 선택합니다.

- FREQency는 지정되어 있지 않고 MAXMVC의 기본값은 99이므로, MEDVERfy는 마지막 확인 시간을 기준으로 최상의 99개 MVC 후보를 선택합니다.

- CONMVC의 기본값은 1이므로 한 번에 한 개의 MVC만 처리됩니다.

- 시간 초과는 지정되어 있지 않습니다.

MVC Volser별 MV 수행

MEDVER   MVC(MVC000-MVC049) CONMVC(2) TIMEOUT(720)

이 예에 대한 설명은 다음과 같습니다.

- MEDVERfy는 처리할 MVC volser를 50개 선택합니다.

- FREQency는 지정되어 있지 않고 MAXMVC의 기본값은 99이므로, MEDVERfy는 지정된 50개 MVC 를 모두 처리합니다.

- CONMVC는 2이므로 MEDVERfy가 두 개의 MVC를 동시에 처리합니다.

- MEDVERfy는 시간 초과 전 12시간 동안 실행됩니다.

스토리지 클래스별 MV 수행

MEDVER   STORCLAS(SC1) MAXMVC(50) FREQ(365)

이 예에 대한 설명은 다음과 같습니다.

- MEDVERfy는 스토리지 클래스 SC1에서 처리할 MVC를 선택합니다.

- MAXMVC는 50이고 FREQency가 365일을 지정하므로, MEDVERfy는 1년 이상 확인하지 않은 최상의 50개 MVC 후보를 선택합니다.

- CONMVC의 기본값은 1이므로 한 번에 한 개의 MVC만 처리됩니다.

- 시간 초과는 지정되어 있지 않습니다.

VTSS 작업

필요시 VTSS에서 주로 수행할 수 있는 작업은 VTCS Vary VTSS 명령이나 유틸리티를 사용하여 VTSS 온라인, 오프라인 또는 중지 상태로 변경하는 것입니다. 수행하려는 작업과 VTSS를 오프라인 또는 중지 상태로 변경하는 이유와 시기를 항상 알고 있어야 합니다. 그 이유는 VTSS에 유지 관리가 필요하거나 구성에서 VTSS를 제거할 예정일 수 있기 때문입니다. 이에 대해서는 "VTCS 문제 파악 및 해결"에서 설명합니다.

먼저 다음 차트는 VTSS를 지원되는 각 모드로 변경할 경우의 동작과 모든 모드가 가능할 경우 OFFline보다 QUIESCED를 사용해야 하는 이유를 보여줍니다.

테이블 5-1 VTSS 상태

지정된 Vary VTSS 매개변수

VTSS 첫번째 상태

VTSS 다음 상태

ONline

온라인 보류 중 - 온라인 보류 중 상태에서는 온라인 프로세스가 시작되었지만 모든 호스트에서 완료되지는 않았습니다.

온라인 - 온라인 상태에서는 VTSS가 온라인이고 사용 가능하며 프론트 엔드 및 백엔드 작업을 모두 허용합니다. VTSS가 오프라인이었다가 온라인이 된 경우 VTCS에서 VTSS 감사를 권장하는 경고 메시지가 표시됩니다.

QUIESCED

중지 중 - 중지 중 상태에서는 VTCS가 DD 할당을 VTSS로 전달하지 않으며, unit=aff 체인을 사용하는 장시간 실행 중인 작업이 완료될 수 있도록 마운트 보류를 허용합니다. 모든 VTD가 더 이상 사용되지 않을 경우(UCB가 MVS에 할당되지 않음) VTSS가 정지 상태로 전환됩니다. 중지 중 상태에서는 VTSS가 계속 백엔드 작업(예: 마이그레이션, 회수 및 감사)을 허용하고 처리합니다.

중지 - 중지 상태에서는 VTSS가 계속 백엔드 작업(예: 마이그레이션, 회수 및 감사)을 허용하고 처리합니다. 즉, 회수 및 마이그레이션 명령과 유틸리티를 사용하여 정지된 VTSS를 통해 해당 작업을 수행할 수 있습니다.

OFFline

오프라인 보류 중 - 오프라인 보류 중 상태에서는 오프라인 프로세스가 시작되었지만 모든 호스트에서 완료되지는 않았습니다. VTCS가 즉시 VTSS를 종료하고 활성 작업을 모든 중단하고 비우며 대기열에 있는 작업을 모두 비웁니다. VTSS 서버 작업이 종료되고 새 프론트 엔드 작업과 백엔드 작업을 더 이상 허용하지 않습니다. VTCS가 새 VTV를 만들고 대체 VTSS(사용 가능한 경우)에서만 기존 VTV를 마운트/마운트 해제합니다.

오프라인 - 오프라인 상태에서는 VTSS가 모든 호스트에 대해 오프라인이며 프론트 엔드 또는 백엔드 작업을 허용하지 않습니다.

VTV 복사본이 오프라인 VTSS와 MVC에 있고 작업에 VTV가 필요한 경우, VTCS에서 자동으로 VTV를 대체 VTSS(사용 가능한 경우)로 회수합니다.

주:
클라이언트/서버 환경(MVS/CSC 및 LibraryStation 또는 클라이언트 호스트의 SMC/HTTP 서버) 환경에서는 장시간 실행 중인 작업이 클라이언트 호스트에서 활성 상태인지 VTCS에서 확인할 수 없습니다. 따라서 VTSS가 오프라인 상태가 된 후에는 (a) 명시적으로 VTD를 MVS에 대해 오프라인으로 변경하거나 (b) 클라이언트 호스트에 대한 가상 테이프 작업이 중단되었는지 확인해야 합니다.
클러스터화된 VTSS 또는 CTR(Cross-TapePlex Replication) 구성에서는 VTSS에 대한 Clink를 오프라인으로 변경하여 복제 및 전자 내보내기 처리를 중지해야 합니다.

서비스를 위해 VTSS 중지

VTSS를 서비스하기 전에 다음과 같이 VTSS를 중지하십시오.

1. 모든 호스트에서 VTSS를 VTD 오프라인으로 변경합니다.
모든 호스트에서 모든 장치가 오프라인이 될 때까지 기다립니다. 참고로, VTD는 더 이상 할당되지 않을 때까지 오프라인 프로세스를 거치지 않습니다. 장시간 실행 중인 작업이 VTD를 사용할 경우 작업이 완료될 때까지 기다리거나 작업을 취소해야 합니다.

2. 이름이 지정된 VTSS가 정의된 VTCS에서 VTSS를 QUIESCED로 변경합니다.
각 VTCS 시스템에서 VTSS가 중지되었음을 나타내는 SLS6742I 메시지가 나타날 때까지 기다립니다.

3. 선택적으로 VTSS에서 데이터를 마이그레이션할 수 있습니다.

4. 이름이 지정된 VTSS가 정의된 VTCS에서 VTSS를 OFFLINE으로 변경합니다.
각 VTCS 시스템에서 VTSS가 오프라인 상태임을 나타내는 SLS6742I 메시지가 나타날 때까지 기다립니다. 이제 VTSS를 서비스할 수 있습니다.

VTSS 제거

다음은 VTSS 제거 시나리오입니다. 두 개의 개별 VSM 시스템을 만들었는데 한 시스템에 대한 작업 로드는 증가하고 다른 시스템에 대한 작업 로드는 감소합니다. 솔루션: 시스템 A에서 VTSS를 제거하고 시스템 B에 제공하십시오. ELS 설치에 VTSS 추가 방법이 설명되어 있으므로, 이 절에서는 VTSS를 제거하기 위해 수행하는 작업에 대해서만 설명합니다.

VTSS를 제거하려면 다음을 수행하십시오.

1. VTSS를 제거하기 전에 다음을 수행합니다.

- 삭제하기 전에 VTSS를 비울 필요는 없습니다. 해야 할 일은 모든 VTV가 완전히 마이그레이션되었는지 확인하는 것입니다. 또한 새 작업이 제거된 VTSS로 경로 지정되지 않도록 다른 매개변수(예: TAPEREQ 문)를 변경하는 것도 고려하십시오.

- VTSS에서 한 장치 유형/ACS 조합을 모두 제거한 경우 모든 VTV가 제대로 마이그레이션되었는지도 먼저 확인합니다. 위에서 언급했듯이, VTSS의 변경된 마이그레이션 기능(예: ACS 및 매체를 지정하는 스토리지 클래스를 가리키는 관리 클래스)을 반영하도록 다른 매개변수를 변경하는 것을 고려하십시오.

2. VTSS를 중지 상태로 변경합니다.
오프라인 상태가 되면 3단계로 이동합니다.

3. VTSS를 제거한 다음 CONFIG를 다시 실행하여 VTSS를 논리적으로 제거합니다.

다음은 CONFIG를 사용하여 구성에서 물리적으로 제거한 VTSS2에 대한 호스트 액세스를 거부하도록 구성을 업데이트하는 샘플 JCL을 보여줍니다. 이 예에서는 매개변수 없이 VTSS2에 대한 VTSS 문을 다시 지정하여 이 VTSS에 대한 호스트 액세스를 거부합니다.

//UPDATECFGEXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSCNTLDD DSN=FEDB.VSMLMULT.DBASEPRM,DISP=SHR
//SLSCNTL2DD DSN=FEDB.VSMLMULT.DBASESEC,DISP=SHR
//SLSSTBYDD DSN=FEDB.VSMLMULT.DBASETBY,DISP=SHR
//SLSPRINTDD   SYSOUT=*
//SLSINDD   *
CONFIG
GLOBALMAXVTV=32000MVCFREE=40
RECLAIMTHRESHLD=70MAXMVC=40  START=35
VTSSNAME=VTSS1  LOW=70 HIGH=80  MAXMIG=3  RETAIN=5
RTDNAME=VTS18800 DEVNO=8800 CHANIF=0A
RTDNAME=VTS18801 DEVNO=8801 CHANIF=0I
RTDNAME=VTS18802 DEVNO=8802 CHANIF=1A
RTDNAME=VTS18803 DEVNO=8803 CHANIF=1I
RTDNAME=VTS18811 DEVNO=8811 CHANIF=0E
RTDNAME=VTS18813 DEVNO=8813 CHANIF=1E
VTDLOW=8900 HIGH=893F
VTSSNAME=VTSS2

VTV 작업

이 절은 필요시 수행해야 하는 가장 가능성이 높은 작업 즉, 스크래치 VTV 삭제 및 VTV 속성 변경으로 구성됩니다.

주:
SET VOLPARM 또는 CONFIG MVCVOL 처리의 결과로 구성에서 VTV를 삭제하는 경우 다음 사항에 유의하십시오.

- volser를 구성에 MVC로 다시 입력할 수 없습니다.

- 고유의 HSC 테이프에 volser를 사용하지 마십시오.

메시지 SLS6944I는 삭제된 VTV 수를 나타냅니다.

스크래치 VTV 삭제

스크래치 VTV를 삭제할 수 있는 방법은 다음 두 가지입니다.

- 정책에 따라 VTV 관리 클래스에 DELSCR(YES)을 지정하고 HSC 또는 LCM 스크래치 동기화를 사용하여 실제 스크래치를 수행합니다.

- 특정 작업의 경우 DELETSCR 유틸리티를 사용합니다. DELETSCR은 VTSS에서 스크래치 VTV를 삭제하고 마이그레이션된 VTV와 MVC의 링크를 해제합니다. 버전 지정 정보가 유지되더라도 삭제된 VTV는 초기화되지 않은 것으로 표시됩니다.

ELS 설치에서 스크래치 VTV 삭제에 대해 다루므로 이어지는 내용에서는 "필요시" 버전에 대해 다룹니다.

다음 경고에 유의하십시오.

주의:
DELETSCR을 사용하여 스크래치 VTV를 삭제할 경우 해당 VTV에 있는 모든 데이터가 삭제되며 복구할 수 없습니다!

VTV 삭제는 괜히 수행하는 작업이 아닙니다. 스크래치 VTV를 수동으로 삭제해야 한다면 이는 의 시나리오에 표시된 것과 같은 문제가 있기 때문입니다.

운영자 명령을 통해 실수로 VTV를 삭제하는 것을 방지하기 위해 DELETSCR은 SLUADMIN 유틸리티 전용이며, 다음과 같은 기능이 있습니다.

- VTV는 volser(개별 volser, 목록 또는 범위), 관리 클래스 또는 HSC 스크래치 풀별로 지정할 수 있습니다. MVC 및 VTV 보고서를 사용하여 후보를 식별하고 해당하는 DELETSCR 옵션을 적용하는 가장 좋은 방법을 이미 파악했을 것입니다. 한 개의 옵션(VTVid, MGMTclas 또는 SCRpool)만 지정할 수 있으며 아무것도 지정하지 않을 경우 DELETSCR이 해당하는 VTV를 모두 삭제합니다. 이것이 원하는 결과일 수 있지만, 이 방법을 사용하기 전에 잘 생각하십시오.

- 필수 매개변수 NOTREF는 VTV를 참조한 이후의 경과 일 수(1-999)를 지정합니다. NOTREF는 사실상 유예 기간으로, 지정된 유예 기간 내에 참조된 VTV는 삭제되지 않습니다.

- DELETSCR이 삭제하는 최대 VTV 수를 지정하는 편리한(선택적) MAXVTV 매개변수가 있습니다. 이것은 목표값이 아니라 최대값입니다. 사용량이 적은 기간에 미리 DELETSCR을 실행한다면 MAXVTV에 대해 걱정하지 않아도 됩니다. 현재 문제가 있다면 분명히 그런 것입니다.
MAXVTV의 범위는 0-999입니다. 0을 지정할 경우 어떻게 해야 될까요? 이 경우 DELETSCR이 VTV를 삭제하지 않지만, 요약 보고서에 DELETSCR 실행 당시에 삭제되었던 VTV 수가 표시됩니다. 즉, 보고서는 스냅샷에 불과합니다.

- 끝으로, 표준 또는 상세(DETAIL 매개변수 지정) 형식의 DELETSCR 보고서를 통해 작업 결과를 확인할 수 있습니다.

DELTSCR JCL 예

다음은 DELETSCR을 사용하여 60일 내에 참조되지 않은 관리 클래스 MC1에서 스크래치 VTV를 삭제(최대 VTV 800개)하고 자세한 보고서를 생성하는 샘플 JCL을 보여줍니다.

//DELETSCR EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=*
//SLSINDD *
DELETSCR MGMTCLAS(MC1) NOTREF(60) MAXVTV(800) DET

VTVMAINT를 사용하여 VTV 속성 변경

VTVMAINT는 VTV 유지 관리를 위한 편리한 도구로서, 다음과 같은 기능을 수행합니다.

- volser(범위, 목록 또는 선택한 개별 volser)를 기준으로 VTV를 선택합니다.

- VTV와 MVC의 링크를 해제합니다. "VTV 관리 클래스 변경 및 VTV와 MVC 링크 해제"의 설명에 따라 VTV 관리 클래스를 변경한 경우 이 작업이 필요할 수 있습니다.

- VTV를 다르게 관리하려는 경우 VTV 관리 클래스를 변경합니다. 다른 방법으로도 이 작업을 수행할 수 있지만, "VTV 관리 클래스 변경 및 VTV와 MVC 링크 해제"에 설명된 것과 같이 최상의 도구는 VTVMAINT입니다.

- 오프라인 VTSS에서 지정된 VTV를 논리적으로 마운트 해제합니다. 이 기능은 "오프라인 VTSS에서 논리적으로 VTV 마운트 해제"에 가장 잘 설명되어 있습니다.

- "CTR(Cross-TapePlex Replication)을 통해 복제된 VTV 관리."

주:
VTVMAINT를 실행하면 VTVMAINT 작업의 영향을 받는 볼륨의 VTV 보고서도 생성된다는 점을 잊지 마십시오.

VTV 관리 클래스 변경 및 VTV와 MVC 링크 해제

VTVMAINT를 사용하여 VTV 관리 클래스를 변경할 수 있습니다. 새 관리 클래스에 다른 스토리지 클래스가 지정된 경우 MVC에서 VTV의 현재 위치가 올바르지 않습니다. 다음 절차는 VTVMAINT를 사용하여 VTV의 관리 클래스와 스토리지 클래스를 변경하는 방법에 대해 설명합니다.

VTV 관리 클래스를 변경하고 링크를 해제하려면 다음을 수행하십시오.

1. VTV를 회수합니다.
2단계에서 링크 해제가 성공하려면 VTV가 VTSS에 있어야 합니다.

2. VTVMAINT ULINKMVC를 사용하여 VTV와 이 VTV가 있는 MVC의 링크를 해제합니다.

3. VTVMAINT MGMTclas를 사용하여 새 관리 클래스를 지정합니다.

4. VTV가 올바른 MVC에 위치하도록 다시 마이그레이션하거나, RECONcil을 사용하여 VTV 스토리지 클래스 변경에서 필요시 VTV를 MVC로 이동하는 절차를 확인합니다.

오프라인 VTSS에서 논리적으로 VTV 마운트 해제

VTSS가 오프라인일 때 VTV가 마운트되고 VTV 복사본이 MVC에 존재하는 경우, VTV가 오프라인 VTSS에서 마운트된 상태이므로 마이그레이션 VTV가 VTCS에서 대체 VTSS로 회수되지 않습니다. 이 경우 VTVMAINT를 사용하여 오프라인 VTSS에서 논리적으로 VTV를 마운트 해제(CDS에서 "마운트됨" 비트 해제)한 다음 VTV를 대체 VTSS로 회수할 수 있습니다. VTCS는 SMF 하위 유형 14 레코드의 SMF14STA 필드에 성공한 VTV 마운트 해제를 매번 기록합니다. VTVRPT(UNAVAIL) 옵션은 오프라인 VTSS에서 사용 불가능한 VTV의 상태를 보고합니다. 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

VTV의 MVC 복사본(있는 경우)이 사용 불가능한 VTV의 컨텐츠와 확실히 동일한 경우가 아니면 사용 불가능한 VTV를 오프라인 VTSS에서 마운트 해제하지 마십시오. 그렇지 않으면 백 레벨 데이터를 포함하는 VTV가 대체 VTSS로 회수될 위험이 있습니다! 예를 들어 읽기용으로 마운트된 VTV는 대체 VTSS로 회수하기 위해 마운트 해제해도 안전합니다. 그러나 쓰기용으로 마운트된 VTV는 업데이트되는 관계로 MVC 복사본이 벡 레벨이므로 마운트 해제할 경우 안전하지 않습니다.

다음 절차는 VTV를 논리적으로 마운트 해제하고 다른 VTSS에서 해당 VTV에 액세스하는 데 사용할 수 있는 일반 단계를 제공합니다.

VTV를 논리적으로 마운트 해제하고 다른 VTSS에서 해당 VTV에 액세스하려면 다음을 수행하십시오.

1. 다음 명령을 사용하여 VTSS를 VTCS에 대해 오프라인으로 변경합니다.

VT VARY VTSS(name) OFFLINE

I/O가 활성 상태이고 VTSS에서 오류가 발생한 경우 MVS는 VTD를 차단하고 MVS 관점에서 마운트된 VTV를 마운트 해제해야 합니다. 그러나 마운트된 VTV가 VTSS에서 실제로 마운트 해제되기 전에 VTSS와의 통신을 실패한 경우 여전히 VTCS에 대해 온라인 상태일 수 있습니다. 따라서 먼저 VTSS를 VTCS에 대해 오프라인으로 변경해야 합니다.

MVS가 VTD를 차단하고 마운트된 VTV를 마운트 해제한 경우 3단계로 이동합니다. 그렇지 않은 경우 2단계로 이동합니다.

2. VTV를 마운트 해제합니다(MVS 관점).

MVS에서 여전히 VTV가 오프라인 VTSS에서 마운트된 것으로 간주하는 경우 다른 VTSS에 있는 VTD에 VTV를 다시 마운트할 수 없습니다. 다음 중 하나를 수행합니다.

- MVS UNLOAD 명령을 사용하여 VTV를 마운트 해제합니다.

- VARY OFFLINE을 사용하여 VTV가 마운트된 VTD를 오프라인으로 변경합니다. 이 경우에도 VTV가 마운트 해제됩니다.

3. 논리적으로 마운트 해제할 오프라인 VTSS 및 VTV를 지정하여 VTVMAINT를 실행합니다.

예를 들어 오프라인 VTSS01에서 VTV VV6823, VV6825 및 VV6688를 논리적으로 마운트 해제하려면 JCL에서 다음 SLSIN DD 문을 코딩합니다.

VTVMAINT DISMOUNT VTV(VV6823,VV6825,VV6688) VTSS(VTSS01)

온라인 VTSS가 마운트 해제된 VTV의 마이그레이션된 복사본에 액세스할 수 있는 경우 이제 이 VTSS를 사용하여 VTV에 액세스할 수 있습니다.

주의:
오프라인 VTSS에 마운트된 VTV 복사본이 수정된 후 마이그레이션되지 않은 경우 대체 VTSS로 회수되는 MVC 복사본이 최신 상태가 아닙니다! 따라서 오라클은 최신 상태가 아닌 이러한 MVC 복사본을 회수하지 말 것을 강력히 권장합니다!

팁:
오프라인 VTSS가 다시 온라인 상태가 될 준비가 된 경우 오라클은 VTSS를 사용하는 프로덕션 작업을 실행하기 전에 VTSS를 감사할 것을 강력히 권장합니다. VTSS VARY ONLINE 명령을 실행하기 전에 차단된 VTD 조건이 해제되었는지도 확인하십시오.

CTR(Cross-TapePlex Replication)을 통해 복제된 VTV 관리

VTVMAINT를 사용하여 CTR을 통해 복제된 VTV의 상태를 다음과 같이 변경할 수 있습니다.

- TapePlex를 소유한 VTV를 변경하려면 VTVMAINT OWNRPLEX를 사용합니다.

- VTV를 참조하는 TapePlex의 이름을 제거하려면 VTVMAINT DELEXpot를 사용합니다.

- VTV를 참조하는 TapePlex의 이름을 추가하려면 VTVMAINT ADDEXpot를 사용합니다.

자세한 내용은 ELS Disaster Recovery and Offsite Data Management Guide를 참조하십시오.

RECONcil을 사용하여 VTV 스토리지 클래스 변경

"VTV 관리 클래스 변경 및 VTV와 MVC 링크 해제"의 설명에 따라 VTVMAINT를 사용하여 VTV 관리 클래스와 스토리지 클래스를 변경할 수 있습니다. 명시적으로 VTV를 다른 스토리지 클래스로 이동하려는 경우 어떻게 해야 될까요? 답: RECONcil을 사용하십시오.

첫번째 RECONcil 작업(SLUADMIN 유틸리티만 해당)을 제출하기 전에 VTV 스토리지 클래스를 변경하려는 이유를 생각해 보십시오. 기본적으로 세 가지 이유가 있습니다.

- 위에서 언급한 것과 같이, VTV 관리 클래스/스토리지 클래스를 명시적으로 변경하려고 합니다.

- VTV가 잘못된 매체 또는 잘못된 ACS에 있거나 둘 다에 있습니다.

- 상당 기간 동안 ACS를 사용할 수 없다가 다시 온라인 상태가 되었습니다. 이 경우 영향을 받는 VTV가 서로 다른 ACS(원하는 경우 매체)를 가리키도록 MGMTclas 문의 MIGpol 매개변수를 변경합니다. 원래 ACS가 다시 온라인 상태가 되면 원래 ACS를 가리키도록 MGMTclas 문의 MIGpol 매개변수를 변경한 다음 업데이트된 MGMTclas(또는 STORclas) 문을 지정하여 RECONcil을 실행함으로써 VTV를 원래 ACS로 이동합니다.

여기서는 RECONcil을 사용하여 VTV의 잘못된 스토리지 클래스(잘못된 MVC 매체, ACS 위치 또는 둘 다)를 조정하는 방법에 대해 설명합니다. 현재 덜 액세스되는 VTV를 액세스 중심 매체(예 T9840 카트리지)에서 스토리지 중심 매체(예: T9940 카트리지) 및 Extended Store ACS 또는 오프사이트로 이동하려는 경우 어떻게 해야 할까요? 이 경우 일반적으로 MGMTCLAS 문의 ARCHAge/ARCHPol 매개변수를 사용하여 아카이브 정책을 설정하십시오. 그러면 ARCHAge 값을 초과하고 VTV가 회수되어 다시 마이그레이션될 경우 ARCHPol 사양에 따라 자동으로 VTV 이동이 발생합니다.

따라서 자동 아카이브 정책은 자동 마이그레이션과 유사합니다. 둘 다 시간이 경과하면 발생하는데, 하나 이상의 VTV가 잘못된 위치에 있을 경우 시간이 경과할 때까지 기다릴 수는 없습니다. 이 경우 RECONcil을 사용하십시오.

RECONcil 작업 실행

RECONcil을 사용하여 VTV ACS/매체를 변경하려면 다음을 수행하십시오.

1. 다음 RECONcil 매개변수 중 하나를 지정하여 검증(즉, 조정이 필요한지 여부)할 VTV를 선택할 수 있습니다.
STORclas - 하나 이상의 스토리지 클래스를 지정합니다. RECONcil은 다음과 같은 기능을 수행합니다.

- 지정된 스토리지 클래스의 ACS 및 매체 정의를 조회합니다.

- 스토리지 클래스에 현재 있는 MVC를 스캔하여 MVC ACS 및 매체가 스토리지 클래스 정의와 일치하는지 확인합니다. 일치하지 않을 경우 오류가 발생한 MVC/VTV를 나열합니다.

MVC - MVC 목록 또는 범위를 지정합니다. RECONcil은 다음과 같은 기능을 수행합니다.

- 지정된 MVC의 실제 ACS 및 매체를 확인합니다.

- 실제 MVC ACS/매체가 MVC의 스토리지 클래스 정의와 일치하는지 확인합니다. 일치하지 않을 경우 오류가 발생한 MVC/VTV를 나열합니다.

MGMTclas - 하나 이상의 관리 클래스를 지정합니다. RECONcil은 다음과 같은 기능을 수행합니다.

- MGMTclas MIGpol 매개변수에 지정된 ACS 및 매체 정의를 조회합니다.

- 지정된 클래스에 현재 있는 VTV를 스캔하여 ACS/매체의 MVC에 있는 VTV가 MGMTclas MIGpol 사양과 일치하는지 확인합니다. 일치하지 않을 경우 오류가 발생한 MVC에 있는 VTV를 나열합니다.

VTV - VTV 목록 또는 범위입니다. RECONcil은 다음과 같은 기능을 수행합니다.

- 지정된 VTV의 관리 클래스를 확인합니다.

- MGMTclas MIGpol 매개변수에 지정된 ACS 및 매체 정의를 조회합니다.

- 지정된 클래스에 현재 있는 VTV를 스캔하여 ACS/매체의 MVC에 있는 VTV가 MGMTclas MIGpol 사양과 일치하는지 확인합니다. 일치하지 않을 경우 오류가 발생한 MVC에 있는 VTV를 나열합니다.

주:
생각하는 바와 같이, 선택 매개변수를 하나도 지정하지 않을 경우 VTCS에서 모든 VTV를 무효화합니다. 이에 대한 자세한 내용은 2단계에 설명되어 있습니다.

2. RECONcil을 처음 실행하는 경우 보고서만 생성하는 기본값을 적용합니다. 생각하는 바와 같이, 데이터 이동은 발생하지 않고 단순히 조정 대상인 VTV를 보고합니다.

주의:
VTV 조정은 리소스를 많이 사용하는 작업이므로 오라클은 먼저 MOVEVTV 없이 RECONcil을 실행하고 필요에 따라 작업을 조정한 후 MOVEVTV를 지정할 것을 강력히 권장합니다.

3. 필요한 경우 RECONcil 작업을 조정합니다.
예를 들어 2단계에서 보고서를 실행한 결과, 장시간 동안 조정해야 할 경우 다음 사항을 고려하십시오.

- 요청식 MVC 공간 재생의 경우와 마찬가지로, 사용량이 적은 처리 기간 동안에 RECONcil을 실행합니다.

- RECONcil 유틸리티 매개변수로 CONFIG RECLAIM THRESHLD, MAXMVC 및 CONMVC 설정을 대체하여 조정 성능을 최적화합니다.

- 최대 조정 시간(분)을 ELAPSE 매개변수에 지정합니다.

주:
조정에 영향을 주는 제한 계수가 여러 개 있습니다(예: MAXMVC 및 ELAPSE). VTCS에서는 가장 엄격한 제한 계수가 적용됩니다. 예를 들어 RECONcil을 실행하고 ELAPSE를 5시간, MAXMVC를 10으로 설정한 다음 VTCS에서 1시간에 MVC를 10개 조정할 경우, ELAPSE 값이 만료되기 전에 VTCS에서 조정이 종료됩니다.

- ARCHive 유틸리티에서 사용 가능하며 유용한 진단을 제공하는 RECONcil POLICYdd 옵션도 있습니다. 보고서만 생성하도록 지정하는 POLICYdd는 대체 MGMTclas 문 세트가 포함된 파일을 가리킵니다.

팁:
이 옵션은 기본적으로 VTV 관리 클래스 변경 및 VTV와 MVC 링크 해제(스토리지 클래스 사양 포함)에 설명된 일부 VTV 관리 클래스를 변경한 다음 RECONcil을 실행한 경우 그 결과가 어떠한지를 보여주는 중요한 ”what if” 도구입니다. 이제 VTV 관리 클래스를 실제로 변경하기 전에 결과를 알 수 있습니다.

주:
RECONcil 요청을 처리하기 위해서는 VTCS 및 HSC가 활성 상태여야 합니다. 단, POLICYdd 매개변수를 지정한 경우는 예외입니다.

4. 필요한 ”what if”, 미세 조정 및 오프피크 일정을 모두 완료했습니다.
이제 실제로 수행할 차례입니다. 다음은 RECONcil을 실행하는 예제 JCL을 보여줍니다.

- 관리 클래스 LOCALPROD1 및 LOCALPROD2에서 VTV를 조정합니다.

- RECONcil 작업에 대해 MAXMVC를 60, CONMVC를 8, ELAPSE를 60으로 설정합니다.

//RECONCIL    EXEC PGM=SLUADMIN
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=*
//SLSINDD *
RECON MGMT (LOCALPROD1,LOCALPROD2) MAXMVC(60) CONMVC(8)
ELAPSE(360) MOVEVTV

얼마나 순조롭게 진행되었는지를 보여주는 실행 후 RECONcil 보고서도 제공되므로 필요에 따라 프로세스를 다시 조정하고 다시 실행할 수 있습니다.

FOR_LOSTMVC를 사용하여 VTV 복구

LOGUTIL FOR_LOSTMVC 문을 사용하여 손실 또는 손상된 MVC에 있는 VTV를 복구할 수 있습니다. LOGUTIL FOR_LOSTMVC 문이 어떻게 작동하며 이를 보다 효율적으로 사용하는 방법은 무엇일까요?

FOR_LOSTMVC 유틸리티는 CDS 및 로그 파일 구조(필요한 경우)를 스캔하여 지정한 volser를 갖는 손실 또는 손상된 MVC에 있는 모든 VTV를 식별하고 테이블 5-2에 설명된 것과 같이 대체 VTV 복사본에서의 복구 방법을 결정합니다. LOGUTIL FOR_LOSTMVC는 손실 또는 손상된 MVC에 있는 모든 VTV와 복구 방법 이외에도 손실 또는 손상된 각 MVC에 대한 요약 정보를 보여줍니다.

테이블 5-2 대체 VTV 복사본 및 복구 프로세스

대체 VTV 복사본 범주

복구 프로세스

범주 1: 현재 VTSS에 상주함

상주 복사본에서 복구가 수행됩니다. 복구 명령을 요청한 경우 VTVMAINT ULINKMVC 명령이 생성되어 손실 또는 손상된 MVC와 VTV의 링크를 해제합니다.

범주 2: 하나 이상의 대체 MVC 복사본에 현재 링크되어 있음

다음 4가지 요소를 기준으로 최상의 대체 MVC에서 복구가 수행됩니다.

- MVC 레코드가 MVC의 CDS에 존재하는가?

- MVC가 손실된 상태인가?

- MVC가 손상된 상태인가?

- 데이터 검사가 MVC에서 수행되었는가?

복구 명령을 요청한 경우 VTVMAINT ULINKMVC 및 RECALL 명령이 생성되어 손실 또는 손상된 MVC와 VTV의 링크를 해제한 다음 MVC를 회수합니다.

범주 3: CTR(Cross-TapePlex Replication)이 수행됨

VTV의 복사본이 포함된 첫번째로 발견된 원격 TapePlex가 VTV 복구에 사용됩니다.

복구 명령을 요청한 경우 EEXPORT ULINKMVC 명령이 생성됩니다. 이 명령은 VTV가 현재 있는 원격 TapePlex에서 실행되어야 합니다. COMMANDS 데이터 세트의 주석에 이 명령을 실행해야 하는 TapePlex가 표시됩니다. 이 명령은 손실 또는 손상된 MVC와 VTV의 링크를 해제한 다음 VTV를 다시 로컬 TapePlex로 CTR합니다.

범주 4: 이전에 하나 이상의 MVC 복사본에 링크되었으며 이 복사본에 여전히 VTV 데이터가 포함되어 있을 수 있음

이전에 링크된 MVC 중 하나가 복구 MVC로 선택되었습니다. 이러한 MVC 복사본은 로그 파일에 있으며 여전히 VTV 복사본을 포함하고 있을 수 있습니다. 선택한 복구 MVC를 감사해야 합니다. 대체 MVC와 동일한 요소를 기준으로 이전에 링크된 MVC 복사본 중 복구를 수행하기에 가장 적합한 복사본이 선택됩니다.

복구 명령을 요청한 경우 AUDIT 명령이 생성되어 MVC를 감사하고 이를 VTV에 링크하려고 시도합니다.

AUDIT MVC에 대해 MVCMAINT READONLY(ON) 명령이 생성됩니다.

범주 5: 복구할 수 없음

복구할 수 없습니다. 복사본이 손실 또는 손상된 MVC에만 있습니다.

주:
복구 명령을 요청한 경우 MVCMAINT 명령이 범주 1, 2, 3, 4에 대해 생성됩니다. 이 명령문은 손실 또는 손상된 MVC가 더 이상 회수 또는 마이그레이션 대상으로 선택되지 않도록 읽기 전용 및 손상으로 표시합니다.

FOR_LOSTMVC 복구 절차

주:
이 절차의 JCL 예제에는 CDS 복사본에 대한 DD 문이 표시되지 않습니다. 이는 HSC가 활성 상태이고 LOGUTIL을 실행 중인 시스템에서 활성 CDS를 사용하려는 경우에 유효합니다. 그렇지 않은 경우 CDS 복사본에 대해 DD 문을 지정해야 합니다.

FOR_LOSTMVC를 사용하여 VTV를 복구하려면 다음을 수행하십시오.

1. 먼저 LOGUTIL FOR_LOSTMVC 명령을 손실 또는 손상된 MVC의 volser와 함께 실행합니다.

예를 들어 다음 예가 보여주는 내용은 다음과 같습니다.

- 로깅 데이터 세트는 LOGIN입니다.

주:
LOGUTIL FOR_LOSTMVC를 지정된 더미 LOGDD와 함께 실행하면 CDS 로깅이 활성화되지 않은 시스템에서 복구를 수행할 수 있습니다. 이 경우 복구가 CDS에 있는 데이터로 제한되지만, 모든 VTV가 대체 MVC 복사본에 있거나 CTR(Cross Tape Replication)을 통해 내보낸 경우에는 유용할 수 있습니다.

- 손상된 MVC의 volser는 DMV509입니다.

- 복구 명령은 데이터 세트 RECVCMD에 로깅됩니다.

//JOBLOGR job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//LOGIN        DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD
//RECVCMD      DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE),
//                UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//                DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
LOGUTIL LOGDD(LOGIN)
FOR_LOSTMVC MVC(DMV509) COMMANDS(RECVCMD)

2. 1단계에서 생성된 LOGUTIL FOR_LOSTMVC 보고서를 검토합니다.

복구할 VTV를 선택한 다음 손실 또는 손상된 MVC에서 복구할 VTV를 지정하여 LOGUTIL FOR_LOSTMVC를 다시 실행합니다. 예를 들면 다음과 같습니다.

//JOBLOGR job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//LOGIN        DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD
//RECVCMD      DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE),
//                UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//                DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
LOGUTIL LOGDD(LOGIN)
FOR_LOSTMVC MVC(DMV509) VTV(DX009) COMMANDS(RECVCMD)

주:
손실 또는 손상된 MVC에 없는 VTV를 지정할 경우 해당 VTV는 무시됩니다.

손상된 MVC에서 지정된 VTV를 모두 복구하려면 3단계로 이동합니다.

3. 지정된 VTV를 복구하려면 2단계에서 지정한 복구 데이터 세트의 명령을 실행합니다.

주:

- 복구 데이터 세트의 명령은 FOR_LOSTMVC를 실행한 후 가능한 빨리 실행(표준 SLUADMIN JCL 사용)해야 정확도가 보장됩니다.

- 오라클은 COMMANDS 파일의 복구 명령을 다음 순서로 실행할 것을 권장합니다.

1. 모든 EEXPORT ULINKMVC 명령

2. 모든 MVCMAINT READONLY(ON) 명령

3. 모든 AUDIT 명령

4. EEXPORT ULINKMVC 또는 AUDIT 명령이 있는 경우 FOR_LOSTMVC를 다시 실행합니다. 새로 실행하는 경우 EEXPORT 또는 AUDIT 명령이 새로 생성된 COMMANDS 파일에 없어야 합니다. 있을 경우 a단계로 돌아갑니다.

5. 모든 MVCMAINT READONLY(ON) ERROR(ON) 명령

6. 모든 ULINKMVC 명령

7. 모든 RECALL 명령

8. RECONcil 유틸리티
MVCMAINT 명령은 지정된 모든 손실 또는 손상된 MVC 중에서 CDS에 있으며 적합한 VTV가 적어도 한 개 있는 MVC에 대해 생성됩니다. MVCMAINT 명령은 손실 또는 손상된 MVC가 회수 또는 마이그레이션 대상으로 할당되지 않도록 이들에 대해 읽기 전용 및 오류/손상 비트를 설정합니다. 각 MVCMAINT 명령에는 최대 3000여 개의 MVC가 포함됩니다.

4. RECONcil 유틸리티를 실행하여 각 VTV에 대해 올바른 개수의 MVC 복사본이 만들어졌는지 확인합니다.
예를 들면 다음과 같습니다.

//JOBLOGR job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//LOGIN        DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD
//RECVCMD      DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE),
//                UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//                DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
RECONCIL VTV(DX009)

6 관리 및 스토리지 클래스를 사용하는 첨단 솔루션

이 절을 참조하여 VTCS 관리 및 스토리지 클래스를 만들고 이러한 클래스와 연관된 일반 작업을 수행할 수 있습니다.

VTCS CDS 레벨

최신 솔루션에 대한 중요한 항목은 CDS VTCS 레벨 및 수행할 수 있는 작업과 수행할 수 없는 작업을 확인하기 위한 것입니다. 테이블 6-1에는 CDS 레벨과 지원되는 기능이 설명되어 있습니다.

테이블 6-1 지원되는 VTCS 버전에 대한 CDS 레벨

VTCS CDS 레벨:

VTCS/NCS 버전:

향상된 기능:

E

6.0, 6.1, 6.2, 7.0

- MVC 복사본 4개

- 800Mb VTV

F

6.1, 6.2, 7.0, 7.1, 7.2, 7.3

- NCO(Near Continuous Operations)

- 양방향 클러스터화

- 향상된 CDS I/O 성능 - 가상 스크래치 하위 풀 관리에 필요한 I/O 감소

G

6.2, 7.0, 7.1, 7.2, 7.3

- 400Mb/800Mb/2Gb/4Gb VTV

- 표준/큰 VTV 페이지

- MVC당 65000 VTV

H

7.1, 7.2, 7.3

- 동적 재확보

- 자율 장치 지원

I

7.3

- VSM 6 32GB VTV 지원

관리 및 스토리지 클래스란?

VTCS 관리 및 스토리지 클래스는 수많은 첨단 기술 구현의 구성 요소로서, 다음과 같은 작업을 수행합니다.

- VTCS 관리 클래스는 VTCS가 VTV를 관리하는 방식을 지정합니다. HSC MGMTclas 제어문은 관리 클래스와 해당 속성을 정의합니다. 예를 들어 MGMTclas 문의 DELSCR 매개변수는 VTCS가 스크래치된 VTV를 VTSS에서 삭제할지 여부를 지정합니다.

- 관리 클래스는 VTCS 스토리지 클래스를 가리킬 수도 있습니다. VTCS 스토리지 클래스는 마이그레이션된 VTV의 상주 위치를 지정합니다. HSC STORclas 제어문은 스토리지 클래스와 해당 속성을 정의합니다. 예를 들면 다음과 같습니다.

MGMT NAME(PAYROLL) MIGPOL(LOCAC,REMAC)
STORCLAS NAME(LOCAC) ACS(00) MEDIA(STK1R)
STORCLAS NAME(REMAC) ACS(01) MEDIA(STK2P,ZCART)

이러한 관리 및 스토리지 클래스 조합의 경우 다음과 같은 메시지가 표시됩니다. ”관리 클래스 PAYROLL의 경우, MVC를 로컬 및 원격 ACS에 분리할 수 있도록 이중으로 마이그레이션하십시오. 로컬 ACS에서는 필요할 때 신속하게 다시 사용할 수 있도록 9840 매체에 저장하십시오. 원격 ACS에서는 ZCART 매체보다 9940을 사용하는 것이 좋지만, 반드시 깊은 스토리지에 저장하십시오.”

먼저 자신의 비즈니스 요구에 맞게 조정할 수 있는 기본 절차인 "VTCS 관리 및 스토리지 클래스 만들기 및 사용: 기본 사항"을 검토하십시오. 그 다음으로, "관리 및 스토리지 클래스를 사용하여 수행할 수 있는 첨단 기술"을 검토하십시오. 이 절은 다양한 옵션을 확인한 다음 자신에게 가장 적합한 옵션을 선택할 수 있는 갤러리입니다.

VTCS 관리 및 스토리지 클래스 만들기 및 사용: 기본 사항

TAPEREQ > POLICY > MGMTclas > STORclas 패턴은 "관리 및 스토리지 클래스를 사용하여 수행할 수 있는 첨단 기술"에 나오는 모든 정보에 대한 토대가 되기 때문에 아주 많이 볼 수 있습니다.

VSM 관리 및 스토리지 클래스를 만들고 사용하려면

1. STORclas 및 MGMTclas 문이 포함된 정의 데이터 세트를 확인합니다.
MGMTclas 및 STORclas 문은 상호 검증을 위해 반드시 동일한 데이터 세트에 있어야 합니다.

2. STORclas 제어문을 통해 스토리지 클래스를 정의합니다.

3. 원하는 경우 MIGRSEL 및 MIGRVTV 문을 사용하여 마이그레이션 정책을 조정합니다.

4. MGMTclas 제어문을 사용하여 관리 클래스를 정의합니다.

MGMTclas 제어문은 다양한 매개변수에 스토리지 클래스를 지정합니다.

5. HSC MGMTDEF 명령을 사용하여 제어문을 로드합니다.

6. SMC POLICY 명령에 테이프 정책을 지정합니다.

7. 다음 중 하나에 VTCS에 대한 정책 이름을 지정합니다.

- SMC TAPEREQ 문

- StorageTek DFSMS 인터페이스에 기록한 SMS 루틴

관리 및 스토리지 클래스 유지 관리

다음 사항에 유의하십시오.

- 관리 클래스를 마운트에 지정하려면 항상 SMC POLICY 명령을 사용합니다.

- TAPEREQ 문 또는 SMS 루틴을 사용하여 정책을 정의할 수 있습니다.

- SMC POLICY 문이 모두 VALID MGMTCLAS 이름을 참조하는지 확인하려면 POLICY VALIDATE를 사용합니다.

- VTVMAINT 유틸리티를 사용하여 VTV의 관리 클래스를 변경할 수 있습니다.  VTVMAINT를 사용하여 VTV 스토리지 클래스를 직접 변경할 수는 없지만, VTV 관리 클래스를 변경할 수 있으므로 서로 다른 스토리지 클래스를 참조할 수 있습니다.

- 구현하려는 정책을 정의하는 데 필요한 최소한의 스토리지 클래스만 사용합니다. 스토리지 클래스가 지나치게 많을 경우 MVC 마운트/마운트 해제 오버헤드가 발생하여 VSM 성능에 영향을 미칠 수 있습니다. 또한 MVC에서는 하나의 스토리지 클래스에만 VTV를 포함할 수 있으므로, 스토리지 클래스가 지나치게 많을 경우 MVC 공간이 충분히 사용되지 않을 수 있습니다.

- 관리 클래스 정의를 삭제하려는 경우, VTV 보고서를 실행하여 관리 클래스가 더 이상 VTV에 지정되지 않는지 확인합니다. 그렇지 않을 경우 예상치 않은 결과가 발생합니다!

관리 및 스토리지 클래스를 사용하여 수행할 수 있는 첨단 기술

다음은 해당되는 작업을 총망라한 목록이 아니라 관리 및 스토리지 클래스로 수행할 수 있는 가장 일반적인 작업입니다.

- MVC 매체 환경 설정에 STORclas MEDIA 매개변수 사용. MVC 매체 환경 설정에 대한 기본값은 있지만, 원하는 방식으로 조정할 수 있습니다. 자세한 내용은 HSC 및 VTCS 관리를 참조하십시오.

- "공유 MVC에서 여러 작업 로드 그룹화." 이것은 예로서, 회사가 데이터 센터를 소유하고 있고 다음을 수행하여 사용 가능한 리소스 사용을 최적화하려는 경우에 유용합니다.

- 중요한 데이터를 이중화하여 MVC를 로컬 및 원격 ACS에 분리합니다. 로컬 ACS에서는 필요할 때 신속하게 다시 사용할 수 있도록 9840 매체에 저장하십시오. 원격 ACS에서는 고용량 매체의 깊은 스토리지를 위해 ZCART 매체보다 9940을 사용하는 것이 좋습니다.

- 이러한 관리/스토리지 클래스에 두 개의 중요한 작업 스트림(급여 및 회계) 액세스 권한을 부여합니다. 결과: 모든 급여 및 회계 데이터가 로컬 및 원격에서 이중화되고, 스토리지 클래스 사양에 설명된 적합한 매체의 동일한 MVC 세트에서 그룹화됩니다.

- 프로덕션 데이터도 중요하지만, 급여 및 회계 데이터에 사용되는 것과는 별도의 MVC 세트에 저장하고자 할 수 있습니다. 이 경우에도 문제 없습니다. 프로덕션 데이터용으로 다른 관리 클래스/스토리지 클래스 조합을 만들면 됩니다.

- "별도의 MVC 세트에 개별 작업 로드 분리." 앞으로 아주 많이 사용하게 될 것이므로 모든 서비스 그룹에서는 이 작업을 주의깊게 살펴보십시오. 고객 각각에게 청구/보안 목적의 고유한 리소스 세트를 제공하고 싶습니까? 그렇다면 작업 로드를 분리하는 것이 그 열쇠입니다.

- "데이터 아카이브." 이 경우에는 VTCS를 사용하여 StorageTek 자동 테이프/가상 테이프 환경에서만 HSM을 모방할 수 있습니다. 즉, MGMTclas 문의 ARCHAge 및 ARCHPol 매개변수를 사용하여 VTV에 대한 아카이브 정책을 관리 클래스에 설정할 수 있습니다.
StorageTek 스토리지 관리 전략인 ILM(Information Lifecycle Management)의 중심 개념은 기업 입장에서의 중요도와 재사용 패턴과 일치하는 매체에 데이터를 저장해야 한다는 것입니다. 즉, 활성 상태이고 중요한 데이터는 빠른 액세스 매체에 있지만, 비활성 상태이고 덜 중요한 데이터는 더 저렴한 고용량 매체에 아카이브됩니다. 이 프로세스를 자동화하는 것이 데이터 스토리지를 관리하는 가장 비용 효율적인 방법으로, 비활성 데이터를 아카이브하는 방식으로 ILM을 구현합니다. VTCS 아카이브를 사용할 경우 VTV를 다른 매체(예: 빠른 액세스 9840 매체에서 고용량 9940 매체까지) 및 다른 위치(예: 로컬 ACS에서 배출/원격 보관용 원격 ACS까지)로 이동할 수 있습니다. 자세한 내용은 "데이터 아카이브"를 참조하십시오.

- "VTV 매체 및 위치 조정." 아카이브는 사전 예방적 조치로 사용하십시오. ILM 주기가 시작될 때 데이터를 올바른 매체에 저장했다가 데이터가 오래되면 다른 매체로 이동하십시오. 데이터가 잘못된 매체에 계속 있을 경우 어떤 일이 발생할까요? 답: RECONcil 유틸리티를 사용하여 데이터를 한 스토리지 클래스에서 다른 스토리지 클래스로 이동하십시오.

- VTV 마이그레이션 제어. ELS를 사용하면 스크래치 VTV를 VTSS 버퍼에서 삭제하고, 즉시 마이그레이션 지연 간격을 지정하며, 최대 VTV 상주 간격을 지정하는 등 VTV 마이그레이션을 매우 정교하게 제어할 수 있습니다. 자세한 내용은 Configuring HSC and VTCS 및 ELS Disaster Recovery and Offsite Data Management Guide를 참조하십시오.

공유 MVC에서 여러 작업 로드 그룹화

스토리지 및 관리 클래스를 사용하여 공유 MVC 세트에서 여러 개의 작업 로드를 그룹화할 수 있습니다. 예를 들어 아래의 STORclas 문은 스토리지 클래스 LOC1, LOC2, REM1 및 REM2를 정의합니다.

STORCLAS NAME(LOC1) ACS(00) MEDIA(STK1R)
STORCLAS NAME(LOC2) ACS(00) MEDIA(STK1R)
STORCLAS NAME(REM1) ACS(01) MEDIA(STK2P,ZCART)
STORCLAS NAME(REM2) ACS(01) MEDIA(STK2P,ZCART)

- 관리 클래스 PAY와 ACCOUNT 모두 MIGPOL 매개변수에 LOC1 및 REM1 스토리지 클래스를 지정합니다. 따라서 PAY 및 ACCOUNT의 VTV는 스토리지 클래스 LOC1 및 REM1에 정의된 MVC에서 이중화되고 그룹화됩니다.

- 관리 클래스 PROD는 MIGPOL 매개변수에 LOC2 및 REM2 스토리지 클래스를 지정합니다. 따라서 PROD의 VTV는 스토리지 클래스 LOC2 및 REM2에 정의된 MVC에서 이중화되고 그룹화되므로, PAY 및 ACCOUNT와 분리됩니다.

MGMT NAME(PAY) MIGPOL(LOC1,REM1)
MGMT NAME(ACCOUNT) MIGPOL(LOC1,REM1)
MGMT NAME(PROD) MIGPOL(LOC2,REM2)

다음은 가상 매체를 지정하고 관리 클래스 PAY, ACCOUNT 및 PROD를 각각 지정하는 테이프 정책을 정의합니다.

POLICY NAME (PPAY) MEDIA(VIRTUAL) MGMT(PAY)
POLICY NAME (PACCOUNT) MEDIA(VIRTUAL) MGMT(ACCOUNT)
POLICY NAME (PPROD) MEDIA(VIRTUAL) MGMT(PROD)

끝으로, 이 예는 다음과 같이 정책을 지정하는 TAPEREQ 문으로 구성됩니다.

- PPAY 정책에 PAYROLL.** 한정자가 있는 데이터 세트가 지정됩니다.

- PACCOUNT 정책에 ACCOUNTS.** 한정자가 있는 데이터 세트가 지정됩니다.

- 다른 모든 데이터 세트는 PPROD 정책에 지정됩니다.

TAPEREQ DSN(PAYROLL.**) POLICY(PPAY)
TAPEREQ DSN(ACCOUNTS.**) POLICY(PACCOUNT)
TAPEREQ DSN(**) MEDIA(VIRTUAL) POLICY(PPROD)

MVC가 스토리지 클래스에 사용되는 경우 현재 VTV 복사본을 포함하면서 해당 스토리지 클래스에 계속 배타적으로 지정됩니다. MVC에서의 이 VTV 그룹화는 MVC에서 재생 처리가 발생한 이후에도 유지됩니다.

주의:
작업 로드를 그룹화하는 데 기본 스토리지 클래스(재생 또는 마이그레이션을 위해 MVC에 기록한 마지막 VTSS의 이름)는 사용할 수 없습니다.

별도의 MVC 세트에 개별 작업 로드 분리

스토리지 및 관리 클래스를 사용하여 별도의 MVC 세트에서 개별 작업 로드를 분리할 수 있습니다. 예를 들어 아래의 STORclas 문은 스토리지 클래스 LOC, CUSTA, CUSTB1 및 CUSTB2를 정의합니다.

STORCLAS NAME(LOC) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTA) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTB1) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTB2) ACS(01) MEDIA(STK2P)

아래의 예는 다음과 같은 관리 클래스를 정의합니다.

- 관리 클래스 CUSTA는 MIGPOL 매개변수에 CUSTA 스토리지 클래스를 지정합니다. VTCS는 이 관리 클래스의 VTV를 오직 CUSTA 스토리지 클래스(로컬 ACS의 9840 매체)에 대해서만 단방향화합니다. 이 클래스가 이 고객이 원하는 클래스이기 때문입니다.

- 고객 B는 보다 강력한 보호(즉, 로컬 및 원격 ACS에 대한 이중화)를 원하므로 관리 클래스 CUSTB는 CUSTB1 및 CUSTB2 스토리지 클래스를 둘 다 가리킵니다.

- 끝으로, 로컬 ACS/9840 매체는 관리 클래스 PROD의 경우와 마찬가지로, 고유한 프로덕션 데이터에 적합합니다. 사용자는 이 관리 클래스에 대한 아카이브 정책을 설정하면 됩니다(데이터 아카이브 참조). 그러면 결과적으로 깊은 스토리지로 이동할 수 있습니다.

MGMT NAME(CUSTA) MIGPOL(CUSTA)
MGMT NAME(CUSTB) MIGPOL(CUSTB1,CUSTB2)
MGMT NAME(PROD) MIGPOL(LOC)

이 예는 가상 매체를 지정하고 관리 클래스 PAY, ACCOUNT 및 PROD를 각각 지정하는 테이프 정책을 정의합니다.

POLICY NAME (PCUSTA) MEDIA(VIRTUAL) MGMT(CUSTA)
POLICY NAME (PCUSTB) MEDIA(VIRTUAL) MGMT(CUSTB)
POLICY NAME (PPROD) MEDIA(VIRTUAL) MGMT(PROD)

끝으로, 아래의 예는 해당하는 TAPEREQ 문과 정책 지정 사항을 보여줍니다.

- PCUSTA 정책에 HLQ CUSTA가 있는 데이터 세트가 지정됩니다.

- PCUSTB 정책에 HLQ CUSTB가 있는 데이터 세트가 지정됩니다.

- 다른 모든 데이터 세트는 PPROD 정책에 지정됩니다.

TAPEREQ DSN(CUSTA.**) POLICY(PCUSTA)
TAPEREQ DSN(CUSTB.**) POLICY(PCUSTB)
TAPEREQ DSN(**) POLICY(PPROD)

주의:
작업 로드를 분리하는 데 기본 스토리지 클래스(재생 또는 마이그레이션을 위해 MVC에 기록한 마지막 VTSS의 이름)는 사용할 수 없습니다.

데이터 아카이브

MGMTclas 문의 ARCHAge 및 ARCHPol 매개변수를 사용하여 VTV에 대한 아카이브 정책을 관리 클래스에 설정할 수 있습니다. VTV의 사용 기간이 ARCHAge 값을 초과할 경우 ARCHPol 매개변수에 지정된 스토리지 클래스에 VTV를 아카이브할 수 있습니다. 실제 아카이브는 다음 두 가지 방법 중 하나로 수행됩니다.

- 다음에 VTV를 회수하고 다시 마이그레이션할 때 자동으로 수행됩니다.

- 요청이 있을 때 ARCHIve 유틸리티를 사용하여 수행됩니다.

이에 대한 "가정"은 규정을 준수하도록 보장하기 위한 것일 수 있습니다. 외부 감사자를 위해 7년 동안 보존해야 하지만, 내부 감사자의 입장에서는 1년에 한번씩 살펴보고자 하는 데이터가 있습니다. 이에 대한 솔루션은 다음과 같습니다.

TAPEREQ DSN(COMPLY.**) POLICY(PCOMPLY)
POLICY NAME(PCOMPLY) MEDIA(VIRTUAL) MGMT(COMPLY)
MGMT NAME(COMPLY) IMMMED(DELETE) MIGPOL(LOC1) -
ARCHAGE(365) ARCHPOL(REMDEEP)
STOR NAME(LOC1) ACS(00) MEDIA(STK1R)
STOR NAME(REMDEEP) ACS(01) MEDIA(STK2P)

이 경우 다음과 같은 작업이 수행됩니다.

- 모든 준수 데이터가 즉시 로컬 ACS로 마이그레이션되고 9840 매체에서 그룹화됩니다. 성공적으로 마이그레이션되면 VTV가 VTSS에서 삭제됩니다. 내부 감사자가 데이터를 내년에 확인하고자 할 경우 이 데이터에 대한 "아카이브 기간"은 365일입니다.

- 이 기간이 경과하면 데이터를 원격 ACS의 9940 매체에 아카이브(이동)할 수 있습니다.

결과: 가상 리소스를 최적화하면서 가능한 최상의 비용으로 준수가 보장됩니다.

아카이브 사용 시 참고 사항

위에서 설명했듯이, 실제 아카이브에 사용할 수 있는 방법에는 두 가지가 있습니다. 즉, VTV가 회수되고 마이그레이션될 때까지 기다리거나, 요청이 있을 때 ARCHIve 유틸리티를 사용하여 수행할 수 있습니다. 다시 마이그레이션될 때까지 기다릴 경우의 문제는 데이터에 액세스되지 않을 수 있다는 점입니다. VTV를 아카이브하는 가장 좋은 방법은 ARCHIve 유틸리티를 자동으로 또는 필요시 실행하는 것입니다.

ARCHive 유틸리티 사용에 대한 몇 가지 팁은 다음과 같습니다.

- 다음 매개변수 중 하나를 지정하여 아카이브할 VTV를 선택할 수 있습니다.

- MGMTclas - 지정된 관리 클래스의 ARCHAge/ARCHPol 매개변수에 지정된 스토리지 클래스에 VTV를 아카이브합니다.

- VTV - 해당 VTV에 대한 관리 클래스의 VTV 목록 또는 범위를 아카이브합니다.

주:
MGMTclas 또는 VTV의 값을 지정하지 않으면 VTCS에서 모든 VTV가 스캔됩니다. 관리 클래스를 통해 작업을 수행해야 하지만, VTV volser 또는 모든 VTV를 통해 작업을 수행하고자 할 수 있습니다.

- MOVEVTV 매개변수를 지정하지 않으면 아카이브 요청으로 처리할 수 있는 VTV, MVC, 및 총 MB 수를 보여주는 중요한 "what if" 상황을 보여주는 보고서가 제공됩니다. 따라서 오라클은 먼저 MOVEVTV 없이 ARCHIve를 실행하고 필요에 따라 작업을 조정한 후 MOVEVTV를 지정할 것을 강력히 권장합니다. 자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

- 요청 아카이브는 리소스를 많이 사용하므로 ARCHIve는 일반적으로 사용량이 적은 처리 기간 동안에 실행합니다. ARCHIve 유틸리티로 CONFIG RECLAIM THRESHLD, MAXMVC 및 CONMVC 설정을 대체하여 아카이브 성능을 최적화할 수도 있습니다. 최대 아카이브 시간(분)을 ELAPSE 매개변수에 지정할 수도 있습니다. 아카이브에 영향을 주는 제한 계수가 여러 개 있습니다(예: MAXMVC 및 ELAPSE). VTCS에서는 가장 엄격한 제한 계수가 적용됩니다. 예를 들어 ARCHIve를 실행하고 ELAPSE를 5시간, MAXMVC를 10으로 설정한 다음 VTCS에서 1시간에 MVC를 10개 아카이브할 경우, ELAPSE 값이 만료되기 전에 VTCS에서 아카이브가 종료됩니다.

- ARCHIve 요청을 처리하기 위해서는 VTCS 및 HSC가 활성 상태여야 합니다. 단, POLICYdd 매개변수를 지정한 경우는 예외입니다. POLICYdd(강제로 "보고서 전용" 모드를 수행함)도 향상된 ”what if” 기능을 제공합니다. 다른 아카이브 정책(서로 다른 ARCHAge 및 ARCHPol 값)을 사용하여 대체 MGMTclas 문을 하나 이상 작성한 다음 POLICYdd를 사용하여 각 시나리오에 대한 아카이브 정책 및 리소스 사용을 확인할 수 있습니다.

- RECONcil 유틸리티도 VTV를 한 스토리지 클래스에서 다른 스토리지 클래스로 이동(즉, 한 MVC 매체에서 다른 MVC 매체로 이동 및/또는 한 ACS에서 다른 ACS로 이동)하므로 ARCHive와 비슷합니다. ARCHive는 사전 예방적 조치로, RECONcil은 대응적 조치로 사용하고, 차이점은 "VTV 매체 및 위치 조정"에 설명된 내용을 확인합니다.

365일이 경과하고 내부 감사자가 나타나지 않는다면 아카이브해야 할 때입니다. 아래 예는 다음과 같이 ARCHive를 실행하기 위한 JCL을 보여줍니다.

- 관리 클래스 COMPLY의 VTV를 원격 ACS의 9940 매체에 아카이브합니다.

- ARCHive 작업에 대해 MAXMVC를 60, CONMVC를 8, ELAPSE를 60으로 설정합니다.

//ARCHIVE     EXEC PGM=SLUADMIN
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=*
//SLSINDD *
ARCH MGMT(COMPLY) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV

팁:
MOVEVTV 매개변수도 보고서를 제공하므로 작업이 잘(또는 잘못) 수행되었는지 확인할 수 있습니다. 조정 매개변수로 원하는 모든 항목을 아카이브하지 못한 경우 작업을 조정한 후 다시 실행하십시오.

VTV 매체 및 위치 조정

RECONcil을 사용하여 VTV 매체와 위치를 조정한다는 것은 기본적으로 VTV를 다른 스토리지 클래스로 이동하는 것을 의미합니다. ARCHive로 데이터를 아카이브하는 것과 비슷할까요? 데이터 이동의 관점에서는 비슷하지만, 수행 이유의 관점에서는 사전 대응적 조치가 아닌 대응적 조치로 수행됩니다. VTV 조정은 보통 다음과 같은 경우에 수행됩니다.

- VTV가 잘못된 매체 또는 잘못된 ACS에 있거나 둘 다에 있습니다.

- 상당 기간 동안 ACS를 사용할 수 없다가 다시 온라인 상태가 되었습니다. 이 경우 영향을 받는 VTV가 서로 다른 ACS(원하는 경우 매체)를 가리키도록 MGMTclas 문의 MIGpol 매개변수를 변경합니다. 원래 ACS가 다시 온라인 상태가 되면 원래 ACS를 가리키도록 MGMTclas 문의 MIGpol 매개변수를 변경한 다음 업데이트된 MGMTclas(또는 STORclas) 문을 지정하여 RECONcil을 실행함으로써 VTV를 원래 ACS로 이동합니다.

조정 프로세스에 대한 자세한 내용은 "조정 예"를 참조하십시오.

조정 예

잘못된 매체 및 잘못된 ACS에 있는 VTV를 조정하려는 경우 이러한 사실을 어떻게 알 수 있을까요? HSC 및 VTCS 관리에 설명된 것과 같이 VTV 보고서를 매주 정독하십시오. 프로덕션(PROD) 관리 클래스에 있는 모든 VTV가 잘못된 매체 및 잘못된 ACS에 있다는 것을 이번 주에 알게 됩니다. 또한 스토리지 클래스도 무엇인가 잘못된 것 같습니다.

어떻게 이러한 일이 발생했을까요? 다음을 수행했다고 간주하십시오.

STORCLAS NAME(LOC) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTA) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTB1) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTB2) ACS(01) MEDIA(STK2P
MGMT NAME(CUSTA) MIGPOL(CUSTA)
MGMT NAME(CUSTB) MIGPOL(CUSTB1,CUSTB2)
MGMT NAME(PROD) MIGPOL(LOC)

이 예에 따르면 관리 클래스 PROD의 모든 항목이 로컬 ACS의 9840 매체에 있어야 하지만, 실제로는 원격 ACS의 9940 매체에 있는데 이는 잘못된 스토리지 클래스에 있는 것과 같습니다.

보다 자세히 살펴보면 프로덕션 관리 클래스는 실제로 다음과 같이 보입니다.

MGMT NAME(PROD) MIGPOL(CUSTA)

이는 다른 이유로 바람직하지 않습니다. 왜냐하면 고객 중 한 명이 전용으로 사용하는 동일한 MVC에 프로덕션 데이터도 있기 때문입니다. 지금 RECONcil을 실행할 때일까요? 그렇지 않습니다. RECONcil을 실행하면 잘못된 스토리지 클래스에서만 VTV가 이동되는데, 관리 클래스 명령문을 작성한 방식에 따르면 CUSTA는 올바른 스토리지 클래스입니다! RECONcil을 실행하기 전에 돌아가서 다음과 같이 관리 클래스를 수정해야 합니다.

MGMT NAME(PROD) MIGPOL(LOC)

이제 아래에 표시된 것과 같이 RECONcil을 실행할 수 있습니다.

- 관리 클래스 PROD의 VTV를 스토리지 클래스 LOC의 (업데이트된) 올바른 위치로 이동합니다.

- RECONcil 작업에 대해 MAXMVC를 60, CONMVC를 8, ELAPSE를 60으로 설정합니다.

//RECONCIL    EXEC PGM=SLUADMIN
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=*
//SLSINDD *
RECON MGMT(PROD) MAXMVC(60)
CONMVC(8) ELAPSE(360) MOVEVTV

RECONcil 사용 시 참고 사항

다음 매개변수 중 하나를 지정하여 조정할 VTV를 선택할 수 있습니다.

- MGMTclas - MIGpol 매개변수에 지정된 스토리지 클래스로 VTV를 이동합니다. 이는 "조정 예"에서 수행했습니다. 관리 클래스가 잘못된 스토리지 클래스를 가리키므로 올바른 스토리지 클래스를 가리키도록 한 다음 업데이트된 관리 클래스에 대해 RECONcil을 실행하십시오.

- STORclas - 지정된 스토리지 클래스로 VTV를 이동합니다. 이 매개변수는 상당 기간 동안 ACS를 사용할 수 없는 경우에 사용합니다.

- MVC - MVC 목록 또는 범위에서 VTV를 조정합니다. VTV에 대한 MGMTclas 문의 MIGpol 매개변수에 지정된 스토리지 클래스로 VTV가 이동됩니다. 이 매개변수를 먼저 사용한 다음 VTV 옵션을 사용할 수 있습니다.

- VTV - VTV 목록 또는 범위를 조정합니다. VTV에 대한 관리 클래스의 MIGpol 매개변수에 지정된 스토리지 클래스로 VTV가 이동됩니다.

주:

- MGMTclas 또는 VTV의 값을 지정하지 않으면 VTCS에서 모든 VTV가 스캔됩니다.

- VTV 조정은 리소스를 많이 사용하므로 RECONcil은 일반적으로 사용량이 적은 처리 기간 동안에 실행합니다. RECONcil 유틸리티로 CONFIG RECLAIM THRESHLD, MAXMVC 및 CONMVC 설정을 대체하여 조정 성능을 최적화할 수도 있습니다. 최대 조정 시간(분)을 ELAPSE 매개변수에 지정할 수도 있습니다.
조정에 영향을 주는 제한 계수가 여러 개 있습니다(예: MAXMVC 및 ELAPSE). VTCS에서는 가장 엄격한 제한 계수가 적용됩니다. 예를 들어 RECONcil을 실행하고 ELAPSE를 5시간, MAXMVC를 10으로 설정한 다음 VTCS에서 1시간에 MVC를 10개 조정할 경우, ELAPSE 값이 만료되기 전에 VTCS에서 조정이 종료됩니다.

- MOVEVTV 매개변수를 지정하지 않으면 조정 요청으로 처리할 수 있는 VTV, MVC 및 총 MB 수에 관한 중요한 "what if" 상황을 보여주는 보고서가 제공됩니다. 따라서 Oracle은 먼저 MOVEVTV 없이 RECONcil을 실행하고 필요에 따라 작업을 조정한 후 MOVEVTV를 지정할 것을 강력히 권장합니다.
자세한 내용은 ELS Command, Control Statement, and Utility Reference를 참조하십시오.

- RECONcil 요청을 처리하기 위해서는 VTCS 및 HSC가 활성 상태여야 합니다. 단, POLICYdd 매개변수를 지정한 경우는 예외입니다. POLICYdd(강제로 "보고서 전용" 모드를 수행함)도 향상된 "what if" 기능을 제공합니다. 다른 조정 시나리오(서로 다른 MIGpol 값)을 사용하여 대체 MGMTclas 문을 하나 이상 작성한 다음 POLICYdd를 사용하여 각 시나리오에 대한 VTV 조정 및 리소스 사용을 확인할 수 있습니다.

- RECONcil 요청을 처리하기 위해서는 VTCS 및 HSC가 활성 상태여야 합니다.

이름이 지정된 MVC 풀 사용 여부

이름이 지정된 MVC 풀은 모든 서비스 그룹의 작업에 적합한 도구입니다. 이름이 지정된 MVC 풀을 사용하여 이름이 지정된 풀의 MVC 소유권을 응용 프로그램에 부여할 수 있습니다. 예를 들어 서비스 그룹은 고객이 MVC 그룹을 구매하고 소유할 수 있는 법적 요건을 갖춘 경우 이름이 지정된 MVC 풀을 사용하도록 선택할 수 있습니다.

그러나 이름이 지정된 MVC 풀에 대한 특정 요구 사항은 없지만 MVC에서 클라이언트 데이터를 그룹화하거나 분리하려는 경우 Oracle은 이름이 지정된 MVC 풀을 사용하지 말 것을 강력하게 권장합니다. 대신 다음 절에 설명된 방법을 사용하십시오.

- 공유 MVC에서 여러 작업 로드 그룹화

- "별도의 MVC 세트에 개별 작업 로드 분리."

위 절에서는 스토리지 클래스를 사용하여 시스템 전체 MVC 풀에서 선택한 MVC에서 데이터를 그룹화하거나 분리하는 방법에 대해 설명합니다. 이 경우 한 개의 MVC 풀만 관리해야 합니다.

이름이 지정된 MVC 풀을 만드는 경우 각 풀을 명시적으로 관리해야 합니다. 여기에는 각 풀에 사용 가능한 MVC 및 사용 가능한 MVC 공간이 충분한지 확인하고, MVCPool MVCFREE, MAXMVC, THRESH 및 START 매개변수를 사용하여 풀마다 다른 정책을 설정하는 것이 포함됩니다.

이름이 지정된 MVC 풀을 사용하도록 선택한 경우 "이름이 지정된 MVC 풀 만들기 및 사용"으로 이동하십시오.

이름이 지정된 MVC 풀 만들기 및 사용

이름이 지정된 MVC 풀을 만들고 사용하려면 다음을 수행하십시오.

1. 기존 POOLPARM 문을 수정하거나 명령문을 더 추가하여 이름이 지정된 MVC 풀을 정의합니다.
POOLPARM NAME 매개변수를 지정하지 않을 경우 VTCS에서 이름이 지정된 MVC 하위 풀이 만들어지지 않으며 지정된 볼륨이 기본 풀(DEFAULTPOOL)에 지정됩니다. 예약된 이름을 DEFAULTPOOL 및 ALL을 사용하여 이름이 지정된 MVC 풀을 만들지 마십시오.

선택적 매개변수 MVCFREE, MAXMVC, THRESH 및 START를 사용하여 CONFIG에 지정된 전역 값을 대체하는 이름이 지정된 MVC 풀 값을 지정할 수 있습니다.

예를 들어 다음 VOLPARM 및 POOLPARM 문은 CONFIG 전역 값을 대체하는 재생 매개변수 값을 사용하여 이름이 지정된 풀 SYS1MVCT1에 대해 암호화할 T10000 전체 볼륨의 범위를 정의합니다.

VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE)
POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)

2. SET VOLPARM을 실행하여 볼륨 및 풀 정의를 적용합니다.

SET VOLPARM APPLY(YES)

3. 스토리지 클래스를 정의하고 이름이 지정된 MVC 풀과 연관시킵니다.

예를 들어 다음 STORclas 문은 STORCL1을 정의하고 이 스토리지 클래스를 이름이 지정된 MVC 풀 CUST1POOL과 연관시킵니다. 스토리지 클래스 STORC1에 대해 MVC를 사용하도록 요청할 경우 이름이 지정된 풀 SYS1MVCT1에서만 MVC가 선택됩니다.

STOR NAME(STORCL1) MEDIA(T!AE) MVCPOOL(SYS1MVCT1)

4. 3단계에서 정의한 스토리지 클래스를 지정하는 관리 클래스를 만들고 데이터 경로를 이름이 지정된 MVC 풀로 지정할 때 이 관리 클래스를 지정합니다.
자세한 내용은 "VTCS 관리 및 스토리지 클래스 만들기 및 사용: 기본 사항"을 참조하십시오.

5. 다음 중 하나에 VTCS에 대한 관리 클래스 이름을 지정합니다.

- SMC TAPEREQ 문

- StorageTek DFSMS 인터페이스에 기록한 SMS 루틴 자세한 내용은 SMC 구성 및 관리를 참조하십시오.

7 VTCS 문제 파악 및 해결

이 절은 무엇인가 잘못되었을 때 어떻게 해야 하는지에 대한 내용입니다. 이미 여러분은 "VTCS 대시보드 사용"에 설명된 대로 일간 작업과 "백업 복사본에서 CDS 복원"에서 설명된 대로 필요시 작업을 수행했는데도 여전히 무엇인가 제대로 되지 않고 있습니다. 여기에서는 "일반적인 문제 해결"에서 발생하는 단순한 문제부터 시작하여 문제가 발생할 때 VTCS를 정상적으로 작동하도록 하는 방법을 설명합니다.

주:
CDS 복구는 주로 HSC 작업이지만 VSM 측면도 있습니다. 자세한 내용은 "PITCOPY를 사용하여 CDS 백업"을 참조하십시오.

일반적인 문제 해결

이 문맥에서 "일반적인"은 최선을 다했음에도 불구하고 잘못될 수 있는 것을 의미합니다. 여러분이 문제에 대해 파악하는 방식은 종종 VTCS 대시보드를 다시 살펴보는 것이고, 해결 방법은 필요시 작업에 있는 경우도 있습니다.

VTV 마운트 성능 문제를 시작하기 전에 이러한 문제는 일반적으로 여러분 스스로 진단하고 해결할 수 있는 일반적인 문제입니다. 하지만 납득할 만한 노력을 한 이후에도 여전히 해결되지 않는 경우 고객 지원 센터의 도움을 요청할 수 있습니다. 추적과 같이 여기에서 다루지 않는 몇 가지 도구도 있지만, 이러한 도구는 기본적으로 오라클 고객 지원 센터의 지시에 따라서만 사용하는 것이 좋습니다.

VTV 마운트 성능 저하

VTV 마운트가 매우 느리게 또는 전혀 발생하지 않는 경우 다음을 확인하십시오.

- 단일 VTD에서 마운트를 실패합니까? 이 문제는 대개 호스트에서 VSM이 회수할 수 없는 MVC 상주 VTV의 마운트를 요청하기 때문에 발생합니다. 이러한 경우 다음을 수행하십시오.

- Display Queue DETail 명령을 실행하여 대기열에 있는 회수를 확인합니다. 회수가 MVC를 기다리면서 대기열에 있는 경우 다른 VTCS 프로세스에서 사용 중일 수 있으며, 이 사실은 Display Active DETail을 사용하여 확인할 수 있습니다.

- MVC가 사용 중이 아닌 경우 다음에 HSC DISPLAY VOLUME 명령을 입력합니다. MVC가 실제로 ACS에 있습니까? 그렇지 않은 경우 MVC를 다시 입력하여 회수를 완료해야 합니다.

- 그런 다음 VTV를 회수하기 위해 MVC를 마운트하는 데 사용할 수 있는 RTD가 있습니까? Display RTD를 입력하여 RTD 가용성을 확인합니다. 사용 가능한 RTD가 없는 경우 모든 호스트에 대해 Display를 사용하여 활성 및 대기열에 있는 프로세스를 확인합니다.
필요한 경우 회수를 완료할 수 있도록 Cancel을 사용하여 프로세스를 취소하고 RTD를 확보합니다. Cancel을 사용하면 VTCS가 시스템 리소스나 정보에 영향을 주지 않고 프로세스 중지를 시도하므로 취소가 즉시 발생하지 않을 수 있습니다. 예를 들어, VTCS는 특정 RTD를 사용하는 프로세스를 종료하기 전에 하드웨어 시간 초과 기간을 기다릴 수 있습니다.

주:
상위 요청을 취소할 경우 상위 및 모든 하위 요청을 중지하게 됩니다. 하위 요청을 취소할 경우 상위 요청은 처리를 계속합니다.

주의:
마이그레이션 스케줄러(MIGrate 매개변수 또는 특정 프로세스 ID)와 연관된 작업을 취소할 경우 이 작업은 종료되지만, 마이그레이션 스케줄러는 다음 타이머 간격에 다른 마이그레이션 작업을 시작합니다. 하지만 migrate-to-threshold를 사용하여 현재 DBU보다 큰 값을 지정하면 자동 마이그레이션을 중지할 수 있습니다.

팁:
MGMTclas 명령문 IMMEDmig 매개변수를 KEEP 또는 DELETE로 설정하면 마이그레이션 처리(및 마이그레이션을 위해 RTD 사용)에 유리할 수 있으며 RTD에 대한 I/O를 증가시킬 수 있습니다.

또한 자동 마이그레이션 작업을 각 VTSS에 대해 정의한 RTD에 대한 다른 작업(예: 회수 및 확보)과 균형을 다시 맞추기 위해 CONFIG MAXMIG 및 MINMIG 매개변수 설정을 변경할 수도 있습니다.

- 여러 VTD에서 마운트를 실패합니까? 이러한 경우 다음을 확인하십시오.

- Display VTD를 사용하여 VTD 상태를 확인합니다.

- Display Active를 입력합니다. 활성 프로세스가 없는 경우 VTCS, HSC, 모든 VTSS 및 모든 통신이 정상적으로 작동 중인지 확인합니다.

- 충분한 VTSS 공간이 있는지 확인합니다.

- 시스템이 사용 가능한 MVC 또는 가용 MVC 공간 중에서 실행 중인지 확인합니다.

- 낮은 AMT를 높이면 더 많은 VTV가 VTSS 공간에 상주하게 되어 가상 마운트 실패를 방지하는 데 도움이 될 수 있습니다.

- VTD가 온라인 상태인데도 VTV 마운트를 실패하는 경우 MVS VARY 명령을 사용하여 VTD를 온라인으로 전환하고, MVS UNLOAD 명령을 사용하여 VTD를 지운 다음 HSC MOUNT 및 DISMOUNT 명령을 사용하여 작업을 재시도합니다.

마이그레이션 성능 저하

VTV 마이그레이션이 매우 느리게 발생하는 경우 다음을 확인하십시오.

- 우선 Display MIGrate를 사용하여 다양한 마이그레이션 작업이 얼마나 좋게 또는 나쁘게 수행되는지 대략적으로 확인합니다. 상황이 더 좋아지도록 설정을 조정할 수 있습니다(예: MAXMIG/MINMIG 값 높임).

- RTD 및 MVC의 공급이 "가상 테이프 상태 확인(일간)"에 설명된 대로 양호한 상태인지 확인합니다. 더 깊이 있게 상황을 파악하고자 하는 경우 Display Queue DETail을 사용하여 대기열에 있는 프로세스의 상태를 확인할 수도 있습니다. 많은 프로세스가 RTD를 기다리고 있고 RTD를 MVS와 공유 중인 경우 전송을 MVS에 오프라인으로 전환하고 VSM에 온라인으로 전환할 수 있습니다.

주:
JES3 환경에서는 올바른 User Exit 수정을 만들고 설치하지 않은 경우 VTV 마운트를 실패할 수 있습니다.

마이그레이션 실패

마이그레이션 성능 저하보다 좋지 않은 것이 단 한 가지 있는데, 그것은 마이그레이션이 전혀 발생하지 않는 것입니다. 다행히 VTCS는 다음 절에 설명된 대로 마이그레이션 실패에 대한 자세한 정보를 제공합니다.

- 메시지 개선

- STORCLas 표시

- MVC 풀 검증 개선

- "스토리지 클래스 검증 개선"

메시지 개선

마이그레이션 실패에 대한 더 정확하고 자세한 정보를 제공하기 위해 메시지 SLS6700E가 다음 메시지로 대체되었습니다.

- SLS6853E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - MVCPool poolname is not defined

- SLS6854E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - no MVCs found for specified media

- SLS6855E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - no MVCs found for specified media/SC/ACS

- SLS6856E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - no usable MVCs found for specified media/SC/ACS

- SLS6857E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - no RTDs for requested media and ACS

- SLS6858E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - all RTDs for requested media and ACS are offline

- SLS6859E Migration failed Storage Class:stor-clas-name ACS:acs-id VTSS:vtss-name - unknown reason (X'xx')

또한 스토리지 클래스의 상세 정보를 제공하기 위해 이전 메시지가 표시된 이후 메시지 SLS6860I이 항상 출력됩니다. 해당하는 경우 SLS6860I은 마이그레이션 요구 사항 충족과 관련된 모든 오류도 보고합니다.

- MVC 풀이 정의되지 않은 경우.

- MVC 풀에 지정된 매체가 포함되지 않은 경우.

- MVC 풀에 지정된 매체의 사용 가능 MVC가 포함되지 않은 경우.

- VTSS/ACS에 마이그레이션 MVC를 쓰도록 정의된 적당한 RTD가 없는 경우.

- 모든 적당한 RTD가 오프라인인 경우.

결과적으로 이제 마이그레이션 실패가 실제로 발생할 경우 더욱 자세한 정보와 해결을 위한 더욱 구체적인 권장 사항을 얻을 수 있습니다.

STORCLas 표시

표시가 STORCLas 매개변수로 개선되었습니다. 출력은 다음과 같습니다.

- 스토리지 클래스의 특성(ACS, MVC 풀 및 매체).

- 모든 VTSS에서 스토리지 클래스로 마이그레이션 대기 중인 VTV.

- 마이그레이션에 사용할 MVC의 요구 사항.

- 마이그레이션 MVC에 쓰는 데 필요한 RTD의 장치 유형.

- 마이그레이션 요구 사항 충족과 관련된 모든 오류.

다시 말하지만, VTCS는 마이그레이션 시나리오에서 중요 요소(스토리지 클래스)에 대한 정보를 제공합니다.

MVC 풀 검증 개선

일반적인 설정 오류를 확인하도록 MVC 풀 검증이 개선되었습니다.

- 적어도 하나의 유효한 MVC 풀이 정의되었는가? 그렇지 않은 경우 메시지 SLS6845E가 표시됩니다. 마이그레이션이 발생할 수 없으므로 VTCS 기능이 심각하게 저하됩니다. 이 메시지가 나타날 경우 알맞은 MVC 풀을 정의해야 합니다. 다음 글머리 기호 내용을 참조하십시오.

- 기본 MVC 풀(DEFAULTPOOL)이 존재하는가? DEFAULTPOOL은 명명된 MVC 풀을 지정하지 않은 스토리지 클래스로 마이그레이션할 때 그리고 스토리지 클래스 !ERROR의 오류 상황에서 사용됩니다. DEFAULTPOOL이 존재하지 않을 경우 메시지 SLS6846W가 표시됩니다.
STORCLAS 명령문에서 MVCPool(pool-name)을 코딩하여 스토리지 클래스로의 마이그레이션에서 특정 MVC 풀을 사용하도록 지정합니다. MVCPool(pool-name)이 코딩되지 않은 경우, VTCS는 STORCLAS를 MVCPool(DEFAULTPOOL)이 코딩된 것처럼 취급합니다.

스토리지 클래스 검증 개선

같은 맥락에서, 일반적인 설정 오류를 확인하도록 스토리지 클래스 검증이 개선되었습니다.

- 스토리지 클래스에서 명명된 MVC 풀을 지정할 경우(STORCLAS NAME(stor-clas-name) MVCPOOL(poolname)), VTCS는 명명된 MVC 풀이 정의되었는지 확인합니다. 따라서 STORCLAS NAME(stor-clas-name) MVCPOOL(poolname)을 코딩할 경우, 명명된 MVC 풀이 존재하는지 확인하십시오. 그렇지 않은 경우 VTCS에서 메시지 SLS6848W를 표시합니다. 이 메시지가 나타날 경우 명명된 MVC 풀을 정의하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

- 마찬가지로 스토리지 클래스에서 명명된 MVC 풀을 지정하지 않을 경우(STORCLAS NAME(stor-clas-name), VTCS는 DEFAULTPOOL이 정의되었는지 확인합니다. 따라서 STORCLAS NAME(stor-clas-name)을 코딩할 경우, 명명된 MVC 풀을 만들지 않는 적어도 하나의 MVCPOOL 명령문이 있는지 확인하십시오. 그렇지 않은 경우 VTCS에서 메시지 SLS6846W를 표시합니다. 이 메시지가 나타날 경우 명명된 MVC 풀을 만들지 않는 적어도 하나의 MVCPOOL 명령문을 코딩하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

- 스토리지 클래스에서 MVC 매체를 지정할 경우(STORCLAS NAME(stor-clas-name) MEDIA(media-type)), VTCS는 MVC 풀에 media-type 유형의 매체가 포함되어 있는지 확인합니다(명명된 MVC 풀이 지정되지 않은 경우 DEFAULTPOOL로 간주됨). 그렇지 않은 경우 VTCS에서 메시지 SLS6849W를 표시합니다. 매체 유형이 해당하는 풀에 존재하는지 확인하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

- 스토리지 클래스에서 ACS 및 매체 유형을 지정할 경우(STORCLAS NAME(stor-clas-name) ACS(acs-id) MEDIA(media-type)), VTCS는 지정된 매체 유형과 호환되는 지정된 ACS에 RTD가 있는지 확인합니다. 그렇지 않은 경우 VTCS에서 메시지 SLS6851W를 표시합니다. 필요한 RTD 유형이 지정된 ACS에 존재하는지 확인하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

- 스토리지 클래스에서 특정 ACS 없이 매체 유형을 지정할 경우(STORCLAS NAME(stor-clas-name) MEDIA(media-type)), VTCS는 지정된 매체 유형과 호환되는 구성에 RTD가 있는지 확인합니다. 그렇지 않은 경우 VTCS에서 메시지 SLS6851W를 표시합니다. 필요한 RTD 유형이 구성에 존재하는지 확인하거나 스토리지 클래스 정의를 변경하거나 둘 다 수행하십시오.

RTD/MVC 실패

처음에는, 매체 실패인지 드라이브 실패인지 알지 못할 수 있습니다. 즉, VTCS가 MVC에서 읽기/쓰기 오류를 감지할 경우 VTCS는 MVC를 다른 RTD로 바꿉니다. VTCS가 MVC에서 더 이상 읽기/쓰기 오류를 감지하지 못할 경우 VTCS는 첫번째 RTD에서 오류가 발생했다고 간주합니다.

메시지 SLS6662A는 RTD가 유지 관리 모드임을 나타내고, 이 상태는 Display RTD 출력에도 보고됩니다. 유지 관리 모드의 RTD는 일반적으로 오류 상태이고 하드웨어 운영 또는 서비스 담당자의 지원이 필요합니다. 복구 모드의 RTD는 초기화 중(예를 들어, 온라인으로 전환될 때)이며, 일반적으로 오류 상태가 아닙니다.

실패한 RTD를 빠르게 복구할 수 없거나 실패한 RTD가 원격 ACS에 연결된 경우 해당 RTD에 할당을 시도하지 못하도록 구성에서 RTD를 제거할 수 있습니다. RTD에 대한 RTD 명령문을 제거하고 CONFIG를 다시 실행하십시오.

주의:
듀얼 ACS 구성(두 ACS가 단일 VTSS에 연결됨)에서는 두 ACS의 모든 RTD를 오랫동안 VTSS에서 사용하지 못하도록 두지 마십시오. ACS에서 사용 가능한 RTD가 없을 경우, 해당 ACS에 대해 마이그레이션이나 회수가 발생할 수 없으며 VTSS 공간이 가득 찰 수 있습니다. 또한 이 조건으로 인해 다른 ACS에서 RTD로의 마이그레이션이 중단될 수 있습니다.

따라서 듀얼 ACS 구성에서 ACS의 모든 RTD를 오랫동안 사용하지 못하도록 해야 하는 경우 위에 설명된 대로 구성에서 RTD를 제거하십시오.

불량 MVC?

RTD 문제에 대해 위의 확인 목록을 검토했지만 해당하는 문제가 없었고, 더 많은 MVC 공간을 사용 가능하도록 만들기 위해 할 수 있는 모든 작업도 수행했으며, MVC 요약 보고서의 volser를 HSC 볼륨 보고서와 비교한 결과 MVC가 실제로 ACS에 있었습니다. 그렇지 않으면 HSC 볼륨 보고서에 나열되지 않은 모든 MVC를 다시 입력하거나 교체합니다.

실제로 매체 문제가 아닌 것 같습니다. "가상 테이프 상태 확인(일간)"에 설명된 MVC 및 VTV 보고서를 보면 어떤 종류의 매체 문제인지 알 수 있습니다. 이 절에서는 가장 분명한 MVC 비정상 문제에 대한 몇 가지 해결 방법을 설명하고 있습니다. 다음은 MVC 및 VTV 보고서에서 보고 싶지 않은 까다로운 MVC 상태 및 이에 대처하기 위한 작업 목록입니다.

BROKEN

MVC, 드라이브 또는 이 둘의 조합에 문제가 있음을 나타내는 일반적인 오류입니다. VTCS는 이 상태의 MVC를 사용하지 않으려고 시도합니다. 일반적으로 이 상태를 해결하려면 다음과 같이 하십시오.

MVC가 문제의 원인인 경우 DRAIN(EJECT) 명령을 사용하여 MVC를 서비스에서 제거합니다.

RTD가 문제의 원인인 경우 MVCMAINT 유틸리티를 사용하여 MVC 상태를 재설정합니다.

또한 BROKEN 상태에 대해 표시되는 SLS6686, SLS6687, SLS6688, SLS6690 메시지 중 하나 이상을 검토하십시오. 이러한 메시지에 대한 자세한 복구 절차는 VTCS 메시지 및 코드를 참조하십시오.

DATA CHECK

이 MVC에 대해 데이터 확인 조건이 보고되었습니다. VTCS는 이 상태의 MVC를 사용하지 않으려고 시도합니다. 이 상태를 해결하려면 다음과 같이 하십시오.

MVC의 모든 VTV가 이중화된 경우 MVC에서 Eject 옵션 없이 MVCDRain을 사용합니다. 그러면 모든 VTV가 복구되고 MVC가 서비스에서 제거됩니다.

MVC의 모든 VTV가 이중화되지 않은 경우 VTCS가 MVC를 감사합니다. 감사는 실패할 수 있습니다. 감사 후 MVCDRAIN(eject 없이)을 수행합니다. 그러면 오름차순 블록 ID 순서로 데이터 확인 영역 이전의 VTV 및 내림차순 블록 ID 순서로 데이터 확인 영역 이후의 VTV가 회수됩니다. 이 순서로 VTV를 처리하면 VTCS가 매체에서 가능한 많은 VTV를 복구하게 됩니다. 그런 다음 MVC에 여전히 남아 있는 모든 VTV에 대해 데이터를 다시 만들어야 합니다.

데이터 확인을 마쳤으면 "MVC 영구 제거"에 설명된 대로 데이터 확인 오류가 있는 MVC를 제거하고 교체합니다. 이 절차에서는 MVC를 VTCS 사용에서 제거하고 니어라인 작업에 반환하는 방법도 설명합니다.

DRAINING

MVC가 현재 배수 중이거나 실패한 MVCDRain의 주체가 되었습니다.

IN ERROR

MVC가 마운트될 때 오류가 발생했습니다.

INITIALIZED

MVC가 초기화되었습니다.

LOST - FAILED TO MOUNT

VTCS가 MVC를 마운트하려고 시도했지만 15분 시간 초과 기간 이내에 마운트가 완료되지 않았습니다. VTCS가 하드웨어 문제, HSC 문제 또는 ACS에서 제거 중인 MVC로 인해 발생할 수 있는 상황으로부터 복구를 시도하는 중입니다. VTCS는 이 상태의 MVC를 사용하지 않으려고 시도합니다.

VTCS가 LOST(ON) 상태에서 MVC의 다음 마운트를 성공적으로 수행할 경우 VTCS는 상태를 LOST(OFF)로 설정합니다.

오류의 원인을 파악하고 해결하십시오. 또한 다음 이벤트에 대해 VTCS MVCMAINT 유틸리티를 사용하여 LOST(OFF)를 설정할 수도 있습니다.

해결된 LSM 실패 또는 드라이브 오류로 인해 LOST(ON)이 설정되었습니다.

MVC가 ACS 외부에 있었고 다시 입력되었기 때문에 LOST(ON)이 설정되었습니다.

MARKED FULL

MVC가 가득 찼고 이후 마이그레이션에 대한 후보가 아닙니다.

MOUNTED

MVC가 RTD에 마운트되었습니다.

NOT-INITIALIZED

MVC가 CONFIG 유틸리티를 통해 정의되었지만 사용된 적이 없습니다.

READ ONLY

MVC가 다음 조건 중 하나로 인해 읽기 전용으로 표시되었습니다.

- MVC가 내보내기 또는 통합 프로세스의 대상입니다. 읽기 전용 상태가 MVC를 추가 업데이트로부터 보호합니다.

- MVC 매체가 파일 보호로 설정되었습니다. 오류를 해결하고 MVCMAINT 유틸리티를 사용하여 READONLY(OFF)를 설정하십시오.

- VTCS가 MVC를 업데이트하도록 설정된 적절한 SAF 규칙이 MVC에 없습니다. 오류를 해결(자세한 내용은 Installing ELS의 ”Defining A Security System User ID for HSC, SMC, and VTCS” 참조)하고 MVCMAINT 유틸리티를 사용하여 READONLY(OFF)를 설정하십시오.

BEING AUDITED

MVC가 현재 감사 중이거나 실패한 감사의 주체가 되었습니다. 감사를 실패한 경우 VTCS는 마이그레이션을 위해 MVC를 사용하지 않습니다. 이 조건을 해결하려면 이 MVC에 대해 AUDIT 유틸리티를 다시 실행하십시오.

LOGICALLY EJECTED

MVC가 MVCDRain Eject의 주체가 되었거나 MVC가 RACROUTE 호출로 업데이트를 위해 추출되었습니다. MVC는 마이그레이션이나 회수를 위해 다시 사용되지 않습니다. 이 조건을 해결하려면 MVC에 대해 Eject 옵션 없이 MVCDRain을 사용하십시오.

RETIRED

MVC가 폐기되었습니다. VTCS는 MVC에서 회수하지만 MVC로 마이그레이션하지 않습니다. 가능한 빨리 MVC를 교체하십시오.

WARRANTY HAS EXPIRED

MVC의 보증이 만료되었습니다. VTCS는 계속해서 MVC를 사용합니다. MVC가 폐기됨 상태에 도달할 때 교체하기 위한 계획 수립을 시작해야 합니다.

INVALID MIR

VTCS가 RTD로부터 9x40 또는 T10000 매체에 대한 MIR(media information record)이 잘못되었음을 나타내는 상태를 수신했습니다. 잘못된 MIR로 인해 데이터에 액세스하지 못하는 것은 아니지만, 테이프의 레코드에 액세스할 때 중대한 성능 문제가 발생할 수 있습니다. MVC는 유효한 MIR 항목이 없는 테이프의 영역에서 고속 검색을 수행하지 못합니다.

VTCS는 이 조건의 MVC를 사용하지 않으려고 시도합니다. 회수의 경우, VTV가 여러 MVC에 상주한다면 VTCS는 잘못된 MIR을 가진 MVC보다 먼저 유효한 MIR을 가진 MVC를 선택합니다. VTCS는 마이그레이션이 테이프의 시작 지점에 있지 않다면 잘못된 MIR을 가진 MVC 사용을 피합니다. 테이프의 시작 지점에서 마이그레이션하면 MIR이 수정됩니다.

VTCS는 마운트 시점 또는 마운트 해제 시점에 잘못된 MIR 조건을 감지합니다. 마운트 시점에 감지하고 다른 MVC를 사용하여 작업을 완료할 수 있는 경우, VTCS는 첫번째 MVC를 마운트 해제하고 대체 MVC를 선택합니다. 단, VTCS는 대체 MVC로 전환할 수 있는 능력이 제한적이라는 사실을 기억하십시오. 즉, 마이그레이션 및 가상 마운트에 주로 사용됩니다.

잘못된 MIR을 가진 MVC의 경우, 오류의 원인(매체 또는 드라이브 문제 등)을 파악하고 오류를 해결하십시오.

잘못된 MIR을 가진 MVC를 복구하려면 INVENTRY 유틸리티를 사용하십시오. 예를 들어, MVC707을 복구하려면 다음과 같이 입력합니다.

INVENTRY MVCID(MVC707)

데이터 확인을 사용하여 MVC 복구

이것은 일반적인 ”불량 MVC” 문제의 매우 구체적인 예이며, MVC 및 VTV 보고서에서 MVC 데이터 확인 오류를 발견할 때 필요하다는 사실을 알고 있습니다.

데이터 확인을 사용하여 MVC를 복구하려면 다음과 같이 하십시오.

1. MVC에 대해 MVC 감사를 실행합니다.
감사는 MVC에서 순차적으로 VTV 메타데이터를 읽으려고 시도합니다. 데이터 확인을 발견하면 감사를 실패하고, MVC는 감사 중 상태로 남겨집니다. 그러면 VTCS가 출력을 위해 이 MVC를 선택하지 못하게 됩니다.

2. MVC에 대해 MVCDRain Eject를 실행합니다.
그러면 모든 사용 가능한 VTV가 VTSS로 회수된 다음 오류가 없는 새 MVC로 다시 마이그레이션됩니다. 이 작업은 MVC 풀에서 MVC를 논리적으로 제거합니다.

주:

- MVC의 오류 상태로 인해 가능한 경우 VTCS는 대체 MVC에서 VTV를 회수합니다.

- 오류 상태의 MVC에서 VTV를 회수해야 하는 경우(사용 가능한 다른 복사본 없음) 다음과 같이 수행됩니다.

- 데이터 확인 영역 이전 VTV가 오름차순 블록 ID 순서로 회수됩니다.

- 데이터 확인 영역 이후 VTV가 내림차순 블록 ID 순서로 회수됩니다.

3. VTV를 MVC에서 복구할 수 없는지 판단합니다.
MVC에 대한 MVC 상세 보고서를 실행합니다. VTV가 여전히 MVC에 있는 것으로 보고될 경우 이러한 VTV는 복구가 불가능합니다. 다른 방법을 사용하여 데이터를 복구해야 합니다.

4. 다음 중 하나의 작업을 수행하여 결함이 있는 MVC를 관리합니다.
결함이 있는 MVC를 동일한 내부/외부 레이블의 초기화된 테이프 볼륨으로 교체:

1. 결함이 있는 MVC에 대해 HSC EJECT 명령을 입력합니다.

2. 교체 MVC에 대해 HSC ENTER 명령을 입력합니다.

3. 필요에 따라 테이프를 초기화합니다.

4. 새 MVC에 대해 HSC AUDIT을 입력합니다.

5. MVCDRAIN(EJECT 없이)을 실행하여 MVC를 MVC 풀에 반환합니다.

시스템에서 MVC 제거:

1. 결함이 있는 MVC에 대해 HSC EJECT 명령을 입력합니다.

2. MVC 풀 정의를 편집하여 풀에서 결함이 있는 MVC를 제거합니다.

3. 모든 활성 호스트에서 VT MVCDEF를 입력하여 새 MVC 풀 정의를 활성화합니다.

RTV 유틸리티 사용

RTV는 VTCS의 도움 없이 MVC에서 직접 VTV 데이터를 읽도록 설계되었으므로 RTV 유틸리티는 오라클 고객 지원 센터에 문의한 후에만 사용해야 하는 또 다른 도구입니다(예: 실제로 CDS를 손실한 경우).

RTV는 독립형 유틸리티이며, 작동 방식은 MVC에서 VTV를 읽고 VTV를 압축 해제한 다음 데이터를 단일 출력 테이프(실제 테이프 볼륨)에 기록하여 데이터를 사용자 응용 프로그램에서 읽을 수 있도록 합니다. RTV 유틸리티는 독립형 유틸리티이므로 VSM이 작동 중지되었지만 MVS 시스템은 작동 중일 때 RTV를 실행할 수 있습니다.

RTV 유틸리티로 복구 가능한 항목

RTV 유틸리티로 다음 항목을 복구할 수 있습니다.

- 지정된 MVC에서 모든 또는 지정된 VTV. MVC에서 최신 버전의 VTV 위치를 알지 못하는 경우 VTV volser만 지정하면 RTV가 이 MVC에서 찾은 최신 버전의 VTV를 변환합니다.

- 지정된 MVC에서 지정된 블록 ID의 VTV. LISTONLY 매개변수 목록은 VTV를 니어라인 볼륨으로 변환하기 위해 RTV 유틸리티에 입력으로 사용할 수 있는 블록 ID 값을 제공합니다. volser 및 블록 ID를 지정하면 위치 찾기 시간이 단축됩니다.

- 지정된 MVC에서 논리 데이터 세트 번호로 지정된 VTV. volser 및 논리 데이터 세트 번호를 지정하면 volser 및 블록 ID 지정에 비해 위치 찾기 시간이 훨씬 더 길어집니다. volser 및 블록 ID를 사용하는 것이 단일 VTV에 액세스하기 위한 더 좋은 방법입니다.

주:
둘 이상의 VTV가 지정되거나 블록 ID 또는 FILEnum 매개변수가 지정되지 않은 경우 전체 MVC를 읽고 MVC 내용이 출력의 일부로 표시됩니다. 전체 MVC를 읽는 것은 가장 최근의 VTV 복사본만 압축 해제하기 위해 필요합니다.

일반적인 사용 지침

- 변환된 VTV를 포함하는 출력 볼륨은 개별 VTV를 포함할 수 있도록 최대 VTV 크기(400Mb, 800Mb, 2Gb, 4Gb 또는 32Gb) 이상이어야 합니다.

- VTCS MVC 및 VTV 보고서는 RTV가 복구할 VTV 복사본을 지정하도록 하기 위한 정보를 제공합니다. RTV 유틸리티를 실행하기 전에 이러한 보고서의 최신 버전을 가지고 있는지 확인하십시오. 또한 변환할 VTV를 식별하는 데 도움이 되도록 LISTONLY 매개변수를 사용하여 MVC의 VTV 목록을 생성할 수 있습니다.
동일 VTV의 여러 복사본이 동일하거나 서로 다른 MVC에 존재할 수 있으므로 VTV 및 MVC 보고서와 LISTONLY 목록을 면밀히 조사하여 가장 최근의 VTV 복사본을 변환하기 위해 올바른 MVC를 사용하고 있는지 확인하십시오!

- RTV 유틸리티는 변환된 볼륨에 대한 정보로 시스템 카탈로그 또는 TMC를 업데이트하지 않으므로 이 작업은 수동으로 해야 합니다.

보안 고려 사항

- 변환할 VTV 및 이러한 VTV를 포함하는 MVC 모두에 대한 읽기 액세스 권한을 가지고 있어야 하며, 그렇지 않으면 시스템의 보안 응용 프로그램을 실행할 수 없습니다. 또한 변환을 실패합니다.

- APF에서 RTV 유틸리티가 라이브러리를 로드하도록 권한을 부여하는지 확인하십시오.

- RTV는 TMS 보호를 우회하려고 시도하지 않습니다. 모든 RTV 테이프 마운트는 전체 TMS 제어로 귀속됩니다.

주:
RTV 유틸리티는 출력 장치의 테이프 표준 레이블을 재작성할 수 있어야 하고 입력 장치의 레이블 정보보다 우선할 수 있어야 하므로 테이프 볼륨에서 BLP(bypass label processing)를 호출하기 위해 동적 할당이 사용됩니다. 이를 위해서는 SWSRTV 실행 코드를 포함하는 라이브러리가 APF의 권한 부여를 받아야 합니다.

JCL 예

다음은 RTV 유틸리티를 사용하는 JCL 예를 표시합니다.

MVC의 VTV 나열

다음은 MVC MVC001의 VTV를 나열하는 샘플 JCL을 보여줍니다.

//JOBVRECJOB(account),programmer
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=A
//SLSINDD *
RTV  MVC(MVC001)INUNIT(/1AB4) LISTONLY
/*
//

Volser를 지정하여 단일 VTV 변환

다음은 RTV 유틸리티를 실행하여 3490E 전송에 마운트된 MVC MVC001의 VTV VTV200을 변환하는 샘플 JCL을 보여줍니다. 출력(변환된 VTV VTV200)은 전송 280에 마운트된 출력 볼륨으로 이동하고, RTV는 VTV에서 출력 볼륨으로 VTV VOLID를 복사합니다.

//JOBVRECJOB(account),programmer
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=A
//SLSINDD *
RTV  MVC(MVC001) INUNIT(3490E) VTV(VTV200) CPYVOLID OUTUNIT(280)
/*
//

Volser 및 블록 ID를 지정하여 단일 VTV 변환

다음은 RTV 유틸리티를 실행하여 3490E 전송에 마운트된 MVC MVC001의 블록 ID x’8EA484AB’에 있는 VTV VTV200을 변환하는 샘플 JCL을 보여줍니다. 출력(변환된 VTV VTV200)은 전송 480에 마운트된 출력 볼륨으로 이동합니다.

//JOBVRECJOB(account),programmer
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=A
//SLSINDD *
RTV  MVC(MVC001) INUNIT(3490E) VTV(VTV200) BLOCK(8EA484AB) OUTUNIT(480)
/*
//

A LCM 제어문

이 부록에서는 LCM 제어문을 나열합니다.

테이블 A-1 LCM 제어문

LCM 제어문

상태

HSC/VTCS 유틸리티 명령

ACTION CONSOLIDATE

변경되지 않음

CONSOLIDATE

ACTION DRAIN

향상됨

MVCDRAIN

ACTION EJECT

변경되지 않음

EJECT

ACTION EXPORT

변경되지 않음

EXPORT

ACTION MIGRATE

변경되지 않음

MIGRATE

ACTION MOVE

변경되지 않음

MOVE

ACTION RECALL

변경되지 않음

RECALL

ACTION RECLAIM

향상됨

RECLAIM

ACTION SCRATCH

변경되지 않음

SCRATCH

ACTION UNSCRATCH

변경되지 않음

UNSCRATCH, REPLACEALL

ACTION VAULT ASSIGN

향상됨

ACTION VAULT RELEASE

향상됨

ACTION VAULT RETURN

향상됨

DATASET

변경되지 않음

LOCATION

변경되지 않음

MANAGE PHYSICAL

향상됨

MANAGE VIRTUAL

변경되지 않음

METHOD

변경되지 않음

OPTIONS

향상됨

OPTIONS SYNC, SYNCVTV MANAGE PHYSICAL 및 MANAGE VIRTUAL

향상됨

SLUCONDB(및 동등한 SMC 명령)

PULLLIST

변경되지 않음

REPORT CELLCNT

향상됨

REPORT CONSOLIDATE

변경되지 않음

REPORT DATASET

변경되지 않음

REPORT EJECT

변경되지 않음

REPORT ENTER

변경되지 않음

REPORT EXPORT

변경되지 않음

REPORT LSM

향상됨

REPORT MIGRATE

변경되지 않음

REPORT MULTIPLE

변경되지 않음

MVCRPT

REPORT MVC_VTV

향상됨

MVCRPT

REPORT NONSCRCNT

향상됨

REPORT OPERATOR

변경되지 않음

REPORT PHYSICAL

변경되지 않음

VOLRPT

REPORT RECALL

변경되지 않음

REPORT SCRCNT

향상됨

REPORT SUMMARY

향상됨

REPORT VIRTUAL

변경되지 않음

VTVRPT

REPORT VOLUME

향상됨

SET METHOD

변경되지 않음

SUBPOOL

변경되지 않음

SUBPOOL 및 MANAGE PHYSICAL BALSCR

변경되지 않음

SCRATCH REDISTRIBUTION

TMS CA1

변경되지 않음

TMS COMMON

변경되지 않음

TMS CTT

변경되지 않음

TMS CUSTOM

변경되지 않음

TMS OPEN

변경되지 않음

TMS RMM

변경되지 않음

TMS TLMS

변경되지 않음

UNMANAGED

변경되지 않음

인덱스
A  B  C  D  H  L  M  O  R  S  V  공  내  덤  레  마  백  보  복  스  유  일  진  카  컨  통  할  호

A

ABEND 덤프, 1.1

AUDIT, 5.5.3, 6.4.3

B

BACKup 유틸리티

설명, 2.1.3

함수, 2.1.3

C

CAP의 RECOVERY 상태

지우기, 3.5.3

CAP의 RECOVERY 상태를 지우는 방법, 3.5.3 CAP(카트리지 액세스 포트)

Display Cap 명령에서 RECOVERY 상태 지우기, 3.5.3

CDS Disable 명령, 2.5, 2.6.1 CDS 복사(이름 바꾸기 사용), 2.6 CDS 스왑, 2.8 CDS 이동(이름 바꾸기 사용), 2.6 CDS 재배치, 2.6.1 CDS(컨트롤 데이터 세트)

스왑, 2.8

이름 바꾸기 절차, 2.6

COMMPath 명령 및 제어문

사용, 3.5.5

D

DHB(데이터베이스 하트비트) 레코드

CDS Enable/Disable을 사용하여 CDS 재지정, 2.5, 2.6.1

Display 명령, 3.5.8

H

HSC(Host Software Component)

진단 명령

Display, 3.5.8

호스트 간 통신 복원, 3.5.5

L

LSM(라이브러리 스토리지 모듈)

레이블이 누락되거나 레이블을 읽을 수 없는 카트리지 넣기, 3.5.2.2

중복 VOLSER 넣기, 3.5.2.1

LSM에 카트리지 넣기

레이블이 누락되거나 레이블을 읽을 수 없음, 3.5.2.2

중복 VOLSER 및 읽을 수 없는 VOLSER, 3.5.2.1

M

MVC

공간 재생

요청식, 5.1

MVC 풀

VT Display 명령, 4.2.1, 4.2.1

O

ORH(Overdue Response Handler)

개요, 3.5.7.1

마운트, 마운트 해제, 이동 및 스왑 요청에 운영자 응답 필요, 3.5.7.2

R

RESTore 유틸리티

실행 사유, 2.9.1

RTV 유틸리티, 7.2

S

SET 명령

SET SLIDRIVS

절차, 3.1.4, 5.5.4

V

VSM

VTV 마이그레이션

요청식, 5.1.2

VTV 회수

요청식, 5.1.3

관리

VTSS, 4.3

요청식 마이그레이션, 회수 및 재생, 5.1

일반적인 문제 해결, 7.1

VTCS

VTV 마이그레이션

요청식, 5.1.2

유틸리티

AUDIT, 5.5.3, 6.4.3

RTV, 7.2

복구, 7.2

VTD

VT Display 명령, 4.1.1

VTSS

관리, 4.3

VTV

마운트 성능 저하, 7.1.1

마이그레이션

성능 저하, 7.1.2

마이그레이션 성능 저하, 7.1.2 요청식 마이그레이션, 5.1 회수

요청식, 5.1

공

공간 재생

요청식, 5.1

내

내역

이벤트(GTF 추적), 1.1

덤

덤프

프로그램, 3.5.8

레

레이블

레이블이 누락되거나 레이블을 읽을 수 없는 카트리지 넣기, 3.5.2.2

레이블이 누락되거나 레이블을 읽을 수 없음, 3.5.2.2

마

마이그레이션

요청식, 5.1

백

백업

CDS, 2.1.3

보

보고서

BACKup 유틸리티, 2.1.3

복

복구

Display Cap 명령에서 RECOVERY 상태 지우기, 3.5.3

할당된 CAP 해제, 3.5.4

호스트 간 통신 복원, 3.5.5

복구 유틸리티, 7.2

스

스크래치

볼륨

ACS에서 부족, 1.1

스크래치 하위 풀

VT Display 명령, 4.1.1

유

유틸리티

BACKup, 2.1.3

일

일반적인 문제 해결, 7.1

진

진단

프로그램 덤프, 3.5.8

카

카트리지

LSM에 넣기

레이블이 누락되거나 레이블을 읽을 수 없음, 3.5.2.2

중복 VOLSER, 3.5.2.1

컨

컨트롤 데이터 세트 이름 바꾸기, 2.6

통

통신

복원, 3.5.5

할

할당된 CAP 해제, 3.5.4

호

호스트

호스트 간 통신 복원, 3.5.5

호스트 간 통신 서비스 복원, 3.5.5

Oracle 법적공지

저작권 공지

Copyright © 1994-2016, Oracle and/or its affiliates. All rights reserved.

라이센스 제한 보증/간접 손해 부인

본 소프트웨어와 관련 문서는 사용 제한 및 기밀 유지 규정을 포함하는 라이센스 합의서에 의거해 제공되며, 지적 재산법에 의해 보호됩니다. 라이센스 합의서 상에 명시적으로 허용되어 있는 경우나 법규에 의해 허용된 경우를 제외하고, 어떠한 부분도 복사, 재생, 번역, 방송, 수정, 라이센스, 전송, 배포, 진열, 실행, 발행, 또는 전시될 수 없습니다. 본 소프트웨어를 리버스 엔지니어링, 디스어셈블리 또는 디컴파일하는 것은 상호 운용에 대한 법규에 의해 명시된 경우를 제외하고는 금지되어 있습니다.

보증 부인

이 안의 내용은 사전 공지 없이 변경될 수 있으며 오류가 존재하지 않음을 보증하지 않습니다. 만일 오류를 발견하면 서면으로 통지해 주기 바랍니다.

제한적 권한 공지

만일 본 소프트웨어나 관련 문서를 미국 정부나 또는 미국 정부를 대신하여 라이센스한 개인이나 법인에게 배송하는 경우, 다음 공지사항이 적용됩니다.

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

위험한 애플리케이션 공지

본 소프트웨어 혹은 하드웨어는 다양한 정보 관리 애플리케이션의 일반적인 사용을 목적으로 개발되었습니다. 본 소프트웨어 혹은 하드웨어는 개인적인 상해를 초래할 수 있는 애플리케이션을 포함한 본질적으로 위험한 애플리케이션에서 사용할 목적으로 개발되거나 그 용도로 사용될 수 없습니다. 만일 본 소프트웨어 혹은 하드웨어를 위험한 애플리케이션에서 사용할 경우, 라이센스 사용자는 해당 애플리케이션의 안전한 사용을 위해 모든 적절한 비상-안전, 백업, 대비 및 기타 조치를 반드시 취해야 합니다. Oracle Corporation과 그 자회사는 본 소프트웨어 혹은 하드웨어를 위험한 애플리케이션에서의 사용으로 인해 발생하는 어떠한 손해에 대해서도 책임지지 않습니다.

상표 공지

Oracle과 Java는 Oracle Corporation 및/또는 그 자회사의 등록 상표입니다. 기타의 명칭들은 각 해당 명칭을 소유한 회사의 상표일 수 있습니다.

Intel 및 Intel Xeon은 Intel Corporation의 상표 내지는 등록 상표입니다. SPARC 상표 일체는 라이센스에 의거하여 사용되며 SPARC International, Inc.의 상표 내지는 등록 상표입니다. AMD, Opteron, AMD 로고, 및 AMD Opteron 로고는 Advanced Micro Devices의 상표 내지는 등록 상표입니다. UNIX는 The Open Group의 등록상표입니다.

제3자의 컨텐츠, 제품 및 서비스 부인

본 소프트웨어 혹은 하드웨어와 관련문서(설명서)는 제 3자로부터 제공되는 컨텐츠, 제품 및 서비스에 접속할 수 있거나 정보를 제공합니다. 사용자와 오라클 간의 합의서에 별도로 규정되어 있지 않는 한 Oracle Corporation과 그 자회사는 제 3자의 컨텐츠, 제품 및 서비스와 관련하여 어떠한 책임도 지지 않으며 명시적으로 모든 보증에 대해서도 책임을 지지 않습니다. Oracle Corporation과 그 자회사는 제 3자의 컨텐츠, 제품 및 서비스에 접속하거나 사용으로 인해 초래되는 어떠한 손실, 비용 또는 손해에 대해 어떠한 책임도 지지 않습니다. 단, 사용자와 오라클 간의 합의서에 규정되어 있는 경우는 예외입니다.

알파 및 베타 초안 문서 공지

공식적인 공개 이전의 문서인 경우:

본 문서는 공식적인 공개 이전의 문서이며 시연 및 예비 용도로 작성되었습니다. 본 문서는 소프트웨어가 사용되고 있는 귀하의 하드웨어를 위해 특별히 작성되지 않았을 수도 있습니다. Oracle Corporation과 그 자회사는 본 문서와 관련하여 어떠한 책임도 지지 않으며 명시적으로 모든 보증에 대해서도 책임을 지지 않습니다. 또한 본 문서의 사용으로 인해 초래되는 손실, 비용 또는 손해에 대해 어떠한 책임도 지지 않습니다.

비공개 알파 및 베타 초안 문서 공지

공식적인 공개 이전의 비공개 문서인 경우:

본 문서의 내용은 오직 정보를 공유하기 위한 것이며 고객 자문 위원으로서 또는 베타 시험 합의서에 따라서만 사용할 수 있습니다. 이는 어떠한 자료, 코드 또는 기능을 제공하겠다는 약속이 아니고, 어떠한 구매 의사 결정을 필요로 하지 아니합니다. 본 문서에 설명된 기능의 개발, 출시 및 시기에 대한 재량권은 전적으로 오라클에 있습니다.

소프트웨어 또는 인쇄 자료를 포함한 어떠한 형식으로든 본 문서는 오라클의 고유 자산인 독점적 정보를 포함하고 있습니다. 본 기밀 자료의 액세스 및 사용에는 오라클 마스터 합의서, 오라클 라이센스 및 서비스 합의서, 오라클 파트너네트워크 합의서, 오라클 배포 합의서 또는 기타 라이센스 합의서의 조항 및 조건이 적용되며, 사용자와 오라클은 이를 이행하고 준수하여야 합니다. 오라클의 사전 서면 동의 없이 본 문서와 여기에 포함된 정보를 오라클 외부의 다른 사람에게 공개, 복사, 재생산 또는 배포할 수 없습니다. 본 문서는 라이센스 합의서에 포함되지 아니하며 오라클 또는 그 자회사와의 어떠한 합의서에도 편입되지 아니합니다.

설명서 접근성

Oracle의 접근성 개선 노력에 대한 자세한 내용은 http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc에서 Oracle Accessibility Program 웹 사이트를 방문하십시오.

오라클 고객지원센터 액세스

지원 서비스를 구매한 오라클 고객은 My Oracle Support를 통해 온라인 지원에 액세스할 수 있습니다. 자세한 내용은 http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info를 참조하거나, 청각 장애가 있는 경우 http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs를 방문하십시오.