Я с мейнфреймами не работал. Которые нынче IBM z, но работаю с middleware платформой IBM i (бывшая AS/400). Так вот там COBOL до сих пор поддерживается. Т.е. перенести все написанные на COBOL приложения со старого сервера на новый - никаких проблем.
Более того, архитектура этой системы подразумевает хранение в бинарнике не только собственно исполняемого кода, но и промежуточного TIMI (Technology Independant Machine Instructions) кода. И метки под какой процессор сгенерирован исполняемый бинарный код. При переносе на новый сервер (процессор) при первом запуске система обнаружит что исполняемый код не под тот процессор и автоматически перегенерирует его из TIMI.
Там есть ограничения. Про кобол не знаю, мы с RPG работаетм. Там тоже есть поддержка типов с фиксированной точкой. Так вот тип packed (packed decimal - фактически BCD) ограничен 63-мя знаками всего и 31-м знаком после запятой. Т.е. максимально можно объявить
Пример программы на COBOL — это обычный Hello World
Интересно, а сколько людей из тех, кто тут пишет про кобол и мейнфреймы, написали хоть одну программу на нем для этих самых мейнфреймов...
Но ситуация постепенно меняется. Корпорация IBM разработала набор инструментов, позволяющий портировать COBOL-программы на Java — Watsonx Code Assistant.
Рекламы много, вот только не видел ни одного восторженного отзыва типа "Вау!!! Перевели с кобола на джаву - он сразу стало быстрее работать и при этом меньше ресурсов потреблять - смогли заменить один дорогой мейнфрейм на пару дешевых мелких серверов".
Ну вообще я привык что когда что-то делается, оно делается под конкретные сценарии использования. А не "вааще шоб было".
Пример сценария я привел - работа с БД (поддержка типа DECIMAL в БД) и финансовые расчеты. Возможно, есть еще какие-то сценарии с которыми я лично не сталкивался.
Но если понятны сценарии, тогда можно уже рисовать как удобные для потенциальных сценариев API, так и эффективную в рамках данного сценария реализацию.
И да, мне хочется. Не то чтобы хочется, мне это необходимо чтобы (как писал выше) не иметь потенциальных проблем с клиентами банка (репутационные риски, жалобы и риски нежелательного внимания со стороны регулятора, штрафы и т.п.) Но, слава богу, у меня все это есть - я (мы) работаю с языком, где поддержка такой арифметики нативна - я языке есть соответствующие типы и все операции с ними (и в реализации С/С++ на этой платформе есть _Decimal для С и _DecimalT<n,p> для С++). И там да, переполнение всегда вызывает системное исключение, которое можно легко перехватить и обработать (а не обработаешь - ну упадет, оставив дампы и записи в joblog - будет "дефект промсреды").
если вы хорошо разбирайтесь в теме - давайте ссылки где написано, что этот Decimal реализован через BCD
Я в этой систем работаю. IBM i.
Чтобы понять как это работает, достаточно посмотреть что такое BCD и что такое packed decimal у IBM (это тот самый DECIMAL в SQL, _DecimalT<> в C++) Улавливаете сходство (мягко говоря)?
Современные процессоры обычную двоичную арифметику, тоже поддерживают, кстати
Речь о том, для современного процессора вы можете написать реализацию, которая будет работать с фиксированной точкой (BCD) без конвертаций туда-сюда, на уровне инструкций процессора.
Т.е. не эмуляцию, а полноценную реализацию. Что и реализовано у IBM (правда, мы не с x86 работаем, а с рисковыми Power процессорами - подозреваю, что там возможности процессора по работе с BCD побогаче). Т.е. там нет каких-то специальных библиотек. Все это поддерживается на уровне "машинных инструкций" (низкоуровневые примитивные команды)
Самое главное, какая производительность этого дела? Сравнима ли она с double, float?
Производительность в каких приложениях?
Все это делается не для производительности. А, например, для повышения устойчивости к накоплению ошибок округления. Для этого есть специальные тесты
Второй аспект - работа с БД. Там есть типы DECIMAL и NUMERIC. С фиксированной точкой. Широко используются в финансовых расчетах.
Если вам удастся хорошо реализовать "нативную" арифметику с этими типами, то производительность "на круг" будет выше - вам не потребуется каждый раз при чтении из БД конвертировать эти типы в плавающую точку, потом заморачиваться с ошибками округления, а потом конвертировать обратно чтобы записать в БД.
Т.е. вся эта история делается под конкретные сценарии.
не отменили, не знаю кто так реализовывает - будет неудобно
Дело в том, что современные процессоры, если не ошибаюсь, BCD арифметику поддерживают.
Насчет "кто" - например, IBM. Тип DecimalT<n,m>, совпадающий с SQL типом DECIMAL(N,M) реализован именно через BCD.
И это будет ничуть не неудобнее, чем вот это все вот что выше.
при работе с каким-нить int и его переполнением компилятор вам ничего не скажет
Вы считаете это нормальным? Я - нет. Потому что результат дальнейших вычислений становится некорректным, а вы про это знать не знаете.
А поскольку fixed point широко используется в финансовых расчетах, к вам очень быстро придут с претензией - "у меня на счете должно быть 1 000 000 000 а по факту всего 1 000 - где остальное?" И там "компилятор мне ничего не сказал" за отмазку не сканает, поверьте...
Нет. Такой не попадет. Но специфика ситуации в то, что в 99.99% случаев адреса клиентов более полные т.к. они верифицируются в рамках идентификации клиента.
А адреса субъектов - это просто строки в том виде, в котором они пришли от росфина. А там пишется та информация, которая есть в наличии (напомню, что речь идет о "нехороших" товарищах, которые предпринимают усилия для затруднения своей идентификации).
Так что будет наоборот - адрес клиента (проверенный и нормализованный, а часто еще и структурированный для некоторых типов адресов)
Самарская область, г. Самара,Советский р-н, Первый Безымянный пер., д. 144
и адрес субъекта
Самарская область, 1-й Безымянный переулок, дом 144
Существующий алгоритм показывает очень хорошее быстродействие и без всего этого. И результаты будут примерно такие же. Парсинг адресов даст лишнюю нагрузку на сервер, на котором и без того крутится очень много разных процессов. Но при этом он не привнесет никаких существенных улучшений.
Опять вы со своим буквоедством. Вы в таких условиях работаете? Где вас пасут до минуты?
Тут фактически закрепили ту ситуацию, которая сложилась де-факто. Никто никого не заставляет перерабатывать. Но тем не менее, ситуации бывают когда человек просто сам перерабатывает. Ну так получается. "Вот сейчас немного доделаю и тогда уже все". А не бросает все на полдороге потому что звонок прозвенел. Я вот по команде вижу - никто не разбегается просто потому что время вышло. И при этом никто никого не заставляет и не заставлял никогда (за семь лет работы дай бог чтобы пару раз попросили в выходные побыть на связи и подстраховать на случай если что не так пойдет, так это оформили официально и оплатили как положено - по двойному тарифу полные выходные, просто за то что был готов в любой момент подключиться).
А раз так сложилось - это компенсируется сейчас. Раньше только в виде премий и бонусов (не считая нормальной оплаты, регулярных индексаций и пересмотров), сейчас еще дополнительным отпуском ко всему этому.
Это называется нормальная рабочая обстановка. Когда цель - не деньги получить, а дело сделать.
Поэтому ни один серьезный проект в здравом уме никто делать с удаленщиками не будет.
Как считаете - АБС банка из топ10 - это серьезный проект?
Так вот у нас процентов 70-80 тех, кто пишет под центральные сервера (т.е. обеспечивает работу АБС - исправление дефектов, развитие, оптимизация и вот это все), работает на удаленке. И не поверите - с марта 20-го года все это нормально идет. Поначалу были опасения, но быстро развеялись. Все показатели не только не ухудшились, но и местами улучшились.
У меня даже за городом оптика в дом заведена. Да и резервный LTE от 50 до 80мбит с направленной антенной тянет.
А уж в городе-то вообще проблем нет. Там еще и провайдеров куча в каждом доме и можно нормального выбрать.
Кстати, проблемы с нестабильностью часто бывают на "последней миле" - WiFi от роутера в многоквартирных домах где все каналы забиты соседями. Так это решается просто - все, что требует стабильного подключения, подключается проводом.
Да ладно? Все ровно также. Или к тебе подходит в офисе человек и спрашивает можно ли поговорить (у тебя же свои дела есть). Или пишет в джаббер - вот есть проблема, можешь помочь?
По времени все это ровно одинаково. И с шарингом экрана вообще никаких проблем нет.
А у нас, наконец, сказали - "один фиг вы все на удаленке ненормированно работает, так теперь это официально и вот вам по три дня к отпуску за это".
Официально так:
Из последнего опроса eNPS мы выяснили, что многие сотрудники работают по гибкому графику.
Ваша должность подходит под этот формат работы. Поэтому мы переводим вас на ненормированный рабочий день. За такой формат работы полагаются дополнительные 3 дня отпуска в год.
Как можно использовать эти дни:
присоединить к основному отпуску;
взять сразу все 3 дня;
отгулять по одному дню;
получить компенсацию за эти дни в конце года.
Так проще чем следить за каждым сотрудником дошел ли он до компа к 9-ти утра, не отлучался ли больше чем на 45 минут на обед, не ушел ли раньше 6-ти вечера...
Работа работается, задачи закрываются, все коммуникации отлажены - вот тебе K-Talk, вот тебе RocketChat, вот тебе Cisco Jabber, как удобно, так и общайтесь.
Кто-то заказал перенос офисного компа на ферму и работает на нем удаленно, кто-то вообще от него отказался в ползу виртуального рабочего места через VDI...
Java есть но не используем с силу низкой производительности и высокого потребления ресурсов. .NET тут нет. Основной язык - RPG - вся основная работа с БД и бизнес-логика на нем пишется (он специально для этого придуман и очень эффективен с этих приложениях), есть С/С++.
Ну и у нас очень жесткие требования по производительности и ресурсопотреблению. Каждая поставка проходит обязательное нагрузочное тестирование.
И, повторюсь, нас не интересует парсинг адресов (это лишнее время и лишняя нагрузка на сервер). Нас интересуют совпадения. Полные адреса и так неплохо бьются существующим алгоритмом. А неполные и не распарсятся.
Вообще этот подход в данном случае - прикручивание какого-то универсального модуля ради сокращения времени на разработку ценой потери эффективности. Это не наш случай.
Нормированный рабочий день означает что я обязан 5 дней в неделю с 9-ти до 6-ти за вычетом 45 минут на обед быть на рабочем месте.
С переходом на удаленку (которая тоже оформлена официально и отражена в ТД) это надо было или контролировать как-то, или отменить. Что и было сделано.
Что касается сроков - моя работа в том, чтобы решать поставленные задачи в установленные сроки. И никого не волнует - трачу я на это 4 часа в день или 14. Работаю я с 9-ти до 6-ти или вообще по ночам (вдруг мне так удобнее).
Так что ТК - это ТК. А реальная жизнь это реальная жизнь. Все эти выверты нужны исключительно для того, чтобы не возникло вдруг каких-то претензий по законодательству типа - "а вот они у вас удаленно работают, а как вы контролируете что каждый из них ровно с 9-ти и ровно до 6-та работает и на обед тратит не более 45-минут?" И вот чтобы не заморачиваться с контролем просто сказали "а у них всех ненормированный день". А раз ненормированный, значит нужно 3 дня к отпуску дать.
Есть задачи, у каждой есть оценка (обычнотя же ее и даю,иестественно, с запасом) времени. К сроку задача дожна быть решена. Сколько реально потрачено времени никого не волнует
Ну насколько можно верить человеку, ни строчки на коболе не написавшему :-)
Смотреть надо спецификации. Но мне лень сейчас (по крайней мере) :-)
Я с мейнфреймами не работал. Которые нынче IBM z, но работаю с middleware платформой IBM i (бывшая AS/400). Так вот там COBOL до сих пор поддерживается. Т.е. перенести все написанные на COBOL приложения со старого сервера на новый - никаких проблем.
Более того, архитектура этой системы подразумевает хранение в бинарнике не только собственно исполняемого кода, но и промежуточного TIMI (Technology Independant Machine Instructions) кода. И метки под какой процессор сгенерирован исполняемый бинарный код. При переносе на новый сервер (процессор) при первом запуске система обнаружит что исполняемый код не под тот процессор и автоматически перегенерирует его из TIMI.
Там есть ограничения. Про кобол не знаю, мы с RPG работаетм. Там тоже есть поддержка типов с фиксированной точкой. Так вот тип packed (packed decimal - фактически BCD) ограничен 63-мя знаками всего и 31-м знаком после запятой. Т.е. максимально можно объявить
packed(63:31)Это тип, который соответствует SQL типу DECIMAL
Интересно, а сколько людей из тех, кто тут пишет про кобол и мейнфреймы, написали хоть одну программу на нем для этих самых мейнфреймов...
Рекламы много, вот только не видел ни одного восторженного отзыва типа "Вау!!! Перевели с кобола на джаву - он сразу стало быстрее работать и при этом меньше ресурсов потреблять - смогли заменить один дорогой мейнфрейм на пару дешевых мелких серверов".
Тут не про строки, тут про то, как сознательно убиться головой об стену.
100% защиты от дурака не существует - найдет лазейку и любую обойдет.
Ну вообще я привык что когда что-то делается, оно делается под конкретные сценарии использования. А не "вааще шоб было".
Пример сценария я привел - работа с БД (поддержка типа DECIMAL в БД) и финансовые расчеты. Возможно, есть еще какие-то сценарии с которыми я лично не сталкивался.
Но если понятны сценарии, тогда можно уже рисовать как удобные для потенциальных сценариев API, так и эффективную в рамках данного сценария реализацию.
И да, мне хочется. Не то чтобы хочется, мне это необходимо чтобы (как писал выше) не иметь потенциальных проблем с клиентами банка (репутационные риски, жалобы и риски нежелательного внимания со стороны регулятора, штрафы и т.п.) Но, слава богу, у меня все это есть - я (мы) работаю с языком, где поддержка такой арифметики нативна - я языке есть соответствующие типы и все операции с ними (и в реализации С/С++ на этой платформе есть _Decimal для С и _DecimalT<n,p> для С++). И там да, переполнение всегда вызывает системное исключение, которое можно легко перехватить и обработать (а не обработаешь - ну упадет, оставив дампы и записи в joblog - будет "дефект промсреды").
Я в этой систем работаю. IBM i.
Чтобы понять как это работает, достаточно посмотреть что такое BCD и что такое packed decimal у IBM (это тот самый DECIMAL в SQL, _DecimalT<> в C++) Улавливаете сходство (мягко говоря)?
Речь о том, для современного процессора вы можете написать реализацию, которая будет работать с фиксированной точкой (BCD) без конвертаций туда-сюда, на уровне инструкций процессора.
Т.е. не эмуляцию, а полноценную реализацию. Что и реализовано у IBM (правда, мы не с x86 работаем, а с рисковыми Power процессорами - подозреваю, что там возможности процессора по работе с BCD побогаче). Т.е. там нет каких-то специальных библиотек. Все это поддерживается на уровне "машинных инструкций" (низкоуровневые примитивные команды)
Add Numeric (ADDN)
Subtract Numeric (SUBN)
Multiply (MULT)
Divide (DIV)
Там, кстати, еще есть полезные вещи - операции с округлением. Скажем, есть у вас есть два переменных:
A типа decimal(5.3)
и
B типа decimal(4,2)
Так вот, если A = 3.245, то присвоение B = A без округления даст B = 3.24, а присвоение с округлением - B = 3.25
Переполнение - нештатная ситуация. И может возникнуть вне зависимости от жирноты базового типа.
Вопрос в том - заметите вы его сразу, или потащите кривой результат дальше с видом что "так и надо"?
То, как это сделано в С++ не отмазка. Там много чего оставлено на усмотрение конечного разработчика.
Производительность в каких приложениях?
Все это делается не для производительности. А, например, для повышения устойчивости к накоплению ошибок округления. Для этого есть специальные тесты
Второй аспект - работа с БД. Там есть типы DECIMAL и NUMERIC. С фиксированной точкой. Широко используются в финансовых расчетах.
Если вам удастся хорошо реализовать "нативную" арифметику с этими типами, то производительность "на круг" будет выше - вам не потребуется каждый раз при чтении из БД конвертировать эти типы в плавающую точку, потом заморачиваться с ошибками округления, а потом конвертировать обратно чтобы записать в БД.
Т.е. вся эта история делается под конкретные сценарии.
Дело в том, что современные процессоры, если не ошибаюсь, BCD арифметику поддерживают.
Насчет "кто" - например, IBM. Тип DecimalT<n,m>, совпадающий с SQL типом DECIMAL(N,M) реализован именно через BCD.
И это будет ничуть не неудобнее, чем вот это все вот что выше.
Вы считаете это нормальным? Я - нет. Потому что результат дальнейших вычислений становится некорректным, а вы про это знать не знаете.
А поскольку fixed point широко используется в финансовых расчетах, к вам очень быстро придут с претензией - "у меня на счете должно быть 1 000 000 000 а по факту всего 1 000 - где остальное?" И там "компилятор мне ничего не сказал" за отмазку не сканает, поверьте...
А BCD в C++ уже отменили? Насколько помню, арифметика с фиксированной точкой реализуется через BCD.
И еще. В случае переполнения, по-хорошему, нужно бы исключение генерировать. Ибо дальше результат становится непредсказуемым и некорректным.
Нет. Такой не попадет. Но специфика ситуации в то, что в 99.99% случаев адреса клиентов более полные т.к. они верифицируются в рамках идентификации клиента.
А адреса субъектов - это просто строки в том виде, в котором они пришли от росфина. А там пишется та информация, которая есть в наличии (напомню, что речь идет о "нехороших" товарищах, которые предпринимают усилия для затруднения своей идентификации).
Так что будет наоборот - адрес клиента (проверенный и нормализованный, а часто еще и структурированный для некоторых типов адресов)
Самарская область, г. Самара,Советский р-н, Первый Безымянный пер., д. 144
и адрес субъекта
Самарская область, 1-й Безымянный переулок, дом 144
или
Самарская область, 1-й Безымянный переулок
или
Самарская область, г.Самара
И вот все эти случаи попадут под совпадения.
Существующий алгоритм показывает очень хорошее быстродействие и без всего этого. И результаты будут примерно такие же. Парсинг адресов даст лишнюю нагрузку на сервер, на котором и без того крутится очень много разных процессов. Но при этом он не привнесет никаких существенных улучшений.
Опять вы со своим буквоедством. Вы в таких условиях работаете? Где вас пасут до минуты?
Тут фактически закрепили ту ситуацию, которая сложилась де-факто. Никто никого не заставляет перерабатывать. Но тем не менее, ситуации бывают когда человек просто сам перерабатывает. Ну так получается. "Вот сейчас немного доделаю и тогда уже все". А не бросает все на полдороге потому что звонок прозвенел. Я вот по команде вижу - никто не разбегается просто потому что время вышло. И при этом никто никого не заставляет и не заставлял никогда (за семь лет работы дай бог чтобы пару раз попросили в выходные побыть на связи и подстраховать на случай если что не так пойдет, так это оформили официально и оплатили как положено - по двойному тарифу полные выходные, просто за то что был готов в любой момент подключиться).
А раз так сложилось - это компенсируется сейчас. Раньше только в виде премий и бонусов (не считая нормальной оплаты, регулярных индексаций и пересмотров), сейчас еще дополнительным отпуском ко всему этому.
Это называется нормальная рабочая обстановка. Когда цель - не деньги получить, а дело сделать.
Как считаете - АБС банка из топ10 - это серьезный проект?
Так вот у нас процентов 70-80 тех, кто пишет под центральные сервера (т.е. обеспечивает работу АБС - исправление дефектов, развитие, оптимизация и вот это все), работает на удаленке. И не поверите - с марта 20-го года все это нормально идет. Поначалу были опасения, но быстро развеялись. Все показатели не только не ухудшились, но и местами улучшились.
Вы в тайге на елке работаете?
У меня даже за городом оптика в дом заведена. Да и резервный LTE от 50 до 80мбит с направленной антенной тянет.
А уж в городе-то вообще проблем нет. Там еще и провайдеров куча в каждом доме и можно нормального выбрать.
Кстати, проблемы с нестабильностью часто бывают на "последней миле" - WiFi от роутера в многоквартирных домах где все каналы забиты соседями. Так это решается просто - все, что требует стабильного подключения, подключается проводом.
Да ладно? Все ровно также. Или к тебе подходит в офисе человек и спрашивает можно ли поговорить (у тебя же свои дела есть). Или пишет в джаббер - вот есть проблема, можешь помочь?
По времени все это ровно одинаково. И с шарингом экрана вообще никаких проблем нет.
А у нас, наконец, сказали - "один фиг вы все на удаленке ненормированно работает, так теперь это официально и вот вам по три дня к отпуску за это".
Официально так:
Так проще чем следить за каждым сотрудником дошел ли он до компа к 9-ти утра, не отлучался ли больше чем на 45 минут на обед, не ушел ли раньше 6-ти вечера...
Работа работается, задачи закрываются, все коммуникации отлажены - вот тебе K-Talk, вот тебе RocketChat, вот тебе Cisco Jabber, как удобно, так и общайтесь.
Кто-то заказал перенос офисного компа на ферму и работает на нем удаленно, кто-то вообще от него отказался в ползу виртуального рабочего места через VDI...
В итоге все довольны.
Java есть но не используем с силу низкой производительности и высокого потребления ресурсов. .NET тут нет. Основной язык - RPG - вся основная работа с БД и бизнес-логика на нем пишется (он специально для этого придуман и очень эффективен с этих приложениях), есть С/С++.
Ну и у нас очень жесткие требования по производительности и ресурсопотреблению. Каждая поставка проходит обязательное нагрузочное тестирование.
И, повторюсь, нас не интересует парсинг адресов (это лишнее время и лишняя нагрузка на сервер). Нас интересуют совпадения. Полные адреса и так неплохо бьются существующим алгоритмом. А неполные и не распарсятся.
Вообще этот подход в данном случае - прикручивание какого-то универсального модуля ради сокращения времени на разработку ценой потери эффективности. Это не наш случай.
Да, при этом оценку сроков делаю я сам :-)
Нормированный рабочий день означает что я обязан 5 дней в неделю с 9-ти до 6-ти за вычетом 45 минут на обед быть на рабочем месте.
С переходом на удаленку (которая тоже оформлена официально и отражена в ТД) это надо было или контролировать как-то, или отменить. Что и было сделано.
Что касается сроков - моя работа в том, чтобы решать поставленные задачи в установленные сроки. И никого не волнует - трачу я на это 4 часа в день или 14. Работаю я с 9-ти до 6-ти или вообще по ночам (вдруг мне так удобнее).
Так что ТК - это ТК. А реальная жизнь это реальная жизнь. Все эти выверты нужны исключительно для того, чтобы не возникло вдруг каких-то претензий по законодательству типа - "а вот они у вас удаленно работают, а как вы контролируете что каждый из них ровно с 9-ти и ровно до 6-та работает и на обед тратит не более 45-минут?" И вот чтобы не заморачиваться с контролем просто сказали "а у них всех ненормированный день". А раз ненормированный, значит нужно 3 дня к отпуску дать.
Где я сеазал что да?
Есть задачи, у каждой есть оценка (обычнотя же ее и даю,иестественно, с запасом) времени. К сроку задача дожна быть решена. Сколько реально потрачено времени никого не волнует