Опыт использования SETOBJACC

Главная Форумы IBM i (OS/400) Опыт использования SETOBJACC

Просмотр 64 веток ответов
  • Автор
    Сообщения
    • #11898
      Сергей
      Участник

      Есть у кого-нибудь практика использования сабжа для EQUATION?

      Интересно было бы снизить время блокировки при работе с некоторыми микро таблицами, но есть опасения за целостность данных.
      Если есть опыт – каков эффект?

    • #11899
      Sever
      Участник

      Реального практического опыта нет. Есть хорошие результаты рафинированных тестов прогонов некоторых фаз EQDа с предварительной загрузкой файлов EQ в память 1Тб с помощью setobjacc. Результаты по времени выполнения отличались в разЫ при сравнении с обычным механизмом подкачки нужных страниц. Выигрыш гарантируется при условии наличия “хорошего” объема ОП. Если памяти мало, то от setobjacc может быть больше вреда, а не пользы.

      setobjacc не фиксирует объект в памяти. Дается команда системе загрузить его туда, и она честно это делает, при этом при каждой загрузке системе по барабану помещается объект в пул или нет. Все то, что было загружено ранее по setobjacc, не имеет никакого приоритета перед прочими страницами при следующем setobjacc.

    • #11900
      Сергей
      Участник

      С EOD результат более-менее предсказуем, особенно при multystreaming.
      Нашу ситуацию я спрогнозировать не возьмусь, а стресс-тест организовать проблематично.

      проблема в том, что после перехода на 3.82 и отмирания “мостика” начались блокировки таблиц и “вылеты” стандартных масисовких программ в дамп – со всеми вытекающими. Масис то мы заставим переписать софт по человечьи, а вот что делать с задержкой в 60-70 секунд на любой вызов АПИ для внешних интерфейсов…

      Лидер по локам – крохотная табличка в 20-30 байт с неизменным содержимым (по крайней мере с нашими настройками). И вот здесь – сплошные вопросы.

    • #11901
      Sever
      Участник

      нужно больше инфы
      что за таблица и как она используется.

    • #11902
      pre
      Участник

      setobjacc не фиксирует объект в памяти

      Это обходится выделением приватного пула под это дело.

      Используем setobjacc для начальной безусловной загрузки в пул некоторых индексов и програмок на продакшн. Прирост в быстродействии ощутимый.

    • #11906
      Сергей
      Участник

      Вот это уже интереснее. Что вы таким образом ускоряли?
      У нас сейчас 2 проблемы:
      1. дампы при формировании СВИФТовок из чистых платежей и сделок
      2. тормоза при вызове АПИ из внешних систем.

      1-ое можно побороть в ожидании патчей (по вашему сценарию)
      а вот со вторым что делать (кроме как засунуть весь юнит в ОЗУ) пока не ясно…

    • #11907
      Sever
      Участник

      Причину тормозов нужно анализировать. От “молитв” в форуме толку не будет.
      Стандартный путь – обратиться в софтверный сервис IBM. В лаборатории в Рочестере есть специалисты, которые могут по стандартным perf-коллекциям + JW-коллекциям однозначно определить причины таких проблем и дать рекомендации по их устранению.

    • #11908
      Сергей
      Участник

      А… вон оно в чем все дело!
      мы-то, тупенькие, их к себе привозим, а надо-то только файлики посылать!

    • #11930
      Jevgeni Astanovski
      Участник

      По поводу свифтовок – не скажу.
      По поводу задержек АПИ – думаю, что мы тут неплохие специалисты ИМЕННО в этом вопросе.
      Возможно, сможем посоветовать, где искать.
      Работаем в этом направлении уже больше 10 лет, в том числе и свои АПИ пишем – немало.
      Я не наблюдаю существенных задержек, особенно многосекундных.
      Внешние системы без проблем прикладывают по 20-30 ITA в секунду, причем в течение длительного времени. И машина у нас не как у Севера, у нас довольно слабая P10.
      Работаем на 3.6, готовимся к 4.0. Я там тоже пробовал – ПРИНЦИПИАЛЬНЫХ изменений по скорости нет.
      А мостика уже да-а-а-вно-о-о нет.

      Если хочешь пообщаться по поводу API – напиши в личку.

    • #11959
      pre
      Участник

      а вот со вторым что делать (кроме как засунуть весь юнит в ОЗУ)

      Если разница в отклике связана с отказом от мостика, то предположу, что в отличии от джобов внешних интерфейсов мостик бежал в уже готовой среде юнита и держал нужные файлы открытыми. setobjacc здесь может помочь, если принудительно вытащить в пул объекты, которые копируются в QTEMP джобов при заходе в юнит. Практически единственный способ держать необходииые для API файлы открытыми – избегать поднятия новых джобов и организовать пул на уровне придожений.

      Внешние системы без проблем прикладывают по 20-30 ITA в секунду

      Это в одном джобе или в сумме? Если в одном, то действительно интересно как получается так нагрузить аэску через интерфейсы.

    • #11960
      Jevgeni Astanovski
      Участник

      Это в одном джобе или в сумме? Если в одном, то действительно интересно как получается так нагрузить аэску через интерфейсы.

      В одном джобе. В сумме существенно больше бывает.

    • #11963
      Сергей
      Участник

      Благодаря ИБМ, система у нас стабилизировалась, но проблема с внешним интерфейсом как была, так и осталась

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

      К сожалению все несколько сложнее – батчи, отстёгиваемые в “зеленом экране”, (с теми же самыми АПИ для работы со сделками) отрабатывают вполне себе пристойно.

      при относительно небольших нагрузках все работает вполне сносно – дочерние банки, которые сидят на слабеньком ЛПАР на тестовой машине, так и вообще горя не знают…

      самое загадочное, что на резервном 570-ом с P6 процами и ОС 5.4 задержка гораздо меньше, а вот на 770-ом хосте с P7 и ОС 6.1 – стабильные 60-70 сек. от Oracle Transparent Gateway на блокировке таблицы GW124P, длиной в одну запись.

      ясно одно – проблема чисто софтовая, и скорее всего виновата JVM или сам Oracle TG.

    • #11964
      Jevgeni Astanovski
      Участник

      Серго,
      мостик тут абсолютно к делу не относится. В старых версиях (из того, что у нас было) мостик обрабатывал только сделки (deals). Это было при медленных машинах. Сделка вводилась с определенным статусом в GYKSC и вызывающая программа шла дальше. Мостик эту сделку подхватывал и генерировал необходимые постинги. Если все прошло успешно, сделка получала “нормальный” статус в GYKSC. Если не успешно, то часть проводок оставались несделанными, статус ненормальным и бывало что и мостик падал.
      Теперь машины быстрые и постинги связанные со сделкой генерируются на ходу и только по окончании этого процесса API получает ответ. То есть обработка ВСЕХ АПИ стала СИНХРОННОЙ.
      Далее, что касается GW124P. Насколько я кое что понимаю, это файл не используется “впрямую”. У меня создается впечатление, что для джоба создается его копия в QTEMP. В этом случае все Ваши упражнения абсолютно бесперспективны.
      По крайней мере у меня этот файл в KWRKxxx пустой!

      Мне например было бы крайне интересно увидеть фрагмент лога того джоба (любого из) на AS/400, который выполняет API по вызову извне.

      Еще раз предлагаю написать мне в личный адрес – он есть в моих данных.

    • #11966
      Сергей
      Участник

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

    • #11967
      Jevgeni Astanovski
      Участник

      Но при том, что интерфейс по сделкам действительно стал синхронным, у нас там не возникает таких задержек. Мы вводим депозиты автоматом в Equation прямо из интернет-банка. Время исполнения менее секунды, в котороую включено принудительное ожидание минимум 500 миллисекунд между вызовами G36 и G40.
      С почтой – да. Я посмотрел свою – мне видна. Решил, что видна и другим.
      Поискал твою – не увидел 🙁
      Значит, не видна….

    • #11968
      Michael
      Участник

      А что мешает послать письмо в “личку” на сайте? :blush:
      Установите контакт, обменяетесь “нормальными” емейлами…

    • #11969
      Jevgeni Astanovski
      Участник

      Я так и сделал. 🙂

      Просто решил, что раз я свой адрес ввел, то его и другие залогинившись видят.

      За “секретного физика” себя не держу, хотя по зрелому размышлению – оно правильно.

    • #11970
      Michael
      Участник

      А рядом с Вашим мылом в профиле три иконки стоят. И средняя говорит, что это поле (емейл) в профиле не будет видно ни Вам ни другим. 🙂

    • #11972
      Sever
      Участник

      К теме “блокировок”…

      http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/MA40663

      Фикс создан на базе анализа коллекций системы, где работает EQ. CRTDUPOBJ – создает большие накладные расходы и тяжелые seize contentions, особенно при лавинном старте задач.

      В ту же тему…
      http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/MA40634

    • #11973
      Jevgeni Astanovski
      Участник

      CRTDUPOBJ вообще крайне скверная команда, так как она требует полного доступа к source объекту.
      Когда я сталкивался с этой проблемой В СВОЕЙ программе, то я делал CRTDUPOBJ без контента (это – быстро) с последующим CPYF, который не блокирует источник.

      Но гадость то здесь в другом. Мы, например, вообще не знаем, что такое “лавинный старт задач”. Тут в любом случае не идет ведь речь о запуске 3-5 задач, а скорее о десятках-сотнях. У нас джобы для API запускаются 1 (один) раз – утром. И никаких лавинных стартов.

    • #11974
      Sever
      Участник

      У меня много пакетной отчетности, которая обрабатывается в многопоточном режиме. Многие десятки тысяч задач за сутки. Почти во всех на этапе инициализации дублируется макет файлов в QTEMP. Дублирование даже без данных по мнению IBM порождает многочисленные конфликты. Они особо заметны при 100% или около того загрузке на картинках в Idoctor-е. Много дублирования в обычных программах от майсиса и сashiere. Их просто не видно;)
      По мнению лабы проблема еще глубже – при интенсивном создании/удалении объектов одного ownerа возникает другая проблема. Все эти объекты и авторизации на них отображаются в индексе профайла владельца. При высокой интенсивности такой активности возникает конфликт доступа к профайлу для синхронизации этих изменений со стороны сотен задач. В особых случаях все задачи имеющие отношение к этому профайлу может вообще заклинить на минуты.

    • #11975
      Сергей
      Участник

      до работы мне сегодня добраться не судьба.

      Но гадость то здесь в другом. Мы, например, вообще не знаем, что такое “лавинный старт задач”. Тут в любом случае не идет ведь речь о запуске 3-5 задач, а скорее о десятках-сотнях. У нас джобы для API запускаются 1 (один) раз – утром. И никаких лавинных стартов.

      Diktor, такие сервисы, что стартуют один раз, а потом в потоке обрабатывают запросы, и у нас здравствуют. Тот же мостик, только в профиль.

      Проблема именно с “лавинными” запросами, источником которых является парочка сервисов, один из которых работает по чистому jdbc, а другой – через оракловый гейт.
      проблемы именно с последним, пул коннекций на котором достаточно велик – 200-300, и только при интенсивности вызова АПИ в десятки в секунду и в обязательном порядке из обоих источников – от гейта и из “зеленого экрана”.

      Чистоте анализа мешает то, что даже “родные” опции чистых платежей и генерации МТ103 и МТ300 блокируют сами себя, до смешного – пользователь авторизует платеж, приступает к следующему и вторая операция блокирует первую, с дампами и прочей прелестью.
      Масис генерит заплатки, но толку от них пока – чуть.

      Вывод этого самого файлика и еще кое-каких программ и таблиц в ОЗУ, кстати, ничего не дал.

    • #11976
      Сергей
      Участник

      Насчет CRTDUPOBJ – эта беда от Масиса неотделима, к сожалению.
      Когда это было актуально, была идея заменить процедуру создания окружения и вместо дублирования объектов использовать восстановление из савфайла всего комплекта, причем заранее заполненного и подготовленного для каждого пользователя при закрытии дня. нарастить мощность сервера и поставить оверрайды на объекты, на том этапе, оказалось проще.

    • #11983
      Sever
      Участник

      до работы мне сегодня добраться не судьба.

      Проблема именно с “лавинными” запросами, источником которых является парочка сервисов, один из которых работает по чистому jdbc, а другой – через оракловый гейт.
      проблемы именно с последним, пул коннекций на котором достаточно велик – 200-300, и только при интенсивности вызова АПИ в десятки в секунду и в обязательном порядке из [b]обоих источников[/b] – от гейта и из “зеленого экрана”.

      Вывод этого самого файлика и еще кое-каких программ и таблиц в ОЗУ, кстати, ничего не дал.

      Если эти задачи-запросы на “вашей” стороне работают в виде QZDASOINIT, то нужно аккуратно настроить параметры для этих престарт задач в подсистеме QUSRWRK. Нужно изменить значения по умолчанию для нижней границы числа этих задач на нужное значение, которое в вашем случае может лежать в районе 300. Это устранит избыточные старт/стопы. Аналогично нужно изменить дефолтные параметры для signon-сервера. Для него нужно поднять ничнюю границу минимум до 10 задач. Интенсивные старт/стопы этих престарт-задач жутко негативно влияют на производительность системы. А вообще пул на три сотни коннектов это жутко много. Имеет смысл договориться с внешним сервисом об ограничении пула с их стороны. От такого числа коннектов толку никакого.
      Кстати, если не секрет, ваш хомбанк.KZ и есть один из этих двух сервисов?

    • #11988
      Jevgeni Astanovski
      Участник

      Мы добились нормальной производительности таким образом, что для каждой АПИ, вызывающейся из внешнего интерфейса, есть ИНДИВИДУАЛЬНЫЙ обработчик (иногда больше одного). Он запускается при начале дня и дальше все АПИ данного типа идут через запущенный environment. Это значит, что окружение создается один раз на весь день. Поскольку по требованию Майсиса АПИ должны компилироваться в режиме ACTGRP(*CALLER), вся необходимая среда, включая, кстати и глобальные переменные, остается в вите материализованных объектов в течение всего дня.
      Первый вызов занимает в РАЗЫ больше времени – создается активационная группа, среда с дата ареами, library list, загружаются в память H56/H46 и конретная АПИ. Зато потом летает.
      И не надо ничего настраивать дополнительно.
      При проектировании своего Gateway (еще в прошлом веке) мы пробовали гонять через один обработчик разные АПИ – потеря в производительности была почти десятикратная.
      Правда Леонид (Райков) один раз, сделав хитрое лицо, сказал мне, что он знает, как эту проблему можно обойти. Но не сказал как.

      А задачи эти крутятся не в виде QZDASOINIТ а в виде QZRCSRVS, то есть используется “чистый” RPC.
      Мне сильно интересно, можно ли “заставить” jdbc работать так же.

    • #11990
      Sever
      Участник

      IMHO тут подмена понятий.
      Когда говорят, что соединение с хостом осуществляется с помощью jdbc, то доподлинно известно, что соединение вызывается из джава-приложения внешней системы. На принимающем запросы хосте нет никакого jdbc сервиса. На какой порт хоста производится запрос соединения и по какому стандартному или нестандартному протоколу осуществляется обмен определяется jdbc-драйвером находящемся на внешней системе. “Ответкой” на хосте может быть как хостсервер запросов к базе данных данных, так и “нестандартный” листенер для установки сокетных соединений, который может обрабатывать соединения по произвольному порту.

      Другими словами, как jdbc-драйвер запрограммирован, так и будут работать коннекты. Соединение может держаться неопределенное время и пропускать через себя множество последовательных порций обмена, а может тупо “рваться” после каждой транзакции…

    • #12009
      Сергей
      Участник

      Кстати, если не секрет, ваш хомбанк.KZ и есть один из этих двух сервисов?

      Не секрет – да, он входит в первую группу сервисов, с которыми проблем нет, тех самых, что сидят на jdbc пулах. Он вообще асинхронен, впрочем нет особых проблем и с синхронными сервисами, которые “сидят” на ODBC/JDBC.

      Проблема с фронтальным приложением, которое никак не получается всунуть в разумное число коннекций – пробовали… Вот оно-то как раз синхронное и ходит через оракловский “черный ящик” – Oracle TG, который и для IBM – чужой, да и Oracle эта штуковина, что стоит на iSeries, не слишком интересна.
      Консилиум IBM-Oracle стабилизировал эту связку, но и только.

      Дальше этого пока руки не доходят – большое количество разнообразных косяков внутри самого EQ.
      Жаль, что мы не можем отключить транзакционность, как это сделали в Альфе 😉

    • #12010
      Jevgeni Astanovski
      Участник

      Жаль, что мы не можем отключить транзакционность, как это сделали в Альфе 😉

      Так, так, так. А вот с этого места, можно поподробнее?
      Что такое “транзакционность” на языке диаспоры? Имеется в виду “Commitment control”?
      КазКом использует Commitment Control а Альфа – нет?
      Меня этот вопрос крайне интересует, так как мы не используем сейчас и между собой обсуждаем вопрос о том, пробовать его включить или нет.
      Misys, конечное дело, говорит: “Да! Да! И как можно скорее!”
      Правда, на вопрос: “Как?”, мямлит что-то невразумительное (Commitment Control + Mimix).

      Север, Серго?

    • #12011
      Sever
      Участник

      CC идет лесом :laugh:

    • #12015
      Jevgeni Astanovski
      Участник

      На данный момент у нас тоже “идет лесом”.
      И, самое смешное, что я не могу сказать, что его отсутствие (прогулка по лесу) как-то меня напрягает.
      Альфу напрягает?
      Судя по жесткому 😉 ответу Севера – не очень…
      Серго, судя по косвенным признакам :dry: , вовсе его наличие напрягает…
      У моих знакомых в Риге СС включен. Майсис о них гордо сказал: “Сами настроили, вот как легко и просто!” Так вот они ворчат на него, правда, со свойственной нам – северянам (пардон за каламбур 🙂 ) сдержанностью.

      Напрягся то я по другой причине. Мы сейчас на 3.60. Уже на ней появились первые звоночки “фрагментов” СС, которые НЕВОЗМОЖНО отключить. Они доставили нам большой баттхерт.

      Сейчас начали возиться с 4.0. Если ребята из Бангалоров-шмангалоров продолжат в том же духе, то где нам еще ждать гадостей и до какой степени там не будет СС если он выключен?
      Черт его знает.

    • #12022
      Сергей
      Участник

      Именно Commitment Control я и имел ввиду, а что, возможны разночтения? 😉

      Нда, чудны дела МаСиса – мне они тычут в нос Альфой, – “Вон они какие большие, больше вас, а выключили и перешли без проблем”. Правда все это неофициально, по телефону, “забывая” упомянуть, что от нативного EQ в Альфе окромя ядра мало что осталось, да и мостик имени BTC живет и здравствует (что и здорово!).

      Отключать СС? Ну, уж нет! у нас и с ним-то база расползлась разок, а что это будет за винегрет если его отключить и представить страшно.
      На дочерних банках – легко! Впрочем у них и так проблем нет, что с СС, что без него.

      Все наши нынешние проблемы корни свои имеют в кривом (с точки зрения транзакционности) коде МаСиса, разве что оракловый гейт особняком, но и эти проблемы ПРЯМО с СС связаны.
      НО отключать его мы не будем, даже пробовать не собираемся – пусть мы будем маяться еще 2 года с кривым кодом и говорить на малайском инглише, пусть “вылетают” финансовые транзакции, но база будет целостной.

      Так что, как оно было без СС и стало с ним – ничего не скажу, у нас был мостик, а потом сразу СС.

      Насчет 4.0 не переживай – фиксы, которые мы выстрадали, в доке имеют приписку – будет включен в 4.0, так что повремени с годик и перейдешь гладко. 😉

    • #12024
      Sever
      Участник

      2Sergo: Я погуглил вас на выходных – вы молодцы! Крупнейшие в Казахстане. Зауважал.
      Появилось несколько вопросов…
      Как у вас с резервированием системы?
      Как у вас с электричеством? бывают ли проблемы?
      Как с каналами связи?
      Есть ли своя команда сопровождения железа и софта?
      Есть ли уже локализация казахского языка в OS?

    • #12028
      Сергей
      Участник

      Как у вас с резервированием системы?

      Мимикс-овский дизастр только предстоит в этом году. Пока только прокачка и развёртка копий между ДЦ. Мимикс будет реплицировать в ДЦ в другом городе.

      Как у вас с электричеством? бывают ли проблемы?

      Ну, если пьяный электрик рубильником щёлкнет, то будут 😉 Обычная схема – полное резервирование всего на свете.

      Как с каналами связи?

      Двойной резерв – земля-космос, кое-где и тройной

      Есть ли своя команда сопровождения железа и софта?

      А только своя и есть, хотя железо – это больше по части партнера IBM (CBS, скоро и вы с ним познакомитесь).

      Есть ли уже локализация казахского языка в OS?

      Официальной нет и не будет (кроме unikod). Есть 2 “наколеночных” решения и крякнутый Client Access, но мы их не пользуем – для бэка это не критично, а со фронтом и так все в порядке.

    • #12032
      Jevgeni Astanovski
      Участник

      Именно Commitment Control я и имел ввиду, а что, возможны разночтения? 😉

      А хрен его знает. Мне кажется, что лучше переспросить, чем недопонять. Да и языки то у нас разные – глянь на глобус – где ты, где я 🙂

      Нда, чудны дела МаСиса – мне они тычут в нос Альфой, – “Вон они какие большие, больше вас, а выключили и перешли без проблем”. Правда все это неофициально, по телефону, “забывая” упомянуть, что от нативного EQ в Альфе окромя ядра мало что осталось, да и мостик имени BTC живет и здравствует (что и здорово!).

      Я все-таки снова позволю себе переспросить. ТО есть правильно ли я понял, что Misys неофициально советует вам ОТКЛЮЧИТЬ Commitment Control и будет вам счастье на века?!

      Отключать СС? Ну, уж нет! у нас и с ним-то база расползлась разок, а что это будет за винегрет если его отключить и представить страшно.
      На дочерних банках – легко! Впрочем у них и так проблем нет, что с СС, что без него.
      Все наши нынешние проблемы корни свои имеют в кривом (с точки зрения транзакционности) коде МаСиса

      Вот ты сам пишешь, что код кривой с точки транзакционности…
      За последние лет десять база была у нас слегка неаккуратная раз пять. Не больше. Починка состояла из 2 этапов – и это важно.
      Этап 1: Misys чинит базу и локализует причину (обычно “хитрая” сделка).
      Этап 2: Такого рода сделки/операции попадают под категорический запрет, нарушение которого карается расстрелом на 10 лет без права переписки.
      Конечно это требует дисциплины, но с ЭТИМ у нас нормально 😉

      Так что, как оно было без СС и стало с ним – ничего не скажу, у нас был мостик, а потом сразу СС.

      Просто для корректности – они не связаны между собой иначе, чем ВАШИМ графиком и схемой апгрейдов.

      Насчет 4.0 не переживай – фиксы, которые мы выстрадали, в доке имеют приписку – будет включен в 4.0, так что повремени с годик и перейдешь гладко. 😉

      Согласен. По моим прикидкам они справятся с тем, что СЕЙЧАС в очереди на 4.0 примерно к концу этого года. Мы реально пойдем на 4.0 (если пойдем) не раньше середины следующего – так что так оно и получится.

      Кстати по поводу 4.0 и проблемы 2050 года.
      В прошлом году нам всем (кто присутствовал – кстати КазКому поставили прогул!) было с высокой трибуны DisneyLand-а объявлено, что она наконец-то решена в 4.0.
      Ну и я, конечное дело, получив его тут же попробовал.
      Ввел кредит, сгенерировал график, вроде сгенерировался. То есть ошибку не выдал.
      Стал на график глазами смотреть, а он какой-то странный.
      Пригляделся – до 2040 года нормально, а дальше некрасиво.
      Ага, думаю, знаю! Агент календарь то ввел только до 2040 года! Счас введу дальше, и будет мне счастье.
      А вот хренушки – календарь можно ввести только до 2050 года, а дальше НЕВОЗМОЖНО!!! :woohoo:
      Ну и скандал был… По моему все получили по рогам.
      “Ой!”, сказали: “А про календарь то мы забыли!”
      :angry:

    • #12043
      Sever
      Участник

      2Sergo: Спасибо.

    • #12044
      Сергей
      Участник

      Misys неофициально советует вам ОТКЛЮЧИТЬ Commitment Control и будет вам счастье на века?!

      угу, типа того. и всё ваши, северные – Лариса П.

      За последние лет десять база была у нас слегка неаккуратная раз пять. Не больше. Починка состояла из 2 этапов – и это важно.
      Этап 1: Misys чинит базу и локализует причину (обычно “хитрая” сделка).

      Не имеет смысла сравнивать – у нас на дочерних банках база не ломалась ни разу, ни на одном (ну может разок и было – точно уже не помню), а у нас она редко какой год раз по 10 не разъезжалась.
      Это при том, что перед закрытием дня целая пачка проверок на целостность выполняется.

      С вами очевидно какой-то другой МаСис работает, фантастика – Масис базу чинит.

      У нас уже есть опыт краха в 3.82 (не дай бог вам такого), так что увольте от авантюр.

      Просто для корректности – они не связаны между собой иначе, чем ВАШИМ графиком и схемой апгрейдов.

      а также skill и способностью им поделиться.

    • #12046
      Сергей
      Участник

      Кстати по поводу 4.0 и проблемы 2050 года.

      А вот тут уже я напрёгся слегка… Первый раз слышу.
      А потом отпустило – 2050, про кредиты длиннее 20 лет у нас в жизни не слышал.
      К тому времени, ни меня на прежнем месте, ни самих сделок в EQ не будет.

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

    • #12048
      Jevgeni Astanovski
      Участник

      угу, типа того. и всё ваши, северные – Лариса П.

      Просто уточню – с моей точки зрения Лариса – южная, а не северная. 😆

      С вами очевидно какой-то другой МаСис работает, фантастика – Масис базу чинит.
      У нас уже есть опыт краха в 3.82 (не дай бог вам такого), так что увольте от авантюр.

      Может действительно – разные 🙂
      На самом деле у нас договор на Emergency Support. По нему при аварии EOD мы можем позвонить в любое время суток по какому-то номеру телефона и в течение 30 минут нам будет выделен специалист – действительно из лучших. Его обязанность: сделать так, чтоб конец дня прошел и мы смогли работать утром. Раза 3-4 обращались, уровень – реально высокий.

      Обычный суппорт отличается.

      В своей массе крайней бестолковостью и неторопливостью.

      а также skill и способностью им поделиться.

      Это уже какие-то ваши внутренние разборки, как я понимаю.
      У нас проще: семейный подряд на железо и софт и всего 20 лет опыта на двоих.
      Попробуй не поделись 🙂

    • #12049
      Jevgeni Astanovski
      Участник

      Ну то, что ты не слышал про 2050, не значит, что в КазКоме никто не слышал. Со мной рядом на конференции в Дубае сидели 2 девушки из вашей фирмы, когда я первый раз об этом прокукарекал громко.
      У нас уже сегодня есть кредит на (сейчас специально посмотрел) 42 года, который заканчивается в октябре 2049. Правда только один 🙂

      А о каком заветном файле идет речь, если не секрет?

    • #12051
      Сергей
      Участник

      у нас, Emergency Support – это мы сами. Хотя, если уровень высокий… поинтересуюсь.

      Я проплачивал Dedicated Support 24*7 на период миграции – ну, да несколько живее реагируют, но уровень филлипино-малайцев от этого не меняется.

      Тот самый GW124P, который у вас пустой

    • #12060
      Сергей
      Участник

      В качестве итога, если кому интересно, то вот еще одна глава в MiSys CooсkBook:

      после накатки журнального ввода через стандартное кменю (у нас это было после дизастра) файлик GW124P- Journal Sequence work file остается заполненным девятками и прочими шаблонными символами – всего-то одна запись.

      Предназначение этого объекта весьма смутно представляет себе и саппорт масиса (по крайней мере, case, как ввел их в кому 2 недели назад, так и по сию пору они из нее не выбрались).
      Заявлено в доке и проверено на собственной шкуре – используется при накатке журналов, а вот утверждение, что он используется при взаимодействии со внешними системами, в нашем случае подтверждения не нашло…

      Итог изысканий – наличие записи в этой таблице заставляет весь внутренний АПИ (через UTM88R) “идти” по другой ветке.
      Что оно там, себе, при этом думает, осталось загадкой, но после удаления этой записи – очереди блокировок от внешних интерфейсов сократились с сотен до 0-2.
      Время задержки сократилось с 60-70 сек. до 1-2 сек., что на пуле коннекций в 200-300 штук, нас устраивает полностью и дальнейших изысканий не будет (хотя направление уже понятно).

      На “внутренние” приложения это такого живительного эффекта не оказало, но и таких задержек там никогда не было и нет.

      Такую разницу между внутренним и внешним запуском одних и тех же программ, я для себя объяснил различным уровнем CC – на внутренних job-ах, это Job Level, а на гейте – Activation group level.
      Activation group на всех оракловых задачах одна и та же…

    • #12064
      Jevgeni Astanovski
      Участник

      Посмотрел у себя – забавно.
      В живой системе UTM88R не использовался НИ РАЗУ:

      Change date/time . . . . . . . . . . : 16/07/09 17:14:07
      Usage data collected . . . . . . . . : YES
      Last used date . . . . . . . . . . . :
      Days used count . . . . . . . . . . : 0
      Reset date . . . . . . . . . . . . :

      А вот на том юните, где мы накатывали на 4.0 инпут от 3.60 – использовался, так как накатывали его через внешний журнал.

      В живье мы этим не пользовались ни разу в жизни, ввод делаем исключительно через АПИ.
      Привыкли, наверно 🙂

      Тут я подумал. Предположим программа 1 пишет запись в файл А открыв его для записи/чтения. В тот же самый момент к этой записи обращается программа 2.
      Запись заблокирована программой 1, программа 2 это видит и остается ждать освобождения.
      Возникают 2 вопроса:
      1. Как часто программа 2 проверяет, не освободился ли файл А?
      2. Сколько всего времени программа 2 готова ждать освобождения? Или, что видимо, то же самое, через сколько времени она ругнется и вывесит MSGW?

    • #12077
      Сергей
      Участник

      В случае современного подхода (от direct odbc до hibernate) это определяется command timeout + exception в коде программы, соответсвенно ничего проверять не нужно. Как с этим у мастодонтов сложно сказать – то что ты озвучил, это перебор даже для масис, в случае CL, конечно, другого выхода нет, но на РПГ уже реально написать не столь затратную конструкцию.

      На практике, у нас был зафиксирован “рекорд” в 2 минуты.
      С уровнем CC activation group, никаких MSGW & dump не было ни разу.

      Зато на уровне Job – частенько ломались операции, которые пытались работать с залоченной другим job записью.

    • #12081
      Сергей
      Участник

      Вчера, на ночь глядя, лень было …
      Вот время ожидания, прописывается на файле

      Maximum record wait time . . . . WAITRCD 60

      работает только при нативном, прямом доступе. Ну, а дальше уже обработка ошибок…

    • #12110
      Jevgeni Astanovski
      Участник

      Я то как раз из-за этого параметра свой вопрос и сформулировал.
      Вот что мануал пишет по поводу параметра DFTWAIT в атрибутах JOB:
      [code]
      DFTWAIT
      Specifies, for the default maximum wait time, that processing
      of a job is held until a system instruction that
      requires a wait, such as a lock instruction, completes
      running. This default wait time is used when a wait time
      is not otherwise specified for a given situation.
      Normally, this is the amount of time the system user is
      willing to wait for the system before canceling the
      request.
      If the wait time for any instruction is exceeded, an error
      message can be either shown or automatically handled
      by a Monitor Message (MONMSG) command.
      The wait time specified for this parameter is ignored for
      read operations to database files; to specify that attribute,
      use the WAITRCD parameter of the appropriate
      database command (create, change, or override) for a
      physical, logical, or database file command.
      [/code]
      И вот что они пишут по поводу WAITRCD:
      [code]
      WAITRCD
      Specifies the number of seconds that a program waits
      for a record to be updated or deleted, or for a record
      read in the commitment control environment with
      LCKLVL(*ALL) specified. More information on record
      locking is in the DB2 for AS/400 Database Programming
      book. If the record is not allocated in the specified wait
      time, an error message is sent to the program.
      [/code]
      Это означает (как я понимаю), что если программа на RPG пытается писать запись, которая заблокирована, то у нее есть шанс узнать об этом грустном событии не ранее чем через 60 секунд.
      Так как сказано в писании:
      If the record is not allocated in the specified wait
      time, an error message is sent to the program.

      А значит пока это время не пройдет, ошибка не будет сгенерирована и даже если в программе есть обработчик, то он об этом просто не узнает…

      Я думаю, что минутные “зависания” как раз отсюда….

    • #12111
      Сергей
      Участник

      Я думаю, что минутные “зависания” как раз отсюда….

      точно так + разница в уровне блокировок сказывалась:

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

      для activation group – “гарантированное” ожидание в 1 минуту, т.к. задач в этой группе не мало.

      Что лично мне не понятно – почему при этом не было ни единого дампа от задач с Oracle TG, а ожидания больше минуты были.
      Command timeout на коннекции больше 60, но хранимка-то написана на РПГ, выполняется на iSeries и к этому параметру отношения не имеет. разница только в уровне СС.

    • #12136
      Sever
      Участник

      2Sergo Почитал пиар Казкома на банки.ру
      IBM последнее время везде умалчивает название “нашей” операционной системы. Зато несет пургу про Ватсон…

    • #12146
      Сергей
      Участник

      2 Sever.
      да, забавно это читается…
      вьюнош не виноват – о чем на прессконференции говорилось, то он и оттранслировал, а больше всего написал, о том, что лично его интересовало. Ержику мозг “ел” своими мобильными шняжками.

      это пиар не столько ККБ, сколько IBM-CBS (они все и организовали). А “Ууоотсон” любимая тема одного из вице-президентов ИБМ, которой она посвятила 20 минут на прессконференции и 2 часа на вечеренем мероприятии.

    • #12147
      Jevgeni Astanovski
      Участник

      Ну и пурга-а-а :woohoo:
      Мобильный катастрофозащищенный центр в котором (доктор?) Watson в перерывах между игрой в “Свою Игру” обрабатывает 200 миллионов СМС в год с помощью фотокамеры старенького телефона.
      И все это происходит под полонез “Прощание с Родиной” Огинского во время, с трудом осовободившееся после переработки 2000 программных модулей. Правда, за 2 года.

      Аффтар, выпей йаду!

    • #12148
      Jevgeni Astanovski
      Участник

      У меня складывается впечатление, что виновность лежит на Commitment Control.
      При работе без него Misys не испрользует блокировок. Это значит, что на уровне опреационной системы запись (ес-с-сно) блокируется, но только на время записи этой записи – пардон за тавтологию. При включенном же CC (да еще писанном левой задней ногой) по идее может оставаться весьма длинный хвост заблокированных записей на существенное время. Особенно здесь могут вылезать гадости из файлов “счетчиков” – например (но не исключительно) SBPF.
      Думаю, что мы похороним на время идею включения Commitment Control.

      Кстати тут у тебя промелькнуло о планах установки Mimix – было бы весьма интересно.
      Я тут не в затяжку спрашивал – у кого есть CC + HA Mimix, что-то как-то тихо :dry:
      У Рижан есть СС и НА, но у них репликация через IASP.
      Как я понимаю, Агент спрашивал у Misys, может ли кто-нибудь приехать и настроить СС, чтоб работал с существующим Mimix HA, но как то вразумительного ответа не поступило.

      Чего я совсем не понял из твоих писем, так это противопоставления “Job” и “Activation Group”.
      Не совсем понятно. AG не может работать вне джоба. Ну и с другой стороны – внутри каждого джоба одна или более AG.
      Насколько я понимаю….

    • #12149
      Сергей
      Участник

      Чего я совсем не понял из твоих писем, так это противопоставления “Job” и “Activation Group”.
      Не совсем понятно. AG не может работать вне джоба. Ну и с другой стороны – внутри каждого джоба одна или более AG.

      Это CC Level параметр (он же – Commitment Definition), который ставится на JOB и который разный на “внутренних” и “внешних” JOB-ах (ставится, например, через STRCMTCTL).

      команду не помню, посмотреть можно в wrkjob – 16

    • #12201
      pre
      Участник

      у кого есть CC + HA

      Независимо от реализации HA (чтение журналов или же через стораджи) необходимо максимальное журналирование, чтобы исключить вероятность потери данных, находящихся лишь в RAM. Те рижане, которых вы упомянули, насколько мне известно, из соображений производительности, поозволяют себе отключать журналы на время EOD, что не комильфо.

      Участие родных журналов EQ в реализации HA возможно, и не привязано к включению CC. Если интересуют подробности – дайте знать в лс.

    • #12202
      Jevgeni Astanovski
      Участник

      Может оно и не комильфо, но и по моему мнению такой вариант (НА отключено во время конца дня) является правильным. Можешь назвать это балтийской солидарностью :laugh:

      Причин 2.
      1. Если конец дня грохнется при включенном журналировании, он грохнется на обоих машинах и для ремонта нужно делать откат на обоих. При отключенном журналировании НА машина остается в прекрасном состоянии и сразу после ремонта данных там можно запускать конец дня.
      2. Со включенным журналированием коней дня о-о-о-чень медленный.

      Если же грохнется одна из машин (физически) во время конца дня, то всегда есть backup C05 или C50.
      Таким образом по нашему мнению вариант с отключением является правильным.

    • #12203
      pre
      Участник

      НА машина остается в прекрасном состоянии и сразу после ремонта данных там можно запускать конец дня

      После EOD на HA машине незакрытый день?

      Можешь назвать это балтийской солидарностью

      Если судить по представленным в форуме балтийцам, то это как раз сепаратизм:D

    • #12204
      Jevgeni Astanovski
      Участник

      После EOD на HA машине незакрытый день?

      Отчего же? По открытию дня, насколько мне известно, включается синхронизация Data Group.

      Если судить по представленным в форуме балтийцам, то это как раз сепаратизм:D

      Пожилого “балтийца” обидеть может каждый. И заступиться за него некому.
      После отъезда Агента в отпуск (на Украину) а Старого Ника – на работу (в Москву), мне приходится одному отдуваться 🙂

    • #12205
      pre
      Участник

      У вас, видимо, 24×7?

    • #12206
      Jevgeni Astanovski
      Участник

      У вас, видимо, 24×7?

      У нас нет Майсисовского 24х7.

    • #12207
      pre
      Участник

      У нас тоже нет. Просто EOD – термин от майсиса, а вот Data Group – нет.

      Похоже, тема ушла далеко от заголовка топика.
      Может, есть смысл сделать топик вроде курилки майсисоводов, невидимый без логина?

    • #12208
      Jevgeni Astanovski
      Участник

      Data Group это термин от Mimix

    • #12209
      pre
      Участник

      Осмелюсь предположить, что Mimix не имеет альтернатив только при реализации 24×7.

      По открытию дня, насколько мне известно, включается синхронизация Data Group

      Любой другой HA, включаая тот, что через стораджи, будет соотноситься EOD по-своему, и c успехом справляться с задачей обеспечения HA.

    • #12210
      Jevgeni Astanovski
      Участник

      Осмелюсь предположить, что Mimix не имеет альтернатив только при реализации 24×7.

      Мы же не обсуждаем варианты, ы просто писал, как оно есть у нас.

      Любой другой HA, включаая тот, что через стораджи, будет соотноситься EOD
      по-своему, и c успехом справляться с задачей обеспечения HA.

      Как я писал выше, у нас Mimix.
      По той причине, которую я назвал первой, есть смысл выключать любое HA на время конца дня – из соображений не грохнуть обе системы. Хотя как делают рижане, я не знаю.
      Думаю, что на performance IASP не влияет так сильно.
      К IASP я отношусь плохо, привык иметь все у себя.

      Но вот тема, которую я предложил – Mimix + CC – как-то развития не получила. Будем дружно наблюдать за усилиями КазКомерца, если у них с их летучим взрывобезопасным датацентром руки дойдут 🙂

    • #12211
      pre
      Участник

      diktor
      Спасибо.
      Прочитал всё написаное с большим интересом. Нахожу ваш подход аргументированным.

      К IASP я отношусь плохо, привык иметь все у себя

      К IASP я отношусь плохо, ощутимо удорожает решение. 🙂

    • #12464
      Сергей
      Участник

      Если кому-то интересно решение масис по GW124P и всему, что с этим связано, то вот оно

      FJRF – Fast journal recovery (DASYSCT2 col 172)
      NOSJ – Journal recovery stream jobs (DASYSCT2 col 173)

      CC174 introduced the functionality for fast journal recovery where applying of journals can be ran in stream jobs. However, this functionality is NOT available in any release as this was not fully tested. The 2 system options that control this functionality are NOT maintainable from menu so that it will NOT be activated.

      However, during the upgrade from EQ342 to EQ382, somehow these 2 system options were set up to FJRF=Y and NOSJ =004 in DASYSCT2 data area.

      When Fast Journaling is set to Y (FJRF=Y), UTM88R always read the first record of GW124P, but it does not release the lock. Thus succeeding jobs will have problem reading the first record and it will time-out.

      Therefore, to resolve this issue, please change manually data area DASYSCT2 position 172 to 175 to be: ‘N000’.

      Вот так вот все просто – косяк в процедуре миграции, полное отсутствие документации, мусор в дистрибудиве, 2 месяца времени на размышление, приезд специалиста… и проблем нет 😉

    • #12469
      Jevgeni Astanovski
      Участник

      История была так себе, но ее конец – супер!
      Агата Кристи отдыхает.
      Особенно мне понравилось фраза:
      “However, during the upgrade from EQ3.42 to EQ3.82, SOMEHOW these 2 system options …..”
      Побежал проверил у себя: везде стоит N004. В том числе и в EQ4.0.

      Фу-у-у-у.

      Но!
      Поскольку я являюсь неисправимым оптимистом (видимо климат способствует B) ) я приятно удивился, что Misys-у удалось таки найти этот косяк и еще и признаться в нем…

    • #12507
      Сергей
      Участник

      Однако, говорят, что нужно N000, а не N004…

      меня поведение масиса совсем не удивило, ибо это тётенька сидит рядом со мной в данный момент и в глаза нести ерунду сложно. тем паче, что она пришла в масис “от сохи” и поработала в 3 банках на администрировании EQ. + ко всему – это не саппорт и не сейлс, а разработка… их политесы волнуют гораздо меньше.

Просмотр 64 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.