CICS
Inne nazwy | System kontroli informacji o kliencie |
---|---|
Pierwsze wydanie | 8 lipca 1969 |
Wersja stabilna | CICS Transaction Server V5.6 / 12 czerwca 2020 r
|
System operacyjny | z/OS , z/VSE |
Platforma | IBM Z |
Typ | Monitor teleprzetwarzania |
Licencja | Prawnie zastrzeżony |
Strona internetowa |
|
IBM CICS (Customer Information Control System) to rodzina serwerów aplikacji obsługujących różne języki, które zapewniają zarządzanie transakcjami online i łączność z aplikacjami w systemach mainframe IBM w systemach z/OS i z/VSE .
Produkty z rodziny CICS są zaprojektowane jako oprogramowanie pośrednie i obsługują szybkie przetwarzanie transakcji online na dużą skalę . Transakcja CICS to jednostka przetwarzania zainicjowana przez pojedyncze żądanie, które może mieć wpływ na jeden lub więcej obiektów. Przetwarzanie to jest zwykle interaktywne (zorientowane na ekran), ale możliwe są transakcje w tle.
CICS Transaction Server (CICS TS) stoi na czele rodziny CICS i dostarcza usługi rozszerzające lub zastępujące funkcje systemu operacyjnego. Usługi te mogą być bardziej wydajne niż uogólnione usługi systemu operacyjnego, a także prostsze w użyciu dla programistów, zwłaszcza w odniesieniu do komunikacji z różnymi urządzeniami końcowymi.
Aplikacje opracowane dla CICS mogą być pisane w różnych językach programowania i korzystać z rozszerzeń językowych dostarczonych przez CICS do interakcji z zasobami, takimi jak pliki, połączenia z bazami danych , terminale lub do wywoływania funkcji, takich jak usługi sieciowe. CICS zarządza całą transakcją w taki sposób, że jeśli z jakiegokolwiek powodu część transakcji zakończy się niepowodzeniem, wszystkie możliwe do odzyskania zmiany mogą zostać wycofane.
Chociaż CICS TS ma największy rozgłos wśród dużych instytucji finansowych, takich jak banki i firmy ubezpieczeniowe, wiele firm z listy Fortune 500 i jednostek rządowych prowadzi CICS. Inne, mniejsze przedsiębiorstwa również mogą korzystać z CICS TS i innych produktów z rodziny CICS. CICS regularnie można znaleźć za kulisami, na przykład w aplikacjach bankowych, ATM , przemysłowych systemach kontroli produkcji, aplikacjach ubezpieczeniowych i wielu innych typach aplikacji interaktywnych.
Najnowsze ulepszenia CICS TS obejmują nowe możliwości poprawiające doświadczenie programistów, w tym wybór interfejsów API, struktur, edytorów i narzędzi do tworzenia, przy jednoczesnym dostarczaniu aktualizacji w kluczowych obszarach bezpieczeństwa, odporności i zarządzania. We wcześniejszych, niedawnych wersjach CICS TS zapewniono obsługę usług sieciowych i języka Java , przetwarzania zdarzeń , kanałów informacyjnych Atom i interfejsów RESTful .
Historia
CICS został poprzedzony wcześniejszym, jednowątkowym systemem przetwarzania transakcji, IBM MTCS . Później opracowano „mostek MTCS-CICS”, aby umożliwić wykonywanie tych transakcji w ramach CICS bez zmian w oryginalnych aplikacjach. IBM Customer Information Control System (CICS), opracowany po raz pierwszy we współpracy z Michigan Bell w 1966 roku. Ben Riggins był inżynierem systemowym IBM w Virginia Electric Power Co., kiedy wpadł na pomysł systemu online.
CICS został pierwotnie opracowany w Stanach Zjednoczonych w IBM Development Center w Des Plaines, Illinois , począwszy od 1966 roku, aby spełnić wymagania przemysłu użyteczności publicznej. Pierwszy produkt CICS został ogłoszony w 1968 roku, nazwany Public Utility Customer Information Control System lub PU-CICS. Natychmiast stało się jasne, że ma zastosowanie w wielu innych branżach, więc prefiks Public Utility został usunięty wraz z wprowadzeniem pierwszego wydania produktu programu CICS 8 lipca 1969 r., Niedługo po systemie zarządzania bazą danych IMS .
Przez kilka następnych lat CICS był rozwijany w Palo Alto i był uważany za mniej ważny „mniejszy” produkt niż IMS, który IBM uznał wówczas za bardziej strategiczny. Presja klientów utrzymywała go jednak przy życiu. Kiedy IBM postanowił zakończyć rozwój CICS w 1974 roku, aby skoncentrować się na IMS, odpowiedzialność za rozwój CICS została przejęta przez oddział IBM Hursley w Wielkiej Brytanii, który właśnie zaprzestał prac nad kompilatorem PL/I i znał wiele takich samych klientów jako CICS. Rdzeń prac rozwojowych jest kontynuowany w Hursley dzisiaj wraz z wkładem z laboratoriów w Indiach, Chinach, Rosji, Australii i Stanach Zjednoczonych.
Wczesna ewolucja
CICS pierwotnie obsługiwał tylko kilka urządzeń marki IBM, takich jak terminal oparty na maszynie do pisania IBM 2741 Selectric (piłka golfowa) z 1965 roku. Terminale wideo IBM 2260 i 1972 IBM 3270 z 1964 r . Były później szeroko stosowane.
sprzętem komputerowym bez dodatkowych opłat . System OS/360 i oprogramowanie do obsługi aplikacji, takie jak CICS, były „otwarte” dla klientów IBM na długo przed inicjatywą oprogramowania open source . Korporacje takie jak Standard Oil of Indiana (Amoco) wniosły znaczący wkład w CICS.
Zespół IBM Des Plaines próbował dodać obsługę popularnych terminali innych niż IBM, takich jak ASCII Teletype Model 33 ASR, ale mały, niskobudżetowy zespół programistów nie mógł sobie pozwolić na sprzęt za 100 USD miesięcznie, aby go przetestować. Kierownictwo IBM błędnie uważało, że przyszłość będzie taka jak przeszłość, z przetwarzaniem wsadowym przy użyciu tradycyjnych kart perforowanych .
IBM niechętnie zapewnił tylko minimalne fundusze, gdy przedsiębiorstwa użyteczności publicznej, banki i firmy obsługujące karty kredytowe zażądały opłacalnego interaktywnego systemu (podobnego do programu IBM Airline Control Program z 1965 r ., Używanego przez komputerowy system rezerwacji American Airlines Sabre ) do szybkiego dostępu do danych - i aktualizować informacje o klientach dla swoich operatorów telefonicznych (bez czekania na nocne systemy przetwarzania wsadowego kart perforowanych).
Dostarczenie CICS do Amoco z obsługą Teletype Model 33 ASR spowodowało awarię całego systemu operacyjnego OS/360 (w tym aplikacji innych niż CICS). Większość programu CICS Terminal Control Program (TCP – serce CICS) oraz część systemu OS/360 musiały zostać mozolnie przeprojektowane i napisane od nowa przez firmę Amoco Production Company w Tulsa w stanie Oklahoma. Następnie zwrócono go firmie IBM w celu bezpłatnej dystrybucji wśród innych.
Za kilka lat [ kiedy? ] CICS wygenerował ponad 60 miliardów dolarów przychodów ze sprzedaży nowego sprzętu dla IBM i stał się ich najbardziej udanym oprogramowaniem dla komputerów mainframe.
W 1972 roku CICS był dostępny w trzech wersjach – DOS-ENTRY (numer programu 5736-XX6) dla maszyn DOS/360 z bardzo ograniczoną pamięcią, DOS-STANDARD (numer programu 5736-XX7), dla maszyn DOS/360 z większą pamięcią, i OS-STANDARD V2 (numer programu 5734-XX7) dla większych maszyn z systemem OS/360.
Na początku 1970 roku wielu oryginalnych programistów, w tym Ben Riggins (główny architekt wczesnych wydań), przeniosło się do Kalifornii i kontynuowało rozwój CICS w IBM Palo Alto Development Center. Kierownictwo IBM nie uznało wartości oprogramowania za produkt generujący dochody, dopóki prawo federalne nie wymagało uwolnienia oprogramowania . W 1980 roku dyrektorzy IBM nie posłuchali zdecydowanych sugestii Bena Rigginsa, że IBM powinien dostarczyć własny EBCDIC i układ mikroprocesorowy z układem scalonym do użytku w komputerze osobistym IBM jako inteligentny terminal CICS (zamiast niekompatybilnego chipa Intela, i niedojrzały Microsoft 1980 DOS oparty na ASCII ).
Ze względu na ograniczoną pojemność nawet dużych procesorów tamtej epoki każda instalacja CICS musiała składać kod źródłowy dla wszystkich modułów systemu CICS po zakończeniu procesu podobnego do generowania systemu (sysgen), zwanego CICSGEN , w celu ustalenia wartości dla warunkowego montażu -wypowiedzi językowe. Ten proces umożliwił każdemu klientowi wykluczenie wsparcia z samego CICS dla dowolnej funkcji, której nie zamierzał używać, takiej jak obsługa urządzeń dla nieużywanych typów terminali.
CICS zawdzięcza swoją wczesną popularność stosunkowo wydajnej implementacji, gdy sprzęt był bardzo drogi, wielowątkowej architekturze przetwarzania, względnej prostocie tworzenia aplikacji transakcyjnych w czasie rzeczywistym opartych na terminalach oraz wielu wkładom klientów typu open source, w tym zarówno debugowaniu, jak i wzmocnienie.
notacja Z
Część CICS została sformalizowana przy użyciu notacji Z w latach 80. i 90. we współpracy z Oxford University Computing Laboratory pod kierownictwem Tony'ego Hoare'a . Ta praca zdobyła Nagrodę Królowej za Osiągnięcia Technologiczne.
CICS jako rozproszony serwer plików
W 1986 roku IBM ogłosił wsparcie CICS dla zorientowanych na rekordy usług plików zdefiniowanych przez Distributed Data Management Architecture (DDM). Umożliwiło to programom na zdalnych komputerach podłączonych do sieci tworzenie, zarządzanie i dostęp do plików, które wcześniej były dostępne tylko w środowiskach przetwarzania transakcji CICS/MVS i CICS/VSE.
W nowszych wersjach CICS usunięto obsługę DDM. Obsługa składnika DDM systemu CICS z/OS została zakończona pod koniec 2003 r. i została usunięta z programu CICS for z/OS w wersji 5.2 i nowszych. W CICS TS dla z/VSE obsługa DDM została ustabilizowana na poziomie V1.1.1, z zapowiedzianym zamiarem wycofania jej w przyszłej wersji. W CICS for z/VSE 2.1 i nowszych CICS/DDM nie jest obsługiwany.
CICS i World Wide Web
CICS Transaction Server po raz pierwszy wprowadził natywny interfejs HTTP w wersji 1.2 wraz z technologią Web Bridge do opakowywania programów terminalowych zielonego ekranu w fasadę HTML. Interfejsy CICS Web i Document API zostały udoskonalone w CICS TS V1.3, aby umożliwić pisanie aplikacji obsługujących Internet w celu efektywniejszego współdziałania z przeglądarkami internetowymi.
Wersje CICS TS od 2.1 do 2.3 koncentrowały się na wprowadzaniu technologii CORBA i EJB do CICS, oferując nowe sposoby integracji zasobów CICS z rozproszonymi modelami komponentów aplikacji. Technologie te polegały na hostowaniu aplikacji Java w systemie CICS. Środowisko hostingu Java przeszło liczne ulepszenia w stosunku do wielu wydań, co ostatecznie doprowadziło do osadzenia profilu WebSphere Liberty w CICS Transaction Server 5.1. Liczne technologie internetowe mogły być hostowane w CICS przy użyciu Javy, co ostatecznie doprowadziło do usunięcia natywnych technologii CORBA i EJB.
CICS TS V3.1 dodał natywną implementację technologii SOAP i WSDL dla CICS, wraz z interfejsami API HTTP po stronie klienta do komunikacji wychodzącej. Te bliźniacze technologie umożliwiły łatwiejszą integrację komponentów CICS z innymi aplikacjami korporacyjnymi i spotkały się z powszechnym przyjęciem. Dołączone zostały narzędzia umożliwiające pobieranie tradycyjnych programów CICS napisanych w językach takich jak COBOL i konwertowanie ich na usługi sieciowe zdefiniowane w formacie WSDL, przy niewielkich zmianach programu lub bez zmian. Ta technologia była regularnie ulepszana w kolejnych wydaniach CICS.
W CICS TS V4.1 i 4.2 wprowadzono dalsze ulepszenia łączności internetowej, w tym natywną implementację protokołu publikowania Atom .
Wiele nowszych technologii internetowych zostało udostępnionych we wcześniejszych wersjach CICS przy użyciu modeli dostarczania innych niż tradycyjne wydanie produktu. Umożliwiło to wczesnym użytkownikom przekazanie konstruktywnych informacji zwrotnych, które mogłyby wpłynąć na ostateczny projekt zintegrowanej technologii. Przykłady obejmują prezentację technologii Soap for CICS SupportPac dla TS w wersji 2.2 lub ATOM SupportPac dla TS w wersji 3.1. Podejście to zostało wykorzystane do wprowadzenia JSON dla CICS TS V4.2, technologii, która została później zintegrowana z CICS TS V5.2.
Technologia JSON w CICS jest podobna do wcześniejszej technologii SOAP , z których obie umożliwiały opakowywanie programów hostowanych w CICS w nowoczesną fasadę. Technologia JSON została z kolei ulepszona w z/OS Connect Enterprise Edition, produkcie IBM do tworzenia interfejsów API JSON, które mogą wykorzystywać zasoby z kilku podsystemów komputerów mainframe.
Wiele produktów partnerskich zostało również wykorzystanych do interakcji z CICS. Popularne przykłady obejmują używanie CICS Transaction Gateway do łączenia się z CICS z serwerów aplikacji Java zgodnych z JCA oraz urządzeń IBM DataPower do filtrowania ruchu sieciowego, zanim dotrze on do CICS.
Nowoczesne wersje CICS zapewniają wiele sposobów integracji zarówno istniejących, jak i nowych zasobów oprogramowania z rozproszonymi przepływami aplikacji. Dostęp do zasobów CICS można uzyskać z systemów zdalnych i można uzyskiwać dostęp do systemów zdalnych; tożsamość użytkownika i kontekst transakcyjny mogą być propagowane; Interfejsy API RESTful mogą być tworzone i zarządzane; urządzenia, użytkownicy i serwery mogą wchodzić w interakcje z CICS przy użyciu technologii opartych na standardach; a środowisko IBM WebSphere Liberty w CICS promuje szybkie wdrażanie nowych technologii.
MicroCICS
W styczniu 1985 roku firma konsultingowa założona w 1969 roku, która wykonała „masywne systemy on-line” dla hoteli Hilton, FTD Florists, Amtrak i Budget Rent-a-Car, ogłosiła, co stało się MicroCICS . Początkowo skupiono się na IBM XT/370 i IBM AT/370 .
Rodzina CICS
Chociaż kiedy wspomina się o CICS, ludzie zwykle mają na myśli CICS Transaction Server, rodzina CICS odnosi się do portfolio serwerów transakcyjnych, konektorów (zwanych CICS Transaction Gateway ) i narzędzi CICS.
CICS na platformach rozproszonych — nie komputerach typu mainframe — nosi nazwę IBM TXSeries . TXSeries to oprogramowanie pośredniczące do przetwarzania transakcji rozproszonych. Obsługuje aplikacje C, C++, COBOL, Java™ i PL/I w środowiskach chmurowych i tradycyjnych centrach danych. TXSeries jest dostępny na AIX , Linux x86, Windows , Solaris i HP-UX . CICS jest również dostępny w innych systemach operacyjnych, zwłaszcza w systemach IBM i i OS/2 . Implementacja z/OS (tj. CICS Transaction Server for z/OS) jest zdecydowanie najbardziej popularna i znacząca.
Wcześniej dostępne były dwie wersje CICS dla VM/CMS , ale obie zostały wycofane. W 1986 roku IBM wypuścił CICS/CMS , który był wersją CICS dla jednego użytkownika przeznaczoną do użytku programistycznego, a aplikacje zostały później przeniesione do systemu MVS lub DOS/VS w celu wykonania produkcyjnego. Później, w 1988 roku, IBM wypuścił CICS/VM . CICS/VM był przeznaczony do użytku w IBM 9370 , niskobudżetowym komputerze mainframe przeznaczonym do użytku w działach; IBM umieścił oprogramowanie CICS/VM działające na komputerach mainframe departamentu lub oddziału firmy do użytku w połączeniu z centralnym komputerem mainframe, na którym działa oprogramowanie CICS for MVS.
Narzędzia CICS
Udostępnianie, zarządzanie i analiza systemów i aplikacji CICS jest zapewniane przez CICS Tools. Obejmuje to zarządzanie wydajnością oraz wdrażanie i zarządzanie zasobami CICS. W 2015 r. cztery podstawowe podstawowe narzędzia CICS (oraz pakiet CICS Optimization Solution Pack dla systemu z/OS) zostały zaktualizowane wraz z wydaniem CICS Transaction Server dla systemu z/OS 5.3. Cztery podstawowe narzędzia CICS: CICS Interdependency Analyzer for z/OS, CICS Deployment Assistant for z/OS, CICS Performance Analyzer for z/OS i CICS Configuration Manager for z/OS.
Wydania i wersje
CICS Transaction Server for z/OS używał następujących numerów wersji:
Wersja | Data ogłoszenia | Data wydania | Data zakończenia usługi | Cechy |
---|---|---|---|---|
CICS Transaction Server for OS/390 1.1 | 1996-09-10 | 1996-11-08 | 2001-12-31 | |
CICS Transaction Server for OS/390 1.2 | 1997-09-09 | 1997-10-24 | 2002-12-31 | |
CICS Transaction Server for OS/390 1.3 | 1998-09-08 | 1999-03-26 | 2006-04-30 | |
CICS Transaction Server for z/OS 2.1 | 2001-03-13 | 2001-03-30 | 2002-06-30 | |
CICS Transaction Server for z/OS 2.2 | 2001-12-04 | 2002-01-25 | 2008-04-30 | |
CICS Transaction Server for z/OS 2.3 | 2003-10-28 | 2003-12-19 | 2009-09-30 | |
CICS Transaction Server for z/OS 3.1 | 2004-11-30 | 2005-03-25 | 2015-12-31 | |
CICS Transaction Server for z/OS 3.2 | 2007-03-27 | 2007-06-29 | 2015-12-31 | |
CICS Transaction Server for z/OS 4.1 | 2009-04-28 | 2009-06-26 | 2017-09-30 | |
CICS Transaction Server for z/OS 4.2 | 2011-04-05 | 2011-06-24 | 2018-09-30 | |
CICS Transaction Server for z/OS 5.1 | 2012-10-03 | 2012-12-14 | 2019-07-01 | |
CICS Transaction Server for z/OS 5.2 | 2014-04-07 | 2014-06-13 | 2020-12-31 | |
CICS Transaction Server for z/OS 5.3 | 2015-10-05 | 2015-12-11 | 2021-12-31 | |
CICS Transaction Server for z/OS 5.4 | 2017-05-16 | 2017-06-16 | 2023-12-31 | |
CICS Transaction Server for z/OS 5.5 | 2018-10-02 | 2018-12-14 | ||
CICS Transaction Server for z/OS 5.6 | 2020-04-07 | 2020-06-12 | Obsługa Spring Boot , Jakarta EE 8, Node.js 12. Nowy interfejs API JCICSX z możliwością zdalnego programowania. Udoskonalenia w zakresie bezpieczeństwa, odporności i zarządzania. | |
CICS Transaction Server for z/OS 6.1 | 2022-04-05 | 2022-06-17 | Wsparcie dla Java 11, Jakarta EE 9.1, Eclipse MicroProfile 5, Node.js 12, TLS 1.3. Udoskonalenia i uproszczenia w zakresie bezpieczeństwa. Tagowanie regionów. | |
Legenda:
Stara wersja
Starsza wersja, nadal utrzymywana
Ostatnia wersja
Najnowsza wersja podglądu
Przyszłe wydanie
|
Programowanie
Rozważania dotyczące programowania
Programy aplikacyjne do obsługi transakcji interaktywnych dla wielu użytkowników musiały być quasi - reentrant w celu obsługi wielu jednoczesnych wątków transakcji . Błąd kodowania oprogramowania w jednej aplikacji może zablokować dostęp do systemu wszystkim użytkownikom. Modułowa konstrukcja programów sterujących CICS wielokrotnego użytku oznaczała, że przy rozsądnym „oczyszczaniu” wielu użytkowników z wieloma aplikacjami można było uruchomić na komputerze z zaledwie 32 KB drogiej pamięci fizycznej z rdzeniem magnetycznym ( w tym z systemem operacyjnym ).
Programiści aplikacji CICS wymagali znacznego wysiłku, aby ich transakcje były jak najbardziej wydajne. Powszechną techniką było ograniczanie rozmiaru poszczególnych programów do nie więcej niż 4096 bajtów, czyli 4 KB, tak aby system CICS mógł z łatwością ponownie wykorzystać pamięć zajmowaną przez dowolny program, który nie jest obecnie używany, do innego programu lub innych potrzeb związanych z pamięcią masową aplikacji. Kiedy pamięć wirtualna została dodana do wersji OS/360 w 1972 roku, strategia 4K stała się jeszcze ważniejsza w ograniczaniu stronicowania i przerzucania nieproduktywnego narzutu związanego z rywalizacją o zasoby.
Wydajność skompilowanych wysokopoziomowych programów w językach COBOL i PL/I pozostawiała wiele do życzenia. Wiele programów aplikacji CICS nadal było napisanych w języku asemblera, nawet po udostępnieniu obsługi języków COBOL i PL/I.
Ponieważ zasoby sprzętowe z lat 60. i 70. były drogie i ograniczone, wśród analityków optymalizacji systemu rozwinęła się konkurencyjna „gra”. Gdy ścieżki krytycznej został zidentyfikowany, fragment kodu był przekazywany od jednego analityka do drugiego. Każda osoba musiała albo (a) zmniejszyć liczbę wymaganych bajtów kodu, albo (b) zmniejszyć liczbę wymaganych cykli procesora . Młodsi analitycy uczyli się na podstawie tego, co robili bardziej doświadczeni mentorzy. W końcu, kiedy nikt nie mógł zrobić (a) lub (b), kod uznano za zoptymalizowany i przeszli do innych fragmentów. Małe sklepy z jednym analitykiem bardzo powoli (lub wcale) nie uczyły się optymalizacji CICS.
Ponieważ programy użytkowe mogły być współużytkowane przez wiele współbieżnych wątków, użycie zmiennych statycznych osadzonych w programie (lub użycie pamięci systemu operacyjnego) było ograniczone (tylko konwencją).
Niestety, wiele „reguł” było często łamanych, zwłaszcza przez programistów COBOL-a, którzy mogli nie rozumieć wewnętrznych mechanizmów swoich programów lub nie korzystać z niezbędnych restrykcyjnych opcji czasu kompilacji . Skutkowało to kodem „bez ponownego wejścia”, który często był zawodny, co prowadziło do fałszywych naruszeń pamięci masowej i awarii całego systemu CICS.
Pierwotnie cała partycja lub region wielu wirtualnych pamięci masowych (MVS) działał z tym samym kluczem ochrony pamięci , w tym z kodem jądra CICS. Uszkodzenie programu i bloku kontrolnego CICS było częstą przyczyną przestojów systemu. Błąd oprogramowania w jednej aplikacji może nadpisać pamięć (kod lub dane) jednej lub wszystkich aktualnie uruchomionych transakcji aplikacji. Zlokalizowanie szkodliwego kodu aplikacji pod kątem złożonych przejściowych błędów czasowych może być bardzo trudnym problemem dla analityka systemu operacyjnego.
Te niedociągnięcia utrzymywały się w przypadku wielu nowych wydań CICS przez okres ponad 20 lat, pomimo ich dotkliwości oraz faktu, że najwyższej jakości umiejętności CICS były bardzo poszukiwane i brakowało. Zostały one uwzględnione w TS V3.3, V4.1 i V5.2 z odpowiednio funkcjami Storage Protection, Transaction Isolation i Subspace, które wykorzystują sprzętowe funkcje systemu operacyjnego do ochrony kodu aplikacji i danych w tej samej przestrzeni adresowej, mimo że aplikacje nie zostały napisane do rozdzielenia. Transakcje aplikacji CICS mają kluczowe znaczenie dla wielu przedsiębiorstw użyteczności publicznej, dużych banków i innych wielomiliardowych instytucji finansowych.
Dodatkowo możliwe jest zapewnienie miary zaawansowanej ochrony aplikacji poprzez wykonanie testu pod kontrolą programu monitorującego, który służy również do udostępniania funkcji Test i Debug.
Programowanie na poziomie makro
Kiedy CICS został wydany po raz pierwszy, obsługiwał tylko programy transakcyjne aplikacji napisane w IBM 360 Assembler. Obsługa języka COBOL i PL/I została dodana lata później. Ze względu na początkową orientację na asembler, żądania usług CICS były wysyłane przy użyciu makr w języku asemblera . Na przykład żądanie odczytu rekordu z pliku, które zostało wykonane przez wywołanie makra do „Programu kontroli plików” systemu CICS, może wyglądać następująco:
DFHFC TYPE=READ,DATASET=myfile,TYPOPER=UPDATE,....etc.
Dało to początek późniejszej terminologii „ CICS na poziomie makro ”.
Po dodaniu obsługi języków wysokiego poziomu makra zostały zachowane, a kod został przekonwertowany przez prekompilator, który rozszerzył makra do ich odpowiedników instrukcji COBOL lub PL/I CALL. W ten sposób przygotowanie HLL było w rzeczywistości kompilacją „dwuetapową” - dane wyjściowe z preprocesora wprowadzane do kompilatora HLL jako dane wejściowe.
Uwagi dotyczące COBOL : w przeciwieństwie do PL/I, IBM COBOL zwykle nie umożliwia manipulowania wskaźnikami (adresami). Aby umożliwić programistom języka COBOL dostęp do bloków kontrolnych CICS i dynamicznej pamięci masowej, projektanci uciekli się do czegoś, co zasadniczo było hackowaniem. Sekcja powiązań COBOL była zwykle używana do komunikacji między programami, takiej jak przekazywanie parametrów. Kompilator generuje listę adresów, z których każdy nazywany jest bazowym lokalizatorem powiązań (BLL), które zostały ustawione przy wejściu do wywoływanego programu. Pierwsza LOGIKA biznesowa odpowiada pierwszemu elementowi w sekcji powiązań i tak dalej. CICS umożliwia programiście dostęp do nich i manipulowanie nimi poprzez przekazanie adresu listy jako pierwszego argumentu do programu. LOGIKI biznesowe mogą być następnie ustawiane dynamicznie, albo przez CICS, albo przez aplikację, aby umożliwić dostęp do odpowiedniej struktury w sekcji powiązań.
Programowanie na poziomie poleceń
W latach 80. IBM w Hursley Park wyprodukował wersję CICS, która obsługiwała tak zwany „CICS na poziomie poleceń”, który nadal obsługiwał starsze programy, ale wprowadził nowy styl API do programów aplikacyjnych.
Typowe wywołanie na poziomie polecenia może wyglądać następująco:
EXEC CICS WYŚLIJ ZESTAW MAP ( 'LOSMATT' ) MAP ( 'LOSATT' ) END-EXEC
Wartości podane w poleceniu SEND MAPSET odpowiadają nazwom użytym w pierwszym makrze DFHMSD w definicji mapy podanej poniżej dla argumentu MAPSET oraz makrze DFHMSI dla argumentu MAP. Jest to wstępnie przetwarzane przez etap translacji wsadowej przed kompilacją, który konwertuje osadzone polecenia (EXEC) na instrukcje wywołania do podprogramu pośredniczącego. Tak więc przygotowanie programów aplikacyjnych do późniejszego wykonania nadal wymagało dwóch etapów. Możliwe było pisanie w trybie mieszanym przy użyciu instrukcji zarówno na poziomie makro, jak i na poziomie poleceń.
Początkowo, w czasie wykonywania, polecenia na poziomie poleceń były konwertowane przy użyciu translatora czasu wykonywania, „The EXEC Interface Program”, na stare wywołanie na poziomie makro, które było następnie wykonywane przez w większości niezmienione programy jądra CICS. Ale kiedy jądro CICS zostało przepisane dla TS V3, EXEC CICS stał się jedynym sposobem programowania aplikacji CICS, ponieważ wiele podstawowych interfejsów uległo zmianie.
Konwersja w czasie wykonywania
CICS dostępny tylko na poziomie poleceń, wprowadzony na początku lat 90., oferował pewne zalety w porównaniu z wcześniejszymi wersjami CICS. Jednak IBM zrezygnował również ze wsparcia dla programów aplikacyjnych na poziomie makro napisanych dla wcześniejszych wersji. Oznaczało to, że wiele programów użytkowych musiało zostać przekonwertowanych lub całkowicie przepisanych, aby używały tylko poleceń EXEC na poziomie poleceń.
W tym czasie na całym świecie istniały być może miliony programów, które w wielu przypadkach były produkowane od dziesięcioleci. Przepisywanie ich często wprowadzało nowe błędy, niekoniecznie dodając nowe funkcje. Znaczna liczba użytkowników korzystała z regionów posiadających aplikacje CICS V2 (AOR), aby kontynuować uruchamianie kodu makr przez wiele lat po przejściu na wersję 3.
Możliwe było również uruchamianie starych programów na poziomie makro przy użyciu oprogramowania do konwersji, takiego jak Command CICS firmy APT International .
Nowe style programowania
Najnowsze ulepszenia CICS Transaction Server obejmują obsługę wielu nowoczesnych stylów programowania.
W CICS Transaction Server w wersji 5.6 wprowadzono ulepszoną obsługę języka Java, aby zapewnić programistom języka Java doświadczenie natywne w chmurze. Na przykład nowy CICS Java API ( JCICSX ) umożliwia łatwiejsze testowanie jednostkowe przy użyciu podejścia mocking i stubbing oraz może być uruchamiany zdalnie na lokalnej stacji roboczej programisty. Zestaw artefaktów CICS w Maven Central umożliwia programistom rozwiązywanie zależności Java przy użyciu popularnych narzędzi do zarządzania zależnościami, takich jak Apache Maven i Gradle . Dostępne są również wtyczki do Maven ( cics-bundle-maven ) i Gradle ( cics-bundle-gradle ), które upraszczają automatyczne tworzenie pakietów CICS przy użyciu znanych środowisk IDE, takich jak Eclipse , IntelliJ IDEA i Visual Studio Code . Ponadto ulepszono obsługę Node.js z/OS w wersji 12, zapewniając szybsze uruchamianie, lepsze domyślne limity sterty, aktualizacje silnika JavaScript V8 itp. Uwzględniono również obsługę Jakarta EE 8.
CICS TS 5.5 wprowadził obsługę IBM SDK dla Node.js, zapewniając pełne środowisko wykonawcze JavaScript, interfejsy API po stronie serwera i biblioteki do wydajnego tworzenia wysokowydajnych, wysoce skalowalnych aplikacji sieciowych dla IBM Z.
CICS Transaction Server w wersji 2.1 wprowadził obsługę języka Java. CICS Transaction Server w wersji 2.2 obsługiwał zestaw Software Developers Toolkit. CICS zapewnia ten sam kontener czasu wykonywania, co rodzina produktów WebSphere firmy IBM, dzięki czemu aplikacje Java EE można przenosić między CICS i Websphere, a ponadto dostępne są wspólne narzędzia do opracowywania i wdrażania aplikacji Java EE.
Ponadto firma CICS położyła nacisk na „opakowanie” istniejących programów aplikacyjnych w nowoczesne interfejsy, tak aby istniejące od dawna funkcje biznesowe mogły zostać włączone do bardziej nowoczesnych usług. Należą do nich interfejsy WSDL, SOAP i JSON, które otaczają starszy kod, dzięki czemu aplikacja internetowa lub mobilna może uzyskiwać i aktualizować podstawowe obiekty biznesowe bez konieczności gruntownego przepisywania funkcji zaplecza.
Transakcje
Transakcja CICS to zestaw operacji, które wspólnie wykonują zadanie. Zwykle większość transakcji to stosunkowo proste zadania, takie jak żądanie spisu inwentarza lub wprowadzenie obciążenia lub uznania rachunku. Podstawową cechą transakcji jest to, że powinna być atomowa . Na IBM Z CICS z łatwością obsługuje tysiące transakcji na sekundę, co czyni go podstawą przetwarzania w przedsiębiorstwie.
Aplikacje CICS obejmują transakcje, które można pisać w wielu językach programowania , w tym COBOL, PL/I, C, C++, IBM Basic Assembly Language, Rexx i Java.
Każdy program CICS jest inicjowany przy użyciu identyfikatora transakcji. Ekrany CICS są zwykle wysyłane jako konstrukcja zwana mapą, moduł utworzony za pomocą makr asemblera Basic Mapping Support (BMS) lub narzędzi innych firm. Ekrany CICS mogą zawierać tekst, który jest podświetlony, ma różne kolory i/lub miga w zależności od typu używanego terminala. Poniżej podano przykład, w jaki sposób można wysłać mapę za pomocą języka COBOL. Użytkownik końcowy wprowadza dane, które są udostępniane programowi poprzez otrzymanie mapy z CICS.
EXEC CICS ODBIERA MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) DO ( NASZA-MAPA ) END-EXEC .
Ze względów technicznych argumenty niektórych parametrów poleceń muszą być cytowane, a niektórych nie, w zależności od tego, do czego się odwołujemy. Większość programistów będzie kodować z podręcznika, dopóki nie zrozumieją, które argumenty są cytowane, lub zazwyczaj używają „szablonu w puszce”, w którym mają przykładowy kod, który po prostu kopiują i wklejają, a następnie edytują zmienić wartości.
Przykład kodu mapy BMS
Podstawowa obsługa mapowania definiuje format ekranu za pomocą makr asemblera, takich jak poniższe. Zostało to złożone w celu wygenerowania zarówno zestawu map fizycznych – modułu ładowania w bibliotece ładowania CICS – jak i zestawu map symbolicznych – definicji struktury lub DSECT w PL/I, COBOL, asemblerze itp., który został skopiowany do programu źródłowego.
LOSMATT DFHMSD TYP = MAP , X MODE = INOUT , X TIOAPFX = YES , X TERM = 3270 - 2 , X LANG = COBOL , X MAPATTS = ( KOLOR , PODŚWIETLENIE ), X DSATTS = ( KOLOR , PODŚWIETLENIE ), X PRZECHOWYWANIE = AUTO , X CTRL = ( FREEKB , FRSET ) * LOSATT DFHMDI ROZMIAR = ( 24 , 80 ), X LINIA = 1 , X KOLUMNA = 1 * LSSTDII DFHMDF POS = ( 1 , 01 ), X DŁUGOŚĆ = 04 , X KOLOR = NIEBIESKI , X POCZĄTKOWE = 'MQCM' , X ATTRB = PROT * DFHMDF POS = ( 24 , 01 ), X DŁUGOŚĆ = 79 , X KOLOR = NIEBIESKI X ATTRB = ASKIP , X POCZĄTKOWE = 'PF7- 8- 9- 10- X 11 - 12 - ANULUJ ' * TYP DFHMSD = KONIEC OSTATNI
Struktura
W środowisku z/OS instalacja CICS obejmuje jeden lub więcej „ regionów ” (ogólnie określanych jako „region CICS”) rozmieszczonych w jednym lub kilku obrazach systemu z/OS. Chociaż przetwarza transakcje interaktywne, każdy region CICS jest zwykle uruchamiany jako przestrzeń adresowa przetwarzania wsadowego ze standardowymi JCL : jest to zadanie, które działa w nieskończoność aż do zamknięcia. Alternatywnie każdy region CICS można uruchomić jako rozpoczęte zadanie . Niezależnie od tego, czy jest to zadanie wsadowe, czy rozpoczęte zadanie, regiony CICS mogą działać przez dni, tygodnie, a nawet miesiące przed wyłączeniem w celu konserwacji (MVS lub CICS). Po ponownym uruchomieniu parametr określa, czy powinien to być start „Zimny” (bez odzyskiwania), czy „Ciepły”/„Awaryjny” (przy użyciu ciepłego zamknięcia lub ponownego uruchomienia z dziennika po awarii). Zimne uruchamianie dużych regionów CICS z wieloma zasobami może zająć dużo czasu, ponieważ wszystkie definicje są ponownie przetwarzane.
Instalacje są podzielone na wiele przestrzeni adresowych z wielu różnych powodów, takich jak:
- separacja aplikacji,
- separacja funkcji,
- uniknięcie ograniczeń wydajności obciążenia pojedynczego regionu, przestrzeni adresowej lub instancji komputera mainframe w przypadku systemu az/OS SysPlex.
Typowa instalacja składa się z wielu odrębnych aplikacji, które składają się na usługę. Każda usługa ma zwykle pewną liczbę „regionów będących właścicielami terminali” (TOR), które kierują transakcje do wielu „regionów będących właścicielami aplikacji” (AOR), chociaż możliwe są inne topologie. Na przykład AOR mogą nie wykonywać operacji we/wy pliku. Zamiast tego istniałby „region będący właścicielem pliku” (FOR), który wykonywałby operacje wejścia/wyjścia pliku w imieniu transakcji w AOR – biorąc pod uwagę, że w tamtym czasie plik VSAM mógł obsługiwać tylko możliwy do odzyskania dostęp do zapisu z jednej przestrzeni adresowej w czas.
Jednak nie wszystkie aplikacje CICS używają VSAM jako podstawowego źródła danych (lub historycznie innych magazynów danych z pojedynczą przestrzenią adresową w czasie, takich jak CA Datacom) — wiele z nich używa IMS/DB lub Db2 jako bazy danych i/lub MQ jako menedżera kolejek. We wszystkich tych przypadkach TOR mogą równoważyć transakcje do zestawów AOR, które następnie bezpośrednio korzystają ze współdzielonych baz danych/kolejek. CICS obsługuje dwufazowe zatwierdzanie XA między magazynami danych, dzięki czemu możliwe są transakcje obejmujące na przykład MQ, VSAM/RLS i Db2 z właściwościami ACID.
CICS obsługuje transakcje rozproszone przy użyciu protokołu SNA LU6.2 między przestrzeniami adresowymi, które mogą działać w tych samych lub różnych klastrach. Pozwala to na aktualizacje ACID wielu magazynów danych przez współpracujące aplikacje rozproszone. W praktyce są z tym problemy, jeśli wystąpi awaria systemu lub komunikacji, ponieważ dyspozycja transakcji (wycofanie lub zatwierdzenie) może być wątpliwa, jeśli jeden z komunikujących się węzłów nie odzyskał sprawności. Tak więc korzystanie z tych urządzeń nigdy nie było bardzo rozpowszechnione.
Eksploatacja Sysplexu
W czasach CICS ESA V3.2, na początku lat 90., IBM stanął przed wyzwaniem, jak skłonić CICS do wykorzystania nowej linii komputerów mainframe zOS Sysplex .
Sysplex miał być oparty na CMOS (Complementary Metal Oxide Silicon), a nie na istniejącym sprzęcie ECL (Emitter Coupled Logic). Koszt skalowania ECL unikalnego dla komputerów mainframe był znacznie wyższy niż CMOS, który był opracowywany przez keiretsu z przypadkami użycia na dużą skalę, takimi jak Sony PlayStation, w celu zmniejszenia kosztu jednostkowego procesorów każdej generacji. ECL był również kosztowny dla użytkowników, ponieważ prąd drenu bramki wytwarzał tak dużo ciepła, że procesor musiał być umieszczony w specjalnym module o nazwie Thermal Conduction Module (TCM), który miał tłoki gazu obojętnego i wymagał instalacji hydraulicznej, aby mógł być chłodzony dużą objętością woda do schłodzenia. Ale prędkość procesora chłodzonej powietrzem technologii CMOS była początkowo znacznie mniejsza niż ECL (zwłaszcza pudełka dostępne od producentów klonów komputerów mainframe, Amdahl i Hitachi ). Było to szczególnie niepokojące dla IBM w kontekście CICS, ponieważ prawie wszyscy najwięksi klienci komputerów mainframe korzystali z CICS i dla wielu z nich było to główne obciążenie pracą komputerów mainframe.
Aby osiągnąć taką samą całkowitą przepustowość transakcji w systemie Sysplex, dla każdego obciążenia musiałoby być używanych wiele urządzeń równolegle, ale przestrzeń adresowa CICS, ze względu na model programowania aplikacji typu semi-reentrant, nie mogłaby wykorzystywać więcej niż około 1,5 procesora na jednym urządzeniu przy czas – nawet przy użyciu podzadań MVS. Bez tego klienci ci mieliby tendencję do przechodzenia do konkurentów, a nie do Sysplex, ponieważ skalowali obciążenia CICS. W IBM toczyła się poważna debata na temat tego, czy właściwym podejściem byłoby przerwanie kompatybilności aplikacji w górę i przejście na model taki jak IMS/DC , który był w pełni reentrant, czy też rozszerzenie podejścia przyjętego przez klientów w celu pełniejszego wykorzystania mocy pojedynczego komputera mainframe – za pomocą operacji wieloregionowych (MRO).
Ostatecznie przyjęto drugą ścieżkę po konsultacjach ze społecznością użytkowników CICS, która stanowczo sprzeciwiała się przerwaniu kompatybilności w górę, biorąc pod uwagę, że mieli oni wówczas perspektywę roku 2000 i nie widzieli wartości w ponownym pisaniu i testowaniu milionów wierszy, głównie COBOL, PL/1 lub kod asemblera.
Zalecana przez IBM struktura CICS w systemie Sysplex polegała na umieszczeniu co najmniej jednego regionu będącego właścicielem terminala CICS w każdym węźle Sysplex, który wysyłał transakcje do wielu regionów będących właścicielami aplikacji (AOR) rozmieszczonych w całym Sysplex. Jeśli te aplikacje potrzebowały dostępu do współdzielonych zasobów, albo korzystały z magazynu danych wykorzystującego Sysplex (takiego jak IBM Db2 lub IMS/DB ), albo koncentrowały, poprzez dostarczanie funkcji, żądania zasobów do pojedynczych regionów zasobów zasobów (ROR) dla każdego zasobu, w tym Regiony będące właścicielami plików (FOR) dla tabel danych VSAM i CICS, regiony będące właścicielami kolejek (QOR) dla MQ , CICS Transient Data (TD) i CICS Temporary Storage (TS). Ta zachowana kompatybilność ze starszymi aplikacjami kosztem złożoności operacyjnej w konfiguracji i zarządzaniu wieloma regionami CICS.
W kolejnych wydaniach i wersjach CICS był w stanie wykorzystać nowe możliwości wykorzystania Sysplex w VSAM/RLS, MQ dla zOS i umieścić własne tabele danych, TD i zasoby TS w zaprojektowanym menedżerze zasobów współdzielonych dla Sysplex -> the Coupling Facility lub CF, rezygnując z większości ROR. CF zapewnia zmapowany widok zasobów, w tym współdzieloną podstawę czasu, pule buforów, blokady i liczniki ze wspomaganiem przesyłania komunikatów sprzętowych, dzięki czemu udostępnianie zasobów w całym Sysplexie jest zarówno bardziej wydajne niż odpytywanie, jak i niezawodne (wykorzystując częściowo zsynchronizowany zapasowy CF do użytku w przypadku awaria).
Do tego czasu linia CMOS miała pojedyncze moduły, które przekraczały moc dostępną przez najszybszy moduł ECL z większą liczbą procesorów na procesor, a po ich połączeniu 32 lub więcej węzłów byłoby w stanie skalować o dwa rzędy wielkości większą całkowitą moc dla pojedyncze obciążenie pracą. Na przykład do 2002 roku Charles Schwab prowadził „MetroPlex” składający się z nadmiarowej pary systemów Sysplex na komputerze mainframe w dwóch lokalizacjach w Phoenix, AZ, każdy z 32 węzłami obsługiwanymi przez jedno współdzielone obciążenie CICS/DB/2 w celu obsługi ogromnej ilości żądania zapytań klienta WWW pre- dotcom-bubble .
Tańsza, znacznie bardziej skalowalna baza technologii CMOS oraz ogromne koszty inwestycyjne związane zarówno z uzyskaniem adresowania 64-bitowego, jak i niezależnym tworzeniem sklonowanej funkcjonalności CF, spowodowały, że twórcy klonów komputerów mainframe IBM jeden po drugim wycofywali się z biznesu.
Odzyskiwanie/ponowne uruchomienie CICS
Celem odzyskiwania/ponownego uruchomienia w systemie CICS jest zminimalizowanie i, jeśli to możliwe, wyeliminowanie szkód wyrządzonych Systemowi Online w przypadku wystąpienia awarii, tak aby zachowana została integralność systemu i danych. Jeśli region CICS został zamknięty zamiast awarii, wykona „ciepły” start, wykorzystując punkt kontrolny zapisany podczas zamykania. Region CICS można również wymusić na „zimny” start, który ponownie ładuje wszystkie definicje i usuwa dziennik, pozostawiając zasoby w jakimkolwiek są stanie.
W ramach CICS poniżej wymieniono niektóre zasoby uważane za możliwe do odzyskania. Jeśli chce się, aby zasoby te były możliwe do odzyskania, należy określić specjalne opcje w odpowiednich definicjach CICS:
- Pliki VSAM
- Tabele danych obsługiwane przez CMT CICS
- TDQ wewnątrz partycji
- Tymczasowa kolejka pamięci masowej w pamięci dyskowej
- Komunikaty we/wy z/do transakcji w sieci VTAM
- Inne zasoby bazy danych/kolejkowania podłączone do CICS obsługujące protokół zatwierdzania dwufazowego XA (takie jak IMS/DB, Db2, VSAM/RLS)
CICS oferuje również rozbudowane funkcje przywracania/restartowania, dzięki którym użytkownicy mogą ustanowić własne możliwości przywracania/restartowania w systemie CICS. Często używane funkcje odzyskiwania/ponownego uruchamiania obejmują:
- Dynamiczne wycofanie transakcji (DTB)
- Automatyczne ponowne uruchomienie transakcji
- Odzyskiwanie zasobów przy użyciu dziennika systemowego
- Odzyskiwanie zasobów za pomocą dziennika
- Ponowne uruchomienie systemu
- Rozszerzone narzędzie odzyskiwania
składniki
Każdy region CICS składa się z jednego głównego zadania, w ramach którego uruchamiana jest każda transakcja, chociaż niektóre usługi, takie jak dostęp do danych IBM Db2 , korzystają z innych zadań (TCB). W regionie transakcje są kooperatywnie wielozadaniowe — oczekuje się, że będą zachowywać się dobrze i będą zużywać procesor, a nie czekać. Usługi CICS obsługują to automatycznie.
Każdemu unikalnemu „ Zadaniu ” lub transakcji CICS przydzielana jest podczas uruchamiania własna pamięć dynamiczna, a kolejne żądania dodatkowej pamięci były obsługiwane przez wywołanie programu „Storage Control” (część jądra CICS lub „ jądra ”), który jest analogiczny do systemu operacyjnego .
System CICS składa się z jądra online , programów obsługi wsadowej i usług aplikacji.
Jądro
Oryginalne jądro CICS składało się z wielu modułów funkcjonalnych napisanych w asemblerze 370 do wersji V3:
- Program kontroli zadań (KCP)
- Program kontroli przechowywania (SCP)
- Program kontroli programów (PCP)
- Program kontroli przerwań programu (PIP)
- Program kontroli interwałów (ICP)
- Program kontroli zrzutów (DCP)
- Program kontroli terminali (TCP)
- Program kontroli plików (FCP)
- Program kontroli danych przejściowych (TDP)
- Program kontroli czasowego składowania (TSP)
Począwszy od V3, jądro CICS zostało przepisane na strukturę jądra i domeny przy użyciu języka IBM PL/AS – który jest wkompilowany w asembler.
Wcześniejsza struktura nie wymuszała rozdzielenia problemów, podobnie jak wiele zależności między programami, które prowadziły do błędów, chyba że przeprowadzono wyczerpującą analizę kodu. Nowa struktura była bardziej modułowa i bardziej odporna, ponieważ łatwiej było ją zmieniać bez wpływu. Pierwsze domeny były często budowane z nazwą poprzedniego programu, ale bez końcowego „P”. Na przykład domena kontroli programów (DFHPC) lub domena danych przejściowych (DFHTD). Jądro działało jako przełącznik dla żądań między domenami – początkowo okazało się to kosztowne w przypadku często wywoływanych domen (takich jak Trace), ale dzięki wykorzystaniu makr PL/AS te wywołania były łączone bez uszczerbku dla projektu oddzielnej domeny.
W późniejszych wersjach dodano całkowicie przeprojektowane domeny, takie jak Logging Domain DFHLG i Transaction Domain DFHTM, które zastąpiły Journal Control Program (JCP).
Programy wsparcia
Oprócz funkcji online CICS ma kilka programów pomocniczych, które działają jako zadania wsadowe.
- Preprocesor języka wysokiego poziomu (makro).
- Tłumacz języka poleceń
- Narzędzie Dump – drukuje sformatowane zrzuty wygenerowane przez CICS Dump Management
- Narzędzie śledzenia — formatuje i drukuje dane wyjściowe śledzenia CICS
- Narzędzie do formatowania dziennika – drukuje sformatowany zrzut regionu CICS w przypadku błędu
Usługi aplikacji
Następujące komponenty CICS obsługują tworzenie aplikacji.
- Podstawowa obsługa mapowania (BMS) zapewnia niezależne od urządzenia wejście i wyjście terminala
- Obsługa APPC zapewniająca obsługę interfejsów API LU6.1 i LU6.2 dla współpracujących aplikacji rozproszonych obsługujących zatwierdzanie dwufazowe
- Data Interchange Program (DIP) zapewnia obsługę programowalnych urządzeń IBM 3770 i IBM 3790
- Zgodność z 2260 umożliwia uruchamianie programów napisanych dla urządzeń wyświetlających IBM 2260 na wyświetlaczach 3270
- EXEC Interface Program – program pośredniczący, który konwertuje wywołania generowane przez polecenia
EXEC CICS
na wywołania funkcji CICS - Wbudowane funkcje – przeszukiwanie tabeli, konwersja fonetyczna, weryfikacja pól, edycja pól, sprawdzanie bitów, formatowanie danych wejściowych, pobieranie ważone
Wymowa
Różne kraje mają różne wymowy
- W IBM (szczególnie / Tivoli k ɪ k s / ) jest określany jako .
- W Stanach Zjednoczonych jest to częściej wymawiane przez recytację każdej litery / ˌ s iː ˌ aɪ ˌ s iː ˈ ɛ s / .
- W Australii, Belgii, Kanadzie, Hongkongu, Wielkiej Brytanii i niektórych innych krajach wymawia się / ˈ k ɪ k s / .
- W Danii wymawia się kopnięcia .
- W Finlandii wymawia się [kiks]
- We Francji wymawia się [se.i.se.ɛs] .
- W Niemczech, Austrii i na Węgrzech wymawia się [ˈtsɪks] i rzadziej [ˈkɪks] .
- W Grecji wymawia się je kiks .
- W Indiach wymawia się kopnięcia .
- W Iranie wymawia się kopnięcia .
- W Izraelu wymawia się CICS .
- We Włoszech wymawia się [ˈtʃiks] .
- W Polsce wymawia się [ˈkʲiks] .
- W Portugalii i Brazylii wymawia się [ˈsiks] .
- W Rosji wymawia się kiks .
- W Słowenii wymawia się kiks .
- W Hiszpanii wymawia się [ˈθiks] .
- W Szwecji wymawia się kopnięcia .
- W Izraelu wymawia się kopnięcia .
- W Ugandzie wymawia się kopnięcia .
- W Turcji wymawia się je kiks .
Zobacz też
- IBM TXSeries (CICS na platformach rozproszonych)
- IBM WebSphere
- IBM2741
- IBM2260
- IBM3270
- OS/360 i następcy
- Narzędzie do przetwarzania transakcji
- Metoda dostępu do pamięci wirtualnej (VSAM)
Linki zewnętrzne
- Oficjalna strona internetowa
- Dlaczego warto wybrać CICS Transaction Server do nowych projektów IT — dokumentacja IBM CICS
- Oprogramowanie IBM - CICS - 35-lecie (2004) w Wayback Machine (archiwum 4 lutego 2009)
- Forum wsparcia dla programowania CICS
- Witryna internetowa społeczności użytkowników CICS zawierająca wiadomości, ogłoszenia i dyskusje związane z CICS
- Witryna internetowa poświęcona CICS Boba Yelavicha. (Ta witryna używa ramek, ale na ekranach o wysokiej rozdzielczości ramka po lewej stronie, która zawiera indeks witryny, może być ukryta. Przewiń ramkę w prawo, aby zobaczyć jej zawartość.) w Wayback Machine (archiwum 5 lutego 2005)