Скорее всего это функция деперсонализвации клиентов. Точнее, очень мала ее часть (т.к. кроме ФОИ у клиентов хранится еще огромная куча всяких данных и все они должны быть деперсонализированы.
Нужно все это при пересоздании тестовых юнитов с боевого. Суть в том, что берется какая-то часть реальных клиентов с боя, деперсоналилируется и этом всем заполняются тестовые юниты.
Это специфический для платформы IBM i (AS/400) язык RPG. Он не то чтобы "встроен в БД" - на этой платформе БД (DB2) является частью ОС ну и языки освновные (С/С++, RPG, COBOL, CL) тоже "встроены" (компилаторы являются частью ОС) в систему.
Язык типа COBOL по назначению - основное в нем работа с БД и коммерческие вычисления.
И да, в синтаксисе есть "привкус" PL-I который IBM одно время активно пыталась развивать. В виде всех этих dcl-... в объявлениях.
Кстати, там нет ожидания ответа. Там именно отправлен ответ отмены операции автоматом. "A cancel reply to an inquiry message was received."
Кабы оно ждало ответа, то задание висело бы в ожидании, а не вывалило бы ошибку.
Вот, не поленился джоблог поднять:
alter table y2ku.tstidxpf drop column tidxclc;
DIAGNOSTIC Изменение в поле TIDXCLC может привести к потере данных.
DIAGNOSTIC Change of file TSTIDXPF in Y2KU canceled.
ESCAPE Файл TSTIDXPF в библиотеке Y2KU не изменен.
DIAGNOSTIC Обработка оператора SQL завершена. Код причины: 10.
И удаление поля из середины записи небезопасная операция. В больших БД с большим количеством интеграций я бы даже сказал недопустимая. Потому что обвал прода в mission-critical системе это уже практически катастрофа.
И мне не кажется что нетипичной такого поведения для БД это хорошо.
Момент номер раз. Удаление поля из БД. Не знаю что там за БД, но, работаю с "дибитухой" (DB2) уже 9 лет и вот там поле из существующей таблицы удалить невозможно. Оно просто не даст это сделать. Выдаст ошибку. Да что там удалить, там не то что тип поля, описание его уже не поменять... Единственное допустимое изменение в таблице - добавление нового поля в конец записи. Все. Остальное только полным пересозданием таблицы с потерей данных (хочется сохранить данные? делай скрипт для миграции, требуется отдельное согласование т.к. мигрировать несколько десятков а то и сотен миллионов записей такое себе...)
Момент номер два. Разделение зон ответственности. БД достаточно большая - несколько десятков тысяч таблиц. И она разделена на "зоны ответственности" разных команд. Так вот, доступ в "чужие" таблицы только через ретриверы и модули внешнего ввода. Никак иначе.
Момент номер три. Тестирование. Первый этап - песочница. Еженедельно пересоздаваемая копия компонентного юнита. Поставка туда разворачивается руками (системой сборки) из гита. Дальше - компонентный юнит. Тут уже установка через devops сервисы - доставка должна быть собрана и размещена в artifactory. Потом бизнес-юнит (бизнес-тест). Далее нагрузочное тестирование на копии промсреды и техтест на прелайве (тоже копия прома). И только после этого внедрение в пром. При внедрении в пром обязательно должен быть прописан план отката. На случай если что. Установками в бизнес-юнит и выше занимается дежурная смена по заявке. Т.е. в пром поставка попадает только после прохождения всех этапов тестирования - компонентного, бизнес, нагрузка, интеграция.
Поскольку всегда с поставкой идет план отката, то внедрение в пятницу нормальное дело. Если, не дай бог, что - поставка просто откатывается силами дежурной смены и все. Единственный мораторий на внедрения (за исключением хотфиксов) - период пиковых нагрузок с середины декабря и до конца новогодних праздников.
Да, проблема в легаси в первую очередь в том, что на ее основе наворочено уже столько всего, что само легаси страшно трогать чтобы ничего не рухнуло...
Последние 8 лет работаю с языком, где два типа строк - char и varchar.
char - обычный буфер заданной длины. И больше туда не впихнуть
dcl-s s1 char(5);
dcl-s s2 char(10);
s2 = '0123456789';
s1 = s2; // s1 = '01234' - что не влезло, то не влезло
s2 = s1; // s2 = '01234 ' - остаток забивается пробелами
При все желании за границу не вылезешь.
Но...
%len(s1); // всегда 5
%len(s2); // всегда 10
а чтобы узнать реальную длину (без хвостовых пробелов) надо
%len(%trimr(s2));
varchar - фактически структура
dcl-s vs varchar(10);
в С будет представлено как
struct t_varchar {
unsugned short len;
char data[10];
} vs;
и тут уже %len вернет реальное значение поля vs.len
И все это достаточно безопасно. Особенно с учетом того, что здесь не бывает неинициализированных переменных - компилятор автоматически инициализирует любую объявленную переменную дефолтным для ее типа значением (если явно не указано иное значение) - для char это "пустая" (заполненная пробелами) строка, для varchar это строка с len = 0, для числовых типов 0.
корпоративные политики, требования ИБ, правила использования сервисов или внутренние регламенты компании
публичные мессенджеры для внутреннего общения не используются (у нас явно запрещены для обсуждения рабочих вопросов, в ТГ есть командные чаты для просто потрепаться, но не более того). Только то, что может быть self-hosted на серверах во внутреннем контуре компании.
В нашем случае, например, используются K-Talk, RocketChat (форк), Cisco Jabber (с привязкой к внутренней IP-телефонии). Сейчас идет замена Рокета и Циски на форк eXpress (т.е. в идеале остается Толк для конференций и Экспресс для всего остального (тоже будет привязка к телефонии) - личные звонки, чаты, командные и тематические каналы. Все рабочие вопросы обсуждаются только там.
Авторизация, естественно, не по номеру телефона, а по корпоративному логину-паролю + IndeedKey.
На винде не заработало. Запускается, просит открыть папку и все... Прозрачное окно и ощущение что не делает вообще ничего (загрузка процессора программой колеблется от 0 до 0.3-0.5%)
Я много чего перепробовал - начинал под голым досом в донортоновские времена. Первое, что был попыткой изобразить хоть какой-то файловый менеджер, еще до нортона, был, по-моему, PCTools.
Так что много чего было, в итоге остановился на дубле как самом для себе приемлемом.
Я на винде-то фаром пользоваться не мог. Интерфейс вообще не заходит. Хотя есть любители, да...
Пользуюсь дублем. В первую очередь потому что он одинаковый и на винде и на линуксе (одна машина под виндой, вторая по линуксом) не надо думать "а как тут вот это..." - при одинаковых настройках все одинаковое. Ну и он бесплатный в отличии от тотала.
В спортивном фехтовании (приятель был - КМС, рассказывал тонкости) сейчас три дисциплины - рапира, шпага и сабля (эспадрон).
Шпага и рапира - колющие. Отличаются весом (шпага тяжелее), хватом (рукоять разная), формой клинка (четырехгранный у рапиры и трехгранный у шпаги) и зоной поражения - у рапиры только корпус, у шпаги все тело. Длина клинка одинаковая.
Сабля - рубяще-колющее. По весу как рапира, но чуть короче клинок. Хват как у шпаги. Зона поражения - все, что выше пояса (корпус и руки).
Ну тут человек представлялся именно как сотрудник службы безопасности или комплаенса или чего-то такого еще, что подразумевало именно штат альфы. Т.е. этот человек по ФИО должен сразу высветиться в поиске в джаббере или на внутреннем портале альфы - должность, подчиненность и т.п.
Выглядит все это как борьба с SQL движком. Бессмысленная и беспощадная.
Пример того, как отказ от SQL в пользу прямой работы с БД ускорил выполнение реальной задачи в ~40раз.
Скорее всего это функция деперсонализвации клиентов. Точнее, очень мала ее часть (т.к. кроме ФОИ у клиентов хранится еще огромная куча всяких данных и все они должны быть деперсонализированы.
Нужно все это при пересоздании тестовых юнитов с боевого. Суть в том, что берется какая-то часть реальных клиентов с боя, деперсоналилируется и этом всем заполняются тестовые юниты.
Это вполне реальная задача.
Это специфический для платформы IBM i (AS/400) язык RPG. Он не то чтобы "встроен в БД" - на этой платформе БД (DB2) является частью ОС ну и языки освновные (С/С++, RPG, COBOL, CL) тоже "встроены" (компилаторы являются частью ОС) в систему.
Язык типа COBOL по назначению - основное в нем работа с БД и коммерческие вычисления.
И да, в синтаксисе есть "привкус" PL-I который IBM одно время активно пыталась развивать. В виде всех этих dcl-... в объявлениях.
Кстати, там нет ожидания ответа. Там именно отправлен ответ отмены операции автоматом. "A cancel reply to an inquiry message was received."
Кабы оно ждало ответа, то задание висело бы в ожидании, а не вывалило бы ошибку.
Вот, не поленился джоблог поднять:
За изменение контракта без обеспечения обратной совместимости должен быть пожизненный эцих с гвоздями...
Да, IBM i.
И удаление поля из середины записи небезопасная операция. В больших БД с большим количеством интеграций я бы даже сказал недопустимая. Потому что обвал прода в mission-critical системе это уже практически катастрофа.
И мне не кажется что нетипичной такого поведения для БД это хорошо.
И получите
Reason code 10 означает "A cancel reply to an inquiry message was received."
Аналогичный результат есть попробовать сделать это через DDS командой CHGPF.
Момент номер раз. Удаление поля из БД. Не знаю что там за БД, но, работаю с "дибитухой" (DB2) уже 9 лет и вот там поле из существующей таблицы удалить невозможно. Оно просто не даст это сделать. Выдаст ошибку. Да что там удалить, там не то что тип поля, описание его уже не поменять... Единственное допустимое изменение в таблице - добавление нового поля в конец записи. Все. Остальное только полным пересозданием таблицы с потерей данных (хочется сохранить данные? делай скрипт для миграции, требуется отдельное согласование т.к. мигрировать несколько десятков а то и сотен миллионов записей такое себе...)
Момент номер два. Разделение зон ответственности. БД достаточно большая - несколько десятков тысяч таблиц. И она разделена на "зоны ответственности" разных команд. Так вот, доступ в "чужие" таблицы только через ретриверы и модули внешнего ввода. Никак иначе.
Момент номер три. Тестирование. Первый этап - песочница. Еженедельно пересоздаваемая копия компонентного юнита. Поставка туда разворачивается руками (системой сборки) из гита. Дальше - компонентный юнит. Тут уже установка через devops сервисы - доставка должна быть собрана и размещена в artifactory. Потом бизнес-юнит (бизнес-тест). Далее нагрузочное тестирование на копии промсреды и техтест на прелайве (тоже копия прома). И только после этого внедрение в пром. При внедрении в пром обязательно должен быть прописан план отката. На случай если что. Установками в бизнес-юнит и выше занимается дежурная смена по заявке. Т.е. в пром поставка попадает только после прохождения всех этапов тестирования - компонентного, бизнес, нагрузка, интеграция.
Поскольку всегда с поставкой идет план отката, то внедрение в пятницу нормальное дело. Если, не дай бог, что - поставка просто откатывается силами дежурной смены и все. Единственный мораторий на внедрения (за исключением хотфиксов) - период пиковых нагрузок с середины декабря и до конца новогодних праздников.
Да, проблема в легаси в первую очередь в том, что на ее основе наворочено уже столько всего, что само легаси страшно трогать чтобы ничего не рухнуло...
Тут скорее камень в огород тех, кто никак не может закопать стюардессу. И продолжает на фундаменте 72-го года пытаться строить hi-tech небоскреб.
Это "паскалевские строки".
Последние 8 лет работаю с языком, где два типа строк - char и varchar.
char - обычный буфер заданной длины. И больше туда не впихнуть
При все желании за границу не вылезешь.
Но...
а чтобы узнать реальную длину (без хвостовых пробелов) надо
varchar - фактически структура
в С будет представлено как
и тут уже %len вернет реальное значение поля vs.len
И все это достаточно безопасно. Особенно с учетом того, что здесь не бывает неинициализированных переменных - компилятор автоматически инициализирует любую объявленную переменную дефолтным для ее типа значением (если явно не указано иное значение) - для char это "пустая" (заполненная пробелами) строка, для varchar это строка с len = 0, для числовых типов 0.
Мне всегда казалось что там, где есть
публичные мессенджеры для внутреннего общения не используются (у нас явно запрещены для обсуждения рабочих вопросов, в ТГ есть командные чаты для просто потрепаться, но не более того). Только то, что может быть self-hosted на серверах во внутреннем контуре компании.
В нашем случае, например, используются K-Talk, RocketChat (форк), Cisco Jabber (с привязкой к внутренней IP-телефонии). Сейчас идет замена Рокета и Циски на форк eXpress (т.е. в идеале остается Толк для конференций и Экспресс для всего остального (тоже будет привязка к телефонии) - личные звонки, чаты, командные и тематические каналы. Все рабочие вопросы обсуждаются только там.
Авторизация, естественно, не по номеру телефона, а по корпоративному логину-паролю + IndeedKey.
На винде не заработало. Запускается, просит открыть папку и все... Прозрачное окно и ощущение что не делает вообще ничего (загрузка процессора программой колеблется от 0 до 0.3-0.5%)
Так что по старинке - darktable. Или RawTherapee
Не умею. И даже учится не хочу...
Я много чего перепробовал - начинал под голым досом в донортоновские времена. Первое, что был попыткой изобразить хоть какой-то файловый менеджер, еще до нортона, был, по-моему, PCTools.
Так что много чего было, в итоге остановился на дубле как самом для себе приемлемом.
Я на винде-то фаром пользоваться не мог. Интерфейс вообще не заходит. Хотя есть любители, да...
Пользуюсь дублем. В первую очередь потому что он одинаковый и на винде и на линуксе (одна машина под виндой, вторая по линуксом) не надо думать "а как тут вот это..." - при одинаковых настройках все одинаковое. Ну и он бесплатный в отличии от тотала.
Не думаю. Просто раньше месяцы занимало переписывание, сейчас то же время уйдет на доскональную проверку каждой строки того, что оно там нагенерило.
И что там 98% тестов проходит - не показатель.
В спортивном фехтовании (приятель был - КМС, рассказывал тонкости) сейчас три дисциплины - рапира, шпага и сабля (эспадрон).
Шпага и рапира - колющие. Отличаются весом (шпага тяжелее), хватом (рукоять разная), формой клинка (четырехгранный у рапиры и трехгранный у шпаги) и зоной поражения - у рапиры только корпус, у шпаги все тело. Длина клинка одинаковая.
Сабля - рубяще-колющее. По весу как рапира, но чуть короче клинок. Хват как у шпаги. Зона поражения - все, что выше пояса (корпус и руки).
Фокусы МВД. Подтверждение ИНН (от ФНС) через СМЭВ как работало, так и работает. Та сбоев не было.
Лучше "Палата №6"
Ну тут человек представлялся именно как сотрудник службы безопасности или комплаенса или чего-то такого еще, что подразумевало именно штат альфы. Т.е. этот человек по ФИО должен сразу высветиться в поиске в джаббере или на внутреннем портале альфы - должность, подчиненность и т.п.