맨위로가기

트랜잭션 처리 기능

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

트랜잭션 처리 기능(TPF)은 1960년대 IBM에서 개발된 항공 예약 시스템인 IBM ACP에서 파생된 상용 소프트웨어 제품이다. TPF는 주로 IBM 시스템/370 어셈블리어 환경에서 개발되었으며, 현재는 C 언어를 권장한다. TPF는 항공 예약, 신용카드 승인, 중앙 예약 시스템 등 다양한 분야에서 활용되며, 여러 CPU를 사용하는 멀티프로세싱 환경을 지원한다. TPF는 고도로 최적화되어 대량의 트랜잭션을 처리하며, 고정된 크기의 레코드와 메모리 블록을 사용한다.

더 읽어볼만한 페이지

  • IBM 메인프레임 운영 체제 - OS/390
    OS/390은 1995년에 출시된 IBM의 운영 체제 패키지로, MVS 운영 체제 핵심 요소를 통합하여 신뢰성, 가용성, 서비스 가능성을 향상시켰으며, 2004년에 지원이 종료되었다.
  • IBM 메인프레임 운영 체제 - OS/360
    OS/360은 IBM System/360 제품군을 위해 개발된 범용 운영 체제로, 상업 및 과학 기술 계산을 지원하고 일괄 처리 시스템에서 발전하여 EBCDIC 문자 코드를 채용하고 자기 디스크 장치를 다루는 최초의 OS가 되었으며, 현재의 IBM 메인프레임 OS인 z/OS의 계승자로서 퍼블릭 도메인으로 공개되어 Hercules 에뮬레이터를 통해 실행 가능하다.
  • 실시간 운영체제 - Nucleus RTOS
    Nucleus RTOS는 1993년 Accelerated Technology에서 출시된 실시간 운영 체제로, 다양한 아키텍처와 구성 요소를 지원하며 안전 인증을 받아 여러 제품에 사용되었다.
  • 실시간 운영체제 - 블랙베리 10
    블랙베리 10은 2013년에 출시된 블랙베리 리미티드의 모바일 운영 체제로, 터치스크린 및 물리 키보드 스마트폰을 지원하며 제스처 기반 인터페이스, 블랙베리 허브 등의 기능을 제공했으나 2022년에 공식 지원이 종료되었다.
  • 트랜잭션 처리 - 2단계 커밋 프로토콜
    2단계 커밋 프로토콜은 분산 컴퓨팅 환경에서 트랜잭션의 원자성을 보장하는 분산 알고리즘으로, 조정자와 참가자로 구성되어 모든 참가자가 트랜잭션을 완료하거나 아무도 완료하지 못하도록 하며, 커밋 요청 및 커밋 단계를 거쳐 모든 참가자의 동의를 얻어야 커밋된다.
  • 트랜잭션 처리 - 온라인 트랜잭션 처리
    온라인 트랜잭션 처리(OLTP)는 실시간 데이터베이스 트랜잭션 처리 방식으로, 가용성, 속도, 동시성, 내구성을 목표로 은행, 항공사, 전자 상거래 등에서 활용된다.
트랜잭션 처리 기능 - [IT 관련 정보]에 관한 문서
기본 정보
IBM 로고
IBM 로고
개발사IBM
소스 모델클로즈드 소스 (소스 코드는 제한된 사용자만 이용 가능)
커널 종류실시간
지원 플랫폼IBM 시스템 z (z/TPF), ESA/390 (TPF4)
사용자 인터페이스3215 3270
계열z/아키텍처 어셈블리어 (z/TPF), ESA/390 어셈블리어 (TPF4)
최초 출시1979년
최신 버전1.1.0.2023
개발 언어z/아키텍처 어셈블리어, C, C++
현재 상태지원 중
라이선스사유 월간 라이선스 (MLC)
웹사이트z/TPF 제품 페이지
역사
관련 정보
인용 뉴스IBM, 리눅스 사용을 위해 오래된 워크호스 업데이트 - 뉴욕 타임스, 2004년 10월 4일
인용 잡지Visa Is Everywhere It Wants To Be - InformationWeek, 1987년 8월 24일
IBM TPF 데이터베이스 기능 (TPFDF)z/Transaction Processing Facility

2. 역사

TPF는 1960년대 중반 IBM이 북미 및 유럽 주요 항공사들과 협력하여 개발한 IBM ACP(Airline Control Program)에서 발전하였다. 1979년 IBM은 ACP를 대체하는 상용 소프트웨어 제품으로 TPF를 출시하였다.[5][6] TPF는 성능상의 이유로 전통적으로 IBM 시스템/370 어셈블리어 환경으로 개발되었으며, 많은 TPF 어셈블러 응용 프로그램들이 존재한다. 그러나 최근 TPF 버전은 C 사용을 권장하며, 사브레토크라는 또 다른 프로그래밍 언어는 TPF에서 도태되었다.

2005년 9월, IBM은 z/TPF V1.1을 출시하며 64비트 주소 지정을 추가하고 64비트 GNU 개발 도구 사용을 의무화했다. z/TPF는 GCC 컴파일러와 DIGNUS Systems/C++ 및 Systems/C를 지원하며, Dignus 컴파일러는 TPF 4.1에서 z/TPF로 이동할 때 소스 코드 변경을 줄여준다.

3. 이용

현재 TPF는 사브레 (예약 부문), Amadeus (예약 부문), 비자카드 (권한 허가), 아메리칸 항공[20], 아메리칸 엑스프레스 (권한 허가), HP SHARES (예약 부문), 홀리데이 인 (중앙 예약 부문), CBOE (주문 전송), 알리탈리아 항공, KLM, 가루다 인도네시아 항공, 암트랙, 매리엇 인터내셔널, 트래블포트, NYPD (911 시스템) 등에서 사용되고 있다. 일본항공은 z/TPF를 구동하는 것으로 알려져 있다.[21]

4. 운영 환경

트랜잭션 처리 기능(TPF)은 다양한 운영 환경을 지원한다.

'''밀결합(Tightly coupled)''' 환경에서는 TPF가 멀티프로세서 시스템에서 실행되며, 여러 CPU(I-스트림)가 메모리를 공유한다. SMP 방식을 따르며, 들어오는 트랜잭션은 CPU 준비 목록을 통해 부하가 가장 적은 I-스트림에 할당되어 균형을 이룬다.[9]

'''소결합(Loosely coupled)''' 환경에서는 여러 대의 메인프레임이 공통 데이터베이스를 공유하며, 최대 32대의 IBM 메인프레임이 연결될 수 있다. 이 환경에서는 레코드 잠금을 통해 데이터 접근을 제어하며, MPLF(Multipathing Lock Facility) 또는 커플링 팩터리가 필요하다.[10][11]

TPF 시스템에서 레코드는 '''프로세서 공유 레코드'''와 '''프로세서 고유 레코드'''로 구분된다. 프로세서 공유 레코드는 모든 프로세서에서 동일한 파일 주소로 접근되므로 레코드 잠금 메커니즘이 필요하다.[1] 반면, 프로세서 고유 레코드는 각 프로세서마다 다른 물리적 주소를 사용한다.[1]

4. 1. 밀결합 (Tightly coupled)

TPF는 여러 CPU가 있는 시스템인 멀티프로세서에서 실행될 수 있다. LPAR 내에서 CPU는 '명령 스트림' 또는 'I-스트림'이라고 불린다. TPF는 둘 이상의 I-스트림을 가진 LPAR에서 실행될 때 '밀결합'되어 있다고 한다. TPF는 SMP 개념을 따르며, 메모리 주소 간의 NUMA 기반 구분은 없다.[9]

'CPU 준비 목록'을 통해 수신된 모든 들어오는 트랜잭션을 측정하고, 수요가 가장 적은 I-스트림에 대기열을 넣어 사용 가능한 프로세서 간에 지속적인 부하 균형을 유지한다. TPF 아키텍처에서 모든 메모리(4KB 크기의 '접두사 영역' 제외)는 모든 I-스트림 간에 공유된다.[9]

4. 2. 소결합 (Loosely coupled)

TPF는 여러 대의 메인프레임을 공통 데이터베이스에 연결하여 작동할 수 있도록 지원한다. 현재 32대의 IBM 메인프레임이 TPF 데이터베이스를 공유할 수 있으며, 이러한 시스템을 '32-웨이 루스 커플링'이라고 부른다. 가장 단순한 루스 커플링 시스템은 두 대의 IBM 메인프레임이 하나의 DASD(직접 접근 저장 장치)를 공유하는 형태이다.

소결합 시스템에서는 데이터 레코드 간의 접근을 직렬화하기 위해 레코드 잠금이라는 방식을 사용한다. 이는 한 메인프레임 프로세서가 레코드에 대한 '홀드'를 획득하면, 다른 모든 프로세서가 동일한 홀드를 획득하는 것을 방지하고 요청 프로세서에 대기 중임을 알려야 함을 의미한다. 역사적으로 레코드 잠금은 LLF (Limited Locking Facility)와 ELLF (확장된)를 통해 DASD 제어 장치에서 수행되었으며, 이들은 모두 MPLF(Multipathing Lock Facility)로 대체되었다. 클러스터된(소결합) z/TPF를 실행하려면 모든 디스크 제어 장치에 MPLF가 있거나 커플링 팩터리라는 대체 잠금 장치가 필요하다.[10][11]

4. 2. 1. 프로세서 공유 레코드

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

TPF 시스템의 모든 프로세서 공유 레코드는 동일한 파일 주소를 통해 접근되며, 이 주소는 동일한 위치로 해석된다.[1]

4. 2. 2. 프로세서 고유 레코드

프로세서 고유 레코드는 소결합 복합체에 포함될 각 프로세서가 'FRED' 레코드 유형과 100개의 순서를 갖도록 정의된 레코드이다. 그러나 둘 이상의 프로세서 사용자가 레코드 유형 'FRED', 순서 '5'가 가리키는 파일 주소를 검사하면 서로 다른 물리적 주소가 사용되고 있음을 알 수 있다.[1]

5. TPF 속성

TPF는 고속, 대량, 고 처리량의 트랜잭션 처리를 위해 설계된 운영 체제이다. 높은 신뢰성을 가지며, 24시간 연중무휴 연속 운용이 가능하다. 시스템과 소프트웨어 업그레이드를 진행하면서도 10년 이상 온라인 처리를 지속하는 경우도 드물지 않다.[18]

TPF는 SABRE에서 발전하여 1960년대 중반 IBM이 구미의 주요 항공사와 공동 개발한 Airlines Control Program (ACP)을 기원으로 한다.[18] 1979년 IBM은 ACP를 대체하는 유료 제품으로 TPF를 출시했다.[18]

PARS라는 애플리케이션이 있으며, 많은 항공사가 PARS 또는 국제판 IPARS를 좌석 예약 시스템에 사용한다.[18] 성능을 중시하여 370 어셈블리 언어로 작성되었으며, 애플리케이션도 어셈블리 언어로 작성된 것이 많았지만, 최근에는 C 언어를 사용한다.[18] TPFDF라고 불리는 고성능 데이터베이스 시설이 주요 구성 요소이다.[18]

TPF 채택 사이트에서는 트랜잭션 처리 외의 용도로 다른 IBM 메인프레임용 운영 체제 (z/OS나 z/VM)도 사용하는 경우가 많다.[18] IBM의 파티셔닝 기술 덕분에 이러한 OS들은 하나의 메인프레임 상에 공존할 수 있다.[18]

2005년에는 System z (z/Architecture) 대응인 '''z/TPF'''가 등장했다.[18] z/TPF는 64비트를 지원하며, GCC 컴파일러를 포함한 GNU 도구를 사용할 수 있다.[18]

TPF는 다음과 같은 특징을 가진다.


  • GUI가 없고, 단순한 CUI를 사용한다.[18]
  • 컴파일러, 어셈블러, 텍스트 에디터 등이 없다.[18] TPF용 애플리케이션 개발은 z/OS 등에서 이루어지며, z/TPF에서는 리눅스 상에 개발 환경이 있다.[18]
  • 온라인 매뉴얼 등이 없어 종이 매뉴얼을 참고해야 한다.[18]
  • 디버깅 기능이 거의 없다.[18]
  • 트랜잭션을 포함한 메시지 교환을 고속화하도록 최적화되어 있다.[18]
  • 고속화를 위해 메모리 상에 프로그램 전체를 로드하여 실행하는 방식을 사용했다.[18]


과거 TPF 시스템의 데이터와 메모리는 381, 1055, 40,000억의 고정된 레코드 크기를 가졌으나, z/TPF에서는 이러한 제약이 대부분 사라졌고, 메모리는 (z/TPF에서는 ) 크기의 프레임으로 분할되어 관리된다.

5. 1. TPF가 아닌 것

TPF는 범용 운영 체제가 아니다. TPF는 내장된 그래픽 사용자 인터페이스 기능을 갖추고 있지 않으며, 직접적인 그래픽 디스플레이 기능을 제공한 적이 없다. TPF의 사용자 인터페이스는 위로 스크롤되는 단순한 텍스트 디스플레이 터미널을 사용하는 명령줄 기반이며, 마우스 기반 커서, 창 또는 아이콘이 없다. 모든 작업은 X가 없는 유닉스와 유사한 명령줄을 사용하여 수행된다.[18]

TPF는 특수 목적 운영 체제이므로 범용 운영 체제에서 찾을 수 있는 컴파일러, 어셈블러, 텍스트 편집기를 호스팅하지 않으며 데스크톱의 개념을 구현하지 않는다. TPF 애플리케이션 소스 코드는 일반적으로 외부 시스템에 저장되며 "오프라인"으로 빌드된다. z/TPF 1.1부터 리눅스가 지원되는 빌드 플랫폼이다. z/TPF 작동을 위한 실행 프로그램은 s390x-ibm-linux에 대한 ELF 형식을 준수해야 한다.[18]

TPF를 사용하려면 "명령 가이드"에 대한 지식이 필요하며, 온라인 명령 "디렉토리" 또는 "man"/도움말 기능에 대한 지원이 없다. TPF 시스템 관리를 위해 IBM에서 생성하고 제공하는 명령은 "기능 메시지"라고 하며, 일반적으로 "Z-메시지"라고 한다. 모든 명령의 접두사가 문자 "Z"이기 때문이다. 다른 문자는 고객이 자체 명령을 작성할 수 있도록 예약되어 있다.[18]

5. 2. TPF인 것

TPF는 지원되는 네트워크의 메시지를 다른 위치로 전환하거나, 애플리케이션(특정 프로그램 집합)으로 라우팅하거나, 데이터베이스 레코드에 매우 효율적으로 접근할 수 있도록 고도로 최적화되어 있다.[18] TPF는 SABRE에서 발전하여 1960년대 중반 IBM이 구미의 주요 항공사와 공동 개발한 Airlines Control Program (ACP)을 기원으로 하는 OS이다.[18] 1979년 IBM은 ACP를 대체하는 유료 제품으로 TPF를 출시했다.[18]

TPF는 고속, 대량, 고 처리량의 트랜잭션 처리가 가능하며, 대규모 광역 네트워크에서 트랜잭션을 지속적으로 대량 처리한다.[18] 대규모 TPF 시스템에서는 매초 수만 건의 트랜잭션을 처리하는 것이 일반적이다.[18] TPF는 높은 신뢰성을 가지며, 24시간 연중무휴 연속 운용이 가능하다.[18] 시스템과 소프트웨어 업그레이드를 진행하면서도 10년 이상 온라인 처리를 지속하는 경우도 드물지 않다.[18]

TPF에는 PARS라는 애플리케이션이 있다.[18] 많은 항공사가 PARS 또는 국제판 IPARS를 좌석 예약 시스템에 사용한다.[18] TPF는 성능을 중시하여 370 어셈블리 언어로 작성되었으며, 애플리케이션도 어셈블리 언어로 작성된 것이 많다.[18] 그러나 최근에는 C 언어를 사용한다.[18] TPF의 주요 구성 요소는 TPFDF라고 불리는 고성능 데이터베이스 시설이다.[18]

TPF를 채택하는 사이트에서는 트랜잭션 처리 외의 용도로 다른 IBM 메인프레임용 운영 체제 (z/OS나 z/VM)도 사용하는 경우가 많다.[18] IBM의 파티셔닝 기술 덕분에 이러한 OS들은 하나의 메인프레임 상에 공존할 수 있다.[18]

2005년에는 TPF의 System z (z/Architecture) 대응인 '''z/TPF'''가 등장했다.[18] z/TPF는 64비트를 지원하며, GCC 컴파일러를 포함한 GNU 도구를 사용할 수 있다.[18]

TPF는 다음과 같은 특징을 가진다.

  • GUI가 없고, 단순한 CUI를 사용한다.[18]
  • 컴파일러, 어셈블러, 텍스트 에디터 등이 없다.[18] TPF용 애플리케이션 개발은 z/OS 등에서 이루어지며, z/TPF에서는 리눅스 상에 개발 환경이 있다.[18]
  • 온라인 매뉴얼 등이 없어 종이 매뉴얼을 참고해야 한다.[18]
  • 디버깅 기능이 거의 없다.[18]
  • 트랜잭션을 포함한 메시지 교환을 고속화하도록 최적화되어 있다.[18]
  • 고속화를 위해 메모리 상에 프로그램 전체를 로드하여 실행하는 방식을 사용했다.[18]

5. 2. 1. 데이터 레코드

과거 TPF 시스템의 모든 데이터는 381, 1055, 4000 바이트의 고정된 레코드(및 메모리 블록) 크기에 맞아야 했다. 이는 부분적으로 DASD에 위치한 블록의 물리적 레코드 크기 때문이었다. 파일 작업 중에 운영 체제가 큰 데이터 엔티티를 작은 것으로 분할하고 읽기 작업 중에 이를 재조립하는 과정에서 발생하는 오버헤드를 많이 줄였다. IBM 하드웨어는 '''채널''' 및 '''채널 프로그램'''을 사용하여 I/O를 수행하므로 TPF는 속도를 위해 매우 작고 효율적인 채널 프로그램을 생성한다. 또한 초기에는 메모리나 디스크 등 저장 매체의 크기가 중요했기 때문에 TPF 애플리케이션은 매우 적은 리소스를 사용하면서도 매우 강력한 기능을 수행하도록 발전했다.

오늘날 이러한 제약은 대부분 제거되었다. 사실, 4000 바이트 미만의 DASD 레코드는 레거시 지원 때문에 여전히 사용되고 있다. DASD 기술의 발전으로 인해 4000 바이트 레코드의 읽기/쓰기는 1055 바이트 레코드만큼 효율적이다. 동일한 발전으로 각 장치의 용량이 증가하여 데이터를 가능한 한 작은 모델에 압축하는 능력에 더 이상 중요성이 부여되지 않는다.

5. 2. 2. 프로그램 및 상주

TPF는 역사적으로 381, 1055 및 4KB 크기의 '''레코드'''로 할당된 프로그램 '''세그먼트'''를 가졌다.[5][6] 각 세그먼트는 단일 레코드로 구성되었으며, 일반적으로 포괄적인 애플리케이션은 수십 개 또는 수백 개의 세그먼트가 필요했다. TPF 역사상 처음 40년 동안 이러한 세그먼트는 링크 편집되지 않았다. 대신, 재배치 가능한 객체 코드(어셈블러의 직접 출력)가 메모리에 배치되어 ''내부적으로'' (자기 참조) 재배치 가능한 심볼이 해결된 다음 전체 이미지가 시스템에 나중에 로드하기 위해 파일에 기록되었다. 이는 ''서로 관련된 세그먼트가 서로 직접 주소를 지정할 수 없는'' 어려운 프로그래밍 환경을 조성했으며, 세그먼트 간의 제어 전송은 '''ENTER/BACK''' ''시스템 서비스''로 구현되었다.

항공사 제어 프로그램(ACP)/TPF 초창기(1965년경)에는 메모리 공간이 심각하게 제한되어 '''파일 상주''' 프로그램과 '''코어 상주''' 프로그램 간의 구분이 생겼다. 가장 자주 사용되는 애플리케이션 프로그램만 메모리에 기록되어 절대 제거되지 않았('''코어 상주'''); 나머지는 파일에 저장되어 필요에 따라 읽혀졌고, 실행 후 백킹 메모리 버퍼가 해제되었다.

TPF 3.0 버전에서 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의 재진입성 요구 사항을 강화한다.

5. 2. 3. 메모리 사용

과거 및 이전 핵심 블록과 마찬가지로, 메모리 역시 크기가 381, 1055, 였다.[1] '''모든''' 메모리 블록은 이 크기여야 했기 때문에 다른 시스템에서 메모리 획득에 따른 대부분의 오버헤드가 제거되었다.[1] 프로그래머는 필요한 크기의 블록을 결정하고 요청하기만 하면 되었다.[1] TPF는 사용 중인 블록 목록을 유지하고 사용 가능한 목록의 첫 번째 블록을 단순히 제공했다.[1]

물리적 메모리는 각 크기별로 예약된 섹션으로 나뉘어, 1055바이트 블록은 항상 특정 섹션에서 가져와 그곳으로 반환되었다.[1] 필요한 유일한 오버헤드는 해당 주소를 적절한 물리적 블록 테이블의 목록에 추가하는 것이었다.[1] 압축이나 데이터 수집은 필요하지 않았다.[1]

애플리케이션이 더 발전하면서 메모리에 대한 요구 사항이 증가했고, C가 사용 가능해지자 크기가 정해지지 않거나 큰 메모리 덩어리가 필요하게 되었다.[1] 이로 인해 힙 저장소와 일부 메모리 관리 루틴이 사용되었다.[1] 오버헤드를 줄이기 위해 TPF 메모리는 크기(z/TPF에서는 )의 프레임으로 분할되었다.[1] 애플리케이션에서 특정 바이트 수가 필요한 경우, 해당 요구 사항을 충족하는 데 필요한 연속된 프레임 수가 할당된다.[1]

참조

[1] 웹사이트 z/TPF, z/TPFDF, TPF Operations Server, and TPF Toolkit 4.6 for 2023 https://www.ibm.com/[...] IBM
[2] 뉴스 IBM Updates Old Workhorse to Use Linux https://www.nytimes.[...] 2004-10-04
[3] 간행물 Visa Is Everywhere It Wants To Be 1987-08-24
[4] 웹사이트 TPF Database Facility (TPFDF) https://www-01.ibm.c[...] 2016-11-11
[5] 뉴스 IBM bolsters its mainframe platform https://www.computer[...]
[6] 뉴스 IBM pumps up Linux virtual machines on mainframe OS https://www.computer[...]
[7] 웹사이트 TPF Users Group, Job Corner http://tpfug.org/Job[...]
[8] 웹사이트 IBM News room - 2008-04-14 Japan Airlines International to Upgrade Reservation and Ticketing System With IBM Mainframe - United States http://www-03.ibm.co[...] 2008-04-14
[9] 뉴스그룹 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!)) https://groups.googl[...]
[10] 웹사이트 IBM Knowledge Center http://publib.boulde[...] 2014-10-24
[11] 웹사이트 IBM z/Transaction Processing Facility Enterprise Edition V1.1 hardware requirements - United States http://www-01.ibm.co[...] 2022-01-17
[12] 웹사이트 z/TPF Glossary https://www.ibm.com/[...] 2018-04-19
[13] 웹사이트 IBM TPF Operations Server https://www.ibm.com/[...] 2018-04-19
[14] 웹사이트 z/TPF Operations Command Guide https://www.ibm.com/[...] 2019-01-29
[15] 웹사이트 Bedford Associates, Inc. http://www.bedfordit[...] 2012-10-17
[16] 웹사이트 TPF Software, Inc. http://www.tpfsoftwa[...] 2012-10-17
[17] 웹사이트 IBM TPF Toolkit Overview https://www.ibm.com/[...] 2017-12
[18] 웹사이트 【事例編】JTB、基幹系プラットフォームを刷新 - 進化するITプラットフォーム Part8 https://it.impressbm[...]
[19] 웹인용 z/TPF, z/TPFDF, TPF Operations Server, and TPF Toolkit 4.6 for 2023 https://www.ibm.com/[...] IBM
[20] 웹인용 Job Corner http://www.tpfug.org[...] 2015-10-31
[21] URL http://www-03.ibm.co[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com