CICS - CICS

Для использования в других целях, см CICS (значения) .
CICS
IBM logo.svg
Другие имена Система управления информацией о клиентах
изначальный выпуск 8 июля 1969 г . ; 52 года назад ( 8 июля 1969 г. )
Стабильный выпуск
CICS Transaction Server V5.6 / 12 июня 2020 г . ; 13 месяцев назад ( 2020-06-12 )
Операционная система z / OS , z / VSE
Платформа IBM Z
Тип Монитор телеобработки
Лицензия Проприетарный
Интернет сайт www .ibm .com / IT -инфраструктура / z / cics

IBM CICS (Customer Information Control System) - это семейство многоязычных серверов приложений, которые обеспечивают оперативное управление транзакциями и возможность подключения для приложений в системах мэйнфреймов IBM под управлением z / OS и z / VSE .

Продукты семейства CICS разработаны как промежуточное ПО и поддерживают быструю обработку больших объемов онлайн-транзакций . Транзакция CICS - это единица обработки, инициированная одним запросом, который может повлиять на один или несколько объектов. Эта обработка обычно интерактивна (ориентирована на экран), но возможны фоновые транзакции.

Сервер транзакций CICS (CICS TS) стоит во главе семейства CICS и предоставляет услуги, расширяющие или заменяющие функции операционной системы. Эти службы могут быть более эффективными, чем общие службы операционной системы, а также более простыми для использования программистами, особенно в отношении связи с различными оконечными устройствами.

Приложения, разработанные для CICS, могут быть написаны на различных языках программирования и использовать предоставляемые CICS языковые расширения для взаимодействия с такими ресурсами, как файлы, соединения с базой данных , терминалы, или для вызова таких функций, как веб-службы. CICS управляет всей транзакцией, так что в случае сбоя части транзакции по какой-либо причине все восстанавливаемые изменения могут быть отменены.

Хотя CICS TS пользуется наибольшим авторитетом среди крупных финансовых учреждений, таких как банки и страховые компании, многие компании из списка Fortune 500 и государственные учреждения, как сообщается, используют CICS. Другие, более мелкие предприятия также могут использовать CICS TS и другие продукты семейства CICS. CICS можно регулярно находить за кулисами, например, в приложениях для банковских служащих, системах банкоматов, системах управления промышленным производством, страховых приложениях и многих других типах интерактивных приложений.

Последние усовершенствования CICS TS включают новые возможности для улучшения взаимодействия с разработчиками, включая выбор API, фреймворков, редакторов и инструментов сборки, и в то же время предоставляют обновления в ключевых областях безопасности, устойчивости и управления. В более ранних, последних выпусках CICS TS, поддержка предоставлялась для Web-сервисов и Java , обработки событий , каналов Atom и интерфейсов RESTful .


История

CICS предшествовала более ранняя однопоточная система обработки транзакций IBM MTCS . Позже был разработан «мост MTCS-CICS», позволяющий выполнять эти транзакции под CICS без изменения исходных прикладных программ.

CICS изначально был разработан в США в Центре разработки IBM в Дес-Плейнсе, штат Иллинойс , начиная с 1966 года для удовлетворения требований отрасли коммунальных услуг. Первый продукт CICS был анонсирован в 1968 году под названием Public Utility Customer Information Control System , или PU-CICS. Сразу стало ясно, что он применим во многих других отраслях, поэтому префикс Public Utility был упразднен с выпуском первого выпуска программного продукта CICS 8 июля 1969 года, вскоре после системы управления базами данных IMS .

В течение следующих нескольких лет CICS разрабатывалась в Пало-Альто и считалась менее важным «меньшим» продуктом, чем IMS, которую IBM тогда считала более стратегической. Однако давление со стороны покупателей поддерживало его. Когда в 1974 году IBM решила прекратить разработку CICS, чтобы сосредоточиться на IMS, ответственность за разработку CICS взял на себя сайт IBM Hursley в Соединенном Королевстве, который только что прекратил работу над компилятором PL / I и поэтому знал многие из них. клиентов как CICS. Основная работа по развитию продолжается сегодня в Хёрсли, наряду с вкладами лабораторий в Индии, Китае, России, Австралии и США.

Ранняя эволюция

Изначально CICS поддерживала только несколько устройств марки IBM, например терминал на базе пишущей машинки IBM 2741 Selectric (мяч для гольфа) 1965 года . Позднее широко использовались видеотерминалы IBM 2260 1964 года и IBM 3270 1972 года .

На заре создания мэйнфреймов IBM компьютерное программное обеспечение было бесплатным - без дополнительной платы поставлялось в комплекте с компьютерным оборудованием . OS / 360 Операционная система и поддержка прикладного программного обеспечения , как CICS были «открыты» для клиентов IBM задолго до программного обеспечения с открытым исходным кодом инициативы. Такие корпорации, как Standard Oil of Indiana (Amoco), внесли большой вклад в CICS.

Команда IBM Des Plaines пыталась добавить поддержку популярных терминалов сторонних производителей, таких как ASCII Teletype Model 33 ASR, но небольшая команда разработчиков низкобюджетного программного обеспечения не могла позволить себе аппаратное обеспечение стоимостью 100 долларов в месяц для его тестирования. Руководители IBM ошибочно полагали, что будущее будет похоже на прошлое с пакетной обработкой с использованием традиционных перфокарт .

IBM неохотно предоставляла лишь минимальное финансирование, когда коммунальные предприятия, банки и компании, выпускающие кредитные карты, требовали рентабельной интерактивной системы (аналогичной программе IBM Airline Control 1965 года, используемой компьютерной системой бронирования American Airlines Sabre ) для высокоскоростного доступа к данным. и обновлять информацию о клиентах для их телефонных операторов (не дожидаясь, пока системы перфокарт для пакетной обработки в ночное время не ждут).

Когда CICS был доставлен Amoco с поддержкой Teletype Model 33 ASR, это привело к сбою всей операционной системы OS / 360 (включая прикладные программы, не относящиеся к CICS). Большая часть программы управления терминалом CICS (TCP - сердце CICS) и часть OS / 360 пришлось тщательно переработать и переписать производственной компанией Amoco в Талсе, штат Оклахома. Затем он был возвращен IBM для бесплатного распространения среди других.

За несколько лет CICS принесла IBM более 60 миллиардов долларов дохода от нового оборудования и стала их самым успешным программным продуктом для мэйнфреймов.

В 1972 году CICS был доступен в трех версиях - DOS-ENTRY (номер программы 5736-XX6) для машин DOS / 360 с очень ограниченной памятью, DOS-STANDARD (номер программы 5736-XX7), для машин DOS / 360 с большим объемом памяти, и OS-STANDARD V2 (номер программы 5734-XX7) для больших компьютеров, на которых работала OS / 360.

В начале 1970 года ряд первоначальных разработчиков, в том числе Бен Риггинс (главный архитектор ранних выпусков), переехали в Калифорнию и продолжили разработку CICS в Центре разработки IBM в Пало-Альто . Руководители IBM не признавали ценность программного обеспечения как продукта, приносящего доход, до тех пор, пока федеральный закон не потребовал разделения программного обеспечения . В 1980 году руководители IBM не прислушались к настойчивым предложениям Бена Риггинса о том, что IBM должна предоставить свою собственную операционную систему на основе EBCDIC и микропроцессорный чип с интегральной схемой для использования в персональном компьютере IBM в качестве интеллектуального терминала CICS (вместо несовместимого чипа Intel, и незрелая основанная на ASCII Microsoft 1980 DOS ).

Из-за ограниченной мощности даже крупных процессоров той эпохи каждая установка CICS требовала сборки исходного кода для всех системных модулей CICS после завершения процесса, аналогичного генерации системы (sysgen), называемого CICSGEN , для установки значений для условной сборки -языковые заявления. Этот процесс позволил каждому клиенту исключить поддержку со стороны самого CICS для любой функции, которую он не намеревался использовать, например, поддержки устройств для неиспользуемых типов терминалов.

CICS обязана своей ранней популярностью своей относительно эффективной реализации, когда оборудование было очень дорого, своей многопоточной архитектурой обработки, относительной простотой разработки приложений транзакций в реальном времени на основе терминала, а также многочисленными предложениями заказчиков с открытым исходным кодом, включая как отладку, так и функции. улучшение.

Обозначение Z

Часть CICS была формализована с использованием обозначения Z в 1980-х и 1990-х годах в сотрудничестве с вычислительной лабораторией Оксфордского университета под руководством Тони Хора . Эта работа получила Королевскую премию за технологические достижения.

CICS как распределенный файловый сервер

В 1986 году IBM объявила о поддержке CICS для файловых служб, ориентированных на записи, определенных в Архитектуре управления распределенными данными (DDM). Это позволило программам на удаленных компьютерах, подключенных к сети, создавать, управлять и получать доступ к файлам, которые ранее были доступны только в средах обработки транзакций CICS / MVS и CICS / VSE.

В более новых версиях CICS удалена поддержка DDM. Поддержка компонента DDM в CICS z / OS была прекращена в конце 2003 года и удалена из CICS для z / OS в версии 5.2 и новее. В CICS TS для z / VSE поддержка DDM была стабилизирована на уровне V1.1.1 с объявленным намерением прекратить ее поддержку в будущих выпусках. В CICS для z / VSE 2.1 и более поздних версий CICS / DDM не поддерживается.

CICS и всемирная паутина

CICS Transaction Server впервые представил собственный HTTP- интерфейс в версии 1.2 вместе с технологией Web Bridge для обертывания программ терминала с зеленым экраном и фасадом HTML. API-интерфейсы CICS Web и Document были улучшены в CICS TS V1.3, чтобы позволить писать веб-приложения для более эффективного взаимодействия с веб-браузерами.

CICS TS версий с 2.1 по 2.3 был посвящен внедрению технологий CORBA и EJB в CICS, предлагая новые способы интеграции ресурсов CICS в модели распределенных компонентов приложений. Эти технологии основывались на размещении приложений Java в CICS. Среда размещения Java претерпела множество улучшений по сравнению с многими выпусками, что в конечном итоге привело к встраиванию WebSphere Liberty Profile в CICS Transaction Server V5.1. В CICS с использованием Java можно было разместить множество веб-технологий, что в конечном итоге привело к удалению встроенных технологий CORBA и EJB.

В CICS TS V3.1 добавлена ​​собственная реализация технологий SOAP и WSDL для CICS, а также клиентские HTTP API для исходящей связи. Эти двойные технологии позволили упростить интеграцию компонентов CICS с другими корпоративными приложениями и получили широкое распространение. Были включены инструменты для преобразования традиционных программ CICS, написанных на таких языках, как COBOL , в веб-службы, определенные WSDL, с небольшими изменениями программы или без них. Эта технология регулярно улучшалась по сравнению с последовательными выпусками CICS.

В CICS TS V4.1 и V4.2 были внесены дополнительные усовершенствования в возможности веб-подключения, включая встроенную реализацию протокола публикации Atom .

Многие из новых веб-технологий были доступны для более ранних выпусков CICS с использованием моделей доставки, отличных от традиционного выпуска продукта. Это позволило ранним последователям предоставить конструктивную обратную связь, которая могла повлиять на окончательный дизайн интегрированной технологии. Примеры включают предварительную версию Soap для технологии CICS SupportPac для TS V2.2 или ATOM SupportPac для TS V3.1. Этот подход был использован для внедрения поддержки JSON для CICS TS V4.2, технологии, которая впоследствии была интегрирована в CICS TS V5.2.

Технология JSON в CICS похожа на более раннюю технологию SOAP , обе из которых позволяли программам, размещенным в CICS, обернуть современный фасад. В свою очередь, технология JSON была усовершенствована в z / OS Connect Enterprise Edition, продукте IBM для создания API-интерфейсов JSON, которые могут использовать ресурсы из нескольких подсистем мэйнфреймов.

Многие партнерские продукты также использовались для взаимодействия с CICS. Популярные примеры включают использование шлюза транзакций CICS для подключения к CICS с JCA- совместимых серверов приложений Java и устройств IBM DataPower для фильтрации веб-трафика до того, как он достигнет CICS.

Современные версии CICS предоставляют множество способов интеграции существующих и новых программных активов в распределенные потоки приложений. Ресурсы CICS могут быть доступны из удаленных систем и могут иметь доступ к удаленным системам; идентификация пользователя и транзакционный контекст могут быть распространены; RESTful API можно составлять и управлять ими; устройства, пользователи и серверы могут взаимодействовать с CICS с использованием основанных на стандартах технологий; а среда IBM WebSphere Liberty в CICS способствует быстрому внедрению новых технологий.

MicroCICS

К январю 1985 года основанная в 1969 году консалтинговая компания, разработавшая «массовые онлайн-системы» для Hilton Hotels, FTD Florists, Amtrak и Budget Rent-a-Car, объявила о том, что стало MicroCICS . Первоначально в центре внимания были IBM XT / 370 и IBM AT / 370 .

Семья CICS

Хотя когда упоминается CICS, люди обычно имеют в виду сервер транзакций CICS, семейство CICS относится к портфелю серверов транзакций, соединителей (называемых шлюзом транзакций CICS ) и инструментов CICS.

CICS на распределенных платформах, а не на мэйнфреймах называется IBM TXSeries . TXSeries - это промежуточное ПО для распределенной обработки транзакций. Он поддерживает приложения C, C ++, COBOL, Java ™ и PL / I в облачных средах и традиционных центрах обработки данных. TXSeries доступен на платформах AIX , Linux x86, Windows , Solaris и HP-UX . CICS также доступен в других операционных системах, особенно в IBM i и OS / 2 . Реализация z / OS (т. Е. CICS Transaction Server для z / OS) на сегодняшний день является самой популярной и важной.

Две версии CICS ранее были доступны для VM / CMS , но с тех пор обе были прекращены. В 1986 году IBM выпустила CICS / CMS , которая была однопользовательской версией CICS, предназначенной для использования в процессе разработки, а приложения позже были перенесены в систему MVS или DOS / VS для производственного исполнения. Позже, в 1988 году, IBM выпустила CICS / VM . CICS / VM предназначалась для использования на IBM 9370 , мэйнфрейме начального уровня , предназначенном для использования в отделах; IBM разместила CICS / VM, работающую на мэйнфреймах отделов или филиалов, для использования вместе с центральным мэйнфреймом, на котором работает CICS для MVS.

Инструменты CICS

Обеспечение, управление и анализ систем и приложений CICS обеспечивается CICS Tools. Сюда входит управление производительностью, а также развертывание и управление ресурсами CICS. В 2015 году четыре основных базовых инструмента CICS (и пакет CICS Optimization Solution Pack для z / OS) были обновлены с выпуском CICS Transaction Server для z / OS 5.3. Четыре основных инструмента CICS: CICS Interdependency Analyzer для z / OS, CICS Deployment Assistant для z / OS, CICS Performance Analyzer для z / OS и CICS Configuration Manager для z / OS.

Программирование

Соображения по программированию

Многопользовательские прикладные программы интерактивно-транзакции должны были быть квази - реентерабельная для того , чтобы поддерживать несколько одновременных транзакции темы . Ошибка программного кода в одном приложении может заблокировать доступ всех пользователей к системе. Модульная конструкция реентерабельных / многоразовых управляющих программ CICS означала, что при разумной «отсечке» несколько пользователей с несколькими приложениями могут быть выполнены на компьютере, имеющем всего 32 КБ дорогостоящей физической памяти на магнитном сердечнике (включая операционную систему ).

Программистам приложений CICS потребовались значительные усилия, чтобы сделать свои транзакции максимально эффективными. Распространенной техникой было ограничение размера отдельных программ не более чем 4096 байтами, или 4 КБ, чтобы CICS мог легко повторно использовать память, занятую любой программой, которая в настоящее время не используется, для другой программы или других требований к хранилищу приложений. Когда виртуальная память была добавлена в версию OS / 360 в 1972 году, стратегия 4K стала еще более важным , чтобы уменьшить подкачки и обмолот непроизводительных накладных расходов ресурсов конкурирующих.

Эффективность скомпилированных программ на языке COBOL и PL / I высокого уровня оставляла желать лучшего. Многие прикладные программы CICS продолжали писать на языке ассемблера даже после того, как стала доступна поддержка COBOL и PL / I.

Из-за того, что аппаратные ресурсы 1960-х и 1970-х были дорогими и дефицитными, между аналитиками по оптимизации систем развивалась конкурентная «игра». Когда код критического пути был идентифицирован, фрагмент кода передавался от одного аналитика к другому. Каждый человек должен был либо (а) уменьшить количество требуемых байтов кода, либо (б) уменьшить количество требуемых циклов ЦП . Молодые аналитики учились у более опытных наставников. В конце концов, когда никто не смог сделать (а) или (б), код сочли оптимизированным, и они перешли к другим фрагментам. Небольшие магазины с одним аналитиком изучали оптимизацию CICS очень медленно (или совсем не учились).

Поскольку прикладные программы могут совместно использоваться многими параллельными потоками, использование статических переменных, встроенных в программу (или использование памяти операционной системы), было ограничено (только по соглашению).

К сожалению, многие из «правил» часто нарушались, особенно программистами на COBOL, которые могли не понимать внутреннего устройства своих программ или не использовать необходимые ограничительные параметры времени компиляции . Это привело к появлению «невозвратного» кода, который часто был ненадежным, что приводило к ложным нарушениям хранилища и сбоям всей системы CICS.

Первоначально весь раздел или область нескольких виртуальных хранилищ (MVS) работали с одним и тем же ключом защиты памяти, включая код ядра CICS. Повреждение программы и повреждение блока управления CICS были частой причиной простоя системы. Ошибка программного обеспечения в одной прикладной программе может привести к перезаписи памяти (кода или данных) одной или всех текущих транзакций приложения. Обнаружение проблемного кода приложения для сложных переходных временных ошибок может быть очень сложной проблемой для аналитика операционной системы.

Эти недостатки сохранялись для нескольких новых выпусков CICS в течение более 20 лет, несмотря на их серьезность и тот факт, что высококачественные навыки CICS пользовались большим спросом и были в дефиците. Они были адресованы в TS V3.3, V4.1 и V5.2 с функциями защиты хранилища, изоляции транзакций и подпространства соответственно, которые используют аппаратные функции операционной системы для защиты кода приложения и данных в одном и том же адресном пространстве, даже если заявки не писались для разделения. Транзакции приложений CICS остаются критически важными для многих коммунальных предприятий, крупных банков и других многомиллиардных финансовых учреждений.

Кроме того, можно обеспечить меру расширенной защиты приложений, выполнив тестирование под управлением программы мониторинга, которая также обеспечивает функции тестирования и отладки.

Макроуровневое программирование

Когда CICS был впервые выпущен, он поддерживал только программы транзакций приложений, написанные на IBM 360 Assembler . Поддержка COBOL и PL / I была добавлена ​​спустя годы. Из-за первоначальной ориентации на ассемблер запросы на сервисы CICS выполнялись с использованием макросов языка ассемблера . Например, запрос на чтение записи из файла, сделанный вызовом макроса к «Программе управления файлами» CICS, может выглядеть следующим образом: 

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

Это привело к более поздней терминологии « макроуровень CICS.»

Когда была добавлена ​​поддержка языков высокого уровня, макросы были сохранены, а код был преобразован предварительным компилятором, который расширил макросы до их эквивалентов операторов COBOL или PL / I CALL. Таким образом, подготовка HLL- приложения фактически представляла собой «двухэтапную» компиляцию  - выходные данные препроцессора передавались компилятору HLL в качестве входных данных.

Замечания по COBOL : в отличие от PL / I, IBM COBOL обычно не предусматривает манипуляции с указателями (адресами). Чтобы позволить программистам COBOL получить доступ к блокам управления CICS и динамическому хранилищу, дизайнеры прибегли к тому, что, по сути, было взломом. Секция связи COBOL обычно использовалась для межпрограммного взаимодействия, например, для передачи параметров. Компилятор генерирует список адресов, каждый из которых называется базовым локатором для связывания (BLL), которые были установлены при входе в вызываемую программу. Первый BLL соответствует первому элементу в разделе «Связь» и так далее. CICS позволяет программисту обращаться к ним и манипулировать ими, передавая адрес списка в качестве первого аргумента программе. Затем BLL могут быть динамически установлены либо CICS, либо приложением, чтобы разрешить доступ к соответствующей структуре в разделе Linkage.

Программирование на уровне команд

В течение 1980-х годов IBM в Hursley Park выпустила версию CICS, которая поддерживала то, что стало известно как «CICS командного уровня», которая по-прежнему поддерживала старые программы, но представила новый стиль API для прикладных программ.

Типичный вызов на уровне команд может выглядеть следующим образом: 

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

Значения, указанные в команде SEND MAPSET, соответствуют именам, используемым в первом макросе DFHMSD в определении карты, приведенном ниже для аргумента MAPSET, и макросе DFHMSI для аргумента MAP. Это предварительно обрабатывается этапом пакетной трансляции перед компиляцией, который преобразует встроенные команды (EXEC) в операторы вызова подпрограммы-заглушки. Итак, подготовка прикладных программ к последующему выполнению все еще требовала двух этапов. Было возможно писать приложения « смешанного режима », используя операторы как макроуровня, так и командного уровня.

Первоначально во время выполнения команды командного уровня были преобразованы с помощью транслятора времени выполнения, «Программа интерфейса EXEC», в старый вызов макроуровня, который затем выполнялся практически неизменными программами ядра CICS. Но когда ядро ​​CICS было переписано для TS V3, EXEC CICS стал единственным способом программирования приложений CICS, поскольку многие из базовых интерфейсов были изменены.

Преобразование времени выполнения

Команда уровня только CICS введена в начале 1990 - х годов предложил ряд преимуществ по сравнению с предыдущими версиями CICS. Однако IBM также отказалась от поддержки прикладных программ макроуровня, написанных для более ранних версий. Это означало, что многие прикладные программы пришлось преобразовать или полностью переписать, чтобы использовать только команды EXEC на уровне команд.

К этому времени во всем мире, возможно, были миллионы программ, которые во многих случаях производились десятилетиями. Их переписывание часто приводило к появлению новых ошибок без обязательного добавления новых функций. Было значительное количество пользователей, которые запускали области, владеющие приложениями (AOR) CICS V2, чтобы продолжать выполнять макрокод в течение многих лет после перехода на V3.

Также было возможно выполнять старые программы макроуровня с помощью программного обеспечения для преобразования, такого как Command CICS от APT International .

Новые стили программирования

Последние улучшения CICS Transaction Server включают поддержку ряда современных стилей программирования.

В CICS Transaction Server версии 5.6 представлена ​​расширенная поддержка Java, позволяющая разработчикам Java работать с облачными технологиями. Например, новый CICS Java API ( JCICSX ) позволяет упростить модульное тестирование с использованием методов имитации и заглушки и может запускаться удаленно на локальной рабочей станции разработчика. Набор артефактов CICS в Maven Central позволяет разработчикам разрешать зависимости Java с помощью популярных инструментов управления зависимостями, таких как Apache Maven и Gradle . Плагины для Maven ( cics-bundle-maven ) и Gradle ( cics-bundle-gradle ) также предоставляются для упрощения автоматизированного построения пакетов CICS с использованием знакомых IDE, таких как Eclipse , IntelliJ IDEA и Visual Studio Code . Кроме того, поддержка z / OS Node.js улучшена для версии 12, обеспечивая более быстрый запуск, улучшенные ограничения кучи по умолчанию, обновления механизма JavaScript V8 и т. Д. Также включена поддержка Jakarta EE 8.

CICS TS 5.5 представила поддержку IBM SDK для Node.js, предоставляя полную среду выполнения JavaScript, серверные API-интерфейсы и библиотеки для эффективного создания высокопроизводительных, высокомасштабируемых сетевых приложений для IBM Z.

В CICS Transaction Server версии 2.1 появилась поддержка Java. Сервер транзакций CICS версии 2.2 поддерживает набор инструментов разработчика программного обеспечения. CICS предоставляет тот же контейнер времени выполнения, что и семейство продуктов IBM WebSphere, поэтому приложения Java EE могут переноситься между CICS и Websphere, и есть общие инструменты для разработки и развертывания приложений Java EE.

Кроме того, CICS делает упор на «обертывание» существующих прикладных программ внутри современных интерфейсов, чтобы давно установленные бизнес-функции могли быть включены в более современные сервисы. К ним относятся интерфейсы WSDL, SOAP и JSON, которые обертывают устаревший код, чтобы веб-приложение или мобильное приложение могло получать и обновлять основные бизнес-объекты, не требуя серьезного переписывания внутренних функций.

Сделки

Транзакция CICS - это набор операций, которые вместе выполняют задачу. Обычно большинство транзакций представляют собой относительно простые задачи, такие как запрос инвентарного списка или ввод дебета или кредита на счет. Основная характеристика транзакции - то, что она должна быть атомарной . На серверах IBM Z CICS легко поддерживает тысячи транзакций в секунду, что делает его основой корпоративных вычислений.

Приложения CICS содержат транзакции, которые могут быть написаны на многих языках программирования , включая COBOL, PL / I, C, C ++, IBM Basic Assembly Language, REXX и Java.

Каждая программа CICS запускается с использованием идентификатора транзакции. Экраны CICS обычно отправляются в виде конструкции, называемой картой, модуля, созданного с помощью макросов ассемблера Basic Mapping Support (BMS) или сторонних инструментов. Экраны CICS могут содержать текст, который выделен, имеет разные цвета и / или мигает в зависимости от типа используемого терминала. Пример того, как карту можно отправить через COBOL, приведен ниже. Конечный пользователь вводит данные, которые становятся доступными для программы после получения карты от CICS. 

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

По техническим причинам аргументы некоторых параметров команды должны быть указаны в кавычках, а некоторые не должны цитироваться, в зависимости от того, на что делается ссылка. Большинство программистов будут кодировать из справочника до тех пор, пока не получат «зависание» или представление о том, какие аргументы цитируются, или они обычно будут использовать «шаблонный шаблон», где у них есть пример кода, который они просто копируют и вставляют, а затем редактируют в изменить значения.

Пример кода карты BMS

Базовая поддержка отображения определяет формат экрана с помощью макросов ассемблера, таких как следующие. Он был собран для создания как физического набора карт  - модуля загрузки в библиотеке загрузки CICS, так и набора символьных карт  - определения структуры или DSECT в PL / I, COBOL, ассемблере и т. Д., Который был скопирован в исходную программу. 

 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

Структура

В среде z / OS установка CICS включает одну или несколько « областей » (обычно называемых «областью CICS»), распределенных по одному или нескольким образам системы z / OS. Хотя он обрабатывает интерактивные транзакции, каждая область CICS обычно запускается как пакетная обработка | пакетное адресное пространство со стандартными операторами JCL : это задание, которое выполняется бесконечно до завершения работы. В качестве альтернативы каждый регион CICS может быть запущен как запущенная задача . Будь то пакетное задание или запущенная задача, регионы CICS могут работать в течение нескольких дней, недель или даже месяцев, прежде чем будут отключены для обслуживания (MVS или CICS). После перезапуска параметр определяет, должен ли запуск быть «холодным» (без восстановления) или «теплым» / «аварийным» (с использованием горячего отключения или перезапуска из журнала после сбоя). Холодный запуск больших регионов CICS с большим количеством ресурсов может занять много времени, так как все определения повторно обрабатываются.

Установки разделены на несколько адресных пространств по множеству причин, например:

  • разделение приложений,
  • разделение функций,
  • избежание ограничений емкости рабочей нагрузки для одного региона, адресного пространства или экземпляра мэйнфрейма в случае z / OS SysPlex.

Типичная установка состоит из нескольких отдельных приложений, составляющих службу. У каждой службы обычно есть несколько «областей-владельцев терминалов» (TOR), которые направляют транзакции в несколько «областей-владельцев приложений» (AOR), хотя возможны и другие топологии. Например, AOR могут не выполнять файловый ввод-вывод. Вместо этого была бы «область владения файлом» (FOR), которая выполняла файловый ввод-вывод от имени транзакций в AOR - учитывая, что в то время файл VSAM мог поддерживать только восстанавливаемый доступ на запись из одного адресного пространства в время.

Но не все приложения CICS используют VSAM в качестве первичного источника данных (или исторически другого хранилища данных с единым адресом, например CA Datacom) - многие используют IMS / DB или Db2 в качестве базы данных и / или MQ в качестве администратора очередей. Во всех этих случаях TOR могут балансировать нагрузку транзакций с наборами AOR, которые затем напрямую используют общие базы данных / очереди. CICS поддерживает двухфазную фиксацию XA между хранилищами данных, поэтому транзакции, охватывающие, например, MQ, VSAM / RLS и Db2, возможны со свойствами ACID.

CICS поддерживает распределенные транзакции с использованием протокола SNA LU6.2 между адресными пространствами, которые могут выполняться в одном или разных кластерах. Это позволяет обновлять ACID в нескольких хранилищах данных за счет взаимодействия распределенных приложений. На практике возникают проблемы с этим, если происходит сбой системы или связи, потому что обработка транзакции (возврат или фиксация) может быть сомнительной, если один из взаимодействующих узлов не восстановился. Таким образом, использование этих средств никогда не было очень распространенным.

Эксплуатация Sysplex

Во время выпуска CICS ESA V3.2, в начале 1990-х годов, IBM столкнулась с проблемой: как заставить CICS использовать новую линейку мэйнфреймов zOS Sysplex .

Sysplex должен был быть основан на CMOS (комплементарном металлическом оксиде кремния), а не на существующем оборудовании ECL (Emitter Coupled Logic). Стоимость масштабирования ECL, уникального для мэйнфреймов, была намного выше, чем у CMOS, которая разрабатывалась компанией keiretsu с крупномасштабными сценариями использования, такими как Sony PlayStation, для снижения удельной стоимости ЦП каждого поколения. ECL также был дорогостоящим для пользователей, потому что ток стока затвора произвел так много тепла, что ЦП пришлось упаковать в специальный модуль, называемый модулем теплопроводности (TCM), который имел поршни инертного газа и нуждался в водопроводе для охлаждения большого объема. вода для охлаждения. Но изначально скорость ЦП CMOS-технологии с воздушным охлаждением была намного ниже, чем у ECL (особенно у производителей клонов мэйнфреймов Amdahl и Hitachi ). Это особенно беспокоило IBM в контексте CICS, поскольку почти все крупнейшие заказчики мэйнфреймов использовали CICS, и для многих из них это была основная рабочая нагрузка мэйнфреймов.

Чтобы достичь такой же общей пропускной способности транзакций на Sysplex, необходимо будет использовать несколько блоков параллельно для каждой рабочей нагрузки, но адресное пространство CICS из-за своей модели программирования полуреентерабельных приложений не может использовать более 1,5 процессоров на одном блоке при время - даже с использованием подзадач MVS. Без этого эти клиенты будут склонны переходить к конкурентам, а не к Sysplex, поскольку они наращивают рабочие нагрузки CICS. Внутри IBM велись серьезные споры о том, будет ли правильным подходом отказаться от восходящей совместимости приложений и перейти к такой модели, как IMS / DC, которая полностью реентерабельна, или расширить подход, принятый заказчиками, для более полного использования мощности одного мэйнфрейма. - с использованием многорегиональной операции (MRO).

В конце концов, второй путь был выбран после того, как с сообществом пользователей CICS были проведены консультации, и они решительно выступили против нарушения восходящей совместимости, учитывая, что в то время у них была перспектива проблемы 2000 года, с которой нужно было бороться, и они не видели ценности в переписывании и тестировании миллионов строк в основном COBOL, PL / 1 или код ассемблера.

Рекомендуемая IBM структура для CICS на Sysplex заключалась в том, что на каждом узле Sysplex размещался как минимум один регион-владелец терминала CICS, который отправлял транзакции во многие регионы-владельцы приложений (AOR), распределенные по всему Sysplex. Если этим приложениям требовался доступ к общим ресурсам, они либо использовали хранилище данных с использованием Sysplex (например, Db2 или IMS / DB ), либо концентрировали, путем доставки функций, запросы ресурсов в отдельные для каждого ресурса области владения ресурсами (ROR), включая File Области-владельцы (FOR) для таблиц данных VSAM и CICS, области-владельцы очередей (QOR) для MQ , временные данные CICS (TD) и временное хранилище CICS (TS). Это позволило сохранить совместимость для унаследованных приложений за счет сложности эксплуатации многих регионов CICS и управления ими.

В последующих выпусках и версиях CICS могла использовать новые возможности использования Sysplex в VSAM / RLS, MQ для zOS и размещать свои собственные таблицы данных, TD и ресурсы TS в спроектированном диспетчере общих ресурсов для Sysplex -> Coupling Facility. или CF, без необходимости в большинстве ROR. CF обеспечивает отображение ресурсов, включая общую временную базу, буферные пулы, блокировки и счетчики с аппаратными средствами обмена сообщениями, что сделало совместное использование ресурсов в Sysplex более эффективным, чем опрос, и надежным (с использованием полусинхронизированного резервного CF для использования в случае отказ).

К этому времени в линейке CMOS были отдельные блоки, мощность которых превышала мощность, доступную для самого быстрого блока ECL с большим количеством процессоров на ЦП, и когда они были соединены вместе, 32 или более узлов могли бы масштабировать на два порядка больше общей мощности для разовая рабочая нагрузка. Например, к 2002 году Charles Schwab запускал «MetroPlex», состоящий из резервной пары его мэйнфреймов Sysplexes в двух местах в Фениксе, штат Аризона, каждый с 32 узлами, управляемыми одной общей рабочей нагрузкой CICS / DB / 2, для поддержки огромного объема запросы веб-клиентов до доткомов и пузырей .

Эта более дешевая, гораздо более масштабируемая технологическая база CMOS и огромные инвестиционные затраты, связанные с необходимостью как перехода к 64-битной адресации, так и независимого создания клонированных функций CF, одного за другим вытеснили производителей клонов мэйнфреймов IBM.

Восстановление / перезагрузка CICS

Целью восстановления / перезапуска в CICS является минимизация и, если возможно, устранение ущерба, нанесенного онлайн-системе в случае сбоя, чтобы сохранить целостность системы и данных. Если регион CICS был отключен вместо сбоя, он выполнит «теплый» запуск, используя контрольную точку, записанную при завершении работы. Область CICS также может быть принудительно запущена на «холодный» запуск, который перезагружает все определения и стирает журнал, оставляя ресурсы в том состоянии, в котором они находятся.

В рамках CICS ниже перечислены некоторые ресурсы, которые считаются восстанавливаемыми. Если кто-то хочет, чтобы эти ресурсы можно было восстановить, в соответствующих определениях CICS должны быть указаны специальные параметры:

  • Файлы VSAM
  • Таблицы данных, поддерживаемые CMT CICS
  • Внутрираздельный TDQ
  • Очередь временного хранилища во вспомогательной памяти
  • Сообщения ввода-вывода из / в транзакции в сети VTAM
  • Другие ресурсы базы данных / очередей, подключенные к CICS, которые поддерживают протокол двухфазной фиксации XA (например, IMS / DB, Db2, VSAM / RLS)

CICS также предлагает широкие возможности восстановления / перезапуска для пользователей, чтобы установить собственные возможности восстановления / перезапуска в своей системе CICS. Обычно используемые средства восстановления / перезапуска включают:

  • Динамический откат транзакции (DTB)
  • Автоматический перезапуск транзакции
  • Восстановление ресурсов с использованием системного журнала
  • Восстановление ресурсов с помощью журнала
  • Перезагрузка системы
  • Расширенное средство восстановления

Составные части

Каждый регион CICS включает одну главную задачу, на которой выполняется каждая транзакция, хотя некоторые службы, такие как доступ к данным Db2, используют другие задачи (TCB). Внутри региона транзакции выполняются в многозадачном режиме  - ожидается, что они будут хорошо себя вести и уступят центральному процессору, а не ждать. Сервисы CICS обрабатывают это автоматически.

Каждой уникальной « Задаче » или транзакции CICS при запуске выделяется собственная динамическая память, и последующие запросы на дополнительную память обрабатывались вызовом «Программы управления памятью» (часть ядра CICS или « ядра »), которая является аналог операционной системы .

Система CICS состоит из онлайн- ядра , программ пакетной поддержки и сервисов приложений.

Ядро

Исходное ядро ​​CICS состояло из ряда функциональных модулей, написанных на ассемблере 370 до V3:

  • Программа управления задачами (KCP)
  • Программа управления хранением (SCP)
  • Программа управления программой (PCP)
  • Программа управления прерыванием программы (PIP)
  • Программа контроля интервалов (ICP)
  • Программа управления дампом (DCP)
  • Программа управления терминалами (TCP)
  • Программа управления файлами (FCP)
  • Программа управления переходными данными (TDP)
  • Программа контроля временного хранения (TSP)

Начиная с версии V3, ядро ​​CICS было переписано в структуру ядра и домена с использованием языка IBM PL / AS, который скомпилирован в ассемблер.

Предыдущая структура не требовала разделения функций и поэтому имела много межпрограммных зависимостей, которые приводили к ошибкам, если не был проведен исчерпывающий анализ кода. Новая структура была более модульной и такой устойчивой, потому что ее было легче изменить без последствий. Первые домены часто строились с именем предыдущей программы, но без буквы «P» в конце. Например, домен управления программой (DFHPC) или переходный домен данных (DFHTD). Ядро работало как переключатель для междоменных запросов - изначально это оказалось дорогостоящим для часто вызываемых доменов (таких как Trace), но с использованием макросов PL / AS эти вызовы были встроены без ущерба для дизайна отдельного домена.

В более поздних версиях были добавлены полностью переработанные домены, такие как домен регистрации DFHLG и домен транзакции DFHTM, которые заменили программу управления журналом (JCP).

Программы поддержки

В дополнение к онлайн-функциям CICS имеет несколько программ поддержки, которые выполняются как пакетные задания.

  • Препроцессор языка высокого уровня (макро)
  • Переводчик командного языка
  • Утилита дампа - печатает отформатированные дампы, созданные CICS Dump Management.
  • Утилита трассировки - форматирует и печатает выходные данные трассировки CICS
  • Утилита форматирования журнала - печатает отформатированный дамп области CICS в случае ошибки

Сервисы приложений

Следующие компоненты CICS поддерживают разработку приложений.

  • Базовая поддержка отображения (BMS) обеспечивает независимый от устройства ввод и вывод терминала
  • Поддержка APPC, обеспечивающая поддержку API LU6.1 и LU6.2 для совместной работы распределенных приложений, поддерживающих двухфазную фиксацию.
  • Программа обмена данными (DIP) обеспечивает поддержку программируемых устройств IBM 3770 и IBM 3790
  • Совместимость с 2260 позволяет программам, написанным для устройств отображения IBM 2260, работать на дисплеях 3270.
  • Программа интерфейса EXEC - программа-заглушка, которая преобразует вызовы, сгенерированные EXEC CICSкомандами, в вызовы функций CICS.
  • Встроенные функции - поиск по таблице, фонетическое преобразование, проверка полей, редактирование полей, проверка битов, форматирование ввода, взвешенное извлечение

Произношение

В разных странах разное произношение

  • В IBM ( в частности , Tivoli ) он упоминается как / к ɪ к s / .
  • В США, это более обычно произносится произнося каждую букву / ˌ s ˙I ˌ aɪ ˌ s ˙I ɛ s / .
  • В Австралии, Бельгии, Канаде, Гонконге, Великобритании и некоторых других странах, она выражена / к ɪ к s / .
  • В Финляндии произносится [кикс]
  • Во Франции произносится [se.i.se.ɛs] .
  • В Германии, Австрии и Венгрии произносится [ˈTsɪks] и, реже,[ˈKɪks] .
  • В Греции произносится как кикс .
  • В Индии это ярко выраженный пинок .
  • В Иране это ярко выражено кайфом .
  • В Израиле произносится как CICS .
  • В Италии произносится [ˈTʃiks] .
  • В Польше произносится [ˈKʲiks] .
  • В Португалии и Бразилии произносится [ˈSiks] .
  • В России произносится как кикс .
  • В Словении произносится как кикс .
  • В Испании произносится [ˈΘiks] .
  • В Швеции это ярко выражено кайфом .
  • В Израиле это ярко выражено кайфом .
  • В Уганде это ярко выражено кайфом .
  • В Турции произносится как кикс .

Смотрите также

использованная литература

внешние ссылки