거래처리시설

Transaction Processing Facility
z/TPF
디벨로퍼IBM
기재.z/아키텍처 어셈블리 언어, C, C++
OS패밀리z/아키텍처 어셈블리어(z/TPF), ESA/390 어셈블리어(TPF4)
작업상태현재의
원천모델폐쇄형 소스(소스 코드는 제한이 있는 라이선스 사용자가 사용할 수 있음)
초기출시1979년; 44년전 (1979)
최신판1.1.0.2023[1]
플랫폼IBM System z(z/TPF), ESA/390(TPF4)
커널형실시간
체납
사용자 인터페이스		3215 3270
면허증.월간 라이선스 비용(MLC)
공식 홈페이지z/TPF 제품 페이지
IBM 메인프레임 운영체제의 역사
초기 메인프레임 컴퓨터 OS
기타 S/360 라인 OS
DOS/360 및 후속 제품(1966)
OS/360 및 후속 제품(1966)
VM라인
TPF선
유닉스 및 유닉스 계열

TPF([2]Transaction Processing Facility)는 zSeries 및 System z9를 포함한 IBM System/360 계열의 메인프레임 컴퓨터용 실시간 운영 체제입니다.

TPF는 지리적으로 분산된 대규모 네트워크에 걸쳐 본질적으로 단순한 대규모 트랜잭션의 지속적인 부하를 처리함으로써 빠르고, 대량의 처리량이 높은 트랜잭션 처리를 제공합니다.

IBM의 CICS 및 IMS를 비롯한 다른 산업 강도 높은 트랜잭션 처리 시스템도 있지만, TPF의 전문 분야는 극단적인 볼륨, 많은 동시 사용자 수 및 매우 빠른 응답 시간입니다.예를 들어, 휴가 쇼핑 성수기에 비자 신용카드 거래 처리를 처리합니다.[3][2]

많은 항공사에서 TPF 승객 예약 애플리케이션 PARS 또는 그 국제 버전 IPARS를 사용하고 있습니다.PARS는 응용 프로그램이고, TPF는 운영 체제입니다.

TPFDF(TPF Database Facility)라 불리는 고성능의 전문 데이터베이스 설비는 TPF의 주요 옵션 구성 요소 중 하나입니다.[4]

TPF의 가까운 친척인 트랜잭션 모니터 ALCS는 보다 일반적인 메인프레임 운영 체제 MVS(현재 z/OS)에 TPF 서비스를 통합하기 위해 IBM에 의해 개발되었습니다.

역사

TPF는 1960년대 중반 IBM이 북미 및 유럽의 주요 항공사와 협력하여 개발한 무료 패키지인 항공사 제어 프로그램(ACP)에서 발전되었습니다.1979년 IBM은 TPF를 ACP의 대체품으로, 그리고 가격이 책정된 소프트웨어 제품으로 선보였습니다.그 새로운 이름은 그것의 더 큰 범위와 비항공사 관련 실체로의 진화를 암시합니다.

TPF는 성능상의 이유로 인해 전통적으로 IBM System/370 어셈블리 언어 환경이었으며, 많은 TPF 어셈블리어 응용 프로그램이 지속되고 있습니다.그러나 최근 버전의 TPF는 C의 사용을 권장합니다.또 다른 프로그래밍 언어인 SabreTalk가 TPF에서 탄생하고 사라졌습니다.

IBM은 2005년 9월 z/TPF V1.1로 명명된 TPF의 현재 출시를 발표했습니다.가장 중요한 것은 z/TPF가 64비트 주소 지정을 추가하고 64비트 GNU 개발 도구의 사용을 의무화한다는 점입니다.[5][6]

GCC 컴파일러와 DIGNUS Systems/C++ 및 Systems/C는 z/TPF용으로 지원되는 유일한 컴파일러입니다.Dignus 컴파일러는 TPF 4.1에서 z/TPF로 이동할 때 감소된 소스 코드 변경을 제공합니다.

사용자

현재 사용자는 Sabre(예약), VISA Inc.(허가), American Airlines,[7] American Express(허가), DXC Technology SHARES(예약), Amtrak, Merriott International, Travelport(갈릴레오, 아폴로, 월드스팬), 씨티은행, 트레니탈리아(예약), 델타 항공(예약 및 운영) 및 일본 항공 등입니다.[8]

운영환경

단단하게 결합됨

IBM의 3083은 TPF를 "빠른 속도로..." 운영하는 것을 목표로 하고 있었습니다.유니프로세서",[9] TPF는 멀티프로세서, 즉 CPU가 둘 이상 있는 시스템에서 실행할 수 있습니다.LPAR 내에서 CPU는 명령 스트림 또는 단순히 I-스트림으로 지칭됩니다.둘 이상의 I-스트림이 있는 LPAR에서 실행될 때, TPF는 긴밀하게 결합되어 실행된다고 합니다.TPF는 SMP 개념을 고수하며, 메모리 주소 간에 NUMA 기반의 구분이 존재하지 않습니다.

CPU 준비 목록의 깊이는 들어오는 트랜잭션이 수신될 때 측정되며, 가장 낮은 요구량으로 I-stream을 위해 대기하므로 사용 가능한 프로세서 간에 지속적인 로드 밸런싱을 유지합니다.느슨하게 결합된 구성이 멀티프로세서 CPC(Central Processing Complex, 즉 하나의 시스템 캐비닛에 패키징된 물리적 기계)에 의해 채워지는 경우, SMP는 여기에 설명된 바와 같이 CPC 내에서 발생하는 반면, CPC 간 자원 공유는 아래에 설명된 바와 같이 발생합니다.

TPF 아키텍처에서는 모든 메모리(4KB 크기의 접두사 영역 제외)가 모든 I 스트림에서 공유됩니다.메모리-레지던트 데이터가 I-스트림에 의해 분리되어야 하거나 분리되어야 하는 경우들에서, 프로그래머는 일반적으로 저장 영역을 I-스트림의 수와 동일한 수의 서브섹션들로 할당하고, 할당된 영역의 기본 주소를 취함으로써 원하는 I-스트림 관련 영역에 액세스하는,여기에 각 서브섹션 크기의 I-stream 상대적 개수의 곱을 추가합니다.

느슨하게 결합됨

TPF는 여러 메인프레임(단일 I-stream이든 여러 I-stream이든)을 공통 데이터베이스에 연결하고 작동하도록 지원할 수 있습니다.현재 32개의 IBM 메인프레임이 TPF 데이터베이스를 공유할 수 있습니다. 이러한 시스템이 작동 중이라면 32-way loosely coupled라고 할 것입니다.느슨하게 결합된 가장 간단한 시스템은 하나의 DASD(Direct Access Storage Device)를 공유하는 두 개의 IBM 메인프레임일 것입니다.이 경우 제어 프로그램은 메모리에 동일하게 로드되고 DASD의 각 프로그램 또는 레코드는 메인프레임에 의해 액세스될 수 있습니다.

느슨하게 연결된 시스템에서 데이터 레코드 간의 액세스를 직렬화하려면 레코드 잠금이라고 하는 방법을 사용해야 합니다.즉, 하나의 메인프레임 프로세서가 레코드에 대한 홀드를 획득할 경우, 메커니즘은 다른 모든 프로세서가 동일한 홀드를 획득하지 못하도록 방지하고, 요청 프로세서가 대기 중인 것으로 통신해야 합니다.긴밀하게 연결된 시스템에서는 레코드 홀드 테이블을 사용하여 I 스트림 간에 쉽게 관리할 수 있습니다.그러나 DASD 제어 장치에서 TPF 프로세서의 오프보드에서 잠금을 획득한 경우에는 외부 프로세스를 사용해야 합니다.역사적으로, 기록 잠금은 LLF(Limited Locking Facility)라고 하는 RPQ와 나중에 ELLF(Extended)라고 하는 RPQ를 통해 DASD 제어 유닛에서 수행되었습니다.LLF와 ELLF는 모두 MPLF(Multipathing Lock Facility)로 대체되었습니다.클러스터된(느리게 결합된) z/TPF를 실행하려면 모든 디스크 제어 장치에 MPLF 또는 Coupling Facility라는 대체 잠금 장치가 필요합니다.[10][11]

프로세서 공유 레코드

기록 잠금 프로세스에 의해 반드시 관리되어야 하는 기록은 프로세서 공유 기록입니다.TPF에서는 레코드 유형과 순서형을 사용하여 대부분의 레코드 액세스를 수행합니다.100개의 레코드 또는 서수를 가진 'FRED'의 TPF 시스템에 레코드 유형이 있을 경우, 프로세서 공유 방식에서 레코드 유형 'FRED' 서수 '5'는 DASD에서 정확히 동일한 파일 주소로 해결되므로 레코드 잠금 메커니즘을 사용해야 합니다.

TPF 시스템의 모든 프로세서 공유 레코드는 동일한 파일 주소를 통해 액세스되며, 동일한 위치로 해결됩니다.

프로세서 고유 레코드

프로세서 고유 레코드란 느슨하게 결합된 복합체에 있을 것으로 예상되는 각 프로세서가 'FRED'의 레코드 유형과 약 100개의 서수를 갖도록 정의되는 레코드입니다.그러나 2개 이상의 프로세서에서 'FRED' 또는 '5' 순서로 기록된 파일 주소를 검사하면 다른 물리적 주소가 사용되는 것을 알 수 있습니다.

TPF 속성

TPF가 아닌 것

TPF는 범용 운영 체제가 아닙니다.TPF의 전문적인 역할은 트랜잭션 입력 메시지를 처리한 다음 출력 메시지를 1:1 단위로 짧은 최대 경과 시간 제한과 함께 극도로 높은 볼륨으로 반환하는 것입니다.

TPF에는 그래픽 사용자 인터페이스 기능이 내장되어 있지 않으며 TPF는 직접 그래픽 디스플레이 기능을 제공한 적이 없습니다. 호스트에 구현하는 것은 불필요하고 잠재적으로 유해한 실시간 시스템 리소스 전용으로 간주됩니다.TPF의 사용자 인터페이스는 위쪽으로 스크롤하는 간단한 텍스트 표시 단자로 명령줄 구동되며 TPF Prime CRAS[12](컴퓨터 룸 에이전트 세트 - "오퍼레이터 콘솔"로 가장 잘 알려진)에는 마우스로 구동되는 커서, 윈도우 또는 아이콘이 없습니다.문자 메시지는 인간 사용자와의 의사소통 방식을 의도한 것입니다.모든 작업은 X가 없는 UNIX와 유사하게 명령줄을 사용하여 수행됩니다.Prime CRAS에 연결하고 TPF Operations Server와 같은 TPF 운영자에게 그래픽 인터페이스 기능을 제공하는 여러 제품이 있습니다.[13]원하는 경우 최종 사용자를 위한 그래픽 인터페이스는 외부 시스템에서 제공해야 합니다.이러한 시스템은 문자 내용에 대한 분석을 수행하고(화면 스크래치 참조), 메시지의 상황에 따라 원하는 그래픽 형식으로 변환합니다.

특수 목적 운영 체제인 TPF는 컴파일러/어셈블러, 텍스트 편집기를 호스팅하지 않으며 범용 운영 체제에서 찾을 수 있는 데스크톱의 개념을 구현하지 않습니다.TPF 응용 프로그램 소스 코드는 일반적으로 외부 시스템에 저장되며, 마찬가지로 "오프라인"으로 구축됩니다.z/TPF 1.1부터 Linux가 지원되는 빌드 플랫폼입니다. z/TPF 운영을 위한 실행 프로그램은 s390x-ibm-linux의 ELF 형식을 준수해야 합니다.

사용자가 익숙할 수 있는 온라인 명령 "디렉토리" 또는 "맨"/도움말 기능이 지원되지 않으므로 TPF를 사용하려면 명령 가이드에[14] 대한 지식이 필요합니다.TPF의 시스템 관리를 위해 IBM에서 작성 및 발송한 명령어를 "기능 메시지"라고 하며, 모두 "Z" 문자 앞에 붙이기 때문에 일반적으로 "Z-메시지"라고 합니다.그 외의 편지는 고객이 직접 명령어를 작성할 수 있도록 예약되어 있습니다.

TPF는 분산 클라이언트-서버 모드로 디버깅을 구현하는데, 이는 시스템의 머리가 없는 다중 처리 특성 때문에 필요합니다. 하나의 작업을 트랩하기 위해 전체 시스템을 일시 중지하는 것은 매우 역효과를 가져옵니다.디버거 패키지는 TPF 호스트에서 요구되는 "중단/계속" 작업에 대해 매우 다른 접근 방식을 취하여 디버거 클라이언트를 실행하는 인간 개발자와 서버측 디버그 컨트롤러 사이의 트래픽에 사용되는 고유한 통신 프로토콜을 구현한 서드파티 벤더에 의해 개발되었습니다.뿐만 아니라 클라이언트 측에서 디버거 프로그램 작업의 형태와 기능.타사 디버거 패키지의 두 가지 예로는 Bedford Associates의[15] Step by Step Trace와 CMSTPF, TPF/GI, zTPFGI 등이 있으며, 모두 TPF Software, Inc.의 것입니다.[16]어느 패키지도 다른 패키지와 완전히 호환되지 않으며 IBM 자체 제품과도 호환되지 않습니다.IBM의 디버깅 클라이언트 오퍼링은 IBM TPF Toolkit라는 IDE로 패키지화되어 있습니다.[17]

TPF란

TPF는 지원되는 네트워크의 메시지를 다른 위치로 전환하거나 애플리케이션(특정 프로그램 집합)으로 라우팅하거나 데이터베이스 레코드에 매우 효율적으로 액세스할 수 있도록 매우 최적화되어 있습니다.

자료기록

지금까지 TPF 시스템의 모든 데이터는 381, 1055 및 4K 바이트의 고정 레코드(및 메모리 블록) 크기에 맞추어야 했습니다.이는 DASD에 위치한 블록의 물리적 레코드 크기 때문이기도 했습니다.운영 체제의 모든 부분에서 파일 작업 중에 큰 데이터 개체를 작은 개체로 분할하고 읽기 작업 중에 다시 조립하는 것을 방지함으로써 많은 오버헤드를 절약할 수 있었습니다.IBM 하드웨어는 채널과 채널 프로그램을 사용하여 I/O를 수행하기 때문에 TPF는 속도라는 이름으로 I/O를 수행하기 위해 매우 작고 효율적인 채널 프로그램을 생성하게 됩니다.초창기에는 메모리든 디스크든 스토리지 미디어의 크기를 중요하게 여겼기 때문에 TPF 애플리케이션은 매우 적은 리소스를 사용하면서도 매우 강력한 작업을 수행하게 되었습니다.

오늘날 이러한 제약은 상당 부분 해소되고 있습니다.사실 레거시 지원 때문에 4K DASD 레코드보다 더 작은 레코드가 여전히 사용되고 있습니다.DASD 기술의 발전으로 4K 레코드의 읽기/쓰기는 1055바이트 레코드만큼 효율적입니다.동일한 발전으로 인해 각 장치의 용량이 증가하여 가능한 가장 작은 모델로 데이터를 포장하는 기능에 프리미엄을 더 이상 부여하지 않게 되었습니다.

프로그램과 레지던트

또한 TPF는 프로그램 세그먼트를 381, 1055 및 4K 바이트 크기의 레코드로 역사상 여러 지점에 할당했습니다.각 세그먼트는 하나의 레코드로 구성되어 있으며, 일반적으로 포괄적인 애플리케이션은 수십 개 또는 수백 개의 세그먼트를 필요로 합니다.TPF 역사상 처음 40년 동안 이러한 세그먼트는 링크 편집되지 않았습니다.대신 재배치 가능한 객체 코드(어셈블러에서 직접 출력)를 메모리에 배치하고 내부적으로 재배치 가능한 기호를 해결한 다음 전체 이미지를 파일로 작성하여 나중에 시스템에 로드할 수 있도록 했습니다.이것은 서로 관련된 세그먼트들이 서로 직접 주소를 지정할 수 없는 어려운 프로그래밍 환경을 만들었고, 그들 사이의 제어 전달은 ENTER/BACK 시스템 서비스로 구현되었습니다.

ACP/TPF의 초창기(1965년경)에는 메모리 공간이 심각하게 제한되어 파일-레지던트 프로그램과 코어-레지던트 프로그램 간에 차이가 발생했습니다. 가장 자주 사용되는 애플리케이션 프로그램만 메모리에 기록되고 제거되지는 않았습니다(코어-레지던스). 나머지는 파일에 저장되고 주문형으로 읽혀졌습니다.execution 후에 그들의 백업 메모리 버퍼들과 함께.

버전 3.0에서 TPF에 C 언어를 도입한 것은 링크 편집의 부재를 포함한 세그먼트 규약에 따라 처음으로 구현되었습니다.이 계획은 가장 단순한 C 프로그램 이외의 어떤 것에도 실용적이지 않다는 것을 빠르게 증명했습니다.TPF 4.1에서는 TPF에 완전 연결 로드 모듈이 도입되었습니다.이것들은 TPF 특정 헤더 파일을 사용하여 z/OS C/C++ 컴파일러로 컴파일되고 IEWL과 연동되어 z/OS 적합 로드 모듈이 생성되었으며, 이는 어떤 방식으로도 기존의 TPF 세그먼트로 간주될 수 없었습니다.TPF 로더는 z/OS 고유 로드 모듈 파일 형식을 읽고 파일에 상주하는 로드 모듈의 섹션을 메모리에 배치하도록 확장되었습니다. 한편, 어셈블리 언어 프로그램은 TPF의 세그먼트 모델에 국한되어 있어 어셈블러로 작성된 응용 프로그램과 상위 레벨 언어(HLL)로 작성된 응용 프로그램 간에 분명한 차이가 발생했습니다.

z/TPF 1.1에서 모든 소스 언어 유형은 ELF 사양을 준수하도록 개념적으로 통일되고 완전히 링크 편집되었습니다.세그먼트 개념은 더 이상 쓸모가 없어졌습니다. 즉, 어셈블러를 포함한 모든 소스 언어로 작성된 모든 프로그램이 이제는 어떤 크기라도 될 수 있습니다.또한 외부 참조가 가능해졌고, 한때 세그먼트였던 개별 소스 코드 프로그램을 공유 객체로 직접 연결할 수 있게 되었습니다.중요한 점은 중요한 레거시 애플리케이션이 단순한 재패키징을 통해 효율성 향상의 이점을 얻을 수 있다는 점입니다. 단일 공유 객체 모듈의 구성원 간에 이루어지는 호출은 시스템의 ENTER/BACK 서비스를 호출하는 것에 비해 실행 시 경로 길이가 훨씬 짧습니다.z/TPF 1.1에서 도입된 copy-on-write 기능 덕분에 동일한 공유 객체의 구성원이 쓰기 가능한 데이터 영역을 직접 공유할 수 있습니다. 이 기능은 우연히 TPF의 재진입 요구 사항을 강화합니다.

파일 및 메모리 상주의 개념도 z/TPF 설계로 인해 더 이상 쓸모가 없게 되었습니다. 모든 프로그램을 항상 메모리에 상주시키고자 했기 때문입니다.

z/TPF는 HLL 프로그램이 스택 기반 메모리 할당의 혜택을 받을 수 있는 능력을 제공하는 고급 언어 프로그램을 위한 콜 스택을 유지해야 했기 때문에, 선택적으로 콜 스택을 어셈블리 언어 프로그램으로 확장하는 것이 메모리 압력을 완화하고 재귀적 프로그래밍을 용이하게 할 수 있는 이점이 있다고 판단되었습니다.

이제 모든 z/TPF 실행 프로그램이 ELF 공유 개체로 패키지됩니다.

메모리사용량

역사적으로 그리고 이전과 보조를 같이 했던 코어 블록(메모리)의 크기도 381, 1055, 4K 바이트였습니다.모든 메모리 블록은 이 크기여야 했기 때문에 다른 시스템에서 발견되는 메모리를 얻기 위한 대부분의 오버헤드가 폐기되었습니다.프로그래머는 단지 어떤 크기의 블록이 필요에 적합한지를 결정하고 그것을 요구하기만 하면 되었습니다.TPF는 사용 중인 블록 목록을 유지 관리하고 사용 가능한 목록의 첫 번째 블록을 간단히 배포합니다.

물리적 메모리를 각 크기에 맞게 예약된 섹션으로 나누었기 때문에 항상 섹션에서 1055 바이트 블록을 가져와 해당 섹션으로 반환할 때 필요한 오버헤드는 적절한 물리적 블록 테이블 목록에 해당 주소를 추가하는 것뿐이었습니다.압축이나 데이터 수집이 필요 없습니다.

응용 프로그램들이 메모리에 대한 고급 수요가 증가함에 따라, C가 사용 가능해지면, 불확정하거나 큰 크기의 메모리 청크가 필요하게 되었습니다.이로 인해 힙 스토리지와 일부 메모리 관리 루틴이 사용되었습니다.오버헤드를 줄이기 위해 TPF 메모리를 4KB 크기의 프레임(z/TPF 포함 시 1MB)으로 분할했습니다.응용프로그램에 특정 바이트 수가 필요한 경우 해당 필요를 채우는 데 필요한 연속 프레임 수가 부여됩니다.

참고문헌

  1. ^ "z/TPF, z/TPFDF, TPF Operations Server, and TPF Toolkit 4.6 for 2023". IBM.
  2. ^ a b Steve Lohr (October 4, 2004). "IBM Updates Old Workhorse to Use Linux". The New York Times.
  3. ^ Michelle Louzoun (August 24, 1987). "Visa Is Everywhere It Wants To Be". InformationWeek. p. 19.
  4. ^ IBM Corporation. "TPF Database Facility (TPFDF)". z/Transaction Processing Facility. Retrieved November 11, 2016.
  5. ^ "IBM bolsters its mainframe platform". Computerworld.
  6. ^ Jennifer Mears. "IBM pumps up Linux virtual machines on mainframe OS". Computerworld.
  7. ^ "TPF Users Group, Job Corner". Archived from the original on 2000-01-15.
  8. ^ "IBM News room - 2008-04-14 Japan Airlines International to Upgrade Reservation and Ticketing System With IBM Mainframe - United States". 03.ibm.com. 2008-04-14. Retrieved 2017-03-15.
  9. ^ Anne & Lynn Wheeler. "IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))". Newsgroup: alt.folklore.computers.
  10. ^ "IBM Knowledge Center". Publib.boulder.ibm.com. 2014-10-24. Retrieved 2017-03-15.
  11. ^ "IBM z/Transaction Processing Facility Enterprise Edition V1.1 hardware requirements - United States". www-01.ibm.com. Archived from the original on 7 October 2012. Retrieved 17 January 2022.
  12. ^ IBM Corporation (19 Apr 2018). "z/TPF Glossary". IBM. Retrieved 10 May 2018.
  13. ^ IBM Corporation (19 April 2018). "IBM TPF Operations Server". IBM. Retrieved 10 May 2018.
  14. ^ IBM Corporation (29 January 2019). "z/TPF Operations Command Guide". IBM.
  15. ^ Bedford Associates. "Bedford Associates, Inc". Retrieved October 17, 2012.
  16. ^ TPF Software. "TPF Software, Inc". Retrieved October 17, 2012.
  17. ^ IBM Corporation (Dec 2017). "IBM TPF Toolkit Overview". IBM. Retrieved 10 May 2018.

서지학

  • 트랜잭션 처리 기능: R. Jason Martin (하드커버 - April 1990), ISBN 978-0139281105의 응용 프로그래머를 위한 가이드 (Yourdon Press Computing Series)

외부 링크