День добрый!

Уважаемые гуру, подскажите пожалуйста, как можно из 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... Из-за огромного объема данных часть самых массивных таблиц периодические нарезается на отдельные куски, поквартально, или по году. В итоге заранее никогда не знаешь, где находится нужная тебе запись, по дате определяешь схему, в которой хранятся данные с периодом действия на определенный диапазон дат, пихаешь все это в строку - и вперед. Жесть полнейшая. Почему не пытались использовать партиционирование - непонятно совершенно. Хотя при таких объемах партиционирование может и не помочь, по всей видимости...