День добрый!

Уважаемые гуру, подскажите пожалуйста, как можно из Data Studio сделать deploy хранимой процедуры так, чтобы ее исходник оказался в файле QSQLSRC? Впервые в жизни столкнулся в работе с этой СУБД, причем со специфической версией для мэйнфрейма - темный лес...

knudsenMikhail.Gurusov,

Да, кстати, AS/400 (iSeries, IBM i, Power Systems) <> Mainframe (System z, zSeries, s390),

а зачем исходники в SRC-FILE класть, это требование такое?

Что же тогда AS/400?

Да, есть такое требование - все исходники должны быть в src файле, админы потом используют эти скрипты для переноса между средами.

knudsen,

Спасибо за ссылки. Документацию усиленно читаю, но от этого легче не становится, слишком специфичная платформа. Rational Developer for i можно конечно попробовать запросить, но вряд ли его приобретение будет одобрено, все работают через Access for Windows.

Крайне удручает отсутствие в СУБД аналитических функций, для отчетности просто незаменимых. То, что есть (ранжирование) - просто слезы. Но больше всего удивляет скорость работы, миллионы записей перемалывает с потрясающей легкостью.

knudsenMikhail.Gurusov,

Вы собираетесь OLAP запросы на iSeires запускать? Господа знают толк в извращениях? Хотя вы уже на Power 7, так?

О да, в извращениях мы знаем толк, вся наша работа по большому счету извращение... OLAP не OLAP, но хранилище для отчетности именно на iSeries, меня не так давно угораздило сменить работу - до этого не имел дела с IBM вообще за все 20 лет... Все было - и MS SQL, и Sybase, и Oracle разумеется, и даже такая экзотика как Informix...

Какая именно там железяка стоит - понятия не имею, можно поинтересоваться, конечно.

Вчера перезалили рабочую станцию, и оказалось, что техсаппорт устанавливает только 6-ую версию i Access. Сегодня мудохался весь день с 7-ой версией, ибо задолбался ждать, пока до меня снизойдут - и таки установил ее, даже сразу с патчем. Натуральное извращение, но зато теперь у меня есть возможность анонимные блоки SQL выполнять - это просто праздник какой-то.

knudsenMikhail.Gurusov,

Не, не ... на IBM не жалуйся! Это уже религиозный спор получится. Лучше скажите (хитро так прищуриваясь) - у вас там Java-программы, случайно, никто на IBM i (iSeries) не запускает по обработке данных? Вот это самое извратное извращение (личное мнение).

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

Программы какие-то на Java точно есть, но я пока в эти глубины не погружался, мне бы с отчетами разобраться, и заставить наконец свою процедуру расчетную работать - задача-то выеденного яйца не стоит, а я бьюсь над ней уже две недели. Скачал кстати Rational, надо будет установить и посмотреть.

knudsenMikhail.Gurusov,

понятненько... не знаю как сейчас, но много лет назад я делал embedded SQL в программках на RPG (+CLLE), затем всё это вываливал или в печатную форму, или в data-file для доступа построителем отчётов... Но если есть коннект к базе, то можно и CALL PROCEDURE прямо со станции запустить.

Ну здесь к счастью есть средства построения отчетов - Crystal Reports, Business Objects. Отсутствие аналитических функций в СУБД - траур печальный, конечно, но что делать, придется извращаться...

knudsen,

Начинаю тихо закипать... В чем разница между RUNSQLSTM в терминале и Deploy из Data Studio? Одну и ту же процедуру создаю двумя разными способами, и получаю разный результат! После того, как загрузил исходник на сервер и прогнал RUNSQLSTM в терминале - результирующая таблица обновляется, если развернуть из Data Studio - при запуске процедуры получаю SQLCODE:-7008 SQLSTATE:55019 MESSAGE:Таблица ... в ... недопустима для операции.

knudsenMikhail.Gurusov,

Даже и не знаю что такое. Я вот и из "Сценария" создавал и из 5250 - арбайт по стахановски
Как делаете deploy?

Так:

Да, именно так и делаю deploy.

Весь фокус в том, что таблица не должна журналироваться - это витрины данных, которые в случае чего всегда можно пересчитать. Журналирование убивает производительность наповал, да оно в данной задаче и нафинг не нужно.

knudsen,

А что означает эта галочка - внедрить исходный код? Куда он, мать его, внедряется? Явно не в QSQLSRC. Ну и хрен бы с ним, в конце концов QSQLSRC нужен будет только тогда, когда передавать скрипты админам. Но при выполнении

RUNSQLSTM SRCFILE(.../QSQLSRC) SRCMBR(...) COMMIT(*NONE) DATFMT(*ISO) DFTRDBCOL(*NONE)

в результате процедура работает! И журналирования не требует. Видимо вся соль в COMMIT(*NONE)

Mikhail.Gurusovknudsen,

А что означает эта галочка - внедрить исходный код? Куда он, мать его, внедряется? Явно не в QSQLSRC. Ну и хрен бы с ним, в конце концов QSQLSRC нужен будет только тогда, когда передавать скрипты админам. Но при выполнении

RUNSQLSTM SRCFILE(.../QSQLSRC) SRCMBR(...) COMMIT(*NONE) DATFMT(*ISO) DFTRDBCOL(*NONE)

в результате процедура работает! И журналирования не требует. Видимо вся соль в COMMIT(*NONE)

Хотя у меня в тексте самой процедуры явно указано
SET OPTION USRPRF = *OWNER
,COMMIT = *NONE
,DATFMT = *ISO
,DBGVIEW = *SOURCE
,DFTRDBCOL = *NONE

Мда... Выполнить процедуру, использующую объекты из разных библиотек без явного указания схемы получается только из System i Navigator, после того, как выполняешь CL: ADDLIBLE LIB(...) для всех библиотек. Data Studio вроде как более продвинутый инструмент, и отладка в нем есть, но как для него задать список библиотек - непонятно... Rational Developer - могучая кувалда, позволяет даже в QSQLSRC залезть, но выполнить в ней отладку не получается - требует старта сервера отладки, а для этого нужны дополнительные права... В Data Studio форматирование исходников при развертывании слетает, в навигаторе все убогое до невозможности...

Тихо охреневаю - просто взрыв какой-то на макаронной фабрике... Какой инструмент в итоге использовать для разработки? Что-то стороннее искать?

knudsen,

5250 - это терминал? если да - то это совсем жестко, терминал - инструмент админа, а не разработчика, имхо...

Таблицы не логируются, совершенно точно, все дело в том, каким образом создается процедура. Версия у нас кстати 7.1, хотя вряд ли есть какая-то существенная разница.

Еще одна печаль - это вынужденное использование динамического SQL... Из-за огромного объема данных часть самых массивных таблиц периодические нарезается на отдельные куски, поквартально, или по году. В итоге заранее никогда не знаешь, где находится нужная тебе запись, по дате определяешь схему, в которой хранятся данные с периодом действия на определенный диапазон дат, пихаешь все это в строку - и вперед. Жесть полнейшая. Почему не пытались использовать партиционирование - непонятно совершенно. Хотя при таких объемах партиционирование может и не помочь, по всей видимости...

knudsenMikhail.Gurusov,

ничего не меняется... проходили много лет назад. Можно использовать нативные процедуры на языках PRG и/или C, логические файлы, OPNQRYFILE и т.д. - строишь программу, регистрируешь её как процедуру и вызываешь когда надо из SQL.
Я всегда считал, что нативные продукты работают быстрее, а SQL к AS/400 был прикручен где-то с версии 3.7 или 4.3, точно не помню. А 5250 - прекрасный инструмент без всякого "мышколожества". STRPDM и вперрррёд с песнями!

Мышколожество - какой интересный термин, однако... Под этим надо понимать GUI с тыканием мышой? Сам предпочитаю работать по максимуму с клавиатурой, безальтернативное использование мыши в некоторых случаях просто раздражает, и командной строки не чураюсь, начинал работать вообще под DOS, такие файлы пакетные рисовал, что щас наверное сам не повторил бы, и с Novell пришлось в свое время покувыркаться. Но нормальный редактор с GUI для меня все-таки предпочтительнее, чем терминал. Нет никакого желания переключать внимание с задач бизнеса на какую-то техническую хрень.

Еще умиляет ограничение на ширину кода в 80 символов в QSQLSRC. Хотя я и настраиваю форматер кода так, чтобы не было этих длинных хвостов, само по себе ограничение какое-то нелепое...

knudsenMikhail.GurusovЕще одна печаль - это вынужденное использование динамического SQL... Из-за огромного объема данных часть самых массивных таблиц периодические нарезается на отдельные куски, поквартально, или по году. В итоге заранее никогда не знаешь, где находится нужная тебе запись, по дате определяешь схему, в которой хранятся данные с периодом действия на определенный диапазон дат, пихаешь все это в строку - и вперед.

есть какая команда OVRDBF

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rbam6/ovrbf.htm?lang=en

очень частенько пользовался, только она CL-ная.

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

knudsen,

Скажите, пожалуйста, а с партиционированием иметь дела не приходилось? Есть какие-то противопоказания в данной СУБД, объем данных предельный, например?

noMAXMikhail.Gurusov, в IBM i 7.1 начиная с 26 уровня группы фиксов к DB2 можно вызывать CL команды прямо из SQL:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM i Technology Updates/page/QSYS2.QCMDEXC() procedure no longer requires a command length

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

knudsenMikhail.Gurusovknudsen,

Скажите, пожалуйста, а с партиционированием иметь дела не приходилось? Есть какие-то противопоказания в данной СУБД, объем данных предельный, например?

Сам не работал с партиционированными табличками на AS/400 (только LUW & z), это достаточно новая "фича" и вот документация -

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/db2/rbafzhctabl.htm?lang=en




Интересно было бы попробовать партиционирование. Может быть его и не использовали, если это относительно новая возможность.

А почему "фича" в кавычках?

PS Надо будет как-нить напроситься к коллегам в Teradata, посмотреть еще и на этого монстра.

Оказывается библиотека и схема - не одно и то же, как мне сказали.
Вот что нашел
http://www.ibm.com/developerworks/ibmi/library/i-sqlnaming/index.html?ca=dat
http://www.ibm.com/developerworks/ibmi/library/i-system_sql2/index.html?ca=drs#_Ref327694950

Сделал прототип процедуры с использованием OVRDBF, динамический SQL исключил, но наступил на другие грабли - план запроса убийственный, вместо индекса полное сканирование огромных таблиц... С динамическим SQL такой проблемы не наблюдается, запрос выполняется очень быстро... Охреневаю, дорогая редакция!

Mikhail.GurusovСделал прототип процедуры с использованием OVRDBF, динамический SQL исключил, но наступил на другие грабли - план запроса убийственный, вместо индекса полное сканирование огромных таблиц... С динамическим SQL такой проблемы не наблюдается, запрос выполняется очень быстро... Охреневаю, дорогая редакция!

Разница во времени выполнения катастрофическая, 2 мин против 3 сек! Держите меня 10 мужиков, как такое вообще возможно?!

knudsenknudsen,

OVRDBF , всё-таки лучше использовать для программ, а не для хранимок. Что такого в хранимой SQL процедуре, что нельзя сделать на язык ах С, CL, RPG (ILE) ? Ну если исключить скорость написания.

Если бы стояла задача обработки по одной записи - может быть имело бы смысл заморочиться с изучением этих языков. Но такой задачи не стоит, нужна обработка больших массивов данных, и лучше SQL для этого еще ничего не придумали, имхо. Все процедуры для существующих отчетов уже написаны на SQL, требование к новым отчетам - тоже только SQL, поскольку потом это кому-то придется сопровождать, а людей, даже просто знающих что такое CL и RPG - раз, два, и обчелся. Я сам впервые об этих языках услышал, да и времени на их изучение никто не даст - необходимо в срочном порядке решать прикладные задачи... Отчеты новые появляются каждую неделю, требования к уже реализованным могут меняться каждый день, глюки всевозможные и ошибки реализации вылезают ежедневно - в общем-то ничего нового, типичная тупая интеллектуальная долбежка.

Кстати C - классический процедурный С, правильно понимаю?

noMAXMikhail.Gurusovпропущено...


Разница во времени выполнения катастрофическая, 2 мин против 3 сек! Держите меня 10 мужиков, как такое вообще возможно?!

В IBM i наличествует два движка выполнения запросов. У вас, похоже, именно такой случай.
По следующей ссылке дается описание того, как можно рулить этими вариантами:

http://www-01.ibm.com/support/docview.wss?uid=nas8N1018857

noMAX,

да, очень похоже на то.

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

knudsenMikhail.Gurusov,

ну почему одна запись обрабатывается, и SQL-ку любую...




Drums - во множественном числе, очень символично))) Не просто бубен, а много бубнов!

knudsen,

Так понял что C в контексте данной системы какой-то свой язык. И для обработки массивов все равно использовать вкрапления SQL. Получается без вариантов - только SQL, пусть он и своеборазный в этой СУБД...

knudsenMikhail.Gurusov,

нет, не понял! вкрапления SQL не есть основная обработка, но можно и так. Вообщет-то всё от задачи зависит, вот я бы заполнял таблицу бы программой, а читал бы в BI уже SQLем и как можно более простым...

Возможно программирование на на SQL для данной платформы более эффективно с точки зрения скорости выполнения, использования системных ресурсов, и т.п. Но кроме как в рамках данной платформы эти знания больше нигде не применимы, а много ли таких систем используется в России? Мне кажется на пальцах можно пересчитать. Сколько времени потребуется, чтобы освоить эти чудо-языки и выдавать грамотный код? Так что, коллега, увольте)))

Здесь по сути такой же подход используется - заполняются временные сессионные таблицы, и возвращаются курсоры. Всю малину портит динамический SQL. Даже нединамический код написан так, что озвереешь, пока разберешься - многоэтажные неформатированные конструкции. Вчера долбил целый день элементарнейший отчет: после изменения структуры данных были внесены коррективы в код, потом после серии манипуляций с переносом со среды на среду на тестовой оказался старый код, перенесли новый код со среды разработки - он отработал, но выдал совершеннейший бред, опечалив тестеров... Открыл текст процедуры - два предварительных шага по заполнению временных таблиц (которые при внимательном рассмотрении просятся схлопнуться в один), и финальный запрос, возвращающий данные. Отчет примитивнейший, но в коде столько наворочено, что мама не горюй... Предварительные шаги переписал, есть подозрение, что финальный запрос тоже бредовый, на разные даты выдает одни и те же значения, а этот финальный запрос - столь нелюбимый мной и совершенно неоправданный в задачах по построению отчетности динамический SQL - сегодняшний день будет посвящен разгребанию этой помойки...

knudsenMikhail.Gurusov,

Вы не любите кошек? Вы просто не умеете их готовить!

всё-таки свалились в религиозные споры... печалька... а по поводу невостребованности - даже сейчас открыты вакансии на iSeries в 3-х конторах, как минимум, но конечно всего таких организаций маловато (даже очень) и это уже в других ветках форума...

Помилуйте, какие могут быть религиозные споры? Прекрасная система, то, как она перемалывает огромные массивы информации, достойно всяческого уважения. Но специфична она - этот факт отрицать невозможно. И рынок труда тоже хочешь не хочешь, а приходится учитывать, если вакансий по тому же Ораклу - более чем достаточно, то IBM - раз два и обчелся.

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

Serg0Его создала операционка, во время исполнения команды компиляции с опцией DEBUG(*SOURCE)
Классно, осталось понять, какой инструмент эту команду выдал - Data Studio или Rational Developer fot i...

Всем доброго времени суток :)

Я еще жив, как ни странно. Продолжаю воевать с DB2 for System i, и натолкнулся на одну загадочную граблю: строишь запрос, проверяешь его на корректность работы, добиваешься приемлемой производительности, смотришь на план запроса - все прекрасно, используются индексы, выборка по огромной таблице проходит за считанные секунды. Затем тот же запрос переезжает в хранимую процедуру, и при прочих равных с теми же параметрами он начинает нещадно тупить, и в плане запроса появляется полное сканирование таблицы...