Начинается старая песня о главном - что в жизни не случилось, какие-то дятлы виноваты :-)

Эти дятлы переворотили весь IBM в поисках человека, который поможет перевести это на true-мэйнфреймовое решение. Пригнали даже архитектора из Китая и отправили БПЦ на курсы CICS в Сингапур. Единственным выводом из всего было - для переписывания решения потребуется пара человеко-лет. Кто будет платить. Но мы-то знаем, что именно ты мог спасти мир, просто был чем-то очень важным занят. Борщ ел?)

Интересно, действитиельно, меня никто не информировал и к проекту не привлекал. К чему бы это?
А что в жизни то не случилось? А то я может не знаю.
А дятлы привлекли "специалистов" из китая, кторые почему-то три месяца hello word не могли написать. А может не хотели.
Так что бурная имитация кипучей деятельности дятлов никакого отношения к делу не имела. И не стоило имитировать кипучую деятельность пол года.
Достаточно было спросить нормального технаря, во что выльется переписывание 50 MB кода на С с posix на монитор транзакций.
И всё!
Всех делов, один вопрос, хотя бы мне.
Но нет, пол года сношания мозгов, проведения совещаний, командировок, и надувания щёк, чтобы выяснить - да, блин, сами с наскока не можем, этому учиться надо, ИБМ за это не заплатит, а деньги на проект уже ушли, и уже вообще никто не заплатит.
А ведь все данные были известны, технарь со стороны БПЦ был, архииектуру описал толково.
Факт тестирования на HP non-stop был, результаты ивестны, устройство этого чуда описано, сколько времени на это чудо портировали - тоже известно (оно куда проще портировать на non-stop чем на z/OS). Куда улучшать там - тоже понятно, при необходимости могут сильно улучшить.
А тут ИБМ все в белом, д'Артаньяны, с 12 транзакциями в секунду!
А предложение написать MQ "Light" for SYSPLEX? Во!
Это какой размах, какая ширь и глубь! До какой степени надо ничего не понимать!
Не, ну чо, првильно, только совещания и командировки, в такой ситуации помогут избежать ответсвенности, по-другому никак.

> Интересно, действитиельно, меня никто не информировал

Откуда же ты столько знаешь, если тебя никто не информировал? Кажется ты как всегда обманываешь Все уже привыкли, не переживай

> А что в жизни то не случилось? А то я может не знаю.

Потому что не все наши прекрасные инициативы закончились победой. Так бывает в жизни когда много работаешь. Зато мы получили бесценный опыт. Пойдёшь в этом месяце зарплату получать и не забудь сказать "спасибо вам ребята, благодаря вашим стараниям мне есть на что жить" ;-)

> Достаточно было спросить нормального технаря, во что выльется переписывание 50 MB кода на С с posix на монитор транзакций.

Мы именно его и искали в Китае (и не только), где монитор транзакций популярен. Мы также подключали нашу лабу, результат как всегда: IMS - наше всё и все исчезли.

> А ведь все данные были известны, технарь со стороны БПЦ был, архииектуру описал толково.

И? Что это значит? Отменяет два человеко-года работы по переписыванию? Отменяет серьёзное изменение архитектуры, за которое БПЦ не готово было браться? Нашлись деньги, которые никто не был готов платить? Создаёт бизнес-кейс как БПЦ заработает на нерастущей платформе?

> оно куда проще портировать на non-stop чем на z/OS

Спасибо, кэп! Теперь ты понимаешь почему в Китае искали помощь? Такую важную информацию даже я мог выдать.

> Это какой размах, какая ширь и глубь! До какой степени надо ничего не понимать!

Ну раз ты всё понимаешь, хотя я честно говоря так и не понял твоего конкретного предложения, набери Женю Распопина, который нынче работает в БПЦ, и расскажи ему все свои идеи. Контакты возьми у твоего коллеги "на пол-ставки".

> Не, ну чо, првильно, только совещания и командировки, в такой ситуации помогут избежать ответсвенности, по-другому никак

Тебе, бездельник, столько лет зарплату просто так платили, так что на командировки уж точно никто не разорился, не переживай

Ок, по итогу, за всей словесной шелухой - пустота.
Ничего ведь нету, кроме растраты разных бюджетов.
Просто цель надо ставить не продать, а сделать.
Покупка чего бы то ни было не решает ни одной проблемы.
И действительно, откуда же я столько знаю, не учавствуя в проекте?
Так сами БПЦ же про ИБМ и рассказывали
А благодарить мне тебя не за что, за вредительство не благодарят.

У тебя опять нечего по делу сказать? Предложений по БПЦ нет? Почему я не удивлён? Ах, да, потому что критиковать других - единственное что ты умеешь в этой жизни. Ещё я про потраченные бюджеты не слышал твоих фантазий, расскажи давай что я ещё не так делал пока ты сапоги чистил и борщик ел

Предложений по БПЦ ?
Легко.
Ничего не делать.
Отлично работающее Unix приложение, максимально использующе Posix.
State-less.
Типичный маршрутизатор.
z/OS для такогро приложения - маразм.
Что ты делал не правильно? Так а что ты делал, кроме вредительства?

Это твой список достижений за последний десяток лет можно уложить в одну фразу "ничего не делать", а наших рассказов на увесистую книжку хватит

История с БПЦ была очень важной, потому что карточный процессинг - приложение, которое по своей природе должно быть популярно на мэйнфрейме (большая транзакционная нагрузка, требования к надежности, безопасности), но почему-то в мире количество инсталляций не больше десятка.

HP съел весь наш хлеб из-за таких лодырей как ты, которые всё прозевали и хотели ничего не делать. В итоге нет ни одного современного карточного софта, кроме ACI, который бы работал на мэйнфрейме. И мы старались это исправить, для всего мира, не только для России. Мы не "тратили зря бюджеты", а убеждали нашу компанию инвестировать в обучение БПЦ, чтобы показать всю мощь и преимущества нативных средств z/OS. Не боялись брать на себя ответственность за эти средства и делали всё на благо развития платформы.

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

Ага, всё верно, только там транзакций нету, в приложении.
Оно не транзакционное.
Чистый маршрутизатор - куда отправить транзакцию на обработку.
Этому приложению мейнфрейм не нужен.
А остальное - пусть будет.
Ну что же, пусть я не талантливый трудолюбивый инженер
Не продавец, и то слава Б-гу

Да, нашёл свои С-шные исходники с начала 2000 года, тоже чистый POSIX, multithreding, телекомовский билинг, всего то 286 килобайт, но как представлю, что это переписать под IMS TM.... Это куча работы, и во многих местах мейнфреймовской - тот же cross memory.
Это всего 386 килобайт! А не 50 мегабайт!

50 Мб правил маршрутизирования

Главное что у тебя есть в команде кому работать, пока ты тут лясы точишь с продавцами. А то прошлый раз когда ты пытался что-то сам сделать - до установки IMS даже дело толком не дошло, кругом сплошные вредители))))

Сегодня праздник.
А про установку IMS гонишь
Повторяю для дятла-продавца, раз с первого раа непонятно - я не ставил, а переносил, с одной версии adcd, на другую. Отлично перенеслось в рамках z/OS ветки 1, и абсолютно не переносится ничего с ветки 2 на ветку 1, по понятным причинам.
А вообще-то я не системщик, а прикладник.
Хотя, последний год много пришлось системой заниматься - некому больше было.
Не надоело?
Приезжай к нам, посмотри, и выскажи всё
Слао?

Не слабо, я бы уже собрался и приехал, не смотря на праздник. Но я в Нью-Йорке живу. У нас в юнисе много инженеров, кому наверняка будет интересно, можно организовать обмен опытом. Они заодно расскажут как, наверное, единственные в России CICS поддерживают 24x7.

Не, юникс - уже не интересно.
Вообще-то, всё правильно, там тебе и место.

Спасибо, а то я всё ищу своё место и наконец-то ценный совет!

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

Это вряд ли - я лапшу на уши не воспринимаю

Вредительством как раз ты занимался все эти годы. Еще ты бегал жаловаться к руководству неся полную чушь. Благо тебя никто всерьез не воспринимал. За годы ты сделал ровным счетом ничего. Вся твоя беготня с ИМС кончилась ничем, потому что дальше разговоров у тебя никогда ничего не шло. Хватит брюзжать тут, иди пили что ты там должен пилить на работе. Хотя я с трудом верю в то, что ты что-то полезное делаешь.

Ни хрена не понимаю.
Что это за хрень?
Но по факту, я уже сделал, что должен.
Команда создана, обучена, архитектура разработана, структуры баз созданы, приложения написаны, тестовые скрипты нагрузки отрабатываются, образец клиентского приложения сделан, протокол обмена между клиентским приложением и серверными транзакциями создаётся.
Всё равно не понял, что это за хрен была.
Сдаётся мне, что это как раз тот человек, кто тестировал в Монтпелье текущую архитектуру клиента.
Тот, кто меня поучал, что главное в производительности СУБД - это архитектура клиентского приложения.
Так что очевидно же, что перед нагрузочным тестированием он убедился в правильности архитектуры приложения.
Я угадал?
Думаю, да.
Ну что ещё высрем?

А значит ты после того как тебя выперли все осознал и стал реально работать? Ты еще скажи, что ты все это сделал с использованием IMS и скоро все это будет внедрено в продуктив? Чесать тут языком легко, а проверить что ты там реально навоял сложнее. Может быть там работы было на пару недель… А то мы по твоим достижениям в ИБМ имеем хорошее представление о том, что ты можешь.

А как проверять будем?
На текущий момент имеем факты - у приложения, кторое ты тестировал, зачастую время ответа на запрос бесконечно.
Ну как бесконечно. Клиент ждём часа два и звонит с просьбой убить сессию (на клиенте не сделали кнопки самоубиться).
У приложения, кторое сделала наша команда, достатточно тяжёлый случай - поиск с regexp(), который возвращает чть больше ста тысяч записей - отрабатывает порядка минуты. И то большая часть времени тратется на IPC в USS. Сейчас идёт переделка на cross memory services.
И таки да, это сделано всё в IMS, данные в IMS DB, транзакции в IMS TM.
нагрузка в скриптах WSIM.
Клиентское место пока на Java, но будет создаваться на .net.
Ещё вопросы?

Кстати, по поводу чесать языком. Ну, могу ИБМеров пригласить, того же Егорова, или Солодкова, им продемонстрировать. С командой познакомить. Команда расскажет и покажет, как работает твоя реализация, которую ты тестировал, и конечно же, убедился, что архитектура соответсвует, ты же меня этому "учил", и ты "ответственный". И покажет, как работает наша реализация, которую придумал я бестолковый и бесталанный, неответственный, ну или как там ещё.

Зашуршали авторитетные фамилии.. Пора бы уже про Кирилла Геннадиевича вставить фразочку, чтобы все испугались

Ну хорошо, пусть не эти авторитетные фамилии.
Пусть другие, пусть не такие авторитетные.
Мне скрывать нечего.
Что сделано, как сделано, какие результаты.
Так что могут придти и посмотреть.

Я к тому, что трудно скрыть то, над чем работает десяток человек, и за чем наблюдают с прол сотни человек.
Так что "чесать языком" не получится - опровергнут моментально.
Но я готов на большее - готов поделится результатами и архитектурой.
В принципе, подобная реализация возможна и даже существует на ADABAS.
И даже ручной работы меньше, за счёт использования готового решения.
Но оно более универсальное.
В этом плане IMS можно сравнить с вагоном стройматериалов. Есть кирпичи, цемент, песок, доски, гвозди, и можно построить всё, что угодно, и если руки не из задницы растут, то результат может быть отличным.
И наше решение не столь универсальное, а сильно заточены на реалии заказчика, его процессов.
Хотя базовые алгоритмы, принципы, одинаковы, детали реализации сильно отличаются.
И получается классическое противостояние - универсальное решение против узкоспециализированного.
Это про ADABAS vs IMS, если что.
Решение на DB2 вообще самое неудачное, что можно было бы придумать.

Наш системщик вот раскопал, что у windows тоже есть свой cross memory services
http://resources.infosecinstitute.com/using-c....windows

Несколько раз имел планы на USS, и даже делал маленький пилотничек. Для себя понял - если есть возможность избежать работы с этим наростом в zOS, то лучше избегать. Во-первых, медленно. Причем в разных версиях то один механизм ускорят, то другой, зато что-то иное работает медленно. Например, в 1.7 ftp медленно устанавливал соединение, в 1.13 его сделали быстрее, но наборы данных открываются медленнее, чем в 1.13 (именно юниксовые наборы, то есть те, которые файлы).
Файловая система тоже капризная и медленная.
Вообще все эти POSIX-нашлепки оставляют впечатление искусственности. В свое время еще в Windows NT была своя native-POSIX среда, и что? Разве использование ее было массовым и удачным? Так она, похоже, внутри Windows и умерла, не развившись. В zOS немного живее, но тоже как-то костыльно все происходит, и ощущение сырости не оставляет меня все это время. Видимо, Юникс-среды слишком быстро эволюционируют, и производители не успевают за их качественным развитием и не могут органично и надежно встраивать их в такие консервативные системы, как MVS-подобные ОС.
Мне вот подход товарища AKonev нравится - использовать родные механизмы межпространственных коммуникаций. Их же в MVS - что дров в Карелии, и многим из них лет по 20-30, они еще из OS/VS переходят...

Надо все-таки отдать должное IBM-ерам, ZFS-файловая система в нынешней жизни работает гораздо лучше чем раньше. Уже в 1.13 появилось много  болтиков, которые можно покрутить и ввод/вывод начинает работать гораздо лучше. Про HFS надо просто забыть, если вы еще там, то надо немедленно мигрировать на zfs. А что касается карельских дров, действительно жизнь в межадресном пространстве не стояла на месте, к програмколлу (PC) сначала альтернативой было асинхронное планирование программы ( SRB ) , а теперь мало что SRB переписали и упростили, так их разновидностей стало не пересчитать...

кстати, опция PLO2 (реализующий Perform Locked Operation) к вызову msgget() (который создаёт очередь) резко, ну очень резко ускоряет процесс.
Завтра протестируем.

Давным-давно, в том числе и с моим участием, был реализован обмен информацией между двумя адресными пространствами через POST/WAIT. Сам буфер обмена находился в общей области. Размер буфера был не сильно важным, так как обмен шел порциями. Механизм оказался настолько жизнеспособным, что почти без изменений функционирует до сих пор. Разумеется писалось на ASM-е, нулевой ключ защиты, несколько макро и никаких накладных расходов типа LE. А для прикладных программистов это свелось к вызову некой программы с указанием параметров кому и сколько байт. Так вот еще в OS/390, я делал тест по вызову этой программы из-под USS (тогда еще OE) и каких-либо задержек в работе замечено не было.
А по поводу компилятора, вряд ли будет эффект, так как проблема спрятана не ваших кодах. а в упомянутом kernel и sys/msg, я также подозреваю, что все осталось неизмененным.

С удовольствием бы переняли опыт в любом виде, 
Перед этим нашим опытом я предложил сразу делать обмен через CSA, ассемблерщики есть, но в виду желания быстро реализовать функционал, попробовали вот... как попробовали.
Если в недрим - то у нас это тоже на десятилетия.