Убрать ограничения по таймауту

[Greed]

Добрый день. Иногда с талкиваешься с тем, что z-программы, написанные для любимых пользователей, сильно долго работают и вроде как уже достаточно оптимизированы, но времени для отработки не хватает и вылетают по таймауту. Можно ли как-то в коде сбрасывать таймаут, что б прога работала пока не закончит, либо пока не надоест и не сбросишь вручную...?

[Sam]

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

[Uukrul]

вам надо обратиться к своему базису.

Но они могут и отказать, причина в том что количество диалоговых процессов в системе ограничено, если их забить вашими программами то по факту вы подвесите всю систему. Как обходной метод если у вас в цикле отрабатывают несколько разных селектов, поставьте между ними вызов COMMIT WORK, это сбрасывает счетчик времени процесса.

[Greed]

спасибо. Интересно, что под парой пользователями программа в дамп не падает и судя по тому, что она уже часа 2 работает как я ее запустил, то и подо мной тоже)

[Semen F.]

спасибо. Интересно, что под парой пользователями программа в дамп не падает и судя по тому, что она уже часа 2 работает как я ее запустил, то и подо мной тоже)

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

[Greed]

не, они на том же работают. Базисники разводят руками:"копай свою прогу..."

[Semen F.]

Тут вопрос комплексный. В зависимости от сложности запроса и размеров таблиц время выполнения может быть разным и если ваша программа работает как должна и оптимизировать её дальше не представляется возможным, то возможно стоит обсудить увеличение времени работы диалогов с базисом.
Кстати мы так и не узнали с какой ошибкой падает ваша программа...

[Uukrul]

Кстати мы так и не узнали с какой ошибкой падает ваша программа...

Кстати, да... если можно кусок начала дампа в студию... а то параметр времени выполнения на процесс оно глобальное и не может так быть чтобы у одних работало у других нет.

[Greed]

у меня в дамп не падает, вот есть только то, что у пользователя...

[Uukrul]

у меня в дамп не падает, вот есть только то, что у пользователя...

Ну да времени не хватило... но тут еще надо смотреть с какими параметрами запускают, поэтому них падает у тебя нет.

[Semen F.]

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

[Greed]

коммит верк счетчик таки сбрасывает) В общем в исключительных случаях его применить можно.

[Uukrul]

коммит верк счетчик таки сбрасывает) В общем в исключительных случаях его применить можно.

Сбрасываться то сбрасывается, но там еще кроме этого оно делает следующее:

• 
  Выполняет запуск всех подпрограмм, которые вызываются с использованием инструкций вида PERFORM <имя подпрограммы> ON COMMIT и всех функциональных модулей объявленных как CALL FUNCTION <имя модуля> IN UPDATE TASK.
• Вызывает инициирование событий для службы Object Services. Поэтому если у вас есть фоновые процессы, запускающиеся по событию, то именно эта операция генерирует все заявленные в блоке обработки события.
• Обрабатываются все SAP блокировки, установленные в текущей программе по значению формального параметра _SCOPE для соответствующих функций блокирования, происходит снятие таких блокировок.
• Закрывается текущий LUW блок и все курсоры на уровне базы данных.
• Вызывается событие TRANSACTION_FINISHED, что устанавливает для системного класса CL_SYSTEM_TRANSACTION_STATE  значения COMMIT_WORK.

так что если вам выше описанные действия не беспокоят.. то можете и через COMMIT WORK делать сброс счетчика времени выполнения транзакции.