IBM CICS (Customer Information Control System) — это семейство серверов приложений с поддержкой смешанного языка, которые обеспечивают онлайн-управление транзакциями и подключение приложений на мэйнфреймах IBM под управлением z/OS и z/VSE .
Продукты семейства CICS разработаны как промежуточное программное обеспечение и поддерживают быструю обработку больших объемов онлайн-транзакций . Транзакция CICS — это единица обработки, инициированная одним запросом, который может повлиять на один или несколько объектов. [2] Эта обработка обычно является интерактивной (ориентированной на экран), но возможны фоновые транзакции.
CICS Transaction Server (CICS TS) стоит во главе семейства CICS и предоставляет сервисы, которые расширяют или заменяют функции операционной системы. Эти службы могут быть более эффективными, чем общие службы операционной системы, а также более простыми в использовании для программистов, особенно в отношении связи с различными терминальными устройствами.
Приложения, разработанные для CICS, могут быть написаны на различных языках программирования и использовать языковые расширения, поставляемые CICS, для взаимодействия с такими ресурсами, как файлы, соединения с базами данных , терминалы, или для вызова таких функций, как веб-службы. CICS управляет всей транзакцией таким образом, что в случае сбоя какой-либо части транзакции все восстанавливаемые изменения могут быть отменены.
Хотя CICS TS пользуется наибольшим авторитетом среди крупных финансовых учреждений, таких как банки и страховые компании, сообщается, что многие компании из списка Fortune 500 и государственные учреждения используют CICS. Другие, более мелкие предприятия также могут использовать CICS TS и другие продукты семейства CICS. CICS регулярно можно обнаружить «за кулисами», например, в банковских приложениях, системах банкоматов , системах управления промышленным производством, страховых приложениях и во многих других типах интерактивных приложений.
Недавние усовершенствования CICS TS включают новые возможности для улучшения работы разработчиков, включая выбор API, платформ, редакторов и инструментов сборки, и в то же время предоставляют обновления в ключевых областях безопасности, отказоустойчивости и управления. В более ранних, последних выпусках CICS TS предоставлялась поддержка веб-служб и Java , обработки событий , каналов Atom и интерфейсов RESTful .
CICS предшествовала более ранняя однопоточная система обработки транзакций IBM MTCS . Позже был разработан «мост MTCS-CICS», позволяющий выполнять эти транзакции под CICS без изменения исходных прикладных программ. Система управления информацией о клиентах IBM (CICS), впервые разработанная совместно с Michigan Bell в 1966 году. [3] Бен Риггинс был системным инженером IBM в компании Virginia Electric Power Co., когда ему пришла в голову идея онлайн-системы. [4]
Первоначально CICS была разработана в США в Центре разработки IBM в Дес-Плейнсе, штат Иллинойс , начиная с 1966 года для удовлетворения потребностей предприятий коммунального хозяйства. Первый продукт CICS был анонсирован в 1968 году и назывался « Система управления информацией о клиентах коммунальных предприятий » или PU-CICS. Сразу стало ясно, что он применим во многих других отраслях, поэтому префикс Public Utility был исключен с выпуском первого выпуска программного продукта CICS 8 июля 1969 года, вскоре после появления системы управления базами данных IMS .
В течение следующих нескольких лет CICS разрабатывалась в Пало-Альто и считалась менее важным, «меньшим» продуктом, чем IMS, которую IBM тогда считала более стратегически важной. Однако давление клиентов поддерживало его. Когда в 1974 году IBM решила прекратить разработку CICS и сконцентрироваться на IMS, ответственность за разработку CICS взяла на себя компания IBM в Херсли в Великобритании, которая только что прекратила работу над компилятором PL/I и поэтому знала многие из них. клиентов как CICS. Основная работа по разработке продолжается в Херсли и сегодня, наряду с вкладом лабораторий Индии, Китая, России, Австралии и США.
Первоначально CICS поддерживала только несколько устройств марки IBM, таких как терминал на базе пишущей машинки IBM 2741 Selectric (мяч для гольфа) 1965 года. Позже широко использовались видеотерминалы IBM 2260 и IBM 3270 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 Program 1965 года , используемую компьютерной системой бронирования American Airlines Sabre ) для высокоскоростного доступа к данным. и обновление информации о клиентах для их телефонных операторов (не дожидаясь ночной пакетной обработки систем перфокарт).
Когда CICS был доставлен в Amoco с поддержкой Teletype Model 33 ASR, это привело к сбою всей операционной системы OS / 360 (включая прикладные программы, не относящиеся к CICS). Большую часть программы управления терминалами CICS (TCP — сердце CICS) и часть OS/360 пришлось кропотливо перепроектировать и переписать компании Amoco Production Company в Талсе, Оклахома. Затем он был возвращен 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. [5]
В начале 1970 года ряд первоначальных разработчиков, в том числе Бен Риггинс (главный архитектор ранних выпусков), переехали в Калифорнию и продолжили разработку CICS в Центре разработки IBM в Пало-Альто . Руководители IBM не признавали ценность программного обеспечения как продукта, приносящего доход, до тех пор, пока федеральный закон не потребовал разделения программного обеспечения . В 1980 году руководители IBM не прислушались к настойчивым предложениям Бена Риггинса о том, что IBM должна предоставить свою собственную операционную систему на базе EBCDIC и микропроцессорную микросхему для использования в персональном компьютере IBM в качестве интеллектуального терминала CICS (вместо несовместимого чипа Intel, и незрелая версия Microsoft 1980 DOS на основе ASCII ).
Из-за ограниченной мощности даже больших процессоров той эпохи при каждой установке CICS требовалось собрать исходный код для всех системных модулей CICS после завершения процесса, аналогичного генерации системы (sysgen), называемого CICSGEN , для установления значений для условной сборки. -языковые высказывания. Этот процесс позволял каждому клиенту исключить поддержку со стороны самой CICS для любой функции, которую он не собирался использовать, например, поддержку устройств для типов терминалов, которые не используются.
CICS обязана своей ранней популярностью относительно эффективной реализации, когда оборудование было очень дорогим, многопоточной архитектуре обработки, относительной простоте разработки приложений для транзакций в реальном времени на основе терминалов, а также многочисленным вкладам клиентов с открытым исходным кодом, включая как отладку, так и функции. улучшение.
Часть CICS была формализована с использованием нотации Z в 1980-х и 1990-х годах в сотрудничестве с Вычислительной лабораторией Оксфордского университета под руководством Тони Хоара . Эта работа получила Королевскую премию за технологические достижения. [6]
В 1986 году IBM объявила о поддержке CICS файловых служб, ориентированных на записи, определенных архитектурой распределенного управления данными (DDM). Это позволило программам на удаленных, подключенных к сети компьютерах создавать, управлять и получать доступ к файлам, которые ранее были доступны только в средах обработки транзакций CICS/MVS и CICS/VSE. [7]
В новых версиях CICS поддержка DDM удалена. Поддержка компонента DDM в CICS z/OS была прекращена в конце 2003 года и удалена из CICS для z/OS начиная с версии 5.2. [8] В CICS TS для z/VSE поддержка DDM была стабилизирована на уровне V1.1.1, с объявленным намерением прекратить ее в будущем выпуске. [9] В CICS для z/VSE 2.1 и более поздних версиях CICS/DDM не поддерживается. [10]
CICS Transaction Server впервые представил собственный HTTP- интерфейс в версии 1.2 вместе с технологией Web Bridge для обертывания программ на базе терминала с зеленым экраном в HTML-фасад. API CICS для веб-сайтов и документов были усовершенствованы в 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, а также API-интерфейсы HTTP на стороне клиента для исходящей связи. Эти двойные технологии позволили упростить интеграцию компонентов CICS с другими корпоративными приложениями и получили широкое распространение. Были включены инструменты для использования традиционных программ CICS, написанных на таких языках, как COBOL , и преобразования их в веб-службы, определенные WSDL, с небольшими изменениями в программе или без них. Эта технология регулярно улучшалась по сравнению с последующими выпусками CICS.
В CICS TS V4.1 и V4.2 были внесены дальнейшие улучшения в возможности подключения к Интернету, включая встроенную реализацию протокола публикации Atom .
Многие из новых веб-технологий были доступны для более ранних выпусков CICS с использованием моделей доставки, отличных от традиционного выпуска продукта. Это позволило ранним пользователям предоставить конструктивную обратную связь, которая могла повлиять на окончательный дизайн интегрированной технологии. Примеры включают предварительную версию технологии Soap for 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 возможен из удаленных систем, а также возможен доступ к удаленным системам; личность пользователя и контекст транзакции могут распространяться; API-интерфейсы RESTful можно создавать и управлять ими; устройства, пользователи и серверы могут взаимодействовать с CICS, используя технологии, основанные на стандартах; а среда IBM WebSphere Liberty в CICS способствует быстрому внедрению новых технологий.
К январю 1985 года консалтинговая компания, основанная в 1969 году, разработавшая «массивные онлайн-системы» для Hilton Hotels, FTD Florists, Amtrak и Budget Rent-a-Car, объявила о том, что стало MicroCICS . [11] Первоначальное внимание уделялось IBM XT/370 и IBM AT/370 . [12]
Хотя когда упоминается CICS, люди обычно имеют в виду CICS Transaction Server, семейство CICS относится к портфелю серверов транзакций, соединителей (называемых CICS Transaction Gateway ) и инструментов CICS.
CICS на распределенных платформах, а не на мэйнфреймах, называется IBM TXSeries . TXSeries — это промежуточное программное обеспечение для распределенной обработки транзакций. Он поддерживает приложения C, C++, COBOL, Java™ и PL/I в облачных средах и традиционных центрах обработки данных. TXSeries доступен на платформах AIX , Linux x86, Windows , Solaris и HP-UX . [13] CICS также доступен в других операционных системах, особенно в IBM i и OS/2 . Реализация z/OS (т. е. CICS Transaction Server для z/OS) на сегодняшний день является наиболее популярной и значимой.
Ранее для VM/CMS были доступны две версии CICS , но с тех пор производство обеих было прекращено. В 1986 году IBM выпустила CICS/CMS , [14] [11] , которая представляла собой однопользовательскую версию CICS, предназначенную для использования в целях разработки, приложения позже переносились в систему MVS или DOS/VS для производственного выполнения. [15] [16] Позже, в 1988 году, IBM выпустила CICS/VM . [17] [18] CICS/VM предназначался для использования на IBM 9370 , мейнфрейме начального уровня, предназначенном для использования в ведомствах; IBM позиционировала CICS/VM, работающую на мэйнфреймах департаментов или филиалов, для использования в сочетании с центральным мэйнфреймом, на котором работает CICS для MVS. [19]
Обеспечение, управление и анализ систем и приложений CICS обеспечивается CICS Tools. Сюда входит управление производительностью, а также развертывание и управление ресурсами CICS. В 2015 году четыре основных базовых инструмента CICS (и пакет решений по оптимизации CICS для z/OS) были обновлены с выпуском CICS Transaction Server для z/OS 5.3. Четыре основных инструмента CICS: анализатор взаимозависимости CICS для z/OS, помощник по развертыванию CICS для z/OS, анализатор производительности CICS для z/OS и диспетчер конфигурации CICS для z/OS.
CICS Transaction Server для z/OS использовал следующие номера выпусков:
Многопользовательские прикладные программы с интерактивными транзакциями должны были быть квазиреентерабельными, чтобы поддерживать несколько параллельных потоков транзакций . Ошибка программного кода в одном приложении может заблокировать доступ всех пользователей к системе. Модульная конструкция реентерабельных/многоразовых управляющих программ CICS означала, что при разумном «обрезке» несколько пользователей с несколькими приложениями могли выполняться на компьютере всего с 32 КБ дорогой физической памяти на магнитных сердечниках (включая операционную систему ).
Программистам приложений CICS потребовались значительные усилия, чтобы сделать свои транзакции максимально эффективными. Распространенным методом было ограничение размера отдельных программ не более чем 4096 байтами или 4 КБ, чтобы CICS мог легко повторно использовать память, занимаемую любой программой, которая в данный момент не используется, для хранения другой программы или других приложений. Когда в 1972 году в версии OS/360 была добавлена виртуальная память , стратегия 4K стала еще более важной для уменьшения подкачки и устранения непроизводительных накладных расходов, связанных с конкуренцией за ресурсы.
Эффективность скомпилированных программ на языках высокого уровня COBOL и PL/I оставляла желать лучшего. Многие прикладные программы CICS продолжали писаться на языке ассемблера даже после того, как стала доступна поддержка COBOL и PL/I.
В 1960-х и 1970-х годах аппаратные ресурсы были дорогими и скудными, среди аналитиков системной оптимизации возникла конкурентная «игра». Когда был определен код критического пути , фрагмент кода передавался от одного аналитика к другому. Каждый человек должен был либо (а) уменьшить количество требуемых байтов кода, либо (б) уменьшить количество требуемых циклов ЦП . Более молодые аналитики учились на опыте более опытных наставников. В конце концов, когда никто не смог выполнить (а) или (б), код посчитали оптимизированным, и они перешли к другим фрагментам. Небольшие предприятия, в которых работает только один аналитик, изучали оптимизацию CICS очень медленно (или не учились вообще).
Поскольку прикладные программы могли совместно использоваться многими параллельными потоками, использование статических переменных , встроенных в программу (или использование памяти операционной системы), было ограничено (только по соглашению).
К сожалению, многие «правила» часто нарушались, особенно программистами на COBOL, которые могли не понимать внутреннего устройства своих программ или не использовать необходимые ограничительные параметры времени компиляции . Это приводило к появлению «неповторного» кода, который часто был ненадежным, что приводило к ложным нарушениям памяти и сбоям всей системы CICS.
Первоначально весь раздел или регион Multiple Virtual Storage (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 и т.д.
Это привело к появлению более поздней терминологии « CICS макроуровня ».
Когда была добавлена поддержка языка высокого уровня, макросы были сохранены, а код был преобразован прекомпилятором, который расширил макросы до их эквивалентов операторов COBOL или PL/I CALL. Таким образом, подготовка приложения HLL фактически представляла собой «двухэтапную» компиляцию : выходные данные препроцессора подавались в компилятор HLL в качестве входных данных.
Замечания по COBOL : в отличие от PL/I, IBM COBOL обычно не обеспечивает манипулирование указателями (адресами). Чтобы предоставить программистам COBOL доступ к блокам управления CICS и динамическому хранилищу, дизайнеры прибегли к тому, что по сути было хаком. Раздел COBOL Linkage обычно использовался для межпрограммного взаимодействия, например передачи параметров. Компилятор генерирует список адресов, каждый из которых называется базовым локатором для связи (BLL), который был установлен при входе в вызываемую программу. Первый BLL соответствует первому элементу раздела связей и так далее. CICS позволяет программисту получать доступ к ним и манипулировать ими, передавая адрес списка в качестве первого аргумента программе. Затем BLL могут быть установлены динамически либо с помощью CICS, либо с помощью приложения, чтобы обеспечить доступ к соответствующей структуре в разделе Linkage. [35]
В 1980-х годах компания IBM в Херсли-Парке выпустила версию CICS, которая поддерживала то, что стало известно как «CICS командного уровня», которая по-прежнему поддерживала старые программы, но представила новый стиль API для прикладных программ.
Типичный вызов уровня команды может выглядеть следующим образом:
EXEC CICS ОТПРАВИТЬ 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 . [36]
Последние усовершенствования CICS Transaction Server включают поддержку ряда современных стилей программирования.
В CICS Transaction Server версии 5.6 [37] была представлена расширенная поддержка 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 . Кроме того, в версии 12 улучшена поддержка Node.js z/OS, обеспечивающая более быстрый запуск, улучшенные ограничения кучи по умолчанию, обновления движка 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, Rexx и Java.
Каждая программа CICS запускается с использованием идентификатора транзакции. Экраны CICS обычно отправляются в виде конструкции, называемой картой, модуля, созданного с помощью макросов ассемблера Basic Mapping Support (BMS) или сторонних инструментов. Экраны CICS могут содержать текст, который выделен, имеет разные цвета и/или мигает в зависимости от типа используемого терминала. Ниже приведен пример отправки карты через COBOL. Конечный пользователь вводит данные, которые становятся доступными для программы после получения карты от CICS.
EXEC CICS ПОЛУЧИТЬ MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) INTO ( OUR-MAP ) END-EXEC . По техническим причинам аргументы некоторых параметров команды должны быть заключены в кавычки, а некоторые не должны заключаться в кавычки, в зависимости от того, на что ссылаются. Большинство программистов будут писать код из справочника до тех пор, пока не поймут, какие аргументы заключаются в кавычки, или они обычно используют «стандартный шаблон», где у них есть пример кода, который они просто копируют и вставляют, а затем редактируют в изменить значения.
Базовая поддержка сопоставления определяет формат экрана с помощью макросов ассемблера, таких как следующие. Он был собран для создания как набора физических карт (загрузочный модуль в библиотеке загрузки CICS), так и набора символических карт (определение структуры или DSECT в PL/I, COBOL, ассемблере и т. д.), который был скопирован в исходную программу. [38]
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 - ОТМЕНА ' * ТИП DFHMSD = КОНЕЧНЫЙ КОНЕЦ В среде z/OS установка CICS включает один или несколько « регионов » (обычно называемых «регионом CICS») [39] , распределенных по одному или нескольким образам системы z/OS. Хотя он обрабатывает интерактивные транзакции, каждый регион CICS обычно запускается как пакетное адресное пространство со стандартными операторами JCL : это задание выполняется неопределенно долго до завершения работы. Альтернативно, каждый регион CICS может быть запущен как запущенная задача . Независимо от того, является ли пакетное задание или запущенная задача, регионы CICS могут работать в течение нескольких дней, недель или даже месяцев, прежде чем завершаться для обслуживания (MVS или CICS). При перезапуске параметр определяет, должен ли запуск быть «Холодным» (без восстановления) или «Теплым»/«Аварийным» (с использованием «теплого» завершения работы или перезапуска из журнала после сбоя). Холодный запуск крупных регионов CICS с большим количеством ресурсов может занять много времени, поскольку все определения обрабатываются повторно.
Установки делятся на несколько адресных пространств по самым разным причинам, например:
Типичная установка состоит из ряда отдельных приложений, составляющих службу. Каждая служба обычно имеет несколько «регионов владения терминалами» (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 нескольких хранилищ данных за счет взаимодействия распределенных приложений. На практике с этим возникают проблемы, если происходит сбой системы или связи, поскольку выполнение транзакции (откат или фиксация) может оказаться под вопросом, если один из взаимодействующих узлов не восстановился. Таким образом, использование этих средств никогда не было широко распространенным.
Во времена CICS ESA V3.2, в начале 1990-х годов, IBM столкнулась с проблемой, как заставить CICS использовать новую линейку мэйнфреймов zOS Sysplex .
Sysplex должен был быть основан на CMOS (дополнительный металлооксид кремния), а не на существующем оборудовании ECL (логика, связанная с эмиттером). Стоимость масштабирования ECL, уникального для мэйнфреймов, была намного выше, чем CMOS, который разрабатывался кейрэцу с сценариями большого объема использования, такими как Sony PlayStation, для снижения удельной стоимости процессоров каждого поколения. Использование ECL также было дорогостоящим для пользователей, потому что ток стока затвора выделял так много тепла, что ЦП пришлось упаковать в специальный модуль, называемый модулем теплопроводности (TCM [40] ), который имел поршни из инертного газа и нуждался в водопроводе с высокой температурой. объем охлажденной воды, подлежащей охлаждению. Однако скорость ЦП технологии CMOS с воздушным охлаждением изначально была намного медленнее, чем у ECL (особенно у блоков, доступных от производителей клонов мэйнфреймов Amdahl и Hitachi ). Это особенно беспокоило IBM в контексте CICS, поскольку почти все крупнейшие заказчики мэйнфреймов использовали CICS, и для многих из них это была основная рабочая нагрузка мэйнфреймов.
Чтобы достичь одинаковой общей пропускной способности транзакций в Sysplex, для каждой рабочей нагрузки необходимо будет использовать несколько блоков параллельно. Однако адресное пространство CICS из-за своей квазиреентерабельной модели прикладного программирования не могло одновременно использовать более 1,5 процессоров на одном компьютере – даже с использованием подзадач MVS. Без расширенного параллелизма клиенты будут склонны переходить к конкурентам IBM, а не использовать Sysplex при масштабировании рабочих нагрузок CICS. Внутри IBM шли серьезные споры о том, будет ли правильным подходом отказаться от восходящей совместимости приложений и перейти к такой модели, как IMS/DC , которая является полностью реентерабельной, или же расширить подход, принятый клиентами, для более полного использования мощности одного мэйнфрейма. – с использованием многорегиональной работы (MRO).
В конце концов, после консультаций с сообществом пользователей CICS, был принят второй путь. Сообщество яростно выступало против нарушения восходящей совместимости, учитывая, что в то время у них была перспектива 2000 года, и они не видели смысла в переписывании и тестировании миллионов строк, главным образом, COBOL, PL/I или ассемблерного кода.
Рекомендованная IBM структура для CICS в Sysplex заключалась в том, что по крайней мере один регион владения терминалом CICS размещался на каждом узле Sysplex, который отправлял транзакции во множество регионов владения приложениями (AOR), разбросанных по всему Sysplex. Если этим приложениям требовался доступ к общим ресурсам, они либо использовали хранилище данных, использующее Sysplex (например, IBM Db2 или IMS/DB ), либо концентрировали посредством доставки функций запросы ресурсов в отдельные для каждого ресурса регионы владения ресурсами (ROR), включая Регионы владения файлами (FOR) для таблиц данных VSAM и CICS, регионы владения очередями (QOR) для MQ , временные данные CICS (TD) и временное хранилище CICS (TS). Это позволило сохранить совместимость с устаревшими приложениями за счет усложнения настройки и управления многими регионами CICS.
В последующих выпусках и версиях CICS смогла использовать новые возможности использования Sysplex в VSAM/RLS, [41] MQ для zOS [42] и поместила свои собственные таблицы данных, ресурсы TD и TS в спроектированный менеджер общих ресурсов для Sysplex -> Coupling Facility или CF, что позволяет обойтись без большинства ROR. CF обеспечивает отображение ресурсов, включая общую временную базу, пулы буферов, блокировки и счетчики, а также аппаратные средства обмена сообщениями, которые сделали совместное использование ресурсов в Sysplex более эффективным, чем опрос, и надежным (с использованием полусинхронизированного резервного CF для использования в случае отказ).
К этому времени в линейке CMOS были отдельные блоки, мощность которых превышала мощность самого быстрого блока ECL с большим количеством процессоров на процессор. Когда они будут объединены вместе, 32 или более узлов смогут масштабировать на два порядка большую общую мощность для одной рабочей нагрузки. Например, к 2002 году Чарльз Шваб использовал «MetroPlex», состоящую из резервной пары сисплексов мэйнфреймов в двух местах в Фениксе, штат Аризона, каждый из которых имел 32 узла, управляемых одной общей рабочей нагрузкой CICS/DB/2 для поддержки огромного объема запросы веб-клиента до dotcom-bubble .
Эта более дешевая и гораздо более масштабируемая технологическая база CMOS, а также огромные инвестиционные затраты, связанные с необходимостью как перехода к 64-битной адресации, так и независимого создания клонированных функций CF, вынудили производителей клонов мэйнфреймов IBM одного за другим покинуть бизнес. [43] [44]
Целью восстановления/перезапуска CICS является минимизация и, если возможно, устранение ущерба, нанесенного онлайн-системе в случае сбоя, чтобы сохранить целостность системы и данных. [45] Если регион CICS был отключен, а не произошел сбой, он выполнит «теплый» запуск, используя контрольную точку, записанную при завершении работы. Для региона CICS также можно принудительно запустить «холодный» запуск, при котором все определения перезагружаются и журнал удаляется, оставляя ресурсы в том состоянии, в котором они находятся.
В соответствии с CICS ниже приведены некоторые ресурсы, которые считаются восстанавливаемыми. Если вы хотите, чтобы эти ресурсы можно было восстановить, в соответствующих определениях CICS необходимо указать специальные параметры:
CICS также предлагает обширные возможности восстановления/перезапуска, позволяющие пользователям установить собственные возможности восстановления/перезапуска в своей системе CICS. Обычно используемые средства восстановления/перезапуска включают в себя:
Каждый регион CICS включает в себя одну основную задачу, над которой выполняется каждая транзакция, хотя некоторые службы, такие как доступ к данным IBM Db2, используют другие задачи (TCB). Внутри региона транзакции являются совместными многозадачными — ожидается, что они будут хорошо себя вести и будут использовать ресурсы ЦП, а не ждать. Службы CICS обрабатывают это автоматически.
Каждой уникальной « задаче » или транзакции CICS при запуске выделяется собственная динамическая память , а последующие запросы на дополнительную память обрабатываются вызовом «программы управления хранилищем» (часть ядра или « ядра » CICS), которая аналог операционной системы .
Система CICS состоит из онлайн- ядра , программ пакетной поддержки и служб приложений. [46]
Исходное ядро CICS состояло из ряда функциональных модулей, написанных на ассемблере 370 до V3:
Начиная с версии V3, ядро CICS было переписано в структуру ядра и домена с использованием языка IBM PL/AS , который компилируется в ассемблер.
Предыдущая структура не обеспечивала разделения задач и поэтому имела множество межпрограммных зависимостей, которые приводили к ошибкам, если не был проведен исчерпывающий анализ кода. Новая структура была более модульной и устойчивой, поскольку ее было легче изменить без каких-либо последствий. Первые домены часто создавались с названием предыдущей программы, но без завершающей буквы «P». Например, домен управления программой (DFHPC) или домен переходных данных (DFHTD). Ядро работало как переключатель междоменных запросов – первоначально это оказалось дорогостоящим для часто вызываемых доменов (таких как Trace), но благодаря использованию макросов PL/AS эти вызовы были встроены без ущерба для отдельного дизайна домена.
В более поздних версиях были добавлены полностью переработанные домены, такие как домен ведения журнала DFHLG и домен транзакций DFHTM, которые заменили программу управления журналом (JCP).
В дополнение к онлайн-функциям CICS имеет несколько программ поддержки, которые выполняются в виде пакетных заданий. [47] : стр. 34–35.
Следующие компоненты CICS поддерживают разработку приложений. [47] : стр. 35–37.
EXEC CICSкомандами, в вызовы функций CICS.В разных странах произношение разное [48]
CICS DDM больше не доступен от IBM, и поддержка была прекращена с 31 декабря 2003 г. CICS DDM больше не доступен в CICS TS, начиная с версии 5.2.
Поддержка управления распределенными данными CICS (DDM) стабилизирована в CICS TS для VSE/ESA V1.1.1.
В будущем выпуске CICS TS для z/VSE IBM намерена прекратить поддержку CICS DDM.
Управление распределенными данными CICS (CICS/DDM) не поддерживается CICS TS for z/VSE V2.1.
Семейство персональных компьютеров IBM XT/370.