CICS - CICS

Pro jiná použití, viz CICS (disambiguation) .
CICS
Logo IBM.svg
Ostatní jména Systém řízení informací o zákaznících
První vydání 8. července 1969 ; Před 52 lety ( 08.07.1969 )
Stabilní uvolnění
CICS Transaction Server V5.6 / 12. června 2020 ; Před 13 měsíci ( 2020-06-12 )
Operační systém z/OS , z/VSE
Plošina IBM Z
Typ Teleprocesní monitor
Licence Proprietární
webová stránka www .ibm .com /it-infrastruktura /z /cics

IBM CICS (Customer Information Control System) je rodina vícejazyčných aplikačních serverů, které poskytují online správu transakcí a konektivitu pro aplikace na sálových systémech IBM v systémech z / OS a z / VSE .

Produkty řady CICS jsou navrženy jako middleware a podporují rychlé, velkoobjemové online zpracování transakcí . Transakce CICS je jednotka zpracování iniciovaná jediným požadavkem, který může ovlivnit jeden nebo více objektů. Toto zpracování je obvykle interaktivní (orientované na obrazovku), ale transakce na pozadí jsou možné.

CICS Transaction Server (CICS TS) sedí v čele rodiny CICS a poskytuje služby, které rozšiřují nebo nahrazují funkce operačního systému. Tyto služby mohou být efektivnější než zobecněné služby operačního systému a také jednodušší pro programátory, zejména pokud jde o komunikaci s různými koncovými zařízeními.

Aplikace vyvinuté pro CICS mohou být napsány v různých programovacích jazycích a mohou používat jazyková rozšíření dodávaná CICS k interakci se zdroji, jako jsou soubory, databázová připojení , terminály, nebo k vyvolávání funkcí, jako jsou webové služby. CICS spravuje celou transakci tak, že pokud z jakéhokoli důvodu část transakce selže, lze všechny obnovitelné změny zálohovat.

Zatímco CICS TS má nejvyšší profil mezi velkými finančními institucemi, jako jsou banky a pojišťovny, CICS provozuje mnoho společností a vládních subjektů z žebříčku Fortune 500 . Jiné, menší podniky mohou také provozovat CICS TS a další produkty řady CICS. CICS lze pravidelně nacházet v zákulisí například v bankomatových aplikacích, bankomatových systémech, systémech řízení průmyslové výroby, pojišťovacích aplikacích a mnoha dalších typech interaktivních aplikací.

Nedávná vylepšení CICS TS zahrnují nové funkce pro zlepšení zkušeností vývojářů, včetně výběru rozhraní API, rámců, editorů a nástrojů pro vytváření, a současně poskytují aktualizace v klíčových oblastech zabezpečení, odolnosti a správy. V dřívějších nedávných vydáních CICS TS byla poskytována podpora pro webové služby a Javu , zpracování událostí , kanály Atom a rozhraní RESTful .


Dějiny

CICS předcházel dřívější systém zpracování transakcí s jedním vláknem , IBM MTCS . Později byl vyvinut 'můstek MTCS-CICS', který těmto transakcím umožní provádět v rámci CICS bez změny původních aplikačních programů.

CICS byl původně vyvinut ve Spojených státech v IBM Development Center v Des Plaines, Illinois , počínaje rokem 1966 za účelem řešení požadavků z odvětví veřejných služeb. První produkt CICS byl oznámen v roce 1968 s názvem Public Utility Customer Information Control System nebo PU-CICS. Okamžitě se ukázalo, že je použitelný v mnoha dalších průmyslových odvětvích, takže předpona Public Utility byla zrušena zavedením prvního vydání produktu CICS Program 8. července 1969, nedlouho po systému správy databází IMS .

Několik příštích let byl CICS vyvinut v Palo Alto a byl považován za méně důležitý „menší“ produkt než IMS, který pak IBM považovala za strategičtější. Tlak zákazníků to však udržel naživu. Když se IBM v roce 1974 rozhodlo ukončit vývoj CICS a soustředit se na IMS, odpovědnost za vývoj CICS převzal web IBM Hursley ve Spojeném království, který právě přestal pracovat na kompilátoru PL/I, a tak znal mnoho stejných zákazníky jako CICS. Jádro vývojové práce pokračuje v Hursley dnes spolu s příspěvky z laboratoří v Indii, Číně, Rusku, Austrálii a USA.

Raná evoluce

CICS původně podporoval pouze několik zařízení značky IBM, jako je psací stroj typu IBM 2741 Selectric (golfový míček) na psacím stroji. Terminály pro zobrazování videa IBM 2260 a 1972 IBM 3270 z roku 1964 byly později široce používány.

V počátcích sálových počítačů IBM byl počítačový software zdarma - dodáván bez příplatku s počítačovým hardwarem . OS / 360 operačního systému a podpora aplikační software jako CICS byly „otevřené“ pro zákazníky IBM dlouho před open-source software iniciativy. Korporace jako Standard Oil of Indiana (Amoco) významně přispěly do CICS.

Tým IBM Des Plaines se pokusil přidat podporu pro populární terminály jiných výrobců než IBM, jako je ASCII Teletype Model 33 ASR, ale malý nízkorozpočtový tým pro vývoj softwaru si nemohl dovolit hardware 100 $ za měsíc na jeho testování. Vedoucí pracovníci IBM nesprávně cítili, že budoucnost bude jako minulost, s dávkovým zpracováním pomocí tradičních děrných štítků .

IBM neochotně poskytla jen minimální finanční prostředky, když společnosti veřejných služeb, banky a společnosti vydávající kreditní karty požadovaly nákladově efektivní interaktivní systém (podobný programu 1965 Airline Control Program používaný počítačovým rezervačním systémem American Airlines Sabre ) pro vysokorychlostní přístup k datům- a aktualizace informací o zákaznících pro jejich telefonní operátory (bez čekání na systémy dávkových karet přes noc dávkové zpracování).

Když byl CICS dodán společnosti Amoco s podporou Teletype Model 33 ASR, způsobilo to selhání celého operačního systému OS/360 (včetně aplikačních programů jiných než CICS). Většinu programu CICS Terminal Control Program (TCP - srdce CICS) a část OS/360 musela pracně přepracovat a přepsat společnost Amoco Production Company v Tulsa Oklahoma. Poté byl vrácen společnosti IBM k bezplatné distribuci ostatním.

Za několik let CICS generoval přes 60 miliard dolarů z nových hardwarových příjmů pro IBM a stal se jejich nejúspěšnějším mainframovým softwarovým produktem.

V roce 1972 byl CICS k dispozici ve třech verzích-DOS-ENTRY (číslo programu 5736-XX6) pro stroje DOS/360 s velmi omezenou pamětí, DOS-STANDARD (číslo programu 5736-XX7), pro stroje DOS/360 s více pamětí, a OS-STANDARD V2 (číslo programu 5734-XX7) pro větší stroje se systémem OS/360.

Na začátku roku 1970 se řada původních vývojářů, včetně Ben Riggins (hlavní architekt prvních verzí), přestěhovala do Kalifornie a pokračovala ve vývoji CICS v IBM Palo Alto Development Center. Vedoucí pracovníci společnosti IBM nerozpoznali hodnotu softwaru jako produktu generujícího příjmy, dokud federální zákony nevyžadovaly oddělení softwaru . V roce 1980 vedoucí pracovníci IBM neuposlechli důrazných návrhů Bena Rigginse, že by IBM měla poskytnout vlastní operační systém na bázi EBCDIC a mikroprocesorový čip s integrovaným obvodem pro použití v osobním počítači IBM jako inteligentní terminál CICS (namísto nekompatibilního čipu Intel, a nezralý ASCII -založený Microsoft 1980 DOS ).

Vzhledem k omezené kapacitě i velkých procesorů té doby byla každá instalace CICS vyžadována k sestavení zdrojového kódu pro všechny systémové moduly CICS po dokončení procesu podobného generování systému (sysgen), nazývaného CICSGEN , ke stanovení hodnot pro podmíněné sestavení -jazyková prohlášení. Tento proces umožnil každému zákazníkovi vyloučit podporu ze samotného CICS pro jakoukoli funkci, kterou neměl v úmyslu použít, například podporu zařízení pro nepoužívané typy terminálů.

CICS vděčí za svou ranou popularitu relativně efektivní implementaci, kdy byl hardware velmi drahý, své architektuře zpracování více vláken, relativní jednoduchosti vývoje transakčních aplikací založených na terminálech v reálném čase a mnoha otevřeným zdrojovým příspěvkům zákazníků, včetně ladění a funkcí zvýšení.

Z notace

Část CICS byla formalizována pomocí notace Z v 80. a 90. letech ve spolupráci s Oxford University Computing Laboratory , pod vedením Tonyho Hoareho . Tato práce získala Cenu královny za technologický úspěch.

CICS jako distribuovaný souborový server

V roce 1986 společnost IBM oznámila podporu CICS pro služby souborů orientované na záznamy definované architekturou DDM ( Distributed Data Management Architecture ). To umožnilo programům na vzdálených počítačích připojených k síti vytvářet, spravovat a přistupovat k souborům, které byly dříve k dispozici pouze v prostředích zpracování transakcí CICS/MVS a CICS/VSE.

V novějších verzích CICS byla podpora pro DDM odebrána. Podpora komponenty DDM systému CICS z/OS byla ukončena na konci roku 2003 a ve verzi 5.2 byla z CICS pro z/OS odebrána. V CICS TS pro z/VSE byla podpora DDM stabilizována na úrovni V1.1.1 s oznámeným záměrem ji v budoucím vydání ukončit. V CICS pro z/VSE 2.1 a dále není CICS/DDM podporováno.

CICS a World Wide Web

CICS Transaction Server poprvé představil nativní rozhraní HTTP ve verzi 1.2 spolu s technologií Web Bridge pro zabalení terminálových programů se zelenou obrazovkou do fasády HTML. Webová a dokumentová rozhraní CICS byla v CICS TS V1.3 vylepšena tak, aby umožňovala psaní webových aplikací, aby mohly efektivněji komunikovat s webovými prohlížeči.

CICS TS verze 2.1 až 2.3 se zaměřil na zavedení technologií CORBA a EJB do CICS a nabízí nové způsoby integrace aktiv CICS do modelů komponent distribuovaných aplikací. Tyto technologie spoléhaly na hostování Java aplikací v CICS. Hostitelské prostředí Java zaznamenalo během mnoha vydání četná vylepšení, což nakonec vedlo k vložení profilu WebSphere Liberty do CICS Transaction Server V5.1. V CICS bylo možné pomocí Javy hostovat mnoho technologií pro web, což nakonec vedlo k odstranění nativních technologií CORBA a EJB.

CICS TS V3.1 přidal nativní implementaci technologií SOAP a WSDL pro CICS spolu s HTTP API na straně klienta pro odchozí komunikaci. Tyto dvojité technologie umožnily snazší integraci komponent CICS s jinými podnikovými aplikacemi a byly rozšířeny. Byly zahrnuty nástroje pro přijímání tradičních programů CICS napsaných v jazycích, jako je COBOL , a jejich převod na webové služby definované WSDL s malými nebo žádnými změnami programu. Tato technologie zaznamenala pravidelná vylepšení oproti postupným vydáním CICS.

CICS TS V4.1 a V4.2 zaznamenaly další vylepšení připojení k webu, včetně nativní implementace protokolu publikování Atom .

Mnoho novějších webových technologií bylo zpřístupněno pro dřívější vydání CICS pomocí jiných modelů doručení, než je tradiční vydání produktu. To umožnilo začínajícím uživatelům poskytnout konstruktivní zpětnou vazbu, která by mohla ovlivnit konečný návrh integrované technologie. Mezi příklady patří náhled technologie Soap for CICS SupportPac pro TS V2.2 nebo ATOM SupportPac pro TS V3.1. Tento přístup byl použit k zavedení podpory JSON pro CICS TS V4.2, technologii, která byla integrována do CICS TS V5.2.

Technologie JSON v CICS je podobná dřívější technologii SOAP , přičemž oba umožnily programům hostovaným v CICS zabalit moderní fasádu. Technologie JSON byla zase vylepšena v z/OS Connect Enterprise Edition, produktu IBM pro vytváření rozhraní JSON API, která mohou využívat aktiva z několika sálových subsystémů.

K interakci s CICS bylo také použito mnoho partnerských produktů. Mezi oblíbené příklady patří použití CICS Transaction Gateway pro připojení k CICS z aplikačních serverů Java kompatibilních s JCA a zařízení IBM DataPower pro filtrování webového provozu před dosažením CICS.

Moderní verze CICS poskytují mnoho způsobů, jak integrovat stávající i nová softwarová aktiva do toků distribuovaných aplikací. K aktivům CICS lze přistupovat ze vzdálených systémů a lze přistupovat ke vzdáleným systémům; lze šířit identitu uživatele a transakční kontext; RESTful API lze skládat a spravovat; zařízení, uživatelé a servery mohou komunikovat s CICS pomocí technologií založených na standardech; a prostředí IBM WebSphere Liberty v CICS podporuje rychlé přijetí nových technologií.

MicroCICS

V lednu 1985 oznámila poradenská společnost založená v roce 1969, která provedla „rozsáhlé on-line systémy“ pro hotely Hilton, květinářství FTD, Amtrak a Budget Rent-a-Car a oznámila, co se stalo MicroCICS . Počáteční zaměření bylo na IBM XT/370 a IBM AT/370 .

Rodina CICS

Ačkoli když se řekne CICS, lidé obvykle znamenají CICS Transaction Server, CICS Family označuje portfolio transakčních serverů, konektorů (nazývaných CICS Transaction Gateway ) a CICS Tools.

CICS na distribuovaných platformách - nikoli na sálových počítačích - se nazývá IBM TXSeries . TXSeries je distribuovaný middleware pro zpracování transakcí. Podporuje aplikace C, C ++, COBOL, Java ™ a PL/I v cloudových prostředích a tradičních datových centrech. TXSeries je k dispozici na platformách AIX , Linux x86, Windows , Solaris a HP-UX . CICS je také k dispozici v jiných operačních systémech, zejména IBM i a OS/2 . Implementace z/OS (tj. CICS Transaction Server pro z/OS) je zdaleka nejpopulárnější a nejvýznamnější.

Pro VM/CMS byly dříve k dispozici dvě verze CICS , ale od té doby byly obě ukončeny. V roce 1986 IBM vydala CICS / CMS , což byla verze CICS pro jednoho uživatele určená pro vývojové použití, přičemž aplikace byly později převedeny do systému MVS nebo DOS / VS pro provádění výroby. Později, v roce 1988, IBM vydala CICS/VM . CICS/VM byl určen pro použití na IBM 9370 , low-end sálovém počítači zaměřeném na oddělení; IBM umístila CICS/VM běžící na mainframech resortů nebo poboček pro použití ve spojení s centrálním mainframem se systémem CICS pro MVS.

Nástroje CICS

Zřizování, správu a analýzu systémů a aplikací CICS zajišťují nástroje CICS. To zahrnuje správu výkonu i nasazení a správu prostředků CICS. V roce 2015 byly s vydáním CICS Transaction Server pro z/OS 5.3 aktualizovány čtyři základní základní nástroje CICS (a balíček CICS Optimization Solution Pack pro z/OS). Čtyři základní nástroje CICS: CICS Interdependency Analyzer pro z/OS, CICS Deployment Assistant pro z/OS, CICS Performance Analyzer pro z/OS a CICS Configuration Manager pro z/OS.

Programování

Aspekty programování

Aby bylo možné podporovat více souběžných transakčních vláken, musely být aplikační programy interaktivních transakcí pro více uživatelů kvazi - reentrantní . Chyba kódování softwaru v jedné aplikaci by mohla zablokovat všechny uživatele ze systému. Modulární konstrukce reentrantních / opakovaně použitelných řídicích programů CICS znamenala, že s uvážlivým „prořezáváním“ bylo možné provádět více uživatelů s více aplikacemi na počítači s pouhou 32 kB drahé fyzické paměti magnetického jádra (včetně operačního systému ).

Programátoři aplikací CICS museli vynaložit značné úsilí, aby byly jejich transakce co nejefektivnější. Běžnou technikou bylo omezit velikost jednotlivých programů na maximálně 4 096 bajtů nebo 4K, aby CICS mohl snadno znovu použít paměť obsazenou jakýmkoli programem, který se aktuálně nepoužívá, pro jiný program nebo jiné potřeby ukládání aplikací. Když virtuální paměti byla přidána do verze OS / 360 v roce 1972, strategie 4K stala ještě důležitější ke snížení stránkování a mlácení neproduktivní zdrojů soupeření nad hlavou.

Efektivita kompilovaných programů na vysoké úrovni COBOL a PL/I zanechala mnoho požadavků. Mnoho aplikačních programů CICS bylo i nadále psáno v jazyce assembler, a to i poté, co byla k dispozici podpora COBOL a PL/I.

S drahými a vzácnými hardwarovými prostředky v 60. a 70. letech minulého století se mezi analytiky optimalizace systému vyvinula konkurenceschopná „hra“. Když byl identifikován kód kritické cesty , byl předán fragment kódu od jednoho analytika k druhému. Každá osoba musela buď (a) snížit počet požadovaných bajtů kódu, nebo (b) snížit počet požadovaných cyklů CPU . Mladší analytici se poučili z toho, co udělali zkušenější mentoři. Nakonec, když nikdo nemohl udělat (a) nebo (b), byl kód považován za optimalizovaný a oni přešli na další úryvky. Malé obchody s jediným analytikem se optimalizaci CICS učily velmi pomalu (nebo vůbec).

Protože aplikační programy mohly být sdíleny mnoha souběžnými vlákny, bylo použití statických proměnných vložených do programu (nebo využití paměti operačního systému) omezeno (pouze konvencí).

Mnoho z „pravidel“ bylo bohužel často porušeno, zejména programátory COBOL, kteří možná nerozumí vnitřním složkám svých programů nebo nepoužívají nezbytné omezující možnosti kompilace času . Výsledkem byl kód „nere-entrant“, který byl často nespolehlivý, což vedlo k falešnému narušení úložiště a selhání celého systému CICS.

Původně celý oddíl nebo oblast MVS ( Multiple Virtual Storage ) fungoval se stejným klíčem ochrany paměti včetně kódu jádra CICS. Poškození programu a poškození bloku řízení CICS bylo častou příčinou prostojů systému. Softwarová chyba v jednom aplikačním programu by mohla přepsat paměť (kód nebo data) jedné nebo všech aktuálně spuštěných transakcí aplikace. Vyhledání problematického kódu aplikace pro složité chyby přechodného časování může být velmi obtížným problémem analytika operačního systému.

Tyto nedostatky přetrvávaly u několika nových verzí CICS po dobu více než 20 let, a to navzdory jejich závažnosti a skutečnosti, že vysoce kvalitní dovednosti CICS byly ve vysoké poptávce a nízké nabídce. Byly řešeny v TS V3.3, V4.1 a V5.2 s funkcemi Storage Protection, Transaction Isolation a Subspace, které využívají hardwarové funkce operačního systému k ochraně kódu aplikace a dat ve stejném adresním prostoru, přestože aplikace nebyly napsány k oddělení. Transakce s aplikacemi CICS zůstávají kritické pro mnoho společností poskytujících veřejné služby, velké banky a další mnohamiliardové finanční instituce.

Kromě toho je možné poskytnout míru pokročilé ochrany aplikace provedením testu pod kontrolou monitorovacího programu, který také slouží k zajištění funkcí Test a Debug.

Programování na makroúrovni

Když byl CICS poprvé vydán, podporoval pouze aplikační transakční programy napsané v IBM 360 Assembler . Podpora COBOL a PL/I byla přidána o několik let později. Kvůli počáteční orientaci assembleru byly požadavky na služby CICS vytvářeny pomocí maker v jazyce assembler . Například požadavek na čtení záznamu ze souboru byl proveden voláním makra do „Programu řízení souborů“ CICS může vypadat takto: 

DFHFC TYPE=READ,DATASET=myfile,TYPOPER=UPDATE,....etc.

To dalo vzniknout pozdější terminologií „ makro-level CICS.“

Když byla přidána podpora jazyků na vysoké úrovni, makra byla zachována a kód byl převeden pomocí předkompilovače, který rozšířil makra na jejich ekvivalenty příkazů COBOL nebo PL/I CALL. Příprava aplikace HLL tedy byla ve skutečnosti „dvoustupňovým“ kompilací  -výstup z preprocesoru vložený do kompilátoru HLL jako vstup.

Úvahy COBOL : na rozdíl od PL/I IBM COBOL běžně neposkytuje manipulaci s ukazateli (adresami). Aby se programátorům COBOL umožnil přístup k řídicím blokům CICS a dynamickému úložišti, uchýlili se návrháři k tomu, co bylo v podstatě hack. Sekce propojení COBOL byla obvykle používána pro komunikaci mezi programy, například pro předávání parametrů. Kompilátor generuje seznam adres, z nichž každá se nazývá Base Locator for Linkage (BLL) a které byly nastaveny při vstupu do volaného programu. První BLL odpovídá první položce v sekci propojení a tak dále. CICS umožňuje programátorovi přistupovat k nim a manipulovat s nimi tak, že jako první argument programu předá adresu seznamu. BLL pak lze dynamicky nastavit, buď pomocí CICS, nebo aplikací, aby byl umožněn přístup k odpovídající struktuře v sekci propojení.

Programování na úrovni příkazů

V 80. letech produkovala společnost IBM v Hursley Parku verzi CICS, která podporovala takzvaný „CICS na úrovni příkazů“, která stále podporovala starší programy, ale do aplikačních programů zavedla nový styl API.

Typické volání na úrovni příkazů může vypadat následovně: 

 EXEC CICS
     SEND MAPSET('LOSMATT') MAP('LOSATT')
 END-EXEC

Hodnoty uvedené v příkazu SEND MAPSET odpovídají názvům použitým v prvním makru DFHMSD v níže uvedené definici mapy pro argument MAPSET a makro DFHMSI pro argument MAP. Toto je předem zpracováno fází předkompilovaného dávkového překladu, která převádí vložené příkazy (EXEC) na příkazy volání na podprogram stub. Příprava aplikačních programů na pozdější spuštění tedy stále vyžadovala dvě fáze. Bylo možné psát aplikace „ smíšeného režimu “ pomocí příkazů na úrovni maker i příkazů.

Zpočátku byly v době provádění příkazy na úrovni příkazů převedeny pomocí run-time translatoru „The EXEC Interface Program“ na staré volání na úrovni maker, které pak bylo prováděno většinou nezměněnými programy jádra CICS. Ale když bylo jádro CICS přepsáno pro TS V3, stal se EXEC CICS jediným způsobem, jak programovat aplikace CICS, protože mnoho základních rozhraní se změnilo.

Převod za běhu

Command-level-only CICS představen na počátku 1990 nabídla určité výhody oproti dřívější verze aplikace CICS. IBM však také upustilo od podpory aplikačních programů na úrovni maker napsaných pro dřívější verze. To znamenalo, že mnoho aplikačních programů muselo být převedeno nebo zcela přepsáno, aby používaly pouze příkazy EXEC na úrovni příkazů.

Do této doby bylo na celém světě možná miliónů programů, které se v mnoha případech vyráběly desítky let. Jejich přepisování často představovalo nové chyby, aniž by nutně přidávaly nové funkce. Existoval značný počet uživatelů, kteří provozovali oblasti vlastněné aplikací CICS V2 (AOR), aby po změně na V3 pokračovaly ve spouštění kódu makra mnoho let.

Bylo také možné spouštět staré programy na úrovni maker pomocí konverzního softwaru, jako je APT International Command CICS .

Nové styly programování

Nedávná vylepšení serveru CICS Transaction Server zahrnují podporu řady moderních stylů programování.

CICS Transaction Server verze 5.6 představil vylepšenou podporu pro Javu, aby vývojářům Javy poskytl prostředí nativní v cloudu. Nové CICS Java API ( JCICSX ) například umožňuje snadnější testování jednotek pomocí zesměšňovacích a stubbingových přístupů a lze jej spouštět vzdáleně na místní pracovní stanici vývojáře. Sada artefaktů CICS na Maven Central umožňuje vývojářům řešit závislosti Java pomocí populárních nástrojů pro správu závislostí, jako jsou Apache Maven a Gradle . Plug-ins pro Maven ( cics-bundle-maven ) a Gradle ( cics-bundle-gradle ) jsou také k dispozici pro zjednodušení automatizovaného vytváření balíčků CICS pomocí známých IDE jako Eclipse , IntelliJ IDEA a Visual Studio Code . Kromě toho je pro verzi 12 vylepšena podpora Node.js z/OS, která poskytuje rychlejší spouštění, lepší výchozí limity haldy, aktualizace modulu JavaScript V8 atd. Součástí je také podpora Jakarta EE 8.

CICS TS 5.5 představil podporu pro IBM SDK pro Node.js, poskytující plný běh JavaScriptu, API na straně serveru a knihovny pro efektivní vytváření vysoce výkonných, vysoce škálovatelných síťových aplikací pro IBM Z.

CICS Transaction Server verze 2.1 zavedla podporu pro Javu. CICS Transaction Server verze 2.2 podporoval sadu Software Developers Toolkit. CICS poskytuje stejný run-time kontejner jako produktová řada IBM WebSphere, takže aplikace Java EE jsou přenosné mezi CICS a Websphere a pro vývoj a nasazování aplikací Java EE existují společné nástroje.

CICS navíc kladl důraz na „zabalení“ stávajících aplikačních programů do moderních rozhraní, aby bylo možné do modernějších služeb začlenit dlouhodobě zavedené obchodní funkce. Patří sem rozhraní WSDL, SOAP a JSON, která zabalí starší kód, takže webová nebo mobilní aplikace může získat a aktualizovat základní obchodní objekty, aniž by bylo nutné hlavní přepisování funkcí back-end.

Transakce

Transakce CICS je sada operací, které provádějí úkol společně. Většinu transakcí obvykle tvoří relativně jednoduché úkoly, jako je žádost o inventární seznam nebo zadání debetu nebo kreditu na účet. Primární charakteristikou transakce je, že by měla být atomová . Na serverech IBM Z CICS snadno podporuje tisíce transakcí za sekundu, což z něj činí pilíř podnikových počítačů.

Aplikace CICS zahrnují transakce, které lze zapsat do mnoha programovacích jazyků , včetně COBOL, PL/I, C, C ++, IBM Basic Assembly Language, REXX a Java.

Každý program CICS je inicializován pomocí identifikátoru transakce. Obrazovky CICS se obvykle odesílají jako konstrukce nazývaná mapa, modul vytvořený pomocí maker assembleru Basic Mapping Support (BMS) nebo nástrojů třetích stran. Obrazovky CICS mohou obsahovat zvýrazněný text, různé barvy a/nebo blikání v závislosti na použitém typu terminálu. Níže je uveden příklad, jak lze mapu odeslat prostřednictvím systému COBOL. Koncový uživatel zadává data, která jsou programu zpřístupněna přijetím mapy od CICS. 

 EXEC CICS
     RECEIVE MAPSET('LOSMATT') MAP('LOSATT') INTO(OUR-MAP)
 END-EXEC.

V závislosti na tom, na co se odkazuje, musí být z technických důvodů citovány argumenty některých parametrů příkazu a některé nesmí být uvedeny. Většina programátorů bude kódovat z referenční knihy, dokud nepochopí „viset“ nebo koncept, ve kterém jsou uvedeny argumenty, nebo obvykle použijí „předpřipravenou šablonu“, kde mají ukázkový kód, který pouze zkopírují a vloží, a poté upraví změnit hodnoty.

Příklad BMS mapového kódu

Základní podpora mapování definuje formát obrazovky prostřednictvím maker assembleru, jako jsou následující. Toto bylo sestaveno tak, aby generovalo jak fyzickou sadu map  - zaváděcí modul v zaváděcí  knihovně CICS -, tak symbolickou sadu map - definici struktury nebo DSECT v PL/I, COBOL, assembleru atd., Která byla zkopírována do zdrojového programu. 

 LOSMATT DFHMSD TYPE=MAP,                                               X
                MODE=INOUT,                                             X
                TIOAPFX=YES,                                            X
                TERM=3270-2,                                            X
                LANG=COBOL,                                             X
                MAPATTS=(COLOR,HILIGHT),                                X
                DSATTS=(COLOR,HILIGHT),                                 X
                STORAGE=AUTO,                                           X
                CTRL=(FREEKB,FRSET)
 *
 LOSATT  DFHMDI SIZE=(24,80),                                           X
                LINE=1,                                                 X
                COLUMN=1
 *
 LSSTDII DFHMDF POS=(1,01),                                             X
                LENGTH=04,                                              X
                COLOR=BLUE,                                             X
                INITIAL='MQCM',                                         X
                ATTRB=PROT
 *
         DFHMDF POS=(24,01),                                            X
                LENGTH=79,                                              X
                COLOR=BLUE                                              X
                ATTRB=ASKIP,                                            X
                INITIAL='PF7-          8-           9-          10-     X
                    11-            12-CANCEL'
 *
           DFHMSD   TYPE=FINAL
           END

Struktura

V prostředí z/OS instalace CICS obsahuje jednu nebo více „ oblastí “ (obecně označovaných jako „oblast CICS“), rozložených v jedné nebo více bitových kopiích systému z/OS. Ačkoli zpracovává interaktivní transakce, každá oblast CICS se obvykle spouští jako dávkové zpracování | dávkový adresní prostor se standardními příkazy JCL : je to úloha, která běží neomezeně dlouho až do vypnutí. Alternativně může být každá oblast CICS spuštěna jako spuštěná úloha . Ať už jde o dávkovou úlohu nebo spuštěný úkol, regiony CICS mohou běžet několik dní, týdnů nebo dokonce měsíců před vypnutím z důvodu údržby (MVS nebo CICS). Po restartu parametr určuje, zda má být start „studený“ (bez obnovy) nebo „teplý“/„nouzový“ (pomocí teplého vypnutí nebo restartu z protokolu po havárii). Studené starty velkých oblastí CICS s mnoha zdroji mohou trvat dlouho, než budou všechny definice znovu zpracovány.

Instalace jsou rozděleny do více adresních prostorů z celé řady důvodů, například:

  • separace aplikací,
  • oddělení funkcí,
  • vyhýbání se omezení kapacity pracovní zátěže jedné oblasti nebo adresního prostoru nebo instance sálového počítače v případě az/OS SysPlex.

Typická instalace se skládá z řady odlišných aplikací, které tvoří službu. Každá služba má obvykle určitý počet „regionů, které vlastní terminál“ (TOR), které směrují transakce do více „regionů, které vlastní aplikace“ (AOR), ačkoli jsou možné i jiné topologie. Například AOR nemusí provádět soubor I/O. Místo toho by existovala „Oblast vlastnění souborů“ (FOR), která by prováděla I/O souboru jménem transakcí v AOR-vzhledem k tomu, že v té době soubor VSAM mohl podporovat pouze obnovitelný přístup pro zápis z jednoho adresního prostoru na Doba.

Ale ne všechny aplikace CICS používají VSAM jako primární zdroj dat (nebo historicky jiný jediný adresní prostor v určitém čase v úložištích dat, jako je CA Datacom)- mnoho z nich používá jako databázi IMS/DB nebo Db2 a/nebo MQ jako správce front. Ve všech těchto případech mohou TOR načítat transakce s vyvážením do sad AOR, které pak přímo používají sdílené databáze/fronty. CICS podporuje dvoufázové potvrzení XA mezi datovými úložišti, takže transakce, které pokrývají například MQ, VSAM/RLS a Db2, jsou možné s vlastnostmi ACID.

CICS podporuje distribuované transakce pomocí protokolu SNA LU6.2 mezi adresními prostory, které mohou běžet na stejných nebo různých klastrech. To umožňuje spolupráci s distribuovanými aplikacemi ACID aktualizace více datových úložišť. V praxi s tím jsou problémy, pokud dojde k selhání systému nebo komunikace, protože dispozice transakce (backout nebo commit) může být na pochybách, pokud se jeden z komunikujících uzlů neobnovil. Využití těchto zařízení tedy nikdy nebylo příliš rozšířené.

Využívání Sysplexu

V době CICS ESA V3.2, na počátku 90. let 20. století, čelila společnost IBM výzvě, jak přimět CICS k využívání nové řady mainframe zOS Sysplex .

Sysplex měl být založen spíše na CMOS (Complementary Metal Oxide Silicon) než na stávajícím hardwaru ECL (Emitter Coupled Logic). Náklady na škálování ECL jedinečného sálového počítače byly mnohem vyšší než CMOS, který vyvíjel keiretsu s velkými objemy použití, jako je Sony PlayStation, aby se snížily jednotkové náklady na CPU každé generace. Spuštění ECL bylo pro uživatele také nákladné, protože odtokový proud brány produkoval tolik tepla, že CPU musel být zabalen do speciálního modulu nazývaného Thermal Conduction Module (TCM), který měl písty s inertním plynem a potřeboval instalovat vysokotlaké chlazení voda k ochlazení. Ale rychlost procesoru vzduchem chlazené technologie CMOS byla zpočátku mnohem pomalejší než ECL (zejména krabice dostupné od výrobců mainframe-clone Amdahl a Hitachi ). To se týkalo zejména IBM v kontextu CICS, protože téměř všichni největší zákazníci sálových počítačů provozovali CICS a pro mnohé z nich to byla primární zátěž mainframe.

Aby bylo dosaženo stejné celkové propustnosti transakcí na Sysplexu, muselo by být paralelně použito více boxů pro každé pracovní vytížení, ale adresní prostor CICS by kvůli svému poloreentantnímu modelu programování aplikací nemohl využívat více než 1,5 procesoru na jednom boxu při čas-dokonce i při použití dílčích úkolů MVS. Bez toho by tito zákazníci měli tendenci přesouvat se ke konkurentům spíše než k Sysplexu, protože zvyšovali pracovní zátěž CICS. V IBM se vedla značná debata o tom, zda by správným přístupem bylo prolomit vzestupnou kompatibilitu aplikací a přejít k modelu, jako je IMS/DC, který byl plně reentrantní, nebo rozšířit přístup, který zákazníci zvolili k úplnějšímu využití síly jednoho sálového počítače -pomocí operace více oblastí (MRO).

Druhá cesta byla nakonec přijata poté, co byla konzultována komunita uživatelů CICS a vehementně se stavěla proti prolomení vzestupné kompatibility vzhledem k tomu, že v té době měli perspektivu Y2K, s níž by se mohli poprat, a neviděli hodnotu v přepisování a testování milionů řádků hlavně COBOL, PL/1 nebo kód assembleru.

Struktura doporučená IBM pro CICS na Sysplexu spočívala v tom, že na každý uzel Sysplex byla umístěna alespoň jedna oblast vlastnící terminál CICS, která odesílala transakce do mnoha regionů vlastnických aplikací (AOR) rozložených po celém Sysplexu. Pokud tyto aplikace potřebovaly přístup ke sdíleným zdrojům, buď používaly datové úložiště využívající Sysplex (jako Db2 nebo IMS/DB ), nebo se soustředily prostřednictvím přenosu funkcí na požadavky zdrojů do regionů ROR (singular-per-resource Resource Owing Regions) včetně souboru Vlastnící oblasti (FORs) pro datové tabulky VSAM a CICS, vlastnické oblasti fronty (QOR) pro MQ , přechodná data CICS (TD) a dočasné úložiště CICS (TS). Tato zachovaná kompatibilita pro starší aplikace na úkor provozní složitosti pro konfiguraci a správu mnoha oblastí CICS.

V následujících vydáních a verzích dokázal CICS využívat nová zařízení využívající Sysplex ve VSAM/RLS, MQ pro zOS a umístil vlastní zdroje datových tabulek, TD a TS do navrženého sdíleného správce zdrojů pro Sysplex -> Coupling Facility nebo CF, bez potřeby většiny ROR. CF poskytuje mapovaný pohled na zdroje včetně sdílené časové základny, fondů vyrovnávacích pamětí, zámků a čítačů s hardwarovým zasíláním zpráv, díky čemuž je sdílení zdrojů na Sysplexu efektivnější než polling a spolehlivé (s využitím polosynchronizovaného záložního CF pro použití v případě selhání).

Do této doby měla řada CMOS jednotlivá pole, která přesahovala výkon dostupný nejrychlejším boxem ECL s více procesory na CPU, a když byly spojeny dohromady, 32 nebo více uzlů by dokázalo škálovat o dva řády větší celkový výkon za jediné pracovní vytížení. Například v roce 2002 Charles Schwab provozoval „MetroPlex“ skládající se z nadbytečného páru jeho mainframe Sysplexes na dvou místech ve Phoenixu, AZ, každý s 32 uzly poháněnými jedním sdíleným pracovním vytížením CICS/DB/2, aby podpořil obrovský objem pre -dotcom-bubble žádosti o webového klienta.

Tato levnější, mnohem škálovatelnější technologická základna CMOS a obrovské investiční náklady spojené s přístupem k 64bitovému adresování a nezávislou produkcí klonovaných funkcí CF vytlačily výrobce klonů mainframových počítačů IBM z podnikání jednoho po druhém.

Obnova/restart CICS

Cílem obnovy/restartu v CICS je minimalizovat a je -li to možné eliminovat poškození online systému v případě selhání, aby byla zachována integrita systému a dat. Pokud byla oblast CICS vypnuta namísto selhání, provede „teplý“ start s využitím kontrolního bodu zapsaného při vypnutí. Region CICS lze také přinutit ke „studenému“ startu, který znovu načte všechny definice a vymaže protokol a ponechá prostředky v jakémkoli stavu, ve kterém se nacházejí.

V rámci CICS jsou uvedeny některé ze zdrojů, které jsou považovány za obnovitelné. Pokud si někdo přeje, aby tyto zdroje byly obnovitelné, musí být v příslušných definicích CICS specifikovány speciální možnosti:

  • Soubory VSAM
  • Datové tabulky udržované CMT CICS
  • Meziprostorový TDQ
  • Fronta dočasného úložiště v pomocném úložišti
  • I/O zprávy z/do transakcí v síti VTAM
  • Další zdroje databází/front zařazené do CICS, které podporují protokol dvoufázového potvrzení XA (jako IMS/DB, Db2, VSAM/RLS)

CICS také nabízí rozsáhlé možnosti obnovy / restartu, aby si uživatelé mohli ve svém systému CICS vytvořit vlastní schopnost obnovy / restartu. Mezi běžně používaná zařízení pro obnovu/restart patří:

  • Dynamic Transaction Backout (DTB)
  • Restart automatické transakce
  • Obnovení zdrojů pomocí systémového protokolu
  • Obnovení zdrojů pomocí deníku
  • Restart systému
  • Zařízení pro prodlouženou obnovu

Komponenty

Každá oblast CICS obsahuje jeden hlavní úkol, na kterém běží každá transakce, ačkoli určité služby, jako je přístup k datům Db2, používají jiné úkoly (TCB). V rámci regionu jsou transakce kooperativně víceúlohové  -očekává se, že se budou chovat slušně a přinese CPU spíše než čekání. Služby CICS to řeší automaticky.

Každému jedinečnému „ úkolu “ nebo transakci CICS je při spuštění přidělena vlastní dynamická paměť a následné požadavky na další paměť byly zpracovány voláním „programu pro řízení úložiště“ (část jádra CICS nebo „ jádra “), který je analogicky s operačním systémem .

Systém CICS se skládá z online jádra , dávkových programů podpory a aplikačních služeb.

Jádro

Původní jádro CICS sestávalo z řady funkčních modulů napsaných v 370 assembleru do V3:

  • Task Control Program (KCP)
  • Program pro řízení úložiště (SCP)
  • Program Control Program (PCP)
  • Program pro řízení přerušení programu (PIP)
  • Intervalový kontrolní program (ICP)
  • Program kontroly skládky (DCP)
  • Program pro ovládání terminálu (TCP)
  • Program pro ovládání souborů (FCP)
  • Program pro řízení přechodných dat (TDP)
  • Program pro řízení dočasného úložiště (TSP)

Počínaje verzí V3 bylo jádro CICS přepsáno do struktury jádra a domény pomocí jazyka PL/AS společnosti IBM -který je kompilován do assembleru.

Předchozí struktura nevynucovala oddělení obav a tak měla mnoho závislostí mezi programy, které vedly k chybám, pokud nebyla provedena vyčerpávající analýza kódu. Nová struktura byla modulárnější a odolnější, protože bylo snazší ji změnit bez nárazu. První domény byly často stavěny s názvem předchozího programu, ale bez koncového „P“. Například doména řízení programu (DFHPC) nebo doména přechodných dat (DFHTD). Jádro fungovalo jako přepínač pro požadavky mezi doménami-zpočátku se to ukázalo jako nákladné pro často nazývané domény (například Trace), ale pomocí maker PL/AS byla tato volání vložena bez kompromisů v návrhu samostatné domény.

V novějších verzích byly přidány zcela přepracované domény, jako je logovací doména DFHLG a transakční doména DFHTM, která nahradila program Journal Control Program (JCP).

Programy podpory

Kromě online funkcí má CICS několik podpůrných programů, které běží jako dávkové úlohy.

  • Předprocesor jazyka (makro) na vysoké úrovni
  • Překladač příkazového jazyka
  • Nástroj Dump - vytiskne formátované výpisy generované CICS Dump Management
  • Nástroj Trace - formátuje a tiskne trasovací výstup CICS
  • Obslužný program pro formátování deníku - v případě chyby vytiskne naformátovaný výpis oblasti CICS

Aplikační služby

Následující součásti CICS podporují vývoj aplikací.

  • Základní podpora mapování (BMS) poskytuje koncový vstup a výstup nezávislý na zařízení
  • Podpora APPC, která poskytuje podporu API LU6.1 a LU6.2 pro spolupracující distribuované aplikace, které podporují dvoufázové potvrzení
  • Data Interchange Program (DIP) poskytuje podporu pro programovatelná zařízení IBM 3770 a IBM 3790
  • Kompatibilita 2260 umožňuje programům napsaným pro zobrazovací zařízení IBM 2260 běžet na 3270 displejích
  • Program rozhraní EXEC - program stub, který převádí volání generovaná EXEC CICSpříkazy na volání funkcí CICS
  • Vestavěné funkce-vyhledávání v tabulce, fonetická konverze, ověření pole, úprava pole, kontrola bitů, formátování vstupu, vážené načítání

Výslovnost

Různé země mají různé výslovnosti

  • V IBM (konkrétně Tivoli ) je označován jako / k ɪ k y / .
  • Ve Spojených státech, to je více obvykle vyslovován recitací každé písmeno / ˌ s I ˌ aɪ ˌ s I ɛ s / .
  • V Austrálii, Belgii, Kanadě, Hong Kong, Velké Británii a některých jiných zemích, to je výraznější / k ɪ k y / .
  • Ve Finsku se vyslovuje [kiks]
  • Ve Francii se to vyslovuje [se.i.se.ɛs] .
  • V Německu, Rakousku a Maďarsku se vyslovuje [ˈTsɪks] a méně často[ˈKɪks] .
  • V Řecku se vyslovuje kiks .
  • V Indii se vyslovuje kopy .
  • V Íránu se jedná o výrazné kopy .
  • V Izraeli se vyslovuje CICS .
  • V Itálii se vyslovuje [ˈTʃiks] .
  • V Polsku se to vyslovuje [ˈKʲiks] .
  • V Portugalsku a Brazílii se vyslovuje [ˈSiks] .
  • V Rusku se vyslovuje kiks .
  • Ve Slovinsku se vyslovuje kiks .
  • Ve Španělsku se to vyslovuje [ˈΘiks] .
  • Ve Švédsku se vyslovuje kopy .
  • V Izraeli se to vyslovuje kopy .
  • V Ugandě jsou to výrazné kopy .
  • V Turecku se vyslovuje kiks .

Viz také

Reference

externí odkazy