Тут подход простой: если нормально работает, то ничего не трогать. Если не работает... то хотелось бы сначала услышать, в чем возникла проблема :)
P.S. Вот только не AS/400. iSeries - это, конечно, круто... но это единственное ее достоинство. ТСО будет намного выше по сравнению с аналогичной по производительности и надежности x86-системой.

FantasmoПроблемы самые стандартные- падение производительности, невозможность нормально поддерживать существующие системы в виду закрытого ядра и более того одна из систем вообще уже динозавр, сложности с интеграцией.
Ясно... Вообще, написание учетной системы - дело неблагодарное. Я бы все-таки всерьез подумал о приобретении готовой, вполне вероятно, это будет дешевле, с учетом времени и ресурсов на разработку.
А так, сперва надо определиться, специалисты по каким СУБД есть в штате. Если DB2шник уже есть, можно остановиться на DB2. Если никого нет, тогда я бы рекомендовал MS SQL или Oracle. Все-таки найти толкового специалиста по этим СУБД будет проще. С Sybase ASE связываться не советую. Во-первых, у нее периодически обнаруживаются неприятные "фичи", во-вторых, мутная ценовая политика. То, что входит в цену коробки MS SQL, тут зачастую идет отдельными опциями, и к тому же подход к формированию цен у Sybase слегка индивидуальный :)

FantasmoИ вот еще, стоит ли вообще связываться с риск серверами? или остановиться на обычных? Например сделать поддержку кластеризации, если что довоткнуть)))

Кластеризация прекрасно поддерживается и СУБД для х86. Лично я против risc-систем, особенно если речь идет о inhouse-разработке. Вы постоянно будете сталкиваться с особенностями или ограничениями незнакомой вам платформы, которые вы легко обошли бы в случае с х86.

FantasmoИ подходит ли AS/400 под аналитическую базу. У нас входящий поток не маленький, но не постоянный. В основном аналитическая отчетность и хранение.
Если речь идет об аналитике, я бы серьезно посмотрел в сторону Sybase IQ. Нельзя ставить вопрос "справится ли MS SQL с большими нагрузками". Конечно же, справится, как и любая другая СУБД. Вопрос в том, за какое время и сколько ему потребуется памяти и места под TempDB :) А чтобы ответить на этот вопрос, нужно знать, какие объемы данных, какие запросы (и как они спроектированы), и как часто, и какое предполагается железо (если в этом плане есть ограничения).

FantasmoС Sybase не очень хотелось бы работать... странно у них все)))
А Oracle разве не подходит для этого? Мне кажется еще как.
Это СУБД разного класса. Oracle, как и MS SQL, и DB2, и Sybase ASE - это оперативные СУБД. Они универсальны. Sybase IQ - аналитическая СУБД. Она намного медленнее осуществляет вставку/обновление данных (и, строго говоря, вообще для этого не предназначена, данные в нее лучше загружать через bulk load, допустим, раз в день), зато намного быстрее выполняет выборки данных. Она не заменяет оперативную БД, а дополняет ее в части отчетности и OLAP. Какую из перечисленных оперативных БД выбрать, не так уж важно. Они одинаково универсальны и одинаково справятся с задачей. Я бы согласился с Dimitry Sibiryakov, наличие в штате специалистов по DB2 - это уже серьезный довод в ее пользу.

FantasmoЛогично. Но! Использовать AS-ку или обычную DB2 под x86
А что планируется получить от ASки? Использовать ее тупо как хранилище данных? Или писать на ней и софт? И как тогда писать, на Java (просто на Java иль WebSphere на нее взгромоздить?) или может на RPG? ;-)
Если вы совершенно четко не представляете, зачем вам нужна iSeries, выбор простой: не брать iSeries. Кроме того, надо иметь в виду, что DB2 для iSeries всегда на одну-две версии отстает от DB2 для х86. А еще нужно знать, что SQL у iSeries - неродная приблуда, и на ней хранимые процедуры на SQL работают значительно медленнее, чем APIшная работа с СУБД, так что вам придется или переучивать разработчиков или мириться с низкой производительностью

kordaХотелоь бы заметить, что AS/400 - это не только СУБД , но и железо с операционной системой, специально разработанные для поддержки этой СУБД, и специализированные языки программирования для работы с БД и построения отчётов.

Кролики - это не только ценный мех, но и два-три килограмма диетического, легкоусваиваемого мяса :)

FantasmoА вообще на какой класс задач расчитана AS/400 как чаще всего используется, на что ориентированна. Как транзакционная система или как система аналитической отчетности и хранения?

Как транзакционная. Чаще всего... сейчас - скорее для развития тех систем, которые были построены в то время, когда у AS/400 в своем классе не было конкурентов по надежности. Строить что-то с нуля на AS/400 нынче неэффективно. По ТСО она не конкурент аналогичным по производительности и надежности х86

FantasmoНет не тупо. Реализовать на ней учетно аналитическую систему+ налабать ядро с системой быстрой разработки, администрированием, жарналированием, безопасностью итд. Ну вообщем все по взрослому))))
А какими средствами хотите это сделать? И какую архитектуру собираетесь использовать? Толстые клиенты, тонкие 5250, тонкие JSP? Или что-то еще?

kordaМне нравится документация к AS400, написанная простым понятным языком, все команды, API тоже описаны стандартным образом, так что изучив что-то одно, легко перейти к следующему. Интерфейс самих команд, меню и прочего - тоже единый стандарт. С точки зрения интерфейса пользователя, если следовать этим стандартам, то и ваша собственная разработка и документация будут легче приниматься пользователем. Общался с людьми, много лет работавшими на этой платформе, - никаких зависаний, stack overflow, memory protection error и прочего там не наблюдали чуть ли не с 60-х годов. Считается, что вирусы на этой платформе не возможны в принципе, благодаря архитектуре. Если есть какие-нибудь достоверные данные, говорящие в пользу того, что AS400 уступает другим платформам в плане безопаности, поддержки современных стандартов, стоимости владения, надежности хранения и обработки данных - хотелось бы взглянуть.
В плане безопасности, поддержки современных стандартов, надежности хранения и обработки данных - не уступает. В плане стоимости владения - достоверных данных нет, только реклама. Зато есть опыт в моей организации. Стоимость владения значительно выше. IBM в своих выкладках расписывает количество часов работы админа AS/400 и админа Unix/Windows, умножает на зарплату. У AS/400 получается меньше. Только при этом нигде не считается, что "5 человеко-часов в месяц" - это на самом деле 840 человеко-часов, т.к. брать человека все равно будешь не на 1% ставки, а на полную. И с сооветствующей зарплатой.
А главное в ТСО даже не стоимость обслуживания. Как бы крута не была твоя AS/400, все равно через два-три, ну пусть четыре года ее надо будет модернизировать. Проблема в том, что планка памяти для нее (которая от обычной ECC DDR отличается дырочкой в другом месте и логотипом IBM) стоит сравнимо с потрохами небольшого интеловского сервера...
Ее беда в том, что x86-системы в последнее время сильно прибавили в надежности. А виртуализация позволила значительно снизить время на обслуживание. По поводу API и "людей, много лет работавших на этой платформе" - не следует еще и про продуктивность работы забывать. Эти самые люди кропали софт в SEU (с продуктивностью чуть выше ассемблерщика!) в то время, как на PC уже были RAD-системы. Насколько им можно доверять, ведь они, скорее всего, имели опыта работы на конкурирующих платформах?

korda,

Уфф... А где сейчас можно найти достаточное для разработки количество COBOL-спецов? И почём? И что будет, если другая, более богатая контора одного-двух из них перекупит на середине проекта? А переучить всю контору работать на 5250-терминалах (даже если в чем-то оно и удобнее... хотя это тоже субъективно), в то время как современные девочки/мальчики в жизни ничего кроме WindowsXP/Vista не видели - это вообще кошмар. И не факт, что руководитель проекта его переживет. ИМХО, эти риски достаточны, чтобы связываться с такой "необычной" системой.
Уже много раз убеждался и на своем, и на чужом опыте: самая правильная технология - это та, которая наиболее широко распространена. Даже если у нее есть недостатки, всегда находится и адекватное решение. А AS/400 к массово распространенным платформам, увы, не принадлежит.

korda,

Опытных JAVA-спецов на порядок больше, разве не так? А COBOL'овцев даже бестолковых найти очень сложно, при этом они прекрасно знают свою уникальность, и ломят соответствующую цену.

Что сейчас наиболее распространено, и что будет распространено в ближайшем будущем - тоже вполне очевидно. Java, .NET, Win32, POSIX. Каких-либо предпосылок для изменения состава этой команды не наблюдается.

Что касается распространенности AS/400 - увы, мы живем именно в странах бывшего СССР :)

JErikКак вариант можно рассмотреть FVMas со встроенным форматом TJ7. встроенный функционал для организации аутентификации и шифрования...

Вот первая свежая мысль. А еще лучше - съесть грибочков и поставить его на AS/400 О_о

FantasmoЕще два вопроса:)
1)А под AS400 вообще можно нормальный клиентский интерфейс сделать, использовать терминальное решение с черным экраном-это жесть, хотя может быть и кому-то удобно.
2) Может кто-нибудь привести небольшой список крупных проектов реализованных на Oracle, MS Sql (то что их много я не сомневаюсь). Интересно названия организаций))).

1. Можно сделать веб-интерфейс, благо, фреймворков сейчас для этого полно. Даже для "черных (или зеленых) экранов" IBM придумала приблудку, которая по дисплейным файлам генерирует jsp-морду... правда, работает не всегда удачно... как, впрочем, и большинство других java-творений IBM :)
Плюс, толстые клиенты тоже никто не отменял.

2. Это тебе начальству надо обосновалку подготовить? Я бы на твоем месте погуглил :)