Он появился еще в 1959 году и, возможно, выглядит странно по сравнению с современными языками, но COBOL по-прежнему способствует развитию бизнеса, сообщает Майк Бедфорд.
Вслед за недавним обзором нескольких классических языков программирования, большинство из которых в значительной степени забыты или выглядят несколько странными, в прошлом месяце мы погружались в особенности языка Fortran. Несмотря на свой возраст, этот язык по-прежнему хорошо знаком программистам, и, хотя в своем первоначальном виде он был примитивным, назвать его необычным было бы неправильно. На самом деле, он оказал влияние на разработку некоторых наиболее популярных сегодня языков. Мало того, он и сегодня играет важную роль. Однако Fortran не одинок в этом отношении.
На этот раз мы рассмотрим еще один древний язык, продолжающий играть ключевую роль во многих областях. И чтобы проиллюстрировать что он действительно принадлежит к давно ушедшей эпохе, достаточно назвать имена производителей компьютеров, участвовавших в его совместной разработке. Конечно, свою роль сыграла компания IBM, но и Burroughs, Minneapolis-Honeywell, RCA, Sperry-Rand, Sylvania - все эти компании сейчас уже мало кто помнит. Этот язык называется COBOL - COmmon Business Oriented Language, и хотя он всего на два года моложе Fortran, впервые увидевший свет в 1959 году, в большинстве других аспектов он не может сильно отличаться.
COBOLим вместе
При опросе людей, создающих аппаратные и программные продукты, определившие современную жизнь, обычно можно встретить такие должностные определения как инженер, физик, академик, математик, компьютерщик или предприниматель. Мы крайне редко сталкиваемся в описании с контр-адмиралом ВМС Соединенных Штатов, но все изменится, когда представим Грейс Хоппер. Конечно, надо признать, что она была также ученым-компьютерщиком и математиком, но Грейс Хоппер считается ключевой фигурой в разработке COBOL - совместного проекта ВМС США, ВВС США, Бюро стандартов и ряда производителей компьютеров. Целью проекта была разработка языка для бизнес-приложений, который при этом был бы переносимым на разные платформы. Это резко контрастировало с научными, техническими, инженерными и математическими приложениями, для которых предназначался Fortran. По замыслу Хоппер, который, несмотря на противодействие некоторых кругов, действительно был воплощен в COBOL, программы должны были быть написаны на английском языке, а не в краткой математической нотации. Так, например, оператор, который в Fortran выглядел бы как TD = GP * TR, превратился бы в MULTIPLY GROSS-PAY BY TAX-RATE GIVING TAX-DEDUCTED. в COBOL. Да, мы могли бы использовать более осмысленные имена переменных в коде на Fortran, и тогда оба кода выглядели бы более похожими, но, несмотря на это, в Fortran было принято использовать краткие имена переменных, а в COBOL поощрялись более длинные.
Грейс Хоппер утверждала, что для большинства людей проще написать английское выражение, чем использовать символы. Однако, через несколько лет мы стали слышать что польза от этого была не столько для программистов, сколько для непрограммистов, которым может понадобиться читать и понимать код. Например, было высказано предположение, что в некоторых случаях бухгалтерам, аудиторам и финансовым директорам будет необходимо понимать программы, на которых работают системы их организаций. Но также есть мнение, что эти рассуждения ошибочны. Конечно, показанный нами оператор COBOL несколько проще для понимания, чем эквивалент на языке Fortran, но нематематику и непрограммисту, наверняка не потребуется много времени, чтобы разобраться в отдельных операторах. Гораздо более сложной задачей, которую COBOL не решал, является понимание структуры и работы программы в целом. Действительно, с этим сталкиваются даже программисты при попытке сопровождения или улучшения программы, написанной их коллегой. А бывает и хуже. Англоязычные формулировки приводят к тому, что код получается многословным, а это, как правило, затрудняет интерпретацию. А поскольку на написание длинных высказываний уходит больше времени, чем на короткие, то возникает вопрос, не снижает ли подход COBOL производительность труда программистов.
Таким образом, вопрос о пользе или вреде замены символов на английские слова может быть спорным, и тот факт, что немногие, если вообще какие-либо, более современные языки последовали этому примеру, может быть показательным. Однако, другие особенности COBOL, не разделяемые Fortran и большинством других ранних языков, определенно благоприятствовали финансовым и бизнес-приложениям. На первом месте в списке стоит поддержка иерархических структур данных, которая имеет некоторое сходство со структурами языка C, но до появления этого языка пройдет еще 13 лет. Они обычно использовались при чтении данных фиксированного формата, например, с перфокарт или дисковых файлов фиксированного формата, и определяли способ представления данных в каждой записи. Так, например, клиент может быть определен именем, адресом, датой последней покупки и т.д., а некоторые из этих переменных могут быть разделены на подразделы. Например, любые даты могут быть разделены на день, месяц и год. И эти подразделы могут содержать дальнейшие подразделы. Все самые нижние уровни будут определяться типом данных (например, числовые или текстовые) и их длиной. Рассмотрим на примере, как возможность ссылаться на любой уровень в структуре данных повышает эффективность. Классическим примером COBOL является проверка данных, при которой данные считываются из стопки перфокарт - данные на тех картах, которые признаны достоверными, записываются в файл для последующего использования, а сообщения об ошибках, выявляющих недействительные карты, выводятся на печать. Так, например, проверка даты включает в себя проверку того, что месяц имеет значение от 1 до 12, что предполагает обращение к записи нижнего уровня в структуре данных. Однако запись валидных данных в файл может быть осуществлена с помощью одной инструкции, которая обращается к записи верхнего уровня.
Практическая работа
Мы предполагаем, что большинство из вас не решит заниматься серьезным кодингом на COBOL, но можно попробовать его на скорую руку, чтобы лучше оценить его уникальность, поэтому мы приводим лишь тривиально простой пример. Вы можете попробовать и, возможно, улучшить код, воспользовавшись онлайн-средством Try It Online, но не забудьте сначала заглянуть в примечания, следующие за кодом. Учитывая нишевую природу этого языка, во всяком случае для непрофессионалов, вы, скорее всего, не захотите устанавливать компилятор локально, но если все же решите, то мы рекомендуем GnuCOBOL, который как раз и является компилятором, размещенным на сайте Try it Online.
IDENTIFICATION DIVISION.
PROGRAM-ID. TAX001.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 INPUT-DATA.
02 GROSS-PAY PIC 999999.
02 TAX-RATE PIC V999.
01 TAX-DEDUCTED PIC 999999.
PROCEDURE DIVISION.
ACCEPT INPUT-DATA.
MULTIPLY GROSS-PAY BY TAX-RATE GIVING TAX-DEDUCTED.
DISPLAY TAX-DEDUCTED.
STOP RUN.Ввиду необычности кода, особенно для программистов XXI века, следующие примечания помогут вам лучше понять его.
Оригинальный COBOL накладывал строгие ограничения на то, какие столбцы использовать. В последнее время эти ограничения были смягчены, но все же не начинайте строку раньше 8 столбца.
Программа на языке COBOL разбивается на разделы, первоначально это разделы IDENTIFICATION, ENVIRONMENT, DATA и PROCEDURE DIVISION, хотя большинство современных компиляторов требуют только первый и последний из них. IDENTIFICATION DIVISION содержит обязательный PROGRAM-ID, но могут быть представлены и дополнительные виды информации. Раздел ENVIRONMENT DIVISION, который мы опустили, содержит информацию, относящуюся к конкретному аппаратному обеспечению, поэтому, теоретически, при переносе кода может потребоваться изменение только этого раздела. Сюда, например, включаются сведения об устройствах ввода-вывода. DATA DIVISION, который, несмотря на свою необязательность, необходим практически во всех приложениях, содержит эквивалент объявления переменных, хотя и приспособленный для поддержки иерархических структур данных. А в PROCEDURE DIVISION содержатся исполняемые операторы.
Если бы наш код содержал дисковый ввод-вывод, то DATA DIVISION включал бы в себя INPUT-OUTPUT SECTION. Однако, поскольку для ввода-вывода мы используем только операторы ACCEPT и DISPLAY (см. п. 5), в этом нет необходимости, поэтому у нас есть только раздел WORKING-STORAGE, в котором определяются "обычные" переменные. У нас всего две переменные верхнего уровня (01), а именно INPUT-DATA и TAX-DEDUCTED. Для переменной TAX-DEDUCTED имеется PIC 999999, что определяет переменную как шестизначное число. Для INPUT-DATA такого определения нет, поскольку она разделена на две переменные нижнего уровня (02). Первая из них определяется как шестизначное число, а вторая - как числовое значение, состоящее из трехзначного числа с подразумеваемой десятичной точкой в начале.
Высказывания завершаются точками, что еще раз подчеркивает англоязычный характер языка COBOL.
Для упрощения мы используем ACCEPT и DISPLAY для ввода/вывода. В ранние времена они могли считывать или записывать данные с консоли оператора, но обычно не использовались. Однако, в отличие от других форм ввода/вывода, таких как READ или WRITE, нам не нужно предоставлять информацию в ENVIRONMENT DIVISION или INPUT-OUTPUT SECTION для DATA DIVISION. ACCEPT может принимать значение только для одной переменной, так что в этом отношении он аналогичен чтению с перфокарты. Этой переменной является INPUT-DATA, которая делится на GROSS-PAY и TAX RATE, причем последняя не является процентом, а представляет собой значение в диапазоне от 0 до 0,999. Эти два значения вводятся сразу друг за другом, и их следует набирать в области INPUT до выполнения кода, если вы используете Try it Online. Так, для зарплаты в размере 40 000 и налоговой ставки 0,250 следует ввести
040000250.
COBOL И ОШИБКА Y2K
В 1999 году наиболее сенсационные новостные издания сообщали о том, что с наступлением нового тысячелетия наступит конец цивилизации. В некоторых из них появились сообщения о том, что люди планируют спастись от Армагеддона, запасаясь провизией и оружием и покидая города ради безопасности, в пустыне.Это было связано с "ошибкой Y2K", которая, как предполагалось, приведет к отказу компьютерных систем по всему миру в полночь в канун нового тысячелетия. Сбои были зафиксированы, но массовых разрушений удалось избежать. Проблема заключалась в том, что в старом коде COBOL даты хранились с двузначным годом вместо четырех, поэтому 2000 год интерпретировался как 1900 - такова была необходимость экономить два байта при хранении даты в те времена, когда стоимость хранения данных была очень высока. Многие компании упредили эту проблему, наняв целые армии программистов COBOL, большая часть из которых уже пребывали на пенсии, для поиска и исправления кода, не соответствующего требованиям тысячелетия. История свидетельствует о том, что их поиски увенчались успехом, но, оглядываясь назад, можно смело сказать, что не все так думали. Для некоторых вздох облегчения, когда конец света не наступил, вскоре сменился мнением, что все это было обманом. Попробуйте сказать это Уэйну Хорскрофту, одному из программистов на языке COBOL, который в конце 90-х годов занимался этой проблемой, возглавляя проект "2000 год" в компании Utah Power & Light. В интервью газете Los Angeles Times Хорскрофт признался, что стресс и напряженный темп работы заставили его досрочно выйти на пенсию.
Эволюция
Как язык, который продолжает использоваться уже более 60 лет, неудивительно, что, подобно языку Fortran, COBOL пережил множество изменений, последним из которых является COBOL 2014. Новые версии появлялись вслед за оригиналом; уже в 1961 году вышла версия, в которой появились функции, которые, по всей видимости, должны были присутствовать в первоначальной версии. Похоже, что возможности начальной версии COBOL были ограничены из-за амбициозных сроков разработки. Несмотря на это, новые инструкции в первом обновлении были инновационными. За исключением иерархической структуры данных, функции оригинального COBOL во многом совпадали с функциями других современных языков, хотя и отличались необычным англоязычным синтаксисом. Однако COBOL 61 содержал инструкции, которые, вероятно, даже не рассматривались бы для языков, предназначенных для научных или технических приложений. Первой из таких специфических для бизнеса инструкций стал оператор SORT. Его назначение - сортировка несортированного входного файла с записью результата в файл вывода. Оператор определяет один или несколько ключей - переменных более низкого уровня, каждый из которых может быть отсортирован как по возрастанию, так и по убыванию. Без оператора SORT пришлось бы писать немалый объем кода, либо использовать внешние библиотечные функции, что может негативно сказаться на переносимости. Далее следует оператор MERGE считывающий данные из двух или более ранее отсортированных файлов, записывая объединенный файл в соответствии со спецификацией сортировки. Затем появились различные инструкции, упрощающие составление отчетов.
Как и Fortran, COBOL также выиграл от модернизаций, которые ввели соглашения и парадигмы программирования, появившиеся после его разработки. Требование использования только верхнего регистра - навязанное из-за ограничений перфокарт и линейных принтеров - было смягчено в пользу использования прописных и строчных букв. Был введен блочно-структурный подход. И наконец, начиная с COBOL 2002, он мог похвастаться объектной ориентацией.
Переводы КОБОЛА
Поскольку одна из целей COBOL заключалась в том, что код должен быть англоподобным, чтобы его могли читать непрограммисты, интересно рассмотреть, существовали ли варианты, на основе других естественных языков. В конце концов, французскому бухгалтеру обычная программа на COBOL не покажется такой уж простой, как британскому или американскому. Оказалось, что переводы COBOL действительно существуют.
Нам хотелось бы сообщить, что нашли нечто столь же причудливо выглядящее, как греческий или арабский код COBOL, но мы не уверены, что такое вообще существовало, и даже не можем представить себе китайскую версию. Однако мы знаем, что COBOL переводился на русский язык, и для него, конечно же, использовалась кириллица. Однако, как и в большинстве случаев, связанных с бывшим Советским Союзом, подробностей найти практически невозможно. Однако еще в 1965 году Европейская ассоциация производителей компьютеров опубликовала отчет, определяющий перевод COBOL на французский, немецкий и итальянский языки. Впоследствии эти документы были опубликованы в качестве национальных стандартов. Так что, если вам показалось, что оригинальный COBOL был странным, то вас могут заинтересовать эти эквиваленты нашей ранее цитированной инструкции
MULTIPLY GROSS-PAY BY TAX-RATE GIVING TAX-DEDUCTED.. На французском языке COBOL это будетMULTIPLIER SALAIRE-BRUT PAR TAUX-DIMPOSITION RESULTANT TAXE-DEDUIT.(да, мы также взяли на себя смелость перевести имена переменных), а на немецком языке -MULTIPLIZIERE BRUTTOLOHN MIT STEUEERSATZ ERGIBT STEUERABZUG., а итальянский эквивалент -MOLTIPLICA RETRIBUZIONE-LORDA PER ALIQUOTA-FISCAL DANDO IMPOSTA-DETRATTA..
COBOL сегодня
Учитывая возраст COBOL, можно было бы предположить, что его использование сильно сократилось с момента расцвета, но факты говорят о другом. Еще в 2022 году поставщик основных средств разработки на языке COBOL компания Micro Focus, ныне входящая в состав OpenText, провела исследование, выявившее несколько поразительных фактов. Более 800 млрд. строк COBOL поддерживают современные основные бизнес-системы, и 52% респондентов прогнозируют, что COBOL будет существовать в течение следующего десятилетия и далее, 83% считают, что он будет существовать и после их выхода на пенсию, а 54% ожидают увеличения использования COBOL в ближайшие 12 месяцев. Не менее 92% заявили, что их COBOL-приложения носят стратегический характер.
Эта статистика не говорит о том, что код статичен и не отвечает современным требованиям. Огромные стопки старинного кода, большая часть которого относится к доинтернетным временам, не просто поддерживаются в рабочем состоянии; более того, по результатам опроса 72% респондентов предпочли модернизацию в качестве общей бизнес-стратегии, а двое из трех заявили, что намерены модернизировать свои COBOL-приложения, а не заменить их, поскольку это стратегически лучший вариант для предприятия, не склонного к риску. Но COBOL не только остается критически важным для бизнеса, он также обеспечивает потребителей, на которых мы полагаемся, как объяснил интернет-изданию TechBeacon Эд Эйри (Ed Airey) из компании OpenText. "Большинство вещей, которые мы каждый день воспринимаем как должное, например, возможность снять деньги в банке с помощью банкомата, заказать билет на самолет в отпуск или получить страховое предложение, зависят от COBOL, спокойно работающего в фоновом режиме, - сказал он. Это, конечно, зависит от модернизации, от внедрения технологий, которые были неслыханны, когда код был впервые написан, как пояснил Айри в интервью ITPro Today." Общая кодовая база COBOL продолжает развиваться и изменяться по мере того, как новые возможности ИТ-компаний, такие как веб- и мобильный доступ, развертывание облаков, интеграция API и контейнеризация, используются для поддержки новых требований заказчиков". Результаты опроса свидетельствуют о том, что COBOL не стоит на месте и не находится в режиме технического обслуживания, а, скорее, принимает новые изменения в поддержку новой цифровой эры". Последнее слово мы предоставим Скоту Нейлсону из компании OpenText, который в беседе с ITPro Today также высказался о месте COBOL в современном мире. "Он все еще здесь, потому что все то, что люди создали несколько десятилетий назад, может работать и сегодня. Вам не нужно выбрасывать его и начинать все сначала. Можно строить на его основе".
Может быть, еще через 60 лет мир будет петь дифирамбы COBOL? Возможно, и нет, если разработка, недавно анонсированная компанией IBM, оправдает свой потенциал. По словам представителей IBM, этот продукт с поддержкой искусственного интеллекта, получивший название WatsonX Code Assistant for Z, поможет ускорить трансляции COBOL в Java на своих мэйнфреймах Z и повысит производительность разработчиков на этой платформе. Итак, возможно, COBOL уже не спасти, но готовы ли вы делать на это ставку? Или, может быть, эксперты в конце концов процитируют Марка Твена, который, услышав сообщение о том, что он испустил последний вздох, сказал: "Сообщения о моей смерти сильно преувеличены"?
Комментарии (39)
longclaps
21.11.2023 11:01+1COBOL по-прежнему способствует развитию бизнеса, сообщает Майк Бедфорд.
... 54% респондентов ожидают увеличения использования COBOL в ближайшие 12 месяцев.
Майк Бедфорд, похоже нанятый компанией Micro Focus или OpenText, выдал глупый маркетинговый шлак. Способствует развитию, надо же! И много стартапов запускают проекты на коболе?
С Бредфордом понятно, ему заплатили именно за маркетинг нанимателя. Но у переводчика-то был выбор. Хорошо бы он объяснил, зачем перевёл именно это. Как статья для цикла "об истории языков", она слишком комплиментарна к этому зомби.
vadimr
21.11.2023 11:01+1А почему именно стартапов?
Основная масса кода, а уж тем более – многократно используемого кода, пишется в корпорациях. Ведение бизнеса с нуля и написание кода с нуля являются скорее исключениями.
SpiderEkb
"Суперсила" COBOL была основана прежде всего на то, что это был специализированный язык для коммерческой логики и работы с БД. Именно в этих приложениях он давал максимально быстрый и эффективный результат.
Т.е. он никогда не был "языком общего назначения".
Достаточно спорное утверждение. Вот вам простой пример - есть БД. В ней есть запись, содержащая поля типов date, time, varchar, numeric и decimal. В COBOL эти типы данных поддерживаются языком - объявили структуру, совпадающую со структурой записи, прочитали туда запись и работаем с полями структуры.
Что будет если все это перевести на Java? Как это будет выглядеть? Сначала читаем запись в байтовый буфер, потом создаем объект класса где будет какой-то маппинг полей тех типов, которых нативно в Java нет в какие-то объекты... Но, извините, это все дополнительное время... Когда вам потребуется обработать 100млн записей, вы увидите что старый код на COBOL на том же железе работает ощутимо быстрее, чем новый, транслированный на Java. Да еще и ресурсов меньше требует...
Кроме того, "современный COBOL" (по крайней мере на платформе IBM i, возможно и z тоже) позволяет вставлять SQL запросы непосредственно в COBOL-код:
Как с этим обстоят дела в Java? Нет, конечно, как-то можно прикрутить, но именно прикрутить - быстро и эффективно как в COBOL это работать не будет.
Так что затея весьма сомнительная на самом деле...
AlexCzech01
Интересно, как в вашем представлении супербыстро и эффективно все эти конструкции работают в языке Кобол. Кобол способен читать данные из БД (которые там лежат в виде набора байтов на жёстком диске) в 5 переменных в разных местах оперативной памяти одной командой без промежуточного байтового буфера?
Тогда на этом Коболе надо СУБД писать, им такой функции очень не хватает
vadimr
В Коболе эти переменные не будут лежать в разных местах оперативной памяти, так как привязаны к input-output section.
Кроме того, фаза prepare приведённого оператора SQL приходится на время компиляции программы, а не на время выполнения.
SpiderEkb
Если вы обратили внимание, то там писалось
Структура - сгруппированные в один блок данные. Фактически - буфер с размеченными внутри него полями. Вот в этот буфер и читаются данные (запись) из таблицы.
Как пример - из другого, IBM'вского языка - RPG (Report Program Generator - фактически ровесник COBOL но на платформах IBM до сих пор активно развивается и давно ушел от "позиционного синтаксиса", превратившись в нормальные процедурный язык):
здесь:
dcl-ds - объявление структуры (data structure), которая полностью соответствует тому, что мы хотим получить из SQL запроса
zoned - тип данных в RPG соответствующий NUMERIC в SQL
В качестве параметров в запрос подставляются переменные CUS, CLC, Typ
Результат заносится в переменную (структуру) dsHDARes (которая объявлена выше).
Все. После выполнения запроса мы получаем заполненную структур и можем работать с ее полями - все их типы "нативны" для языка.
В COBOL это будет работать точно также:
PEMPL здесь - структура, соответствующая структуре записи CORPDATA.EMPLOYEE содержащая поля EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT
Как это на Java перевести? Во что это выльется? Как быстро будет работать на больших объемах данных?
Я к тому, что переводить специализированный язык со множеством пропертиарных возможностей на язык общего пользования - дело достаточно неблагодарное.
AlexCzech01
Так и в Java это будет работать точно так же, если вы захотите, чтобы это работало точно так же. Не хотят не потому, что так нельзя, а потому что повесишься в мегатоннах лапши, где всё связано со всем, разбираться потом.
Наверняка есть какие-то особенности, но они связаны со своеобразной архитектурой мэйнфреймов IBM, а не с тем, что Кобол такой великий язык
SpiderEkb
Не будет. Еще раз объясняю. Есть тип, соответствующий DECIMAL или NUMERIC в БД. Это типы с фиксированной точкой. Для COBOL это родные типы. Как int или float. Т.е. не требуется никаких оберток, никаких дополнительных объектов, которые будут создаваться в рантайме (и тратить на это процессорное время).
В Java нет таких типов. Т.е. вам придется прочитать запись, потом на основе байтов "с 5-го по 15-й" буфера создать объект "типа decimal" и только потом вы сможете с этим данными работать. И на создание объекта вы потратите время. И ресурсы процессора.
Поверьте на слово - в этих приложениях 400млн записей - "это немного, таблица до 4млрд поддерживает без партиционирования". А вы хотите 400млн раз создавать объект а потом его освобождать? Зачем, когда COBOL позволяет обходиться безо всего этого...
AlexCzech01
Напишет IBM свою особенную Джаву для своих мэйнфреймов - и там будет. А что эта Джава нигде больше не будет запускаться - так и этот Кобол тоже нигде больше не запустится, это IBM совершенно волновать не будет )
yukon39
Для современных СУБД таблицы с 400 млн строк не являются чем-то уж прям настолько проблемным, как вы тут описываете.
Запрос вида "SELECT TOP 1 * FROM Employees WHERE Code=@Code" вряд ли вызовет хоть какие-то затруднения при выполнении, и уж точно не понадобиться создавать 400 млн раз какие-либо объекты в прикладном коде.
Конечно, то на каком оборудовании это умел делать КОБОЛ еще в 1956 году вызывает уважение, однако, такие объемы в современном мире это далеко не уровень корпораций даже национального масштаба.
Стоимость поддержки для такого кода требуется колоссальная (и это пока еще физически есть те, кто на этом языке писал в 1960-70-х), и далее она будет только возрастать.
SpiderEkb
Я не говорил что это что-то особенное. Наоборот - для нас это совершенно обычное дело.
Но... Есть особенность. Которая в том, что у нас таких процессов одновременно крутится десятки тысяч. И все ворочают миллионами-десятками-сотнями миллионов строк. И не просто перекладывают их из таблицы в таблицу, а что-то с ними делают. Ну вот простейший пример.
Есть 50млн клиентов. У многих из них есть еще "субъекты" (доверенные лица, держатели карт и т.п.) У клиента есть имя (для ФД или наименование для ЮЛ), ДР (для ФЛ), ИНН, 5 типов адресов, для ФЛ несколько ДУЛ (документов удостоверяющих личность).
Есть примерно 500тысяч "субъектов списков росфина" - это всякие террористы-экстремисты и т.п. которые регулярно обновляются. Для каждого субъекта есть похожий набор данных. Только там может быть несколько имен, несколько ИНН и т.п. на каждого.
Есть т.н. "стоплист" - список совпадений клиентов с субъектами. И вот задача которая работает регулярно - сравнить всех клиентов и их субъектов со всеми субъектами списков росфина и выявить совпадения - для ФЛ это ФИО+ДР или ДУЛ или ИНН или адрес. Для ЮЛ - наименование или ИНН или адрес.
И да. Это один из десятков тысяч процессов. Никто не даст вам под эту задачу отдельную машину. А сделать это надо достаточно быстро - даже 5-6 часов уже недопустимо долго.
Решение "в лоб" дает время выполнения порядка 12-ти часов (и это параллельная обработка в 10 потоков). Со всеми ухищрениями сейчас вышли где-то на 2 часа.
Реальные запросы все-таки "немного сложнее". Примеры приводить не буду, просто поверьте что там полтора-два экрана, 5-7 таблиц, 2-3 подзапроса - запросто. И это только отбор, формирование потока данных, который потом будет обрабатываться (а в процессе обработки еще какие-то выборки возможны).
Классический пример - в 2012-м году Банк Содружества Австралии и Океании решил "обновить технологический стек". На это ушло 5 лет (2012-2017гг), обошлось в $750млн. На фоне этого стоимость поддержки старого кода - копейки.
И всегда надо иметь ввиду что сфера применения COBOL (и подобных языков) - финансы. Банки, страховые в первую очередь. Там, где крутятся очень большие деньги. И цена ошибки там очень высока как в денежном, так и в финансовом выражении. Поэтому там всем плевать на ТТМ - главное чтобы все быстро и надежно работало. Там циклы тестирования (всестороннего и многопланового) кратно дольше самой разработки. Всегда. И любое, самое мизерное изменение кода всегда тащит за собой полный регресс-тест.
Подход "скорее в прод, если баг вылезет - потом патчем закроем" тут не работает. Потому что (реальный случай) вышел недотестированный на нагрузку код и выстрелил баг - в период пиковой нагрузки один из критичных модулей начал тормозить. Что привело к лавинному эффекту по всей цепочке связанных с ним модулей. Пока сопровождение не реализовало WA и не откатило глючный патч, миллионы клиентов крупного банка по всей стране в течнии примерно двух часов не могли расплатится картами в магазинах - оплата не проходила - "нет ответа от банка". Ну у кого-то совсем не проходила, у кого-то проходила с 3-5-го раза...
У тог же Банка Австралии в процессе перехода на новый стек был совершенно эпичный баг - в один момент обнулилась кредиторская задолженность всех клиентов (это миллиарды денег если что). Выправить это можно, но это адский труд для сопровождения - откат с ленты на предыдущий день и восстановление всего ручками.
А теперь задумаутесь - вот эти все риски - ради чего? Просто ради того, что кому-то не хочется учить COBOL? при том, что курсы есть - тот же МикроФокус предлагает курсы.
Вся эта ситуация вообще бредовая - очередное юное дарование прошло ускоренные курсы джавы, слабало пару-тройку пет-проектов на несколько тысяч строк и прибегает с горящими глазами в банк в предложением "а давайте тут все на современный стек перепишем".
Да там первый вопрос - "а сколько это будет стоить?" и второй сразу же "а сколько на этом заработает банк и как быстро?". И третий, на засыпку - "какие риски для банка это несет?" Это ключевые вопросы для любого крупного бизнеса - им все равно что там внутри работает. Главное - чтобы оно работало. Быстро и надежно.
yukon39
Не вы же одни работаете вот с этим всем. Как-то справляются другие (и мы в т.ч.) с этими всеми списками и проверками без КОБОЛа. И десятки миллионов строк ворочаем и т.п., но вот нет никакой тут концептуальной проблемы настолько большого уровня, что современный ЯП ну никак не вытянет.
Так вот эти истории про 5 лет и 750 миллионов долларов и потери балансов клиентов и есть цена поддержки этого самого КОБОЛа - и со временем она только возрастает. Т.к. неизбежно теряются компетенции тех, кто эти системы писал 40-50 лет назад. И, условно, еще через 20 лет вопрос будет не о переходе, а переписывании с нуля всей нужной функциональности, т.к. компетенций ответить на вопрос "а как оно сейчас работает" уже не будет.
Учить КОБОЛ в 2023 году? Хороший, конечно вариант - зп сразу от десятки тысяч долларов в месяц, трудоустройство с открыванием двери ногой в любой крупный банк по всему миру. Мечта а не работа...
Конечно проще погасить огонь в глазах юного дарования и сделать его обычным серым хомячком в унылом корпоративном болоте, чем развить его дарования и сделать новые продукты для клиентов, заработав на этом деньги. Бизнесу это не нужно, да.
SpiderEkb
Банк? Страховая? Большие деньги? Постоянный контроль со стороны регулятора? Какая у вас цена ошибки, в том числе проблемы с производительностью? Сколько десятков тысяч бизнес-процессов (самого разного плана - платежи с их контролем, проверки клиентских данных, различные уведомления всем кому не лень, обязательная отчетность и т.д. и т.п.) у вас выполняется одновременно на сервере? Сколько сотен миллионов бизнес операций проходит в сутки?
Вопрос исключительно в этом. Банк не может "купить еще одну виртуалку в облаке" - все, что лежит на центральных серверах, лежит на его центральных серверах и обрабатывается только там. И сервера там очень дорогие т.к. кроме производительности еще и надежность нужна. И когда клиентская база выросла на 25-30% (наша статистика такая - в марте 20-го было 36млн клиентов, сейчас - 50млн), первое что будут делать - искать возможность оптимизировать код. А о покупке нового сервера речь пойдет в последнюю очередь. Потому что это всегда дороже.
Нет. Это цена попытки перехода с того, что работает десятилетиями на "новый технологический стек" просто потому что он новый. Нарушение золотого правила любого бизнеса - "работает - не трогай". Сродни замене авто просто потому что у старого пепельница заполнилась.
Поддержка старого кода (вот просто по нам знаю) стоит намного дешевле. У нас куча модулей, написанных на старом диалекте языка. С позиционным синтаксисом. Там можно увидеть то, что работает по 10 и более лет. И пока оно работает - никто его не трогает. Если возникает нужда (например, изменение логики бизнес-процесса, требований регулятора, законодательства, необходимость оптимизации производительности) старый модуль просто переписывается. Уже на современный лад.
И да. Кроме нашего основного RPG у нас есть и С и С++. И были попытки писать что-то на них. Поверьте - получается и дольше и корявее. Потому что это ЯП общего назначения, они не специализированы для решения конкретных задач. Там тривиальная задача - взять дату из строки, определить формат (ISO|EUR), провалидировать, сконвертировать во внутренний формат (CYMD) и записать в таблицу в виде числа в формате NUMERIC, выливается в пляски с бубном. В нашем языке это 3-4 строки кода максимум встроенными средствами. Вообще не задумываясь. А это настолько "проходная" задача, что тратить на нее более 5-ти минут времени просто полный зашквар.
Легче научить человека специализированному языку, чем постоянно преодолевать трудности с тем, что в языке нет того, нет сего, постоянно городить какие-то надстройки, обертки...
Ну никто не заставляет :-)
yukon39
По опыту нашей разработки - то что "работало 10 лет без изменений" работает 10 лет без изменений как раз потому что никто не знает как там хоть что-то поправить.
Отчего например, часть продуктов приходится запускать на переработанном функционале, а часть, так и остается на легаси, которое уже не отвечает нашим же повышенным требованиям качества разработки и скорости выполнения. А за 10 лет мы научились очень многому...
И мы это возвращаем Бизнесу, который хоть и нехотя, но все же принимает решения по переводу того что уже работает на новые механизмы, как раз потому что новые механизмы более надежные и быстрые, лучше протестированы и документированы.
Доводить ситуацию до варианта, когда дешевле все переписать с нуля, чем модернизировать уже существующее решение и тем самым ставить Бизнес перед фактом - что вы или потратите миллиард долларов за пять лет, или бизнес остановится, ну так себе вариант.
vadimr
Ну у вас просто другая специфика. В корпорациях зачастую десятилетний код считается новой, не до конца ещё внедрённой системой. Масштабы другие.
Вот как раз это вызывает очень большие сомнения. Как программа, которая используется 1 год, может быть лучше протестирована, чем программа, которая используется 10 лет? Или 50?
Тем более что развитие программирования идёт в целом в сторону увеличения производительности труда, а не эффективности и качества кода. Чтобы новая программа работала быстрее старой, не говоря о том, чтобы надёжнее – это редчайшие случаи.
SpiderEkb
Не поверите, но у нас на все есть документация. И что как работает известно. А работает без изменений до тех пор, пока эти изменения не станут реально нужны. По нашим скромным оценкам система насчитывает более 15тыс таблиц, более 30тыс программных объектов, более 150 программных комплексов. Это только на "центральных серверах", не считая "внешних систем" (там своя кухня).
Есть служба сопровождения - они отвечают за то, чтобы все работало. В том числе и мониторят загрузку серверов. Если возникают проблемы производительности - заводится "дефект производительности".
Есть бизнес. Они зарабатывают деньги. У них есть регламент бизнес-процессов, бизнес-требования. Если что-то поменялось - мы получаем задачу на доработку. Есть появляется что-то новое - опять же мы получаем бизнес-требования на разработку нового процесса.
В таком режиме банк работает уже более 30-ти лет. И работает устойчиво. Растут активы (5-е место в финансовом рейтинге, 4-е в рейтинге надежности), растет количество клиентов (только за последние три года более чем на 25%).
А кто сказал что описанная мной ситуация была именно такова? Там как раз скорее было
Т.е. кто-то просто убедил бизнес что "станет еще лучше". И кинулись переделывать все, без особой на то нужды.
Да, у нас идет постепенная модернизация. Но в рамках существующего стека - он доказал свою высокую надежность и производительность. Да, мы внедряем новые подходы. Мы тоже много чему научились в плане написания эффективного кода, у нас есть список "нефункциональных требований" как надо и как не надо.
Но переписывать на "модный стек" никому в голову не придет. Были попытки что-то делать на С++ и ООП (целая команда этим занималась) - тестирование показало что скорость разработки не увеличивается, а местами даже хуже, прироста эффективности тоже нет (в лучшем случае не хуже, а обычно хуже за счет лишних уровней абстракций и отсутствия нативной поддержки нужных типов данных). В общем, идея не взлетела. Хотя некоторые вещи я сам на С/С++ пишу - всякие системные и околосистемные задачки где надо плотно с системными объектами и API работать или на уровне функций-оберток для машинных инструкций (MI).
Но все это прекрасно стыкуется с RPG кодом.
Вот, например, не так давно делал ("непроектная" задача)
Там набор API для RPG, набор системных (CL) команд, набор SQL функций и процедур (например, просмотр скулем содержимого очереди) - это больше для мониторинга и сопровождения.
Все это на С/С++ потому что системное - там все через MI и системные указатели на объект. Еще и по ряду причин все это в модели памяти TERASPACE (динамическое выделение до 2Гб одним куском, 64бит указатели) тогда как обычная работа в модели памяти SINGLE LEVEL (до 16Мб одним куском выделяется, указатели 128бит).
Да, у нас специфическая система - IBM i. Высоконадежные, высокопроизводительные коммерческие (middleware) сервера на процессорах PowerS (мы сейчас сидим на Power9, начинали с Power7 когда-то), уже вышли новые Power10, но пока нет необходимости переходить на них.
Система развивается - примерно раз в два года выходит новая версия (сейчас 7.5, у нас пока 7.4). Два-три раза в год выходит TR - Technical Refresh - минорное обновление системы. Вот на днях очередной вышел, до этого был в мае. при этом поддержка идет как по текущей, так и по предыдущей версиям системы - фактически это два TR - для 7.4 и для 7.5.
В TR обычно входят в том числе всякие плюшки для SQL, для RPG. В весеннем вот докинули несколько фичек типа %concat и %concatarr - сборка строки из списка или массива слов (там еще что-то добавилось, сейчас не вспомню). То, что раньше в цикле делалось, теперь можно одной командой. В последнем - появились enum (dcl-enum).
Так что все вполне себе развивается. У нас как минимум три банка работает на этой платформе - мы, райф и рос. Еще в каких-то структурах знаю что есть такие машинки. В мире много где (и ресурсов полно от групп в LinkedIn до блогов и форумов). Для VSCode есть хороший комплект плагинов для работы с системой. Есть даже бесплатный публичный сервер - регистрируешься, получаешь профайл и работаешь (если кому-то "побаловаться" или для обучения).
Так что ну никак не легаси. Просто узкоспецифическое.
amberovsky
Я не противник и не защитник кобола, который золотая жила для Терехова на матмехе.
Вы в целом описываете типичный огромный корпорат, особенно где-то в районе 90х. В Вашем случае ещё и наличие строго регулятора.
Но ваше самое сильное отличие - отсутствие новых требований со стороны конечных пользователей. Для клиента банка нужен примерно одинаковый набор функций - отчётность, список транзакций, оплата, етц. Апдейтить под новые требования надзорных органов для юриков.
Рост нео/диджатал банков показал тупиковость текущего подхода.
SpiderEkb
Вы точно знаете что у нас именно так? Уверены на все 100%?
На самом деле - не так. Тот же мобильный банк у нас считается лучшим по версии кого-то там (что бы это ни значило). И новых фич там предостаточно. И все они так или иначе приходят к нам.
А еще есть "Phygital Office" с биометрией клиентов...
И запросов на автоматизацию новых бизнес-процессов тоже предостаточно.
Опять же, по оценкам, у нас
Фактически, думаю что больше.
Постоянно идут работы - что-то новое, изменения в старом, оптимизация...
И не надо думать, что банк - это такая одна большая программа на каком-то одном языке. Да, это не микросервисная архитектура (в том узком смысле, к которой вы привыкли). Есть и другие подходы. Например, модель акторов которая была придумана задолго до того, как подавляющее большинство тут присутствующих узнали что такое компьютер (а многие еще и не родились даже). То, что работает у нас, пожалуй, ближе всего именно к этой модели - большое количество программных объектов, каждый из которых выполняет какую-то законченную логическую задачу и может быть модифицирован, оттестирован и внедрен без изменений всего остального.
И абсолютно не важно на чем он там внутри написан - главное что единожды согласованный контракт его использования потребителями не меняется (хотя в наших реальных условиях может расширяться).
Т.о. мы совершенно свободны при очередном изменении модуля полностью переписать его на чем угодно (опять же, в наших условиях это выражается в использовании современного диалекта языка плюс те подходы, которые сформировались с учетом накопленного опыта). Но... "пока работает - не трогай, дороже выйдет". Т.е. никому в голову не придет кинуться и просто так все переписывать.
Но основной момент, который я продвигаю. Если на вашей платформе есть специализированный язык для решений характерного для вас класса задач, использование его даст вам выигрыш и в скорости разработки (потому что там уже будет все что нужно для быстрой реализации типовых потребностей) и в эффективности полученного кода.
Попытка использовать ЯП общего назначения просто потому что за забором стоит очередь голодных Java-джунов (условно) с горящими глазами, готовых работать за еду, но не готовых осваивать новые инструменты (то ли в силу ограниченности мышления, то ли еще по какой причине) - это порочный подход. Ничего хорошего он не даст в долгосрочной перспективе. Дешевле и правильнее готовить самим себе действительно высококвалифицированных специалистов и нормально им платить.
А джуны - если готов осваивать нужный инструмент - велкам. Нет - ну пусть что попроще ищет.
Кстати, до сих пор проблем с наймом у нас не было. В том числе и молодых ребят. Кстати, очень толковых в большинстве своем.
amberovsky
Ну вы сравните себя и какой-нибудь необанк, например монзо. Сравните скорость внедрения новой фичи с ними.
Кобол трогать не будут, это практически гарантия до конца жизни компании.
Акторная архитектура , фреймворки типа Akka - это не прям необычное явление в не-корпоративной среде и вряд ли это говорит о чём-то. В энтерпрайзе свои паттеры, в не-энтерпрайзе другие.
Вам скорее комментируют люди с подходом разработчика, понятно что там околонулевой интерес с копанием 50-летного когда на древнючем языке. С точки зрения менеджера, просчётов ROI, риска и т.д. взгляд совершенно другой и менеджер vs разработчик это вечный конфликт
SpiderEkb
При тех требованиях к надежности что в банках, ведение новой фичи определяется не скоростью разработки, а объемом тестирования.
Ну и если сравнивать, то сколько у них клиентов и сколько у нас... А это очень сильно (уж поверьте) влияет на скорость работы всех процессов. Даже тривиальная операция - посмотреть историю операций по карте в мобильном приложении - это фактически выписка. И есть разница 10 миллионов клиентов в банке или 50.
И что есть у них, чего нет у нас? Можете перечислить?
А еще можно посмотреть размеры активов, динамику их изменения, динамику изменения клиентской базы...
В банк клиенты идут не ради новых фич. А ради условий обслуживания, надежности и т.п. И если новая фича появится на месяц позже, ни один серьезный клиент из банка не уйдет пока его все остальное устраивает. Уж поверьте. Деньги в банке делает бизнес, а не разработчики. Разработчики только обеспечивают работу бизнеса.
И еще. Вы, похоже, очень слабо себе представляете как все это устроено. Все ваши "фичи" опираются на некоторый REST API - прямого доступа к данным вам никто никогда не даст. И вы можете фантазировать строго в рамках того, что есть. А если нет совсем, то придете к нам, на центральные сервера. С просьбой сделать вам нужный сервисмодуль. И вот эта просьба уже будет рассматриваться как ее реализовать так, чтобы не в ущерб всему остальному что тут работает. Потому что не фичи главное в банке. Фичи - это обертка. А конфетка (вкусная или нет) - она вся внутри.
А плодить фичи вы можете на любом самом модном стеке и фреймворке - тут вам полная свобода потому что на работу банка это не влияет от слова совсем никак (а вот за этим уже мы следим).
Не будут трогать пока оно работает как требуется. И вот когда вы на условной джаве сможете написать сервис, который будет работать так же быстро (не требуя дополнительных затрат на апгрейд железа) и проработает столько же лет сколько работают модули на коболе - вот тогда можно будет сравнивать. Пока этого как-то не наблюдается.
Взято отсюда
Зато, наверное, в том что падало фичи плодились очень быстро :-) Вот только падали также быстро как плодились...
amberovsky
Какое-то у вас предвзятое отношение к фичедевелопменту.
Какая разница выписку транзакций делать по базе из 10 млн или 50 млн юзеров?
Я работал на проекте где было 100млн юзеров, 2млн уников в день. Много чего требовалось в плюс-минус реалтайме. Чатик, например. А это не только чтение, но и постоянная запись.
В общем вы как-то предвзято и с пренебрежение относитесь, дескать мы тут в банке программируем как надо, а вы все джава-юнцы вам лишь бы на прод без тестов поскорее.
SpiderEkb
Отнюдь. Просто я понимаю что это другой мир, там другие правила, метрики, требования.
На нашей стороне (АБС) главное - надежность и эффективность. Все остальное вторично. Мы - мастерсистема, mission-critical. Встанет АБС - ни одна фича работать не будет.
Разница в объемах данных будет не в 5, а в 10 и более раз. Даже обычный ФЛ у нас запросто может иметь 4-5 счетов. А ЮЛ, особенно крупный, - там десятки счетов.
Плюс плотность вызовов больше кратно. Вообще всего больше.
Когда у нас было 35млн клиентов, рассылка уведомлений (ежедневная) в сумме занимала минут 20. Сейчас 50млн - уже 45 минут.
Сверка по спискам росфина раньше укладывалась часа в 4-5, сейчас - более 12-ти. И так по всем позициям. Масштабирование вообще страшная штука в плане нагрузки.
А есть периоды пиковых нагрузок. Например, перед НГ когда все по магазинам ломятся. Поток платежей возрастает кратно. Если обычная загрузка серверов не превышает 60%, то в пиках до 90% доходит.
Наши оценки:
И это не самые свежие данные. Думаю, сейчас все еще больше.
И все это лежит на нас фактически. Наша задача чтобы все это работало.
При этом мы еще "банк реального времени". Не все банки так работают - во многих на период EOD работа приостанавливается. Т.е. все операции откладываются и проводятся следующим днем. У нас нет - все переключается на "юнит ночного ввода", а потом все изменения из него "накатываются" по журналам в новый день. Это тоже дополнительные усилия нужны.
lorc
даже на C можно сделать рудиментарную но очень быструю "базу данных", если писать/читать структуры прямо в файл. И никаких промежуточных байтовых буферов не надо. Только на C это будет непереносимо и вообще фу-фу-фу, но возможно КОБОЛ дает большое гарантий относительно размещений полей в структурах, там что там это будет вполне рабочим вариантом.
AlexCzech01
Это не Кобол даёт, это IBM даёт. Я очень мало знаю об этом всём, но всё что я знаю говорит о том, что когда они делали свои мэйнфреймы - ни о какой переносимости не думали принципиально. Там всё сделано самой IBM - и железо, и ОС, и компиляторы, и СУБД, вообще всё. Поэтому там граница между системным и прикладным софтом крайне призрачная. Вот это даёт производительность, а не магия языка Кобол
vadimr
Кобол изначально задумывался, как универсальный переносимый язык. Долгое время Министерство обороны США принципиально не закупало машины, не оснащённые компилятором Кобола. И IBM далеко не главная в коболовской теме, просто она единственная выжила с тех времён. А так IBM ещё с 1966 года безуспешно пыталась заменить Кобол языком PL/I.
SpiderEkb
Ну пытались, да, но параллельно еще развивали RPG. От "эмулятора табуляторов" с позиционным синтаксисом
до вполне нормального процедурного языка
С PL/I они завязли - получилось слишком уж сложно. И бросили это дело. А с RPG вполне себе преуспели - язык живой, постоянно развивается (в каждом TR - technical refresh - минорное обновление системы появляется что-то новенькое).
Есть, там, кстати, "сиснтаксический привкус" от PL/I - все объявления через dcl - dcl-pr, dcl-proc, dcl-c dcl-s, dcl-ds... В последнем TR вот еще dcl-enum появилось...
А COBOL IBM не двигала никогда. Да, поддержка его и по сей день есть - CRTBNDCBL - компиляция программы на COBOL на IBM i. Но основной двигатель тут MicroFocus. Они и сейчас предлагают курсы по COBOL.
FlyingDutchman2
Почему завязли?
PL/I использовался очень широко (да и сейчас используется).
Например, в авиакомпании KLM PL/I являлся основным языком (COBOL тоже использовался). Я там проработал полтора года в конце 1990-х. Думаю, и сейчас они его активно используют.
И другие большие голландские компании (банки и т.д.) активно использовали PL/I.
В PL/I так же можно использовать встроенный SQL (для работы с СУБД Db2). И он лишен такого недостатка COBOL, как ужасный синтаксис.
SpiderEkb
Я имел ввиду, что IBM перестала активно его развивать. на своих платформах. Для i (по крайней мере) все силу бросили на RPG (более 80% кода под i на нем пишется) + концепция ILE (интегрированная языковая среда) куда входят RPG, C/C++, COBOL, CL А вот про поддержку PL/I на IBM i (middleware) не слышал. Он есть, вроде бы, на IBM z (mainframe) и AIX
Вообще, скорее всего, сейчас действительно мало кто пишет на COBOL. Скорее всего, в силу его синтаксиса. Но переводить его на ЯП общего назначения... На мой взгляд малоосмысленно и быстрее оно точно работать не будет (в той специфической нише где он использовался) - слишком там много специфики для которой придется городить разного рода WA - слишком разные концепции заложены в языках, слишком много разных сущностей, не имеющих аналогов.
Как пример - человек пытается с RPG на Java что-то переписать
Да, видел в документации Embedded SQL programming. У IBM и в С/С++ можно SQL в код вставлять (и прямой доступ к БД есть через библиотеку RECIO. Но там проблема в типах данных - для decimal есть тип (и в С и в С++), причем, со 100% соответствием тому что в БД - можно элемент структуры объявить как decimal(n, m) и оно будет работать. Но вот дата/время, таймштамп, numeric - этого в С/С++ нет...
Ну и потом. Допустим, я из БД прочитал поле типа char или varchar. И мне надо его разбить на слова и каждое слово отдельно обработать как-то. В RPG одной строкой делаю цикл
В С придется разбивать руками. В С++ придется создать объект string, засунуть туда str и только после этого с ним работать. А это лишнее время.
Ну и такого очень много. Того, что в специальном языке делается одной строкой без создания лишних сущностей, в ЯП потребует различного рода WA.
Поэтому я и придерживаюсь мнения что если есть некая специфическая область разработки, в которой существует специфический язык, то в этой области этот язык будет давать наилучший результат. Попытки использовать там ЯП общего назначения - мартышкин труд. Ни по скорости разработки, ни по эффективности кода выигрыша не будет.
vadimr
Чтобы читать в C структуры мимо байтовых буферов, нужно выйти за пределы stdlib.
Разумеется, что на C можно сделать почти всё, что на машинном коде, поэтому в принципе любой трюк на C реализуем (по крайней мере, если не говорить об архитектуре IBM i). Но вопрос заключается в том, написать какое-нибудь одно присваивание на более подходящем к предметной области языке, или же несколько страниц низкоуровневых трюков на C, напрямую соответствующих машинному коду компилятора другого языка.
lorc
Ну да, я так и написал:
SpiderEkb
Вот именно об этом я и пишу.
SpiderEkb
Ну вот смотрите. Это RPG, но в COBOL будет примерно также. Кусок реального кода (с сокращениями). Здесь прямой доступ к таблице по индексу. В данном случае это быстрее чем скуль т.к. по одной таблице, по одному индексу и размер выборки невелик - несоколько записей, ну сотня может быть и то редко
Объявляем файл (dcl-f) и структуру (dcl-ds) которая будет точно соответсвовать структуре записи в таблице (likerec)
Читаем записи, для которых поле SCAN равно значению переменной CPNC и суммируем значение поля SCBAL (если валюта SCCCY не рубли - конвертируем в рубли).
Если сумма на счетах превысила значение limitSum - выходим с соотв. результатам (точная сумма нам не важна - больше лимита или меньше, все)
И да. Поле SCBAL имеет тип DECIMAL(23, 0) (по-моему, 23).
Код:
setll позиционирует курсор перед первой записью, у которой SCAN >= CPNC
read читает следующую запись и перемещает курсор к следующей.
Цикл - пока не дойдет до конца файла или SCAN != CPNC
Все.
И да, БД - DB2 for i Достаточно серьезная БД.
yukon39
Тут разве что спасает малое количество записей при отборе по значению индекса и тесная интеграция рантайма с СУБД, которое максимально бесшовно мэппит данные из СУБД в рантайм.
Как видится из вашего же описания - это очень удобно для узкого ряда кейсов - типа постобработки результата запроса, когда полноценная реализация логики в терминах SQL становится слишком громоздкой. Такой расширенный вариант хранимых процедур: удобно, быстро, без потерь на преобразование данных и т.п.
Однако, сейчас паттерн хранимок скорее антипрактика, т.к. удобства скорости рантайма оказались несоизмеримо меньше удобств разработки и эксплуатации. Хотя в условиях сурового корпората с прибитыми к СУБД решениями хранимки, конечно, востребованный инструмент.
SpiderEkb
Естественно.
Тут вопрос вот чем - если выборка мала (сотня-другая записей и меньше или вообще одна запись по уникальному ключу), делается по одной таблице (точнее, по одному индексу), то с точки зрения производительности выгоднее использовать такой вот прямой доступ. Или, например, проверка наличия записи с заданными знаачениями ключа - тут даже читать ее (лезть в саму таблицу) не надо - достаточно проверить ее наличие в индексе - setll + %equal.
Если выборка большая и сложная (много таблиц, много условий) - выгоднее делать это на SQL. Но там тоже свои сложности - часто в точки зрения скорости выгоднее не пихать всю логику в SQL, но сделать запрос попроще (например, избавиться от агрегаций - order by, вынеся их на обработку выборки).
Один из примеров тут приводил.
Вот тут вы неправы. Там, где крутятся очень большие деньги, удобство разработки и ТТМ очень сильно не на первом месте. А вот эффективность и надежность являются основными приоритетами. Цена ошибки тут очень высока. От прямых финансовых потерь с 6-7-ю и более нулями до репрессивных санкций со стороны регулятора (вплоть до лишения лицензии).
Что касается удобства разработки - поверьте, вполне себе удобно :-)
У нас вся бизнес-логика построена именно на этом. Сформировать поток данных (выборка) и что-то с ними сделать. Так работает банк. Я специально подчеркиваю - это не универсальный язык. Это специализированный язык для решения вполне конкретного класса задач. И, будучи специализированным, он для этих задач очень удобен, прост и быстр.
Без претензий на универсальность (если нужно что-то выходящее за рамки удобной разработки на этом языке, я просто напишу кусок на С/С++ - он тут тоже есть и его я тоже знаю и умею).
FlyingDutchman2
.
eugeneyp
Плохо обстоят, стандарту SQLJ 25-ть лет, но его никто использовать не хочет. Более подробно
https://ru.wikipedia.org/wiki/SQLJ
Для С# есть Linq в стиле SQL/
Быстро и эффективно это как? Когда код выполнения SQL запроса мешается с бизнес логикой? Насколько я знаю, PL/SQL проигрывает решениям 3-х уровненной архитектуре в скорости работы.
Потом почему вы берете тоже железо? В случае с Java можно брать несколько нод с более слабым железом, которые в совокупности будут обрабатывать быстрее. Т.е. с т.з. закупочной стоимости COBOL не всегда выигрывает.
decimal типу в Java соответствует BigDecimal.
Также код на COBOL возможно подвержен той ошибкой, которую часто совершают люди использующие dBase, PL/SQL, 1C. Когда вместо SQL с кучей JOIN пишут вложенные циклы, что не дает работать оптимизатору запросов. И вместо быстрой выборки идут бесконечные циклы.
SpiderEkb
Нет. Не соответствует. Посмотрите что такое (физически, в памяти) decimal и поймете, что BigDecimal это некая эмуляция (и даже не полная). И ни в коем случае не нативный тип. Вы не можете объявить статическую структуру, содержащую BigDecimal поле, прочитать туда блок данных из файла и потом работать с этим полем. Вам обязательно потребуется объявить объект, проинициализировать его данными - а это все время в рантайме.
А еще в БД могут быть типы NUMERIC (тоже фиксированная точка, но в памяти иначе лежит), DATE, TIME, TIMESTAMP, VARCHAR... С ними как быть? Ваша задача быстро получить несколько дестаков миллионов записей из БД, что-то с каждой из них сделать и положить обратно в БД - каждый раз для каждого поля будете объекты-обертки туда-сюда крутить? Зачем, если можно проще, без всего этого? В этом по-вашему, "удобство разработки"?
Ок. Вы готовы оплатить лишнюю ноду из своего кармана ради удобства разработки? Мне почему-то кажется что нет. А почему вы думаете, что кто-то за вас должен оплачивать лишнее железо просто потому что у вас как-то предубеждения против инструмента, позволяющего эффективно решить ту же задачу на имеющемся?
Ох... Вы действительно свято верите в идеальность оптимизатора? Скажите честно - хоть раз занимались нагрузочным тестированием, профилированием своего кода? Когда запрос пишете - вы прогоняете его через демонстратор, который рисует план запроса? Смотрите рекомендации оптимизатора? У нас все это обязательно.
И практика показывает что в ряде случаев часть логики выгоднее вынести из запроса на постобработку - будет работать быстрее и эффективнее. Простейший пример тут приводил.
Там еще есть "магия" со статическими и динамическими SQL - в какой момент план запроса строится - на этапе компиляции или в рантайме. При построении плана запроса в рантайме, особенно при большой плотности вызовов, можно потерять до 30% времени и ресурсов. И получить на нагрузочном тестировании такое вот заключение:
С результатом "внедрение не согласовано".